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.

Improving the audio quality of my portable digital music player

I have owned an Apple IPod Touch (3rd generation) for about 1.5 years and have used it like I'm sure a great proportion of the population do i.e. load it with all the music that I owned and have subsequently purchased, regardless of whether or not I intend to actually listen to it. Since catching the audiophile bug I've wondered if and how I could improve the audio playback quality of my current digital music player. This post will outline how I tried to achieve this and some of the interesting observations I made on the way.

So, as mentioned in a previous post I have centralised the storage and structure of my digital music collection within a Network Attached Storage (ReadyNAS) appliance. All of the music has been tagged using MediaMonkey and had album artwork added where missing. My chosen digital audio format is FLAC. This is because it:

1. lossless (the original recording untouched, but the data is compressed)
2. is able to support very high (HD) sampling rates (mp3 files are commonly sampled at 44KHz, but original recordings can be made at rates or 48, 92 and even 192KHz, giving you significantly more detail)
3. has fantastic software and hardware support (almost!) and is the format of choice for the digital audio authoring and publishing industries
   

So it seemed initially obvious that I should be able to just take the audio files that I have painstakingly (re)ripped at lossless quality (or purchased from sites such as HDTracks.com) and simply drop them onto my IPod. The reality was not so straight forward.

The most obvious and perhaps understandable issue was regarding size. A 'typical' MP3 track that is a few minutes long, recorded at a sampling rate of 44KHz will take up on average around 5MB of disk space. The same track recorded at 44KHz (not to mention 48 or 96KHz) in lossless would take about around 25MB. Scaling this up to an entire album means that you would get an average album for about 300MB, as opposed to 60MB in MP3 format. If the average music collection contained 100 albums, then this would require perhaps 30GB of your once limitless disk space. As my IPod Touch only has 30GB of disk space (actually 29.1 GB), which is partially used by the IPod OS and other nice things like Apps, Photos and Videos, I needed to sit down and think about what music I actually want to enjoy on the move, and what I wanted to reserve for my home audio system. Although not expected, this wasn't such a bad thing I believe as it allowed me to better appreciate the music I had and prioritise quality over quantity.

The second less-welcomed issue was specifically caused by my IPod. Apple does not support FLAC as a lossless digital music format, despite its widespread usage. Instead Apple have their own format called ALAC (Apple Lossless Audio Codec). Because FLAC and ALAC are both lossless formats, the data they contain can be restructured into either format easily using a number of free third party tools. To get my nicely tagged and formatted lossless music into iTunes and therefore my IPod I needed to firstly convert all my chosen music into ALAC. What would have been really useful would be if iTunes supported a FLAC to ALAC conversion process as an integrated feature.

I don't want you to think that I have any issues with Apple products; I am very happy with my Touch (less so with iTunes on Windows 7, but that's another story), I just think that Apple could make it much easier for its users to work with lossless digital music files if they have them. As a side note, this restriction is not specific to IPods. Before this I had a Creative Nomad Zen Xtra (they really knew how to name a product!), which was in my opinion much more straight forward to use as it was essentially a portable (40GB) hard disk that could play music. This too could not work with FLAC files and instead expected lossless tracks to be in WAV format.

Once I jam-packed my IPod with lots of lossless music I turned to the last piece of the 'improving audio quality' challenge - headphone/earphone quality. The earphones that come with any digital music player are almost always of a very low quality. Perhaps this is because large portions of the public do not have any desire to investigate better audio quality, therefore the manufacturers see an obvious ways to cut production costs. Replacing the out of the box earphones with even just a sub-£15 set from manufacturers such as Sennheiser, Creative, Ashure (amongst many others) would give a massive improvement in return.

This Christmas I received a pair of Sennheiser CX400-II noise-isolating earphones which I'm just breaking in now. These coupled with my lossless audio tracks have really opened my eyes (or should I say ears) to what is possible and what the original musicians were trying to achieve when they originally recorded their tracks. Pink Floyd's 'Wish you were here' and Miles Davis' 'Kind of Blue' for example sound simply amazing now.
I'm just trying to understand why I didn't go down this path much (much) sooner.

Hope this has been useful. Happy listening.