This article discusses the pains and joys I encountered in my quest to configure single sign-on. I hope you will learn from my mistakes and be able to experience the thrill of seeing your single sign-on implementation work more quickly than I did.

Step by Step

As you may have guessed from the emphasis on planning in "Single Sign-On, Part 2," configuring single sign-on is a multi-step process. Remember, there are two basic parts to single sign-on: authentication and authorization. For authentication, we're using Kerberos. For authorization, we're using EIM associations to map from the "principle" (identified by the Kerberos ticket that's generated when initially signing on to your client) to the appropriate OS/400 user profile.

At a high level, here's how you configure these two pieces. Part of the configuration uses iSeries Navigator, and you need to sign on with a profile that has *ALLOBJ, *SECADM, and *IOSYSCFG special authorities. This user also needs a home directory defined as well as sufficient authority to administer the Kerberos server, which, in my case, was a server running Windows 2003. In iSeries Navigator, you will run two wizards: first, the Network Authentication Services (NAS) wizard. Click on the System name>Security-Network Authentication Services. Right-click and choose Configure. This launches the NAS wizard.

The next step involves configuring the Kerberos server. Since my Kerberos server is on a Windows system, I needed to sign on as Administrator to make the required configuration changes to Active Directory. Your Kerberos configuration will be complete once you run the NAS wizard; set the QDATE, QTIME, and QUTCOFFSET (or QTIMZON in V5R3) system values appropriately; and make the changes on your Windows server.

You configure EIM by launching a second wizard in iSeries Navigator. Click on the system name>Network. Right-click on Enterprise Identity Mapping and choose Configure. Finally, add identifiers to EIM, make the appropriate associations, and away you go. Sounds easy, right? Well, in most cases, I believe this process is pretty simple and straightforward. However, I made several mistakes along the way, making this process more difficult than it needed to be.

Several resources provide step-by-step instructions that walk you through these wizards as well as your Kerberos configuration. I suggest you obtain one (or more) of these resources and read them. Following each step and keeping notes along the way will save you much frustration and re-work.

• The single sign-on topic listed under the Security heading in the V5R3 version of the iSeries Information Center is not only more current than the V5R2 information, but the topic is explained more clearly in this release than in previous releases. The single sign-on topic will also point you to the NAS topic, a.k.a. Kerberos implementation on OS/400, EIM configuration, and LDAP configuration. Personally, I wouldn't spend too much time worrying about the LDAP configuration. The EIM wizard handles that aspect of configuration very well.
• The Redbook Windows-based Single Signon and the EIM Framework on the IBM eServer iSeries Server goes into much more detail than the Info Center does. It also has some helpful tips on troubleshooting your single sign-on configuration.
• Last, but certainly not least, the book I co-authored with Patrick Botz, Experts' Guide to OS/400 & i5/OS Security has one chapter and a lengthy appendix devoted to the concepts of single sign-on. It includes step-by-step instructions for going through the NAS and EIM configuration wizards and a description of the features you'll find when you upgrade to V5R3. It also identifies common errors you may encounter.

Whichever resource or resources you choose to use, I encourage you to read through the directions for all of the steps before you actually start the configuration. While that process probably goes against the nature of most, I believe it will save you time in the long run. Had I realized what was coming, I would have chosen a more simple naming convention, and I may not have had as many issues with my DNS configuration.

Let's take a closer look at my configuration experience. The first issue that I had to contend with was that I didn't have a Kerberos server. However, I had an extra desktop PC, so I installed the Windows 2003 server. Next, I had to configure Active Directory. Neither of these two steps was difficult. My difficulty came in configuring the Domain Name Server (DNS) for my network. My issues there were primarily due to the fact that I had never configured a DNS before, so I was unfamiliar with the terminology and appropriate naming conventions. As I said in "Single Sign-On, Part 2," you will most likely have to enlist the help of your network administrator to perform some of this configuration. For example, you will need the fully qualified domain name of your Kerberos server, and you will have to get an account created in Active Directory that represents your OS/400 system.

I've compared notes with others who have gone before me, and the most common errors in NAS configuration are caused by problems with the DNS configuration. The best hint I can give is to make sure you always enter the realm name in all capital letters. Your host name doesn't need to be in capitals, but it does need to be consistent. For example, I entered my fully qualified host name as skyview.skyviewpartners.com. Yet, as defined in the TCP/IP domain information in OS/400, it was defined in uppercase. Using the Change TCP Domain (CHGTCPDMN) command, I re-entered the host and the domain names in lowercase enclosed in single quotes.

I used the steps outlined in Experts' Guide to know how to test my Kerberos configuration. To test the configuration, you are instructed to run some commands in QShell. To invoke QShell, just type "qsh" and then follow the instructions. Figure 1 shows two efforts to run kinit.

Figure 1: Here are the results of running kinit. (Click images to enlarge.)

The first time I ran kinit, I got the message "Unable to locate security server." That was caused by my not having an entry in my host table on the server for my iSeries. The host table can be found at windowssystem32driversetchosts.

I added the entry and ran kinit again. It was during this step that I found a "feature" of using Windows 2003 rather than Windows 2000 for my Kerberos server. By default, Kerberos runs over UDP, but these packets cannot handle the size of the ticket produced by Windows 2003 (Microsoft adds information to the Kerberos ticket for its own use). With the additional information added in Windows 2003, the ticket becomes too large to be handled over UDP. Therefore, you must switch your NAS configuration to run over TCP. To do this, go to NAS in iSeries Navigator, right-click, choose Properties, and check the box to indicate that it should use TCP as the communications protocol for the KDC.

Where to Look for More Information

I configured Kerberos, tested it, and knew it was working. I configured EIM, created a couple of identifiers, and made the associations between the Kerberos source identity and the OS/400 target identity (Figure 2).

Figure 2: These are the associations for the EIM identity Carol J Woodbury.

And, in iSeries Navigator, I went into the properties for the system I was connecting to, chose Connections, and configured my client to use Kerberos for authentication (Figure 3).

Figure 3: Configure iSeries Navigator to use Kerberos for authentication.

I rebooted my server to make sure no passwords were cached. I waited with bated breath as my server came back up. I logged on as Administrator, clicked on the iSeries Navigator icon, and clicked on the system name, expecting it to open up the tree structure without demanding that first-time user ID and password prompt. While I didn't see a password prompt, the tree didn't open up as expected. Instead I got the following error:



I looked at the details, but the return code that I received wasn't listed. So now what? This error and return code were listed in the Redbook, but the recommended workaround didn't work for me. Your next step is one I didn't find in any resource. To find information about this error, run Work with Active Job (WRKACTJOB) and look for the QZSOSIGN jobs. These jobs run under the QUSRWRK subsystem. (Note: You may have to hit F14 to see these jobs, and there may be more than one of these jobs.) You are looking for a job with a “Network Authentication Service” error message. You may also see some IP or socket errors. In all likelihood, you can ignore those. Hit Help on the NAS message. The second-level message text lists the major and minor error codes. If you are lucky, the explanation of the major and minor codes will be listed in the Recovery section of the error message. If they aren't, the message says they are listed in a header file in QSYSINC. Good luck finding them. I couldn't!

So now what, you ask? Knowing that my system did not have the most current PTFs, I searched the IBM Support Web site, using the keyword "Kerberos." There, I found a PTF with the exact major and minor codes I encountered. I applied the PTF, ended and started the sign-on and Telnet servers, and signed on to my network as the profile Administrator.

Then, I clicked on the system name in iSeries Navigator and watched in amazement as the tree structure opened without my entering my OS/400 user ID and password! Then I clicked on my desktop iSeries icon and was launched immediately into my initial program, running as user CJW. The moral to this section of the article? Get the latest PTFs before you start configuring single sign-on! Need another reason? There is at least one headache that many people experience with the host table configuration that is avoided with the latest NAS and EIM PTFs. (By the way, most, if not all, of the V5R2 PTFs are included in the base of V5R3.)

Single sign-on. It's a rush when your configuration is complete and you see it work for the first time. I hope this series of articles has gotten you interested and has provided you with enough information that you want to try this yourself!

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 and i5/OS. 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 www.pentontech.com/education.

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

 

Carol Woodbury is IBM i Security SME and Senior Advisor to Kisco Systems, a firm focused on providing IBM i security solutions. Carol has over 30 years’ experience with IBM i security, starting her career as Security Team Leader and Chief Engineering Manager for iSeries Security at IBM in Rochester, MN. Since leaving IBM, she has co-founded two companies: SkyView Partners and DXR Security. Her practical experience and her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.

Carol is known worldwide as an author and award-winning speaker on security technology, specializing in IBM i security topics. She has written seven books on IBM i security, including her two current books, IBM i Security Administration and Compliance, 3^rd Edition and Mastering IBM i Security, A Modern, Step-by-Step Approach. Carol has been named an IBM Champion since 2018 and holds her CISSP and CRISC security certifications.

---

MC Press books written by Carol Woodbury available now on the MC Press Bookstore.

		IBM i Security Administration and Compliance: Third Edition Don't miss the newest edition by the industry’s #1 IBM i security expert. List Price $71.95 Now On Sale
		Mastering IBM i Security Get the must-have guide by the industry’s #1 security authority. List Price $49.95 Now On Sale

Also Read

IBM i Security Essentials: 4 Components for an Effective Strategy

New IBM i Security Features and a Farewell

Securing IBM i: A Dual Responsibility