IBM WebSphere Application Server - Not returning group members from IBM Tivoli Directory Server

So this one has been bugging me for a few days.

I have WebSphere Application Server Network 7.0.0.25 hooking into IBM Tivoli Directory Server ( not sure which version ) over SSL.

WAS <-> LDAP connectivity is fine, and I can retrieve lists of users and groups from LDAP.

However, I am not able to see the members of LDAP groups via the WAS Integrated Solutions Console (ISC).

Navigating to Users and Groups > Manage Groups, I enter the group name - ibmbpm_Dev_Team - and click Search.

The group is returned, with the correct Unique Name ( Distinguished Name ).

However, when I click on the group name and click into the Members tab, I see no members and, in fact, see "The group has 0 members".

Needless to say, I can see the members if I connect to LDAP via a LDAP tool ( LDAP Browser Editor ).

I can see, from the exported LDIF, that the group has an objectClass of groupOfNames, and that the members ( 115 in total ) are objectClass of  member.

In WAS, under Global Security > Federated repositories > LDAP ( repository name ) > Group attribute definition, I've currently got Name of group membership unset ( null ), Scope of group membership attribute set to Direct and, under Member Attributes, I've got a single attribute ( member ) defined, with direct scope to object class groupOfNames.

Last time I had this problem ( with ComputerAssociates LDAP ), the problem was that the group was of objectClass groupOfUniqueNames and the members were of objectClass uniqueMember. Therefore, I needed to add the corresponding member attribute of uniqueMember.

However, this time around WAS VMM matches what I see in the LDIF - groupOfNames and member.

The one other strange thing is that, having enabled VMM etc. tracing: -

*=info:com.ibm.ws.security.*=all:com.ibm.websphere.security.*=all:com.ibm.websphere.wim.*=all:com.ibm.wsspi.wim.*=all:com.ibm.ws.wim.*=all

using the Must Gather: -

MustGather: Security problems for WebSphere Application Server

I can see, in trace.log, the group AND the members.

Therefore, it feels like the members ARE being returned from LDAP to VMM, but that the WAS ISC isn't displaying them.

The solution ?

So the trace had the answer - when I looked more closely, I could see the members listed: -

member:    T=e123456789
member:    T=h987654321

In other words, each member had an additional attribute ( T ), rather than the more standard uid or cn e.g. uid-e123456789 or cn=987654321.

The problem was that WAS didn't "know" about this attribute.

It was necessary to add this attribute into the PersonAccount objectClass.

Ironically, the client already had a Jacl script to do this very thing.

What's worse ?

One of my team had been telling me this for 2-3 days :-)

Once I executed the Jacl, and restart WAS, guess what ?

Yes, you've guessed it, the members started showing up in the WAS ISC.

The moral of the story ?

Listen to your colleague, and don't automatically assume that you know best :-)

*UPDATE 18 SEPTEMBER*

As per Sjaak's suggestion, the JACL script adds the T attribute into the PersonAccount Object Class; this is seen in wimconfig.xml which changes from: -

...
   
      uid
   
...

to: -

...
   
      uid
      T
    ...


*UPDATE 18 SEPTEMBER*

*UPDATE 1 OCTOBER 2015*

Here's the script: -

$AdminTask addIdMgrPropertyToEntityTypes { -name T -dataType String -isMultiValued false -entityTypeNames PersonAccount -repositoryIds  LDAP }

$AdminTask updateIdMgrSupportedEntityType { -name PersonAccount -defaultParent o=defaultWIMFileBasedRealm -rdnProperties uid;T }

$AdminConfig save

*UPDATE 1 OCTOBER 2015*