Admin Alert: Configuring i5/OS and a Windows Network Server for SSO

May 4, 2005 Joe Hertvik

Last week, I introduced the concepts and pre-configuration tasks for setting up IBM‘s Single Sign-On (SSO) technology, which allows network users to access a Kerberos server to automatically authenticate and authorize themselves to use i5/OS applications without entering an OS/400 user profile and password. This week, let’s look at some of the configuration tasks for setting up your i5/iSeries partitions and Windows network for SSO.

Please note that this is the second installment of a group of articles on configuring SSO for i5/OS. These articles cover the following information:

Requirements and pre-configuration tasks for enabling SSO on your iSeries partitions (from last week’s story)
Configuring your i5/OS partitions and a Windows Key Distribution Center server (KDC) to exchange Kerberos information for SSO (this week)
Configuring an Enterprise Identity Mapping table (EIM) inside i5/OS to tell Kerberos which i5/OS user profiles Windows users should be signed on as (mapped to) when they access i5/OS partitions and applications transparently through SSO (upcoming article)
Configuring an Enterprise Identity Mapping table (EIM) inside i5/OS to tell Kerberos which i5/OS user profiles Windows users should be signed on as (mapped to) when they access i5/OS partitions and applications transparently through SSO (upcoming article)
User desktop configurations for using SSO for i5 access from a Windows client machine (coming soon)

Most of the step-by-step information for configuring SSO can be found in IBM’s Windows-based Single Sign-On and the EIM Framework on the IBM eServer iSeries Server Redbook (SG24-6975-00). For the purposes of this article, I’ll refer to this manual as “the redbook.” While I won’t repeat the exact details that IBM lays out in that book, I am going to summarize and supplement the SSO server configuration process with details and adjustments that may not be clear in the redbook.

To implement SSO across your i5 and iSeries partitions, you need to configure the following server functions in your partitions and in your Windows network:

Configure your OS/400 partitions with the IBM version of a Kerberos server, which Big Blue refers to as a Network Authentication Service (NAS)
Configure a service principal user in your Windows KDC server’s Active Directory for each i5 or iSeries partition that will allow Single Sign-On
Configure an EIM table for user mapping (not covered in this article)

To perform these configurations, here’s the process I followed by using the redbook, other IBM materials (referenced below), personal experience, and advice from IBM technical support. By following these steps in conjunction with the redbook, you should be able to configure and verify that your i5 partitions can run SSO.

1.Fill out the two checklists (the Prerequisites Checklist and the Configuration Planning Worksheets) in Appendix D of the redbook. Also, review chapters one through six of the redbook, and perform the pre-configuration tasks listed in my previous article, Getting Ready for Single Sign-On. Together, these items should walk you through most of the pre-configuration work for the project.

2. Check the configuration on your partition’s LDAP server to insure that it’s configured for the partition’s fully qualified host name, and start your LDAP server. For SSO, you can use an i5/iSeries-based LDAP server or an LDAP server hosted on another machine. SSO uses LDAP in its implementation. Recheck your LDAP configuration and reconfigure and restart LDAP, if necessary. See IBM’s iSeries Directory Server (LDAP): Configuring and Administering your LDAP Directory Server Web page for a fairly complete list of instructions on running LDAP.

3. Set up the Network Authentication Service (NAS) on your i5 partition (section 7.1.1 of the redbook) by using the NAS Setup Wizard in iSeries Navigator. The Wizard sets up an i5-specific Kerberos implementation for your partition. Be sure to perform and test this configuration first on the i5 partition that is going to host your Enterprise Identity Mapping table (EIM) before you perform it on any other partitions. Using the configuration information you compiled in the Configuration Planning Worksheet, use the NAS setup wizard in iSeries Navigator to perform the configuration. Remember that many of the configuration items (including the Windows KDC name) are case sensitive so be careful to enter all names correctly.

There are a few gotchas to watch out for in this step. First, the configuration wizard will prompt you for a password for the Kerberos service principal. Be sure to write down this password on the Configuration Planning Worksheet as you will use it again when you configure your Windows server to accept SSO requests. You will also need this password every time you add user identity information in the EIM table, which I’ll cover in the next article. The second gotcha is that the wizard will ask you if you want to create a batch file to configure your Windows with a service principal user ID. You will probably want to take this option but–depending on how the configuration goes–you may not use the batch file to configure your service principal user on the Windows server (more on this in step four). The Wizard also prompts you for which i5 services you should enable SSO for, with the choices being iSeries Kerberos Authentication, LDAP, HTTP, and iSeries NetServer. There are a few additional wrinkles involved in configuring SSO for iSeries NetServer, so you may want to bypass NetServer configuration for a later date, after you create a stable SSO environment.

4. Create a Kerberos service principal user in the Active Directory on your Windows KDC server. The Kerberos service principal user will be used for verifying authentication when a user tries to use Kerberos to sign on to your partition without a user ID and password. The Kerberos principal will have the same name as your i5/iSeries host name and you have two choices for creating it. You can either create it manually on your Windows server by using the instructions in section 7.1.2 of the redbook, or you can create it by using the batch file that was generated when you used the NAS Setup wizard.

