Admin Alert: Getting Ready for Single Sign-On

April 27, 2005 Joe Hertvik

One of IBM‘s better i5/OS improvements was the V5R2 addition of single sign-on technology, where network users can access a Kerberos server to automatically authenticate and authorize themselves to sign on to i5/OS applications without entering an OS/400 user profile and password. By using single sign-on, a user can sign on once to a network server and automatically gain access to a wide variety of OS/400 applications, if their network is configured correctly.

At this spring’s COMMON, I attended a number of classes on configuring single sign-on on an i5/OS box, and–with the help of IBM documentation and several calls to IBM technical support–I succeeded in setting up a single sign-on environment that allows Windows network users to automatically sign-on to three i5/OS V5R3 partitions. Based on my experiences, this article is the first in a series describing how to configure single sign-on and how to avoid some of the pitfalls that will slow down your deployment. This issue, I’ll focus on how single sign-on works and the pre-requisites for a successful implementation. Future columns will describe some of the nuts and bolts configuration, testing, and deployment issues.

IBM’s i5/OS single sign-on technology consists of the following elements that are used to authenticate and authorize users to OS/400 applications without signing on:

A network authentication server that uses the Kerberos authentication protocol to authenticate and authorize users to a domain and to serve as a Key Distribution Center (KDC) for the users. The KDC dispatches tickets that authorize a network user to run applications on other servers (including i5/OS partitions) without signing on to those servers. Several different types of servers–including Microsoft Windows 2000 and 2003, IBM AIX, various Linuxes, and IBM i5/OS (since V5R3)–can act as a KDC, but the most common KDC platform is a Windows 2000 or Windows 2003 server running Microsoft’s Active Directory services. In fact, Windows 2000/2003 servers running Active Directory are already using the Kerberos protocol to authenticate Windows network users to other Windows servers in a domain, so it’s a natural fit to add your OS/400 V5R2 or V5R3 servers to a Windows domain for this purpose.
An i5 or iSeries box running OS/400 V5R2 or above that is configured to use the i5/OS version of Kerberos, which, due to legal issues, IBM has renamed to Network Authentication Services (NAS).
An Enterprise Identity Mapping (EIM) table that maps a network user’s Windows domain identity to specific user profiles for each i5/OS partition or application that they need to sign on to. The EIM table is maintained on an i5/OS partition, and accessed through a Lightweight Directory Access Protocol server (LDAP).
A Windows-based PC for running IBM’s iSeries Access software for configuring the i5/OS setups for NAS and EIM. This PC must be running Windows 2000 or above.
Client PCs that will be accessing i5/OS resources and applications without signing on. These Windows client machines must also be running Windows 2000 or above and have iSeries Access installed.

The exact mechanics of how OS/400 uses Kerberos, a KDC, NAS, and EIM to enable single sign-on are beyond the scope of this article, but IBM does a reasonable job of explaining this slightly complicated technology in its Windows-based single sign-on and the EIM Framework on the IBM eServer iSeries Server redbook (SG24-6975-00). If you’re interested in learning more about single sign-on and how to implement it in your network, I recommend using this book.

Before you can implement single sign-on, your network has to have the basic building blocks for running the technology. Here are the pre-requisite and pre-configuration elements you need to have in place to set up a single sign-on system to allow iSeries or i5 users in a Windows domain to automatically log on to i5/OS servers and applications.

An AS/400, iSeries, or i5 box running i5/OS V5R2 or above. All partitions that participate in single sign-on environment must also have the following licensed products installed:

Qshell Interpreter (Option 30)
Host Servers (Option 12)
Cryptographic Access Provider (5722-AC3)
iSeries Access for Windows (5722-XE1)
Up-to-date PTFs for each partition using single sign-on to provide the latest fixes.

All partitions must be configured for TCP/IP access.

A Windows 2000/XP client running iSeries Access for Windows version V5R2M0 or higher for configuring NAS and an EIM table for single sign-on. This PC must also have iSeries Navigation installed, and iSeries Navigator must have the Network and Security components installed. In speeches at Spring COMMON, IBM’s single sign-on experts recommended that you download iSeries Access V5R3 with the latest service pack to insure that you have the most recent fixes.

