One of the great features of Novell Access Manager is the integrated single sign-on capability from Microsoft Active Directory (AD) domain member workstations. Through the use of Kerberos and the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO), the Access Manager Identity Server (IdS) can seamlessly authenticate a Windows desktop.
Users logon to the desktop using their normal credentials and then when they attempt to access an Access Manager protected site, they are not required to login again. Instead, a token is passed to the Access Manager IdS from the workstation. The IdS then verifies that token and allows the user access per the policies as defined in Access Manager.
Complete details on configuring Access Manager can be found in the product documentation. This basically works by the client requesting a service ticket from the domain controller for the IdS. The actual name it passes to the domain controller is known as the Service Principal Name (SPN).
The SPN 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). So, for example, lets say that the DNS name of our IdS (the Base URL) is ids1.appdomain.com and our AD domain (the realm) is ad.appdomain.com. This would make our SPN, as sent by the workstation, the following:
This is what would be sent to the domain controller (the protocol is always listed as HTTP even if it is HTTPS). The client gets back a token that has information about the user in a service ticket encrypted within the token. This is passed in the header to the IdS where it is decrypted (using the shared secret in the nidpkey.keytab file). At this point the user is authenticated and Access Manager will grant or deny access as appropriate.
This all works fine as long as the fully qualified domain name used to build the SPN matches the actual DNS host record (A record) returned when the Windows desktop does a DNS query for ids1.appdomain.com. But what happens if a DNS alias record (CNAME record) is used? Lets say now that the actual hostname of the server acting as the IdS is linux1.appdomain.com and that the DNS record for ids1.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.
What happens in this scenario? When the client builds the SPN, it will look up ids1.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:
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
ids1.appdomain.com. IN A 10.1.1.1
This would result in a host record being returned to the client when it looks up ids1.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 ids1, 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:
However, the URL listed in the local trusted site list in the browser must still be the actual IdS base URL (ids1.appdomain.com in this example), not the true hostname as referenced in the A record.
Using the Kerberos feature in Access Manager is a great way to provide seamless single sign-on to Windows desktops. But it is important to understand how the client is resolving the IdS and building the SPN in order to ensure it functions reliably.
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.