Basic authentication popup window displayed when Kerberos authentication to Identity Server enabled

Kerberos authentication enabled in Linux Identity (IDP) Server. Users logon to the desktop using their normal credentials and then when they attempt to access an Access Manager protected site, they are required to login again instead of getting single signed on to the resource.

Using HTTP plug ins on the browser side, we could confirm that the kerberos token is passed to the Access Manager IdP server from the workstation. The IdS then tries to verify that token to allow the user access per the policies as defined in Access Manager, but fails in our environment.

Looking at the environment in more detail, we found the following:

- Service domain controller (SPN) for the setup is made up of three components, the protocol, the fully qualified domain name of the IdS and the client’s own AD domain name (known as the realm). In our setup, the DNS name of our IdS (the Base URL) is idp.appdomain.com and our AD domain (the realm) is ad.appdomain.com. The SPN, as sent by the workstation, was:

HTTP/idp.appdomain.com@AD.APPDOMAIN.COM

- DNS entries for Kerberos authentication devices. The actual hostname of the IDP server is linux1.appdomain.com;  the DNS record for idp.appdomain.com is actually a CNAME pointing at linux1.appdomain.com:

linux1.appdomain.com. 		IN A		10.1.1.1
ids1.appdomain.com.		IN CNAME	linux1.appdomain.com

Always use A records for your host headers - CNAME's do not work for Kerberos.

In the above example,wWhen the client builds the SPN, it will look up idp.appdomain.com which results in the CNAME being returned. It will then take the actual host record and use that to build the SPN, resulting in:

HTTP/linux1.appdomain.com@AD.APPDOMAIN.COM

This will be sent to the domain controller and will obviously fail since the SPN is incorrect, resulting in the browser being presented with a basic authentication dialog box (the IdS falls back to NTLM authentication).

The preferred solution to this problem is to put in a second host entry for the IdS, not a CNAME:

linux1.appdomain.com. 		IN A		10.1.1.1
idp.appdomain.com.		IN A		10.1.1.1

This would result in a host record being returned to the client when it looks up idp.appdomain.com and that is the value that would be used to build the SPN.

However, there are situations where it may not be possible to enter another host record in DNS. For example, some fault tolerant layer-4 switching solutions provide for management of DNS entries as well in order to support disaster recovery scenarios (such as F5 Networks’ Global Traffic Manager). In this case, the switch may be managing and changing the DNS entries for the virtual IP addresses. Some organizations might use a dedicated or unique zone name for this and therefore have all application names referencing the switch managed entries thorough DNS aliases. In this case, a CNAME must be used.

This will work with Access Manager as long as the true, resolvable, host entry is used for the SPN. So in this example, if a CNAME is used for idp, the value of linux1.appdomain.com would need to be used for the user ID in AD, in the Kerberos class properties (see figure 1), and in the bcsLogin.conf on the IdS server as shown below:

com.sun.security.jgss.accept {
com.sun.security.auth.module.Krb5LoginModule required
debug="true"
useTicketCache="true"
ticketCache="/opt/novell/java/jre/lib/security/spnegoTicket.cache"
doNotPrompt="true"
principal="HTTP/linux1.appdomain.com@AD.APPDOMAIN.COM"
useKeyTab="true"
keyTab="/opt/novell/java/jre/lib/security/nidpkey.keytab"
storeKey="true";
};