IBM Security Access Manager (ISAM) supports Kerberos constrained delegation single sign-on (SSO) for users in multiple Windows domains – in other words, ISAM is able to talk to Active Directory to obtain a Kerberos credential on behalf of a user, which it then presents to the target system (e.g. Sharepoint) – that way the user is logged on to the target system without needing to authenticate again.

(Since ISAM 8.0.0.4 ISAM has been able to perform this Kerberos functionality on its own, without requiring TFIM, and in ISAM 8.0.1 it was enhanced to enable the users to be in any Windows domain. However because of restrictions in Kerberos, both ISAM and the target web server needs to be in the same Windows domain.)

The formal documentation can be found at http://www-01.ibm.com/support/knowledgecenter/SSPREK_8.0.1.2/com.ibm.isamw.doc_8.0.1.2/wrp_config/concept/con_sso_kerberos_constrained_dele.html?lang=en .

I recently helped a customer to set this up, so I thought that it would be worth noting down some of the lessons we learned:

1. It is necessary to have two-way transitive trust between (a) the domain containing WebSEAL and the target web server, and (b) the domain containing the user.
2. It’s useful to know we have a customer with ISAM Kerberos multi-domain SSO working successfully with domain controllers running at the Windows 2003 Server functional level.
3. The manual says the following:
   Prepare the new user so that it can execute as a Kerberos service. You can use the ktpass command line utility that is provided as a part of the Windows support tools to do this. After the SPN has been set for the user, change the login name to reflect the SPN. For example: ktpass -out <Directory For Keytab> -princ HTTP/<Target Server Name>.<DNS domain name>@<AD DOMAIN NAME> -mapuser <Target User Name> -mapOp set -pass <Password> -pType KRB5_NT_PRINCIPAL
   ktpass -out C:\webseal.keytab -princ HTTP/target_service.ad_domain.com@AD_DOMAIN.COM -mapUser AD_DOMAIN\target_service -mapOp set -pass XXX -pType KRB5_NT_PRINCIPAL
   We found that for multi-domain Kerberos SSO support the SPN for WebSEAL needs to be of this format:
   HTTP/isam1.domain1.mycompany.com@DOMAIN1.MYCOMPANY.COM
   where:
   – The realm (such as  ‘DOMAIN1.MYCOMPANY.COM’)  must be an upper case version of the Windows domain name in which ISAM and the Kerberos targets reside.
   – The SPN (such as ‘HTTP/isam1.domain1.mycompany.com’) must be unique across the domains/forests.
   – The second part of the SPN (such as ‘isam1.domain1.mycompany.com’) must end in the Windows domain name in which ISAM and the Kerberos targets reside (although the name is not required to exist in DNS).
4. Regarding kerberos-user-identity, the example in the manual:
   kerberos-user-identity = @attr:FQDN
   is illustrative – it assumes that there is an attribute ‘FQDN’ in the credential that is there as a result of an EAI Server or user mapping.
   The name of the username attribute in the WebSEAL credential is AZN_CRED_PRINCIPAL_NAME. If the iv-user HTTP Header/username is set to username@domain-name, in order to generate a constrained Kerberos delegation token for username@domain-name it is possible to set:
   kerberos-user-identity = attr:AZN_CRED_PRINCIPAL_NAME
5. Debugging: there is some information in the pd.bst.general trace log. For a lot of the work it is necessary to run a packet capture of the communication between WebSEAL and the KDCs. The WireShark analysis of Kerberos traffic is very useful.
6. If you get error KRB5KRB_ERR_S_PRINCIPAL_UNKNOWN:
   – check that the SPN for kerberos-principal-name exists
   – check that there is just one instance of SPN for kerberos-principal-name across the domains/forests
   – check that the SPN for kerberos-principal-name ends in the Windows domain name in which ISAM and the Kerberos targets reside
7. If you get error KRB5KRB_AP_ERR_BADMATCH then check that there is just one instance of SPN for kerberos-principal-name across the domains/forests.
8. When running ktpass, if you get the error:
   ‘am_kinit: KDC reply did not match expectations while getting initial credentials’
   then ensure that the Realm name in the ktpass operation is an upper case version of the Windows domain name in which WebSEAL and the Kerberos targets reside.
9. When running ktpass, if you get the error:
   ‘am_kinit: Keytab contains no suitable keys for HTTP/*** while getting initial credentials’
   then ensure that the Realm name in the ktpass operation is an upper case version of the Windows domain name in which WebSEAL and the Kerberos targets reside.

I hope that this is of use to someone!

Vaughan

Tagged IBM Security Access Manager, ISAM, Kerberos, Kerberos constrained delegation, WebSEAL