Frequently Asked Questions

Q: What are the basic steps for configuring a password-elimination SSO solution? 

A: There are three components that comprise a password-elimination SSO solution: (1) the authentication component— which is Kerberos or Identity Tokens; (2) the authorization component—which is Enterprise Identity Management (EIM); and (3) the application-enablement component. 

For both Kerberos (or the IBM product known as Network Authentication Services) and EIM, IBM provides a respective iSeries Navigator configuration wizard that is run against each iSeries to be enabled for SSO. 

With respect to the application enablement component, IBM has already “Kerberized” and EIM-enabled many popular access methods to the iSeries for SSO, including PC5250 and iSeries Navigator (and there are more). So, for PC5250 and iSeries Navigator starting in V5R2 there are now configuration options that end-users must select in order to use Kerberos for authentication rather than userIDs and passwords. You can see how this is done by viewing our educational flash presentation here.

So, to get SSO (using EIM) to work, you need to: (1) configure each iSeries for EIM and Kerberos using the iSeries Navigator wizards; (2) create a Kerberos principal within Active Directory for each iSeries (using the ktpass command); (3) create the appropriate associations in EIM using TIM SSO; and (4) tell end-users to configure their clients to use Kerberos for authentication. You can undertake steps (1), (2) and (3) without impacting anyone—until an end-user configures their client application to use Kerberos for authentication, then they will still get prompted for a userID and password. 

A: The Windows desktop must be able to authenticate to a Windows domain, so typically Windows XP Professional or Windows 2000. Windows 98 users will not be able to do true SSO. All is not lost for Windows 98 users, however. They are able to load the MIT Kerberos for Windows code to implement ticket caching and handle authenticating to Kerberos. It will require two sign-ons, but then connections to Kerberized applications will authenticate without having to sign-on again. Windows 95 does not support Kerberos. 

Q: What iSeries applications have been enabled by IBM for SSO using EIM and Kerberos? 

A:

• OS/400 V5R2 
• iSeries Access 
• iSeries Navigator 
• Telnet (includes PC5250) 
• ODBC/JDBC/DRDA 
• LDAP 
• QFileSvr.400 
• Post V5R2 GA
• Apache Web Server (PTF Group SF99098)
• IBM WebSphere Host On-Demand (PTF level IP22748)

Q: What if I authenticate to Novell eDirectory instead of Microsoft Active Directory?

A: The key point to note is that password-elimination SSO for Windows clients requires Kerberos for authentication, yet Novell eDirectory does not come with a Kerberos Key Distribution Center (KDC).  So, for SSO to be configured, a KDC must be introduced into the customer's network.

Acronyms referenced below:

• Enterprise Identity Mapping (EIM)
• Kerberos Key Distribution Center (KDC)
• Novell Modular Authentication Service (NMAS),
  a component of Novell eDirectory
• Graphical Identification and Authorization (GINA), describes an interface for the validation of logon credentials) (GINA)

There are two variables in play:

• Are the end-user computers (desktop or laptop) in a Windows domain or not?
• Do the end-users authenticate using a Novell GINA or a Microsoft GINA?

Given this:

• It does not matter which KDC is configured (i.e., Windows, i5/OS V5R3, Linux, etc.).  It only matters that a KDC exists, because password-elimination SSO built on EIM for authorization utilizes Kerberos for authentication.
• If a Windows domain is not configured, the end user computers must use a Microsoft GINA.

The end-user computers must be configured to:  (1) know what Kerberos realm they are in, (2) where its KDC is, and (3) set its Kerberos password. This is accomplished by the end-user running a series of commands (ksetup) on their computer.

The end-user computers must also have a corresponding account in the Kerberos realm. This is accomplished by an administrator adding a user to Active Directory that represents the end-user’s computer and using the ktpass command to:  (1) set a DES password; (2) associate a Service Principal Name (SPN) with the end-user’s computer (just like when adding an iSeries SPN); and (3) check the option on user accounts that allows the use of DES passwords.

• If a Windows domain is configured, then end-user computers can use either the Novell GINA or the Microsoft GINA.