A Windows 2000/2003 KDC server that supports Kerberos Version 5. For many shops, you can use an existing Windows 2000 or Windows 2003 server with Active Directory enabled. If you don’t have a suitable Windows domain set up, you could also use any existing KDC that supports Kerberos Version 5, including i5/OS. For our purposes, I’m assuming we’re using a Windows domain. The Windows KDC server must also have the Ktpass.exe utility installed, which allows you to configure a non-Windows Kerberos service to function as a server security principal (which authorizes users to sign on to other servers) in a Windows 2000/2003 domain. If you cannot find the Ktpass.exe program on your Windows server, you may have to load it from Microsoft’s installation diskettes, as it may not have been installed as a standard feature.

Several Windows 2000 and above PCs that will use the single sign-on configuration to bypass i5/OS sign-on procedures. IBM’s single sign-on technology does not work with Windows 9X or Windows NT technology; it is only supported on the newer technology.

Synchronized server and client time of day properties. Single sign-on works only when all the participating servers and associated clients are time-synchronized to within five minutes of each other. According to IBM, single sign-on may fail if server and client time synchronization is off. i5/OS can be configured to serve as either a Simple Network Time Protocol server (SNTP) or client in order to keep its time synchronized with its associated KDC and EIM servers, as well as Windows clients requesting single sign-on processing.

“Clean” DNS resolution between the requesting client PC and the i5/OS box that the PC is requesting automated sign-on for. As referenced by IBM resources and through my own testing, proper DNS resolution is critical for allowing client PCs to access i5/OS services without specifying a user profile and password. In order for single sign-on to work, the client PC must be able to access its target i5/OS server by using the fully qualified host name of that server. Here’s the drill for checking and correcting your i5/OS DNS setup across the network before you start configuring single sign-on.

1. Determine the fully qualified host name of each i5/OS partition you want to configure single sign-on for. To do this through the green-screen, type in the Change TCP/IP Domain command (CHGTCPDMN) and press the F4 key to view your system’s parameters. On the Change TCP/IP Domain screen that appears, you’ll see two fields called Host Name and Domain Name. These fields list out the components of your partition’s fully qualified host name. The fully qualified name for your partition is constructed by combining the two fields together in the following way:

Fully Qualified Host Name = Host Name +’.’+ Domain Name

So if your i5/OS Host name is equal to ‘admin’ and your domain name is equal to ‘itjungle.com’, your fully qualified host name would be ‘admin.itjungle.com’.

2. Insure that your fully qualified name is part of the Kerberos domain you want to join. If the domain name is “itjungle.com,” for example, your target partition must belong to that domain. If not, you will need to change domains for your i5/OS partition to participate in the Kerberos domain. Again, you can do this through the CHGTCPDMN command.

3. For each i5/OS partition that your administrator and client PCs want to use single sign-on to automatically attach to, each PC must be able to resolve the fully qualified host name of that partition to the partition’s correct IP address. DNS resolution can be tested by opening a command prompt and using the PING command. For our admin.itjungle.com host, for example, we would ping that host by using the following command:

PING admin.itjungle.com

If the ping is successful and it maps to the right IP address, move on to the next step. If we can’t ping the i5/OS host by its fully qualified name, we need to examine the DNS server entries the PC is using to resolve the host name. It may be that the DNS server that the PC uses doesn’t contain an entry for your i5 host or there may be an invalid entry in the DNS or PC host table. If DNS resolution doesn’t properly point to your system, you must straighten out your DNS problems before you can run single sign-on for that host.

4. After the PC can properly resolve the host name to the correct IP address, use PING to perform a reverse DNS lookup to insure that the PC can resolve the IP address back to the i5/OS partition’s fully qualified host name. Like our first ping resolution, this is critical to running single sign-on to the target i5/OS partition. You can use PING to test reverse DNS resolution by running it like this:

PING -a ip_address

5. Look at the domain name in the first line of the returned data. This name should be equal to the fully qualified host name of the i5/OS box that you are pinging. If not, examine the DNS resolution entries that your PC is using and correct the error before you try to configure Kerberos and EIM on your i5/OS partition.

Once you have verified that both forward and reverse DNS name resolution work as intended, your PC will be ready to configure or user Kerberos (NAS) on an i5/OS partition.

While you only have to perform steps 1 and 2 once, you will need to perform steps 3 through 5 every time you configure a new PC to either administer or participate in a Windows domain using single sign-on. DNS errors are one of the most common reasons that single sign-on deployments fail, and–because different PCs may use different DNS servers and different HOST table entries–your DNS resolution needs to be tested for each new PC you add to your single sign-on environment.

Once you have gone through the pre-requisites, you are ready to start configuring your network to use i5/OS single sign-on. I’ll discuss server configuration in my next article on the subject.