Admin Alert: Getting Ready for Single Sign-On

by 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.

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
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.

RELATED STORY

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
Admin Alert: Configuring an i5/OS-based EIM Table for Single Sign-On

by Joe Hertvik

In previous columns, I introduced several concepts and configurations for enabling IBM's
Single Sign-On (SSO) technology, in which Windows domain users access a Kerberos server
to automatically authenticate and authorize themselves to use i5/OS applications without
entering an OS/400 user profile and password. While previous articles focused on network
configuration, this week I'll look at how you create and use an Enterprise Identity Mapping
(EIM) domain to tell Kerberos which i5/OS user profiles to use to automatically sign a user
on to an i5 or iSeries partition.

Please note that this article is the next 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 two weeks ago)
Configuring your i5/OS partitions and a Windows Key Distribution Center server
(KDC) to exchange Kerberos information for SSO (last week's story)
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 (this week)
User desktop configurations for using SSO for i5 access from a Windows client
machine (coming soon)

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), which I'll refer to as "the redbook." While I won't repeat the exact configurations
that IBM uses in the redbook, I will summarize and supplement the EIM configuration
process with additional comments. Also note that all references to i5/OS refer to an i5,
iSeries, or AS/400 machine running OS/400 V5R2 or above.

Under SSO, users are automatically authorized and authenticated to i5 applications using
information contained in an Enterprise Identity Mapping domain (EIM). EIM is basically a
look-up table where each user's identities (user IDs) in different user registries (target
platforms and applications) are mapped to a source identity in a Windows domain containing
a Kerberos Key Distribution Center server (KDC). Using EIM in an SSO environment means
that, after a Windows user is authenticated by the Kerberos KDC, Windows-based
applications that access different i5/OS partitions (such as iSeries 5250 or ODBC) can query
the EIM table to discover which user identity the authenticated user should be assigned to for
that user registry. The user is then allowed to automatically sign on to the user registry
specified in the requesting application by using the target user ID specified in the EIM table
(no password is required).
To create an EIM table that target applications can access, you need to perform the following
steps on your iSeries or i5 boxes:

Configure an EIM domain and an EIM domain controller for your network. In this
article, the domain controller uses a Lightweight Directory Access Protocol server
(LDAP) running on an i5/OS machine, although the controller can be configured to
run on another platform. (I discussed how to configure LDAP for SSO usage in a
previous article in this series)
For each additional i5 partition that you want to enable SSO for, configure IBM's
Network Authentication Service (NAS) on that partition, as described in my previous
article and in sections 8.3-8.3.2 of the redbook. You will also need to add the new i5-
iSeries partition to the EIM domain, as described in section 8.3 of the redbook.
Add one user identifier to your EIM domain for each user that will be using SSO to
automatically sign-on to i5 target applications. The identifier will contain a descriptive
name for each user, the user ID the user signs on as for the source Kerberos KDC
server in your Windows domain, and target entries that contain the i5/OS user ID that
will be used when the source user requests a service from each of your target i5
partitions.
Configure your target applications on the user's desktop to use Kerberos and EIM to
automatically authorize and authenticate the user to sign on to i5/OS applications
without entering a user ID or password (covered next issue).

To perform these configurations, here's the process I followed by using the redbook, other
IBM materials (referenced below), 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. Make sure you have a filled out copy of the Configuration Planning Worksheets from
Appendix D of the redbook. Also be sure to review the earlier articles in this series to insure
that you've completed all the necessary configuration tasks that are needed before setting up
EIM. On the worksheet, you will decide which iSeries LDAP server you want to configure
your EIM domain on (as specified by the fully qualified name of the i5/OS box the EIM table
will be hosted on), the name of your EIM domain, and the Administrator Distinguished Name
(DN) and password for the LDAP server that will be used as the EIM domain controller.

2. Review chapter six of the redbook to understand the concepts behind EIM. Chapter six
explains EIM issues, and it provides a good basis for understanding what's involved in an
EIM configuration.

3. Configure your EIM domain and EIM domain controller by using the EIM configuration
wizard in iSeries Navigator. The exact steps for performing this function are detailed in
section 7.2.1 of the redbook. For the EIM domain controller, you specify that you want to
create and join a new EIM domain by using the values from the worksheet. The wizard asks
for two sets of distinguished names and passwords. The first set--on the Specify User for
Connection window--is used only by the EIM wizard when the wizard connects to the LDAP
server to perform the configuration. The second set--which is listed on the Specify EIM
System User window--is used by various system functions to connect to the EIM domain.
Both sets of distinguished names and passwords can be the same. The wizard will stop and
restart your i5/OS LDAP server during this process. The wizard's final configuration window
will contain a summary of all your configuration choices. You may want to print a copy of
that window for future reference.
4. Add the EIM domain you just created to a list of EIM domains that you want to manage
from your iSeries Navigator client. This allows you to manage, add, and modify EIM
information from your local PC. This configuration option is local to the iSeries Navigator
installation you are currently working on. This step is also necessary to perform the user
identifier configuration listed in step six. If you want to manage the domain from a second PC
running iSeries Navigator, you will need to run this configuration step a second time on that
PC. Setting up iSeries Navigator to manage your EIM domain is a simple process that is
performed by using the instructions listed in section 7.2.2 of the redbook.

