Thursday, 4 July 2013

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


using the Must Gather: -

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


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



to: -




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



Unknown said...

David ... It would be great if you explained what the jacl script did to the wimconfig.xml to solve your problem ... I guess lots of readers of this blog would be helped by that !

Sjaak Ursinus

Dave Hay said...

Hi Sjaak

Thanks for your feedback.

The JACL script adds a property to the PersonAccount Entity Type.

I'll add an update to the original post to indicate before and after.

Cheers, Dave

Sumit Tyagi said...

Hi Dave, I am having the similar issue in my environment. Can you please share the syntax of jacl which you used to update the wimconfig.xml or how does the uid parameter looks like eventually in wimconfig.xml ?

Dave Hay said...

Hi Sumit

Hmmm, the script is getting mangled by Blogger.

Let's try this: -

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

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

$AdminConfig save

Cheers, Dave

Sumit Tyagi said...

Hi Dave,

I just want to say thanks to you for providing these commands. They did exactly what I was looking for and I was struggling to get the exact solution. Thanks once again for your help, much appreciated !!

Thanks & Regards,
Sumit Tyagi

Dave Hay said...

Sumit, no problems, thanks for the kind feedback, cheers, Dave