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