5. If you want to add another i5 or iSeries partition to your EIM domain, follow the
instructions in section 8.3 of the redbook. This may require you to first enable the Network
Authentication Service (NAS) service on your additional i5/OS partition, as well as specifying
that these additional partitions are joining an already existing EIM domain, rather than
creating a new domain for each partition. As you did when you created the EIM domain in
step three, you add i5/OS partitions to an existing EIM domain by using the EIM wizard.
There are a few different configuration options when adding a new i5/OS partition to an
existing domain, so follow the steps in section 8.3.3 carefully, particularly on the Welcome
window and when specifying registries on the Registry Information window.

6. Use iSeries Navigator to add user identifiers and associations to your EIM domain. Users
are set up to use SSO on i5/OS boxes by adding user identifiers and associations to your EIM
domain. These steps are described in section 7.2.3 and 8.3.4 of the redbook.

A user identifier contains a set of entries that describes that user in your EIM domain. It's
helpful to think of a user identifier as a container that holds all the associations needed to
enable SSO for i5 boxes residing in a Windows network. Once a user identifier is added, you
need to add one source association and at least one target association to that identifier for each
user in your EIM domain. A source association specifies the registry name (a fully qualified
domain name) and the user name that is used to sign on to your domain's Kerberos KDC
server. Source entries are specified by an Association type of source. Once a source
association is defined for a user identifier, you can define as many target associations as
necessary for that same identifier. Each target association contains the fully qualified registry
name of an SSO enabled i5 or iSeries partition, as well as the i5/OS user profile name that the
source user will use when as it is automatically signed on to that partition through SSO.
Target entries are specified by an Association type of target.

By entering this information for each user into EIM, a user identifier creates a map for what
user profiles a Windows network domain user should use when he is automatically signed on
to an i5 or iSeries box through SSO.

At this point, you've configured an EIM table on an i5/OS box. The next step is to configure
Windows desktop applications to enable your Windows desktop applications--such as iSeries
Navigator, ODBC, and iSeries Access 5250 emulation--to access your Kerberos-EIM
implementation to automatically sign users on to your target i5 boxes when an SSO enabled
user calls those applications. And that will be the focus of our next article.

References:
Admin Alert: Getting Ready for Single Sign-On, Four Hundred Guru, April 27, 2005, Joe
Hertvik

Admin Alert: Configuring i5/OS and a Windows Network Server for SSO, Four Hundred
Guru, May 4, 2005, Joe Hertvik

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
Admin Alert: Configuring Windows Desktops to Use SSO

by Joe Hertvik

In recent issues, Admin Alert has been covering how to configure and use IBM's Single Sign-
On technology (SSO), which allows Windows domain users to automatically authenticate and
authorize themselves to use i5/OS applications without entering an OS/400 user profile and
password. While prior columns have covered server configurations, this final article
completes the process by discussing how to configure your Windows desktop machines to use
SSO.

If your network is not already configured for SSO, be sure to read these previous three articles
in the series, which cover Windows and i5/iSeries server configurations for SSO:

Requirements and pre-configuration tasks for enabling SSO on your iSeries partitions
Configuring your i5/OS partitions and a Windows Key Distribution Center server
(KDC) to exchange Kerberos information for SSO
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
User desktop configurations for using SSO for i5 access from a Windows client
machine (this week)

By reading these articles and following IBM's examples, you will configure your network and
i5/OS boxes to support SSO and put yourself in position to configure your Windows desktops
to use SSO for automatic sign-on. You will also need to download and read IBM's Windows-
Based Single Signon and the EIM Framework on the IBM eServer iSeries Server redbook
(SG24-6975-00), which I'll refer to as "the redbook." This manual contains step-by-step
configuration tasks, which I have been summarizing and expanding on in order to provide a
template for implementing SSO. You should also note that all references to i5/OS in this
article refer to an i5, iSeries, or AS/400 machine running OS/400 V5R2 or above; SSO is not
available for earlier versions of OS/400.

To configure Windows user desktops to automatically sign-on to i5/OS applications with

SSO, here are the steps you will need to follow:

1. In each i5/OS partition where you have enabled Single Sign-On, change the Remote Sign-
On Control system value (QRMTSIGN) to *VERIFY so that the system will allow your users
to bypass the sign-on screen.

By default, the shipped value is *FRCSIGNON, which will not allow SSO to bypass the sign-
on process. To do this on the green screen, enter the following Work with System Values
command (WRKSYSVAL):

WRKSYSVAL SYSVAL(QRMTSIGN)
On the Work with System Values screen that appears, enter option 2=Change in front of the
QRMTSIGN entry and press ENTER. On the Change System Value screen (CHGSYSVAL)
that appears, enter *VERIFY into the remote sign-on control parameter and press ENTER.
This change will take effect immediately.