In my experience in researching and creating a service principal user on a Windows 2003 server, I found that that it was better to configure the service principal user manually by using the instructions in the redbook. The iSeries Navigator V5R3M0 batch file that the NAS wizard generated didn’t seem to create Active Directory principal user names that were consistent with what IBM was specifying in the redbook. After some trial and error, I found that I was able to configure my service principal correctly with a manual configuration that mirrored the redbook, with one modification. This modification occurred in step three of section 7.1.2, where the manual tells you to enter the fully qualified name of your i5 partition into the Full name field of the new Active Directory service principal user. In my implementation, I found that I needed to only enter the host name part of the fully qualified name into this field, because the configuration would fail when I entered the fully qualified name.

The manual also specifies that your new Active Directory service principal account needs to have the Account is trusted for delegation check box activated for SSO to work Be aware that this checkbox is located in two different places on Windows 2000 and Windows 2003 servers. On a Windows 2000 server, as referenced in the redbook, the checkbox is located under the Account tab of the user account; on a Windows 2003 server, you can find the checkbox located under the Delegation tab of the user account.

Keep in mind, however, that these modifications are based on my experience in configuring SSO. It may be that you will be able to configure the service principal user strictly according to IBM instructions in your environment, using the batch file. If you can’t configure this user correctly, however, you may want to try these two modifications to see if they help you complete your configuration.

5. Verify Network Authentication Service Setup. After NAS is configured on your i5 partition and the service principal user has been added to your Windows Active Directory, IBM gives you instructions for running the keytab, kinit, and klist Qshell interpreter commands to verify your setup. In setting up SSO on my partitions, I found that, while the keytab and klist commands worked without a hitch during verification, I had to call IBM and have them help me make certain adjustments before I could verify my environment was working correctly by using kinit. In particular, I found there were several configuration changes that were critical in getting my SSO environment to work correctly.

In running the kinit command to test out the functionality involved in requesting and receiving a KDC ticket from Windows, I found that kinit generated several errors that needed correction before it would run. You can find some of the errors in Appendix D of the redbook but three errors, in particular, seemed to occur each time I tested my configuration on a different partition by using kinit in QSH.

Error ‘EUVF06007E Unable to obtain name of default credentials cache’ generally occurred because the user profile I was using to run kinit was missing an AS/400 Integrated File System (AS/400 IFS) home directory in its user profile description. The home directory stores a work file that kinit uses to request and receive a KDC ticket from the Windows server. Without this directory to store things in, kinit bombs. To fix the error, I first created an AS/400 IFS home directory for my user in the ‘/home’ folder under the root (‘/) directory of the AS/400 IFS. I did this by running the green-screen Create Directory command (CRTDIR), as follows:

CRTDIR DIR(‘/home/username‘)

I then made sure that the user profile running kinit was authorized to access this folder. I also specified this folder as the user’s home directory by running the Change User Profile command (CHGUSRPRF), like this:

CHGUSRPRF USRPRF(username) HOMEDIR(‘/home/username‘)

After performing these two tasks, theEUVF06007E error went away. The next error occurred when I ran kinit and it issued the following error to tell me that my system time was more than five minutes out of sync with the time on the Windows KDC server, giving me this error:

EUVF06014E Unable to obtain initial credentials. Status 0x96c73a25 – Time differential exceeds maximum clock skew.

After I synchronized my i5 system time to the KDC server’s time, this error went away.

The final error involved kinit issuing an error message stating that my cryptographic access program was producing an error as QSH processed the command. After talking with IBM, they recommended that I run program QYAC3INAT in library QCAP3 from a command line, as follows:

CALL QCAP3/QYAC3INAT

QYAC3INAT is used to correct cryptographic attribute problems that can occur with the 56-bit or 128-bit Cryptographic Access provider licensed program (5722-AC2 or 5722-AC3). Cryptographic access provider corruption is a known issue in i5/OS V5R3M0 after an i5/iSeries partition is upgraded, migrated to another box, or restored. This problem can occur when using SSO or when using VPN but the fix is to use QYAC3INAT to straighten the attributes out.

You may also find other problems occurring when you test SSO using kinit and IBM has provided some solutions to several error codes in appendix D of the redbook.

Once you’ve verified your NAS setup on your i5 or iSeries partition, your Windows domain is configured for Single Sign-On and you should have an active SSO server infrastructure configured on your partition. If you want to set up SSO on other partitions, follow the same redbook process we discussed here, but this time follow the directions listed in section 8.3-8.3.2 of the redbook, called Enabling Another iSeries Server for Single Sign-On.

But we’re not finished setting up SSO on your system yet. The next step is to create and set up user identities in an Enterprise Identity Mapping domain (EIM), which tells Kerberos which i5/OS user profiles should be used when SSO automatically signs a network user on to an i5 or iSeries partition. And that will be the subject of the next article in this particular series.

Admin Alert: Getting Ready for Single Sign-On, IT Jungle, April 27, 2005, Joe Hertvik

References:

Windows-Based Single Sign-On and the EIM Framework on the IBM eServer iSeries Server, IBM Redbook (SG24-6975-00)

Configuring connection-based automation in an i5/OS or OS/400 and Kerberos environment, IBM

Single Sign-On in a Single Day!, TriAWorks

Introduction to Single Sign-On with OS/400 and i5/OS (Presentation Slides), Skyview Partners as hosted on the COMMON Belgium Web site, Carol Woodbury

Single Sign-On Myths, IT Jungle, August 19, 2003, Pat Botz

Configuring i5/OS Single Sign-On (Presentation Slides), TriAWorks Web site, Pat Botz