Planning. Most people loathe planning. They would rather jump right into a project. But jumping into something new without a sound strategy or plan often results in a poor implementation, a solution that doesn't exactly solve the problem, or a project that cannot be completed on time because some information was unavailable. To avoid this situation, I encourage you to take time and plan your single sign-on architecture and implementation strategies.

What's Required

First, let's look at the software requirements for a single sign-on implementation.

1. A Kerberos server--Users are going to have to authenticate to a Kerberos server. If users are logging on to a Windows 2000 or Windows 2003 server running Active Directory, you are already using Kerberos for authentication. In this case, this Kerberos server will probably be the easiest one for you to use. If you are not running in a Windows network or are running Windows NT, you have to find or configure another Kerberos server. Kerberos servers are available for AIX as well as Linux, and the Kerberos server available in i5/OS V5R3 runs in the PACE environment.

2. System release level--All iSeries systems that will participate in your single sign-on architecture must be running V5R2 or later and have the following products installed:

• 5722SS1 - Option 12 - Host servers
• 5722SS1 - Option 30 - Qshell Interpreter
• 5722AC3 - Crypto Access Provider

3. Client software

• Windows XP/2000/2003--Earlier clients are not Kerberos-enabled.
• iSeries Access for Windows V5R2 or later
• iSeries Navigator, particularly the Security and Network components (Note: This is only required for the client from which EIM and Kerberos will be configured.)

Network Information

To configure Network Authentication Services (NAS) in OS/400, you will have to know some information about your network. Therefore, you may have to enlist the help of your network administrator. I'm certain that most of you will first attempt this on your own! But when you launch the NAS wizard out of iSeries Navigator and start scratching your head over some of the questions, I highly recommend that you ask for help rather than guess at the answers. Guessing will likely lead to frustration. The types of information you will need to know about the Kerberos server include the fully qualified host name of the Key Distribution Center (KDC) and the port on which the KDC listens. You may also need information about the DNS server. Also, be sure there is time synchronization between your iSeries systems and the system on which the Kerberos server runs. Kerberos requires that system clocks be set within a specific tolerance--five minutes is the default. This means that the OS/400 system clock can run five minutes faster or slower than the Kerberos server’s system clock.

Planning Your EIM Configuration

Now that you've thought about Kerberos, you need to think about EIM enablement and configuration. For instance, which systems are going to participate in single sign-on? And which system is going to host your EIM configuration? The host system is the "EIM domain controller" (similar to Microsoft's concept of a domain). The EIM domain controller contains your EIM configuration--that is, the other operating systems and applications participating in single sign-on. These systems and applications will look to the EIM domain controller when determining what user ID to use for authorization on their particular system or in their application. EIM is implemented using LDAP, so whatever system you choose must have the LDAP server running.

When choosing your EIM domain controller, consider system availability. The system needs to be available to facilitate user sign-on, so you don't want to choose a system that may be down when users are trying to sign on (like a development or test system).

You also must plan your EIM naming conventions--specifically, the identity and registry naming conventions. Remember that registries may include application names, not just system names, and that the identities may not always be associated with people. They may be associated with printers, for example. Choose a naming convention that is expandable for future uses of EIM.

Which Users?

One of the tremendous benefits of configuring single sign-on for OS/400 is that passwords are no longer required for end-users or application profiles, such as those used for ODBC connections. In Part 1 of this article, I explained that passwords are used for authentication. Once Kerberos is performing the authentication, passwords are no longer required. Imagine: Users would no longer have to type in their passwords multiple times or change them in multiple places! And you can stop users from disabling their profiles when they can't remember their passwords! Therefore, decide whether you want to remove users' passwords – in other words, set the profiles' password parameter to *NONE. At first, you may think you should eliminate passwords for all users, but you will likely determine that certain users should continue to have passwords. (In fact, you may choose not to have all users participate in single sign-on.) Take, for example, your help desk, tech services, operators, or on-call personnel. It's possible that they may have to sign on to an emulation session (such as at the system console) without first signing on to the network. Or remote users may enter your network through another means, such as a Web interface. If they do not first sign on to the network, they won't have a Kerberos TGT to request a Kerberos ST, and they will not get authenticated. To ensure these types of users can always be authenticated, these users' profiles should retain their passwords.