If passwords are not synchronized between Novell eDirectory and Microsoft Active Directory, then using the Microsoft GINA in conjunction with the NMAS plugin will prevent the end-user computer from also prompting for Novell eDirectory credentials.

If Novell eDirectory and Kerberos passwords are synchronized then the NMAS plugin is not required.  Synchronization can be accomplished with Novell’s DirXML product.  There are other ways as well.  In addition to other synchronization products being available on the market, if the end user’s computer uses the Novell GINA then it can be configured to also change the Windows password.

A: Yes. There are new functions being introduced in i5/OS V5R3 that can help enable WebSphere applications for password-elimination Single Sign-On. The first is a JCA connector that is being added to the IBM Java Toolbox. This connector will use a new technology called Identity Tokens. These tokens will allow you to authenticate to other iSeries without having to pass around userID and password.  For more information about this support, including required PTFs, please click one of the following URLs: 

WebSphere Application Server, Configuring the Enterprise Identity Mapping (EIM) Identity Token Connection Factory 

5722-XH2 V5R3 iSeries Access for Web, Configuring the use of authenticated WebSphere credential for SSO (Single Sign-On) with iSeries Access for Web portlets and WebSphere Portal Express for iSeries V5.0 

The second is the ability of the Apache Web Server on iSeries to negotiate authentication with Internet Explorer. The Apache support was added in December 2003 to OS/400 V5R2 via a group PTF. 

The following text is directly copied from a 2004 book co-authored by Carol Woodbury and Pat Botz titled, Experts’ Guide to OS/400 & i5/OS Security:

New in i5/OS 
IBM announced an exciting new capability for creating SSO-enabled WAS and Portal Server applications that access OS/400 and i5/OS services. This capability doesn’t use Kerberos, but it does exploit ElM. The result is the same, but the way things work under the covers is different. Several products from IBM will make use of this new capability, including iSeries Access for the Web, WebFacing, and WebSphere Development Studio Client (WDSc) Web Tools. 

The new function is based on a new technology IBM calls identity tokens. Identity tokens essentially authenticate the WAS/Portal Server application to OS/400-i5/OS (rather than directly authenticate the WAS/Portal Server user to OS/400-i5/OS). The WAS/Portal Server application tells OS/4OO-i5/OS the name of the WAS/Portal Server user who is making the request. As part of the process of verifying the identity token on OS/400-i5/OS, an identity mapping is done to map from the WAS/Portal Server user to the appropriate user profile on the OS/400-i5/OS system. OS/400-i5/OS then swaps to this user profile, and all authorization checks on OS/400-iS/OS are done under that user ID. 

Identity tokens can also be delegated from one OS/400-i5/OS instance to another. A distinct advantage of identity tokens is that audit entries created on the OS/400-i5/OS side include information about the WAS/Portal Server user, each application to which the identity token has been sent or delegated, and the OS/400-i5/OS user profile that was ultimately used to process the request. This information provides a complete view on the endpoint system of the request that flows through the network. Another advantage of identity tokens is that they don’t require user IDs and passwords to be cached on either the client or the server. 

Identity tokens introduce a third prong in the OS/400-i5/OS SSO strategy. You can now pair ElM technology with either Kerberos or identity tokens. In fact, ElM is the underlying technology for the implementation of identity tokens. Whether you choose Kerberos or identity tokens for the applications you write depends on the environment for which you’re building your application. If your application is Windows-based, use Kerberos. If the client application is WAS- or Portal Server-based, use identity tokens. 

The SSO capability is implemented in WAS and Portal Server applications by exploiting an Identity Token Java Connector Architecture (JCA) connector (also known as a “resource adapter”) provided by IBM. The Identity Token JCA connector returns an identity token to the application, which then passes the identity token to an AS/400 Java TooIbox object. The Java Toolbox has been enhanced to know how to use identity tokens to create an authenticated connection to OS/400-i5/OS. 

When you build applications using this implementation of identity tokens, you should treat the identity tokens as if they were real user profiles and passwords. You should consider using Secure Sockets Layer (SSL) in your applications to protect against replay attacks. 

