Desktop SSO with WebSphere Application Server 7 and MS Active Directory - It's Ain't Working

Am posting this to remind myself how to resolve an issue of my own making.

Yesterday, I was working to resolve an issue whereby users from one of a number of Active Directory domains were unable to automagically log in to WebSphere Application Server v7 ( hosting IBM Connections v3 and IBM WebSphere Portal v7 ) using SPNEGO/Kerberos.

The user would arrive at the site, via a load-balanced URL, but would be presented with the login page, rather than getting into the application transparently.

I knew that this worked for me, in another AD domain, so was reasonably confident that the AD and SPNEGO configuration was OK.

Therefore, I enabled tracing in WAS using this trace string: -

*=info: com.ibm.ws.security.spnego.*=all

( I love the way that WAS 7 allows one to enable tracing in-flight, without needing to restart the JVM ).

I saw the usual bunch of SPNEGO messages, indicating that WAS was pulling out the userPrincipalName (UPN) attribute e.g. hayd@foobar.com from the SPNEGO token.

However, I also saw references to a First Failure Data Capture (FFDC) log, and a corresponding com.ibm.websphere.wim.exception.EntityNotFoundException error.

This was the main error within the FFDC log: -

...
[25/07/12 17:13:28:341 BST]     FFDC
Exception:com.ibm.websphere.wim.exception.EntityNotFoundException
SourceId:com.ibm.websphere.security.EntryNotFoundException ProbeId:190
Reporter:com.ibm.websphere.security.EntryNotFoundException@48104810

com.ibm.websphere.wim.exception.EntityNotFoundException: CWWIM4001E The 'bloggsf@snafu.com' entity was not found.
 at com.ibm.ws.wim.registry.util.UniqueIdBridge.getUniqueUserId(UniqueIdBridge.java:226)
 at com.ibm.ws.wim.registry.WIMUserRegistry$6.run(WIMUserRegistry.java:365)…

Given that the error was coming from the WebSphere Identity Manager (WIM) component of WAS, I had a fair suspicion of the root cause.

I compared and contrasted the cell-level wimconfig.xml file, looking at the working domain ( for the UPN hayd@foobar.com ): -

…
     
       
          PersonAccount
       
       
          PersonAccount
       
       
          PersonAccount
       
       
          Group...

and the failing domain ( for the UPN bloggsf@snafu.com ): -

…
     
       
          PersonAccount
       
       
          PersonAccount
       
       
          Group…

Can you spot the error ? I bet you can ….

I'd forgotten to explicitly add: -

       
          PersonAccount
       
to the definition for the newly added realms ( for the two new AD domains ).

Therefore, WAS/WIM was correctly pulling the userPrincipalName attribute, but did not know what to do with that i.e. what to map it to in WIM.

Once I explicitly mapped userPrincipalName to uid, WAS/WIM could then correctly use it as a login attribute ( along with commonName - cn ), and SSO started working.

Something else to add to my ever-evolving presentation: -

Desktop Single Sign-On in an Active Directory World