Mapping a Kerberos principal to a System Authorization Facility (SAF) identity on z/OS

If you choose the Use the KERB segment of an SAF user profile radio button on the Kerberos panel of the WebSphere® Application Server administrative console, you must have your Local OS users mapped to a specific Kerberos principal.

Before you begin

These instructions assume the use of z/OS® Security Server (RACF®). If you use another security product, consult the vendor for more information.

To view the Kerberos administrative console page that contains the Use the KERB segment of an SAF user profile radio button, click Security > Global security. Under Authentication, click Kerberos configuration.

The first radio button on the Kerberos administrative console panel under Mapping Kerberos principal names to SAF identities, Do not use SAF profiles for mapping Kerberos principals to SAF identities, is selected by default, but will not use RACMAP or KERB segment for mapping.

Note: This radio button must be selected if you are using both the Local Operating System registry on z/OS and the built-in mapping module to map Kerberos principals to SAF identities.

The last two radio buttons under Mapping Kerberos principal names to SAF identities, Use the KERB segment of an SAF user profile and Use the RACMAP profiles in the SAF product for distributed identity mapping should not be selected if they already have a JAAS mapping module.

Avoid trouble: If you select the option to use the built-in mapping module, you should not configure other custom JAAS login modules to map the Kerberos principal to a SAF identity.

About this task

There are two ways to map a Kerberos principal to a SAF identity, depending on whether the Kerberos principal is local or foreign. A Kerberos principal is local when it exists in the z/OS KDC of the same z/OS system as the RACF database.

For more information on the using the ALTUSER command to configure your KDC, see Z/OS V1R7.0 Integrated Security Services Network Authentication Service Administration.

You must not include the Kerberos realm name when specifying the local Kerberos principal name.

Mapping a local Kerberos principal:

For example, if you want to map your RACF user USER1 to the local Kerberos principal name of kerberosUser1 (note that the Kerberos principal name is case-sensitive), issue the following RACF command:
ALTUSER USER1 PASSWORD(security) NOEXPIRED KERB(KERBNAME(kerberosUser1))
If you plan on inter-operating with a Windows KDC, specify that the encryption types of DES, DES3, DESD are not supported by issuing the following RACF command:
ALTUSER USER1 PASSWORD(SECURITY) NOEXPIRED KERB(KERBNAME(kerberosUser1) ENCRYPT(DES NODES3 NODESD))
Avoid trouble: You should ensure that the list of supported encryption types specified on the ALTUSER command is consistent with what is specified in the krb5.conf kerberos configuration file. For example, if the krb5.conf configuration file specifies that only aes256-cts-hmac-sha1-96 is supported, then the ENCRYPT operand should have all encryption types set as not supported, except for AES256.
To verify if the previous command completed successfully, issue the following RACF command:
LISTUSER USER1 KERB NORACF

At the end of the output, the following is an example of the Kerberos-related information that is displayed:

KERB INFORMATION                         
----------------                         
KERBNAME= kerberosUser1                  
KEY VERSION= 001                         
KEY ENCRYPTION TYPE= DES NODES3 NODESD

The ALTUSER command should be issued for every user in RACF who needs to login to WebSphere Application Server using Kerberos.

Note: The principal name is not converted to uppercase and the realm name is not included. If the mixed-case password option is not enabled, the ALTUSER command converts the password to uppercase. If this option is not in effect, you must ensure that the uppercase value is used when you request an initial Kerberos ticket. For more information on this option, read about Password case sensitivity using a local operating system registry. You must change the password for the user in order to create the Kerberos secret key.

Mapping a foreign Kerberos principal:

You can map each principal in a foreign realm to its own user ID in RACF, or you can map all principals in a foreign realm to the same user ID in RACF. To map a foreign Kerberos principal to a RACF user, define a general resource profile in the KERBLINK class. Each mapping is defined and modified using the RDEFINE and RALTER commands.

Note: Note: The characters of the profile name of the KERBLINK class are not converted to uppercase, so be sure to enter the realm portion of the profile name in uppercase and the foreign principal name in the appropriate case.

For more information on using the KERBLINK class, see the z/OS Security Server RACF Security Administrator's Guide.

For example, if you want to map the foreign Kerberos principal name foreignKerberosUser2 of the foreign realm FOREIGN.REALM.IBM.COM to the RACF user USER2, issue the following RACF command:
RDEFINE KERBLINK /.../FOREIGN.REALM.IBM.COM/foreignKerberosUser2 APPLDATA('USER2')
To verify that the previous command completed successfully, issue the following RACF command:
RLIST KERBLINK /.../FOREIGN.REALM.IBM.COM/foreignKerberosUser2

The mapped RACF ID is displayed in the APPLICATION DATA field as in the following example output of the RLIST command:

CLASS      NAME
-----      ----
KERBLINK   /.../FOREIGN.REALM.IBM.COM/foreignKerberosUser2

LEVEL  OWNER      UNIVERSAL ACCESS  YOUR ACCESS  WARNING
-----  --------   ----------------  -----------  -------
00    IBMUSER         NONE              ALTER    NO

INSTALLATION DATA
-----------------
NONE

APPLICATION DATA
----------------
USER2

AUDITING
--------
FAILURES(READ)

NOTIFY
------
NO USER TO BE NOTIFIED