Friday, 27 July 2012

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 ): -

      <config:attributeConfiguration> 
        <config:attributes defaultValue="544" name="userAccountControl"> 
          <config:entityTypes>PersonAccount</config:entityTypes> 
        </config:attributes> 
        <config:attributes name="userPrincipalName" propertyName="uid"> 
          <config:entityTypes>PersonAccount</config:entityTypes> 
        </config:attributes> 
        <config:attributes name="samAccountName" propertyName="cn"> 
          <config:entityTypes>PersonAccount</config:entityTypes> 
        </config:attributes> 
        <config:attributes defaultAttribute="cn" name="samAccountName"> 
          <config:entityTypes>Group</config:entityTypes>
...

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

      <config:attributeConfiguration> 
        <config:attributes defaultValue="544" name="userAccountControl"> 
          <config:entityTypes>PersonAccount</config:entityTypes> 
        </config:attributes> 
        <config:attributes name="samAccountName" propertyName="cn"> 
          <config:entityTypes>PersonAccount</config:entityTypes> 
        </config:attributes> 
        <config:attributes defaultAttribute="cn" name="samAccountName"> 
          <config:entityTypes>Group</config:entityTypes>

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

I'd forgotten to explicitly add: -

        <config:attributes name="userPrincipalName" propertyName="uid"> 
          <config:entityTypes>PersonAccount</config:entityTypes> 
        </config:attributes> 

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: -


No comments:

Note to self - use kubectl to query images in a pod or deployment

In both cases, we use JSON ... For a deployment, we can do this: - kubectl get deployment foobar --namespace snafu --output jsonpath="{...