This step is also discussed in section 7.3.1 of the redbook.

2. Configure EIM domain user identifiers that SSO will use to automatically sign your users
on to i5 target applications.

Each user identifier contains a descriptive name for a user, the user ID the user signs on as for
the source Kerberos KDC server in your Windows domain, and target entries that contain the
i5/OS user ID that will be used when the source user requests a service from each of your
target i5 or iSeries partitions. I covered this process in my last article. This step is also
covered in section 7.2.3 of the redbook.

3. Double check the target user profiles for each i5/OS partition listed in your EIM user
identifiers to insure that each profile has a home directory in the AS/400 Integrated File
System (IFS) on that partition.

IBM has stated in some SSO presentations that this is a requirement, and SSO may fail if the
target partition user does not have an IFS directory associated with it. To create a home
directory for your target partition user in the '/home' folder under the root ('/) directory of the
AS/400 IFS, run the following green-screen Create Directory command (CRTDIR):

CRTDIR DIR('/home/username')

Then make sure that the user profile being used for SSO is authorized to access this folder.
You can then specify the folder as the user's home directory by running the Change User
Profile command (CHGUSRPRF), like this:

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

4. For each PC that you want to configure SSO for, you must be running a Windows 2000 or
above operating system.

IBM does not support SSO running on earlier versions of Windows. Also make sure that the
Windows desktop is running iSeries Access for Windows V5R2M0 or V5R3M0. These are
the versions that contain Kerberos support for single sign-on. In larger shops, it's fairly
common to use older iSeries Access versions, so be sure to check this out before you start.
You should also download and install the latest iSeries Access for Windows service pack onto
the SSO-enabled PCs, too.

5. On your Windows desktop, enable iSeries Navigator Single Sign-On support for your
partitions by changing their connection properties to use Kerberos.

This is discussed in section 7.3.2 of the redbook. Make sure that you are signed on to your
Windows network as a domain user who has an EIM user identifier configured with target
entries for the i5 partitions you want to access through SSO. This step involves opening the
Properties menu for each iSeries Navigator i5/OS partition your user will use SSO on, and
then changing the Sign-On Information parameter to use the Kerberos principal name, with no
prompting. Do this for every partition on which this user will be using SSO.

Once this configuration is done, iSeries Navigator will inform you that the Kerberos change
will not go into effect for iSeries Navigator until the program is closed and opened again. If
you have configured Kerberos, SSO, and your EIM identifier correctly, you should be able to
reopen iSeries Navigator and simply click on your Kerberos-enabled partition and the
partition will automatically open without requesting a user ID and password. IBM gives
instructions for verifying that SSO is working correctly in the redbook, but the easiest way to
verify SSO connectivity is to simply reboot your machine and then try opening each of your
SSO-enabled partitions through iSeries Navigator.

After I successfully configured iSeries Navigator for SSO, I found that it not only allowed me
to transparently sign on to that application without entering a user ID and password, it also
automatically enabled SSO for my ODBC drivers, which were configured to use my iSeries
Navigator default connection properties to retrieve their default user IDs. So with one
configuration change, I also configured Microsoft Excel, Access, and any other program that
used ODBC for SSO to my Kerberos-enabled partition. In addition, I also found that
applications that used my OLE DB driver also worked with SSO, presumably because they,
too, were set to use the iSeries Navigator defaults for their default user IDs. In fact, most PC
applications that are configured to use iSeries Navigator default connection properties for
i5/OS sign-on should instantly convert to SSO for automatic sign-on, as long as iSeries
Navigator is set up to use Kerberos.

6. If necessary, configure PC5250 to always use Kerberos as its default sign-on protocol.

Assuming PC5250 is not set up to use default iSeries Navigator connection properties, as
explained in step four, you will also need to change PC5250's default connection properties to
use Kerberos for SSO. You do this by clicking on the Properties button on the Configure
PC5250 screen, as explained in section 7.3.3 of the redbook.

7. Repeat steps two through six for desktop PCs and users that you want to configure for SSO.

At this point, you will have enabled SSO on your user desktops, using the configurations and
techniques I covered in all four articles in this series. Unlike the server configurations, which
are more complicated but only have to be performed once, client SSO configuration is much
easier to perform. There are additional steps and techniques that you can use for expanding
your SSO configuration and making it easier to maintain, but these articles will get you
started using SSO on your network. Good luck with the process and be sure to drop me a line
to let me know how you're doing.

References:

Admin Alert: Getting Ready for Single Sign-On, Four Hundred Guru, April 27, 2005, Joe
Hertvik

Admin Alert: Configuring i5/OS and a Windows Network Server for SSO, Four Hundred
Guru, May 4, 2005, Joe Hertvik

Admin Alert: Configuring an i5/OS-based EIM Table for Single Sign-On, Four Hundred
Guru, May 18, 2005, Joe Hertvik

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