Scenario: Enabling single sign-on for i5/OS
Here are the prerequisites and objectives for enabling single sign-on for the i5/OS® operating system.
Situation
You are a network administrator that manages a network and network security for your company, including the Order Receiving department. You oversee the IT operations for a large number of employees who take customer orders over the telephone. You also supervise two other network administrators who help you maintain the network.
The employees in the Order Receiving department use Windows® 2000 and i5/OS and require multiple passwords for the different applications they use every day.
Consequently, you spend a lot of time managing and troubleshooting problems related to passwords and user identities, such as resetting forgotten passwords.
As the company's network administrator, you are always looking for ways to improve the business, starting with the Order Receiving department. You know that most of your employees need the same type of authority to access the application that they use to query inventory status. It seems redundant and time consuming for you to maintain individual user profiles and numerous passwords that are required in this situation. In addition, you know that all of your employees can benefit by using fewer user IDs and passwords. You want to do these things:
- Simplify the task of password management for the Order Receiving department.
Specifically, you want to efficiently manage user access to the application your employees routinely use for customer orders.
- Decrease the use of multiple user IDs and passwords for the department employees, as well as for the network administrators. However, you do not want to make the Windows 2000 IDs and i5/OS user profiles the same nor do you want to use password caching or synching.
Based on your research, you know that i5/OS supports single sign-on, a solution that allows your users to log on once to access multiple applications and services that normally require them to log on with multiple user IDs and passwords. Because your users do not need to provide as many user IDs and passwords to do their jobs, you have fewer password problems to solve for them. Single sign-on seems to be an ideal solution because it allows you to simplify password management in the following ways:
- For typical users that require the same authority to an application, you can create policy associations. For example, you want the order clerks in the Order Receiving department to be able to log on once with their Windows user name and password and then be able to access a new inventory query application in the manufacturing department without having to be authenticated again.
However, you also want to ensure that the level of authorization that they have when using this application is appropriate. To attain this goal, you decide to create a policy association that maps the Windows 2000 user identities for this group of users to a single i5/OS user profile that has the appropriate level of authority for running the inventory query application. Because this is a query-only application in which users cannot change data, you are not as concerned about detailed auditing for this application. Consequently, you feel confident that using a policy association in this situation conforms to your security policy.
You create a policy association to map the group of order clerks with similar authority requirements to a single i5/OS user profile with the appropriate level of authority for the inventory query application.
Your users benefit by having one less password to remember and one less logon to perform. As the administrator, you benefit by having to maintain only one user profile for user access to the application instead of multiple user profiles for everyone in the group.
- For each of your network administrators who have user profiles with special authorities, such as *ALLOBJ and *SECADM, you can create identifier associations.
For example, you want all of the user identities for a single network administrator to be precisely and individually mapped to one another because of the administrator's high level of authority.
Based on your company's security policy,
you decide to create identifier associations to map specifically from each network administrator's Windows identity to that administrator's i5/OS user profile. You can more easily monitor and trace the activity of the administrator because of the one-to-one mapping that identifier associations provide. For example, you can monitor the jobs and objects that run on the system for a specific user identity. Your network administrator benefits by having one less password to remember and one less log-on to perform. As the network administrator,
you benefit by tightly controlling the relationships between all of your administrator's user identities.
This scenario has the following advantages:
- Simplifies authentication process for users.
- Simplifies managing access to applications.
- Eases the overhead of managing access to systems in the network.
- Minimizes the threat of password theft.
- Avoids the need for multiple sign-ons.
- Simplifies user identity management across the network.
Objectives
In this scenario, you are the administrator at MyCo, Inc., who wants to enable single sign-on for the users in the Order Receiving department.
The objectives of this scenario are as follows:
- System A and System B must participate in the MYCO.COM realm to authenticate the users and services that are participating in this single sign-on environment. To enable the systems to use Kerberos, Systems A and B must be configured for network authentication service.
- The IBM® Directory Server for iSeries™ (LDAP) on System A must function as the domain controller for the new EIM domain.
Refer to Domains to learn how two different types of domains, an EIM domain and a Windows 2000 domain, fit into the single sign-on environment.
- All user identities in the Kerberos registry must map successfully to a single i5/OS user profile with appropriate authority for user access to the inventory query application.
- Based on your security policy, two administrators, John Day and Sharon Jones, who also have user identities in the Kerberos registry, must have identifier associations to map these identities to their i5/OS user profiles which have *SECADM special authority. These one-to-one mappings enable you to closely monitor the jobs and objects that run on the system for these user identities.
- A Kerberos service principal must be used to authenticate the users to the IBM iSeries Access for Windows applications, including iSeries Navigator.
Details
The following figure illustrates the network environment for this scenario.
The figure illustrates the following points relevant to this scenario.
EIM domain data defined for the enterprise
- Three registry definition names:
- A registry definition name of MYCO.COM for the Windows 2000 server registry. You will define this when you use the EIM configuration wizard on System A.
- A registry definition name of SYSTEMA.MYCO.COM for the i5/OS registry on System A. You will define this when you use the EIM configuration wizard on System A.
- A registry definition name of SYSTEMB.MYCO.COM for the i5/OS registry on System B. You will define this when you use the EIM configuration wizard on System B.
- Two default registry policy associations:
EIM lookup operation processing assigns the highest priority to identifier associations. Therefore, when a user identity is defined as a source in both a policy association and an identifier association, only the identifier association maps that user identity. In this scenario, two network administrators, John Day and Sharon Jones, both have user identities in the MYCO.COM registry, which is the source of the default registry policy associations. However, as shown below, these administrators also have identifier associations defined for their user identities in the MYCO.COM registry. The identifier associations ensure that their MYCO.COM user identities are not mapped by the policy associations. Instead, the identifier associations ensure that their user identities in the MYCO.COM registry are individually mapped to other specific individual user identities.
- One default registry policy association maps all user identities in the Windows 2000 server registry called MYCO.COM to a single i5/OS user profile called SYSUSERA in the SYSTEMA.MYCO.COM registry on System A. For this scenario,
mmiller and ksmith represent two of these user identities.
- One default registry policy association maps all user identities in the Windows 2000 server registry called MYCO.COM to a single i5/OS user profile called SYSUSERB in the SYSTEMB.MYCO.COM registry on System B. For this scenario,
mmiller and ksmith represent two of these user identities.
- Two EIM identifiers named John Day and Sharon Jones to represent the two network administrators in the company who have those names.
- For the John Day EIM identifier, these identifier associations are defined:
- A source association for the jday user identity, which is a Kerberos principal in the Windows 2000 server registry.
- A target association for the JOHND user identity, which is a user profile in the i5/OS registry on System A.
- A target association for the DAYJO user identity, which is a user profile in the i5/OS registry on System B.
- For the Sharon Jones EIM identifier, these identifier associations are defined:
- A source association for the sjones user identity, which is a Kerberos principal in the Windows 2000 server registry.
- A target association for the SHARONJ user identity, which is a user profile in the i5/OS registry on System A.
- A target association for the JONESSH user identity, which is a user profile in the i5/OS registry on System B.
Windows 2000 server
- Acts as the Kerberos server (kdc1.myco.com), also known as a key distribution center (KDC), for the network.
- The default realm for the Kerberos server is MYCO.COM.
- All Microsoft® Windows Active Directory users that do not have identifier associations are mapped to a single i5/OS user profile on each of the System i™ platforms.
System A
- Runs i5/OS V5R3,
or later, with the following options and licensed programs installed:
- i5/OS Host Servers (5722-SS1 Option 12)
- Qshell Interpreter (5722-SS1 Option 30)
- iSeries Access for Windows (5722-XE1)
- Network Authentication Enablement (5722-NAE) if you are using i5/OS V5R4
- Cryptographic Access Provider (5722-AC3) if you are using i5/OS V5R3
You can implement this scenario using a system that runs OS/400® V5R2.
However, some of the configuration steps are slightly different. In addition,
this scenario demonstrates some of the single sign-on functions that are only available in i5/OS V5R3, and later, such as policy associations.
- The directory server on System A will be configured to be the EIM domain controller for the new EIM domain, MyCoEimDomain.
- Participates in the EIM domain, MyCoEimDomain.
- Has the service principal name of krbsvr400/systema.myco.com@MYCO.COM.
- Has the fully qualified host name of systema.myco.com.
This name is registered in a single Domain Name System (DNS) to which all PCs and servers in the network point.
- Home directories on System A store the Kerberos credentials cache for i5/OS user profiles.
System B
- Runs i5/OS V5R3,
or later, with the following options and licensed programs installed:
- i5/OS Host Servers (5722-SS1 Option 12)
- Qshell Interpreter (5722-SS1 Option 30)
- iSeries Access for Windows (5722-XE1)
- Network Authentication Enablement (5722-NAE) if you are using i5/OS V5R4, or later
- Cryptographic Access Provider (5722-AC3) if you are running i5/OS V5R3
- Has the fully qualified host name of systemb.myco.com.
This name is registered in a single Domain Name System (DNS) to which all PCs and servers in the network point.
- The principal name for System B is krbsvr400/systemb.myco.com@MYCO.COM.
- Participates in the EIM domain, MyCoEimDomain.
- Home directories on System B store the Kerberos credentials cache for i5/OS user profiles.
Administrative PC
- Runs Microsoft Windows 2000 operating system.
- Runs iSeries Access for Windows (5722-XE1).
- Runs iSeries Navigator with the following subcomponents installed:
- Network
- Security
- Users and Groups
- Serves as the primary logon system for the administrator.
- Configured to be part of the MYCO.COM realm (Windows domain).
Prerequisites and assumptions
Successful implementation of this scenario requires that the following assumptions and prerequisites are met:
- All system requirements, including software and operating system installation,
have been verified.
To verify that these licensed programs have been installed, follow these steps:
- In iSeries Navigator,
expand your system > Configuration and Service > Software > Installed Products.
- Ensure that all the necessary licensed programs are installed.
The Network Authentication Service APIs support job environments for most EBCDIC CCSIDs. However, CCSID 290 and 5026 are not supported because of the variance of lowercase letters a to z.
- All necessary hardware planning and setup are complete.
- TCP/IP and basic system security are configured and tested on each system.
- The directory server and EIM should not be previously configured on System A.
Instructions in this scenario are based on the assumption that the directory server has not been previously configured on System A. However, if you already configured the directory server, you can still use these instructions with only slight differences. These differences are noted in the appropriate places within the configuration steps.
- A single DNS server is used for host name resolution for the network.
Host tables are not used for host name resolution.
The use of host tables with Kerberos authentication might result in name resolution errors or other problems. For more detailed information about how host name resolution works with Kerberos authentication, see Host name resolution considerations.
Configuration steps
You need to thoroughly understand the concepts related to single sign-on, which include network authentication service and Enterprise Identity Mapping (EIM) concepts,
before you implement this scenario. See the following information to learn about the terms and concepts related to single sign-on:
To configure single sign-on on your system, complete these steps.
- Completing the planning work sheets
These planning work sheets demonstrate the information that you need to gather and the decisions you need to make as you prepare to configure the single sign-on function described by this scenario. - Creating a basic single sign-on configuration for System A
The EIM Configuration wizard helps you create a basic EIM configuration. It also opens the Network Authentication Service wizard that you use to create a basic network authentication service configuration. - Configuring System B to participate in the EIM domain and configuring System B for network authentication service
After you have created a new domain and configured network authentication service on System A, you need to configure System B to participate in the EIM domain and configure network authentication service on System B. - Adding both i5/OS service principals to the Kerberos server
You can manually add the necessary i5/OS service principals to the Kerberos server. As this scenario illustrates, you can also use a batch file to add them. - Creating user profiles on Systems A and B
You want all of your users in the MYCO.COM Kerberos registry to map to a single i5/OS user profile on each of your System i platforms. Therefore, you need to create an i5/OS user profile on System A and System B. - Creating home directories on Systems A and B
Each user that connects to i5/OS and i5/OS applications needs a directory in the /home directory. This directory stores the user's Kerberos credentials cache. - Testing network authentication service on Systems A and B
After you complete the network authentication service configuration tasks for both of your systems, you need to verify that your configurations work correctly for both System A and System B. - Creating EIM identifiers for two administrators, John Day and Sharon Jones
As part of setting up your single sign-on test environment, you need to create EIM identifiers for two of your administrators so they can both log on to i5/OS using their Windows user identities. - Creating identifier associations for John Day
You must create the appropriate associations between the EIM identifier, John Day, and the user identities that the person represented by the identifier uses. These identifier associations, when properly configured, enable the user to participate in a single sign-on environment. - Creating identifier associations for Sharon Jones
You must create the appropriate associations between the EIM identifier, Sharon Jones, and the user identities that the person represented by the identifier uses. These associations, when properly configured, enable the user to participate in a single sign-on environment. - Creating default registry policy associations
You can use policy associations to create mappings directly between a group of users and a single target user identity. - Enabling registries to participate in lookup operations and to use policy associations
To use policy associations for a registry, enable their use for that registry as well as enable that registry to participate in lookup operations. - Testing EIM identity mappings
Now that you have created all the associations that you need, verify that EIM mapping lookup operations return the correct results based on the configured associations. - Configuring iSeries Access for Windows applications to use Kerberos authentication
Based on your single sign-on objectives, all users in the Order Receiving department must use Kerberos to authenticate before they can use iSeries Navigator to access Systems A and B. Therefore, you need to configure iSeries Access for Windows to use Kerberos authentication. - Verifying network authentication service and EIM configuration
Now that you have verified the individual pieces of your single sign-on configuration and ensured that all setup is complete, verify that you have configured Enterprise Identity Mapping (EIM) and network authentication service correctly and that single sign-on works as expected. - Optional: Post configuration considerations
The number of additional EIM users that you define depends on your security policy's emphasis on the separation of security duties and responsibilities.
Parent topic:
Scenarios: Using network authentication service in a Kerberos network
Related concepts
Single sign-on overview Domains