Now, let's discuss why you might not want all users to participate in single sign-on. Consider this: A user signs on to the network, launches all desktop applications, and then leaves the workstation unattended. Anyone can come along and perform operations as the original user. Now, consider the single sign-on scenario: A user signs on to the network and walks away from the workstation. Again, anyone can walk up to that workstation and run all of the single sign-on-enabled applications as the original user. But because some organizations are justifiably uncomfortable with this scenario, they have implemented a Microsoft policy that times out the device and puts up a screen-saver that must be unlocked with the user's network password before the user can resume work. However, even with this protection mechanism, you may choose not to enable single sign-on for your powerful users, instead requiring them to provide a user ID and password for all systems accessed. This way, users attempting to exploit another user's authority must provide a valid user ID and password combination. Of course, if a powerful user signs on and then leaves the workstation unattended, authority can be exploited just as in the single sign-on case.

What Applications or Services?

Kerberos authentication is not an all-or-nothing proposition. You can pick and choose which clients will use Kerberos for authentication. For example, you can configure all of the clients in the Payroll department to use Kerberos for authentication, and you can configure Sally's client to only use Kerberos for Telnet. The services that will accept a Kerberos ST include iSeries Access for Windows, JDBC, ODBC, Telnet, NetServer, QFileSvr.400, DRDA, and the Apache Web server.

Availability Considerations

When planning, include the possibility that pieces of the single sign-on puzzle could fail and prevent users from signing on. Consider some of the failure points:

• Kerberos server--To prevent the Kerberos server from being a single point of failure, establish cross-realm trusts between your primary Kerberos server and another Kerberos server in your network. In case of a failure of the primary Kerberos server, users would sign on to the alternate domain running the trusted Kerberos server rather than their normal domain. If you're signing on to a Windows network today, you should already be making this consideration.
• EIM domain controller--EIM is implemented using LDAP. To provide redundancy of your EIM configuration, you can use LDAP's replication facilities to replicate the configuration to another system.
• Password *NONE--What if the Kerberos server is down and no cross-realm trust has been established, or the Kerberos server is working but the system configured as your EIM domain controller ran out of storage, crashed, and hasn't yet recovered? Since users no longer have a password, they cannot sign on to OS/400 even though they can get to the sign-on screen for the system they need to do work on. For this case, you have at least two options. You may want to purchase or write an application that automates resetting users' passwords based on their correctly answering several user-unique questions. If some part of the single sign-on infrastructure is not available, you can enable the application, and users can use this reset application to get their passwords. Another solution is to write a CL program that "temporarily" assigns a password to users. Of course, this CL program will require some planning. Obviously, you will not want to blindly give all profiles a password because not all profiles should have a password (group profiles, most IBM-supplied profiles, etc.). I suggest that you give a password to all "active" users, where "active" is defined as users who have signed on in the last week. (The profile's last sign-on date is updated when authenticating with a Kerberos ticket, so you could look at that date to make this determination.) I also recommend that you refrain from setting the password to be a default password (where the password is the same as the profile name) or giving the same password to all users. You also have to determine a secure method for communicating the temporary password to each user. Finally, keep track of the profiles to which you've assigned a password and set those passwords back to *NONE when everything's back in working order.

Getting Started

Once you've completed your planning, you may be tempted to immediately configure single sign-on for all participating users. Since you can pick and choose which users participate in single sign-on (remember, single sign-on on OS/400 is not an all-or-nothing proposition), I encourage you to start with a small department to configure as a test group. Once you feel comfortable that things are working well for this set of users, you can confidently continue with the roll-out of your single sign-on strategy.

Carol Woodbury is co-founder of SkyView Partners, a firm specializing in security consulting, remediation services and security assessments, including the risk assessment product, SkyView Risk Assessor for OS/400. Carol has over 13 years in the security industry, 10 of those working for IBM's Enterprise Server Group as the AS/400 Security Architect and Chief Engineering Manager of Security Technology. Look for Carol's second book, Experts' Guide to OS/400 and i5/OS Security, now available at http://www.pentontech.com/education.

Carol can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..