Achieving Windows Desktop SSO (SPNEGO) across distinct AD domains

I've been recently working on a requirement for a customer on the subject of SPNEGO based authentication for WebSphere Application Server (WAS), specifically for a set of AD domains that bound together with an 'External Domain Trust'. Based on my findings and the lengths I've needed to go to find out the relevant information, I thought it would be useful to write it all up in a post.

So to start with let me provide some (obfuscated) background on the target AD domains, which are named staff.ouA.com and staff.ouB.org. These two domains are linked using a two-way non-transitive 'External Domain Trust'. The two AD domains were originally completely separate, serving their own part of the organisation. Over time requirements have changed and a unified approach was required. This is was the point at which I arrived as centralised identity management was required to integrate and manage the patchwork of AD domains hosted by this customer.
The customer requirement was quite understandable and logical. Users from any of the existing AD domains should be able to securely access any secure business web applications by carrying out Windows Desktop SSO (SPNEGO).

The main difficulties I faced was that Microsoft's documentation on the subject of Windows authentication across an External Domain Trust, and perhaps to some degree IBM's also, was quite inconsistent. The fallout of this inaccuracy is that an organisation would believe that it was not possible to carryout SPNEGO authentication for disparate AD domains, and be forced to come up with unnecessarily complex security architecture.

For those who are less familiar with Active Directory Trusts, Microsoft Technet provides the following useful description as well an explanation of the various Trust types:

An Active Directory Trust:
Trust relationships between domains establish a trusted communication path through which a computer in one domain can communicate with a computer in the other domain. Trust relationships allow users in the trusted domain to access resources in the trusting domain.

Trust Types
External - A trust between domains within two distinct AD forests
Forest - A trust between domains in the same forest
Realm - A trust between a non-Windows Kerberos realm and a Windows Server 2003 domain
Shortcut - A trust between two domains in the same AD forest, predominantly for the purpose of improving system performance

The key point about the External Domain Trust that exists between my two target AD domains is that (almost) all of the official Microsoft documentation states that Kerberos authentication is not possible, just NTLM (also called NT Lan Manager). IBM's stance is that WebSphere ND does not support SPNEGO when an External Trust is used, which is probably because of the fact that Microsoft has stated that only NTLM tokens can be generated.
Authentication using NTLM tokens is widely as a weak security mechanism, which has several well publicised vulnerabilities that can lead to a complete breach of the credential and therefore a compromised file system. The severity of a single NTLM breach is so high as its tokens contain a hashed copy of a user's password. Kerberos tokens in contrast contain an encrypted ticket which is usable only for a single session.

What I have found using a couple of hard to find Microsoft documents and a Windows lab is that SPNEGO/Kerberos authentication using WebSphere is indeed possible when using an External Domain Trust. The architecture of my environment is illustrated below.

Using the above solution and the below scenarios, I was able to prove that Kerberos authentication is possible in such an environment.

Scenario 1: Single domain Windows SSO

• Logon into the staff.ouA.com domain as user swilliams2, using a standard Windows desktop machine (I used WinXP)
• Open a browser and request the secured target application protected.application.com
• The user is prompted for SPNEGO authentication (a 401 HTTP response is returned by WAS)
• The user contacts AD (actually the Kerberos Key Distribution Center - KDC) for a Service Ticket, referencing the Service Principal Name (SPN) HTTP/protected.application.com
• AD searches its repository for an account that is mapped to the required SPN
• AD finds a matching account
• AD generates a Service Ticket for the user and encrypts this using the account's credential
• The Service Ticket is returned to the user, who in turn sends this onto WAS
• WAS consumes the received encrypted Service Ticket, which has been packaged up in base64 encoded HTTP header called Authorization.
• Using its Kerberos keytab, WAS decrypts the Service Ticket (thus validating the ticket) and extract the Kerberos Principal name.
• The extracted principal name is defined as the user's identity
• WAS searches its repository for an account with a matching principal name (uid/cn)
  
• A WAS session is created for the user and a set of JSESSIONID (session and load balancing) and LTPA (authentication) cookies are returned
• The user is presented with their target page

Scenario 2: Windows SSO across an External Domain Trust

• Logon into the staff.ouB.com domain as user swilliams4 (the UID could have been the same as in the ouA.com domain) using a standard Windows desktop machine
  
• ........ and then surprisingly exactly the same as above!
  

To achieve this there a few key points to bear in mind both when working with a pre-existing or newly created set of domains that are linked using an External Domain Trust.

• The required SPN must be mapped to an AD account in every AD domain that is part of the environment requiring SSO
• The password of the all the service accounts sharing the same SPN must be exactly the same
• The UIDs of the service accounts can be different
  

You may be thinking after all that detail, that I didn't actually mention the External Domain Trust at all. That's because this solution does not in any way use or traverse the trust association. The SPN requested by the user's browser must exist in their 'home' domain. If this SPN cannot be found by AD, then an NTLM token will be returned for which WAS will thrown the user to the 'NTLM token received...' page. At no point are any referrals sent across the trust (i.e. the home domain didn't say to the user 'that SPN aa.bb.cc is hosted over in domain xxx.yyy').

The drawbacks of this solution is that an AD account must be created in every required domain and be mapped to the required SPN(s). Plus the password of all these accounts must be resynchronised whenever they are weekly/monthly/annually changed. To streamline this account management I used IBM Tivoli Identity Manager and its Active Directory adaptor. By using this product to create these accounts in the required domains and then associating them all with a Service entity with password synchronisation enabled, I was able to make sure that the solution did not become 'un-stitched' over time.

A better approach would be to have one AD account defined within a chosen 'primary' AD domain, with the required SPN(s) associated with just that account. From discussing this approach with my Windows AD colleagues it appears that AD definitions called 'Routing Hints' could be defined within the peer (non-primary) domains so that the External Domain Trust is actually used to go and find the required SPN within the 'primary' domain. I will be testing this approach in the coming days, so I'll post an update on the result of this.

To close, the customer I worked with on this requirement has been able to use this solution to define an enterprise wide SSO solution, which will positively affect the application experience and security controls for every one of their employees. In addition this solution will significantly simplify the SSO design for all existing and future applications that the customer deploys. It has been discovered however, that this solution would be unsupported by Microsoft.