Although the new function didn’t make it into the base i5/OS, it will he provided via PTFs for OS/400 and i5/OS at or some time near the General Availability date of i5/OS. You’ll also be able to find the function on the Web at http://www.ibm.com/eserver/iseries/toolbox/downloads.htm. 

Q: How can SSO be enabled for Domino and a native Lotus Notes client? 

A: Lotus Notes is enabled for SSO based on the end-user’s Windows userID and password.  The Lotus Notes client can be deployed in a way such that when the end-user clicks on their Notes desktop icon, the windows userID and password is used for authentication. This is called the “Client Single Logon Feature.” When deployed this way, an end-user's Lotus Notes password is changed at the same time that their Windows password is changed. 

Lotus Notes client userID and password security is actually maintained in a digital certificate. This digital certificate is encrypted on the client with the Notes password. Once decrypted, the digital certificate is used to authenticate with the Domino server. So when the password is changed on Windows, the Lotus Notes client intercepts the change, uses the old password to decrypt the digital certificate and then re-encrypts it with the new Windows password. 

The text below is from Notes 6 client help. It turns out there is a component that must be selected at install time. 

To synchronize your Windows NT/2000 password with your Notes password, you must uninstall Notes. Then use the following procedure when you reinstall Notes. Note if you are uninstalling Notes, make sure to back up important files that you might need such as your bookmarks, Personal Address Book, and UserIDs. 

Note If you use a Smartcard to login to Notes, or if your UserID is protected by multiple passwords, Windows NT/2000 password synchronization is not supported. 

To install and enable single login:

1. While installing Notes, choose to install "Client Single Logon Feature" in the "Custom Setup" dialog box of the "Lotus Notes 6 InstallShield Wizard," and then finish installing Notes. 
2. Launch Notes to set up the Notes Client. 
3. After Notes has been set up, change your Notes password so it matches your Windows NT/2000 password. Note that when you choose File - Security - User Security (Macintosh OS X users: Notes - Security - User Security), the option "Login to Notes using your operating system login" is enabled by default in Security Basics. 
4. When you have changed your Notes password to match your Windows NT/2000 password, exit Notes and restart your computer. When prompted, login to your computer using your Windows NT/2000 password. When you launch Notes, you should not be prompted for a password.

Note: Once the single login feature is installed on your computer, you can enable and disable it at any time. 

To change your synchronized password:

When synchronization is enabled, you can change your synchronized password at any time. Whether you change your password through Windows or through Notes, the passwords synchronize so you can use the new password the next time you login to Windows or Notes. To change it through Windows, refer to Windows Help. You can change your synchronized password through Windows only if your Windows and Notes passwords already match. Otherwise, you must change it through Notes. To change it through Notes, see Changing passwords. 

Q: Where can I host an EIM domain? 

A: EIM domains are maintained in a LDAP directory; specifically (and only) IBM's implementation called IBM Directory Server. IBM Directory Server is integrated into OS/400 and i5/OS.  This, along with the iSeries reliability and scalability make it a good choice to host an EIM domain. IBM Directory Server is also freely available for Windows Server as well as several Unix and Linux distributions. and available for Windows as well as other platforms. 

See IBM Tivoli Directory Server for more details.

A: TriAWorks Identity Manager for Single Sign-On (TIM SSO), does not currently create home directories for iSeries user profiles. 

While it is generally a good idea to create home directories for iSeries user profiles, it is not required depending on the services you intend to use to access the iSeries. For example, if you intend to only access the iSeries using PC5250 you would not need to create iSeries user profile home directories. 

The iSeries user profile home directory is used for a credentials cache when accessing another registry from an iSeries. This credentials cache must be unique for each person and is thus maintained in their home directory. The Distributed Data Management (DDM) service would probably be the most likely instance of this scenario. For example, the end-user first authenticates to a Windows domain, then accesses an iSeries, and then invokes DDM to access files on another iSeries. 

Q: After authenticating to a Windows domain (Kerberos), can end-users access an iSeries with a disabled user profile? 

A: End-users can access an iSeries with an expired password, because Kerberos tickets and not passwords are used for authentication. 

End-users can not access an iSeries with a disabled user profile, however. 

Q: How do HATS and HATS-LE work with EIM? 

A: You cannot enable password-elimination SSO with HATS running from a portlet running on WebSphere on Linux.  HATS-LE (which essentially converts 5250 green screens to web pages) will only run on iSeries but does support SSO. Full HATS will run on Linux is has not been proven (something doesn't read right here) to be SSO enabled. Also HATS-LE will not run in Portal Server. 

SSO can be achieved by using an LTPA cookie that is common to both the WebSphere and Domino servers. This means the browser client must have cookie support enabled for this to work. LTPA allows WebSphere and Domino servers to authenticate to a common user directory using the Lightweight Directory Access Protocol (LDAP). This allows the use of Domino's Name and Address Book or any other LDAP V3-compatible user directory, such as Netscape Directory Server, IBM SecureWay Directory, Novell Directory Server (NDS) or Active Directory. 

To enable SSO, a common set of server encryption keys are created and exported across all servers that run the application. When users first access the site, they are challenged to login with userID and password. This creates a security credential token with the Lightweight Third Party Authentication (LTPA) service, and a cookie is written back to the browser. When the user later accesses another LTPA server in the same domain, information in the shared cookie is used to re-establish the user security context with LTPA. Hence, a second login prompt is unnecessary. 

The LTPA cookie contains the following pieces of information: 

• Cookie name: Always set to LTPA Token. 
• Domain: Set to the Internet domain shared by all servers participating in single sign-on (example: mycompany.com). 
• Cookie expiration: Set to delete this cookie at the end of the browser's lifetime. 
• Secure: Set to "on" to force the use of Secure Sockets Layer (SSL). There is an LTPA configuration setting that creates cookies that are sent only through SSL. 
• Cookie value: This is set to the LTPA token as described below.

The LTPA token is an encrypted string that contains the following pieces of information: 

• User data: Typically set to the userID but can be any user information used to uniquely identify the user.
• Expiration time: Different from the Cookie expiration, this field is used to enforce a time limit that starts from the moment of login and is unaffected by browser activity or inactivity. The time limit is a configurable LTPA setting that defaults to 30 minutes.
• Digital signature: Used to validate the token.

Q: Can iSeries Access for Web be enabled for password-elimination SSO? 

A: Yes. Rather than Kerberos tickets being used for authentication, Identity Tokens are. Kerberos tickets are used to SSO enable Windows applications and Identity Tokens are used to SSO enable Java applications served by WebSphere (like iSeries Access for Web). Identity Tokens require EIM. 

The following host servers are enabled for password-elimination SSO using Identity Tokens: 

• Sign-on server
• Central server 
• File server 
• Database server 
• DRDA and DDM server 
• Data queue server 
• Remote command server 
• Distributed program call server 
• Network print server 

IBM has enabled the following applications for password-elimination SSO using Identity Tokens:

• iSeries Access for Web 
• WebFacing
• WebSphere Development Studio Client (WDSc) Web Tools

Q: Is z/OS enabled for password-elimination SSO? 

The following z/OS services are Kerberized: 

• DB2 V7 and DB2 Connect V7.1 FP2 
• WebSphere V4
• FTP V1R2
• Telnet Server V1R2
• Remote Shell (RSH) Server V1R2
• LDAP with z/OS V1R4
• EIM z/OS V1R5

So, while there is limited exploitation of EIM in z/OS, RACF does support Kerberos. So, you can use Kerberos and EIM on OS/400 and just Kerberos on z/OS. This will not enable you to eliminate RACF passwords, but it lets you use your Windows sign-on to access z/OS. You cannot have a different user id in Windows and z/OS. 

In order to make this work you have to make the Windows userID (i.e. Kerberos principal) the same as the RACF principal. RACF allows you to assign a Kerberos principal to a RACF ID. So that you do not really have to change a RACF userID, you must assign another name to an existing RACF userID. For example, if a RACF userID is FREDDY you could set the Kerberos principal to fred@TRIAWORKS.COM and as long as the Windows user principal name is also fred@TRIAWORKS.COM then RACF will make the proper association and use the FREDDY userID. 

Q: Does Computer Associates CA-ACF2 support Kerberos? 

A: ACF2 does support Kerberos and also supports Digital Certificates for authentication. 

The KERB segment of the USER profile maps Kerberos for z/OS and OS/390 application user identity to an eTrust CA-ACF2 logonID. The KERBLINK USER profile record defines the foreign principals to a local node by linking it to a defined user. KERBLINK profiles can define an individual principal from a foreign realm or all principals from a particular foreign realm. The local LID does not need to have a KERB User Profile record associated with it. The Kerberos segments are documented below: 

KERB-VIO - Specifies the number of Kerberos key violations. This field is similar to the PSWD-VIO count and will be used with the PSWD-VIO count to suspend the user’s LID when the combined counts exceed the global PSWDLMT count field. 

KERBCUR - Specifies the current Kerberos key. This field is not modifiable via the ACF command and is only updated when the password is modified. 

KERBCURV - Specifies the current Kerberos key version. This field is not modifiable via the ACF command and is only updated when the password is modified. 

KERBPRE - Specifies the previous Kerberos key. This field is not modifiable via the ACF command and is only updated when the password is modified. 

KERBPREV - Specifies the previous Kerberos key version. This field is not modifiable via the ACF command and is only updated when the password is modified. 

Digital Certificates are also supported: 

If MVS resources are accessed, the certificate is presented to eTrust CA-ACF2; using the certificate serial number and the issuer's distinguished name, eTrust CA-ACF2 associates the certificate with an MVS userid. An MVS security environment is then created for that user. By using authenticated certificates, passwords are not sent through the network. 

eTrust CA-ACF2 provides complete functionality to generate, install, and maintain digital certificates, key rings, and digital certificate mappings, including the following: 

• Generate a digital certificate and a public/private key pair 
• Create a PKCS #12 certificate package
• Create a PKCS #10 certificate request
• Export a digital certificate or certificate package and private key from eTrust CA-ACF2 to a z/OS and OS/390 dataset
• Display a certificate that is in a z/OS and OS/390 dataset and determine if it is associated with an eTrust CA-ACF2 user
• Display a certificate registered with eTrust CA-ACF2
• Automatically register a digital certificate with eTrust CA-ACF2
• Associate an eTrust CA-ACF2 user with a digital certificate
• Change, display, and delete information about a digital certificate for an eTrust CA-ACF2 user
• Create, change, display, and delete a key ring 
• Add and remove a certificate from a key ring 
• Assign an eTrust CA-ACF2 user to a group of certificates via userID mapping 
• Assign an eTrust CA-ACF2 user to a group of certificates based on system ID, application ID, or application-defined variables 
• Change, delete, and display an eTrust CA-ACF2 user ID mapping 

More detail on both options can be found in the eTrust CA-ACF2 Security Cookbook.

A: The MIT implementation of Kerberos is native to Red Hat Linux; but even if it was not, it could be downloaded for free
(it is open source).

SuSE and most other non-USA Linux flavors implement the Heimdal version (this is due to cryptographic export restrictions; the Heimdal implementation originated in Sweden). Heimdal can be downloaded here for free.

Both MIT and Heimdal provide already compiled binaries for many operating systems and chipsets, but the source is also freely available and can be compiled for most every flavor of Linux, if need be. 

Q: If we implement password-elimination SSO is there anything we can do to improve desktop security? 

A: Provided end-users authenticate to a Windows domain, there is a solution for this: Windows Group Policy capabilities. See the following URLs for more information: 

Windows 2000 Group Policy

Windows Server 2003 Group Policy

 Using a group policy, a network administrator can control the desktop screen saver settings on end-user computers—both the wait time before the screen saver starts and the “On resume, password protect” checkbox. 

Group policies are very powerful. It is possible to enable group policy at the domain level and control these settings such that the user is unable to change them. There are not many end-user desktop settings that cannot be controlled in this way. Group policies are also hierarchical so you can set a domain level policy and override at lower levels, like for an ou or a group or a user.