(ZOS) Mapping a Kerberos principal to a System Authorization Facility (SAF) identity on z/OS
If we choose the Use the KERB segment of an SAF user profile radio button on the Kerberos panel of the WebSphere Application Server administrative console, we must have your Local OS users mapped to a specific Kerberos principal.
These instructions assume the use of z/OS Security Server (RACF ). If we use another security product, consult the vendor for more information.
To view the Kerberos administrative console page containing 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 apping 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.
This radio button must be selected if we 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.
If we select the option to use the built-in mapping module, we should not configure other custom JAAS login modules to map the Kerberos principal to a SAF identity.
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.
We must not include the Kerberos realm name when specifying the local Kerberos principal name.
Mapping a local Kerberos principal:
- For example, 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 we 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))
We 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 displayed:
KERB INFORMATION ---------------- KERBNAME= kerberosUser1 KEY VERSION= 001 KEY ENCRYPTION TYPE= DES NODES3 NODESDThe ALTUSER command should be issued for every user in RACF who needs to login to WAS using Kerberos.
The principal name is not converted to upper case and the realm name is not included. If the mixed-case password option is not enabled, the ALTUSER command converts the password to upper case. If this option is not in effect, 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. We must change the password for the user in order to create the Kerberos secret key.
Mapping a foreign Kerberos principal:
We can map each principal in a foreign realm to its own user ID in RACF, or we 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: The characters of the profile name of the KERBLINK class are not converted to upper case, so be sure to enter the realm portion of the profile name in upper case 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, 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
Create a Kerberos service principal name and keytab file Configure a Java client for Kerberos authentication Configure Kerberos as the authentication mechanism Set up Kerberos as the authentication mechanism for WAS Configure CSIv2 inbound and outbound communication settings Kerberos authentication settings Kerberos authentication commands CSIv2 inbound communications settings CSIv2 outbound communications settings