ldapopen-liberty

Liberty LDAP always uses full DN to search for group membership

OpenLiberty 23.0.0.9 connected to OpenLDAP 2.5.16. Using a custom filter in

Users are identified by uid - eg, user Roy McRoy has uid of 'roy'.

Groups are of objectClass posixGroup. Members are identifed by the 'uid' value in the MemberUid attribute. For example, Group 'Controlled' has an attribute value 'MemberUid:roy' to show roy is a member of the 'Controlled' group.

How it looks in Apache Directory Studio

The groupMemberIdMap is "posixGroup:memberUid"

BUT - and here's the problem! - when Liberty searches Groups to find the MemberUid values, it ALWAYS searches using the user's full DN= , not just the short uid value.

I want to configure the LDAP Repository in Liberty so that Liberty will search groups for:

memberUid=roy

... and not ...

memberUid=cn=roy,ou=i2users,dc=i2support,dc=lan

But so far nothing seems to work. What am I doing wrong? How can I search group memberships for just 'roy'?

Turning on LDAP logging via element in server.xml shows Liberty using the full DN value for roy, as the search term:

[2023-12-24T14:55:17.909+1100] 0000002f LdapConnectio >  search Entry  
         dc=foosupport,dc=lan
         (&(|(objectClass=posixGroup)(objectClass=posixgroup))(memberUid=cn=roy,ou=foousers,dc=foosupport,dc=lan))
         null
   javax.naming.directory.SearchControls@25af6f52
         null
[2023-12-24T14:55:17.909+1100] 0000002f ContextManage >  getDirContext Entry

Which correctly finds no groups - because the real value of MemberUid is just 'roy', not 'cn=roy,ou=foousers,dc=foosupport,dc=lan'

Here is my repository:

<ldapRegistry id="OpenLDAPreg"
              ldapType="Custom"
              realm="ldapRealm"
              host="LDAP01.foobar.lan"
              port="389"
              baseDN="dc=foobar,dc=lan"
              bindDN="cn=Manager,dc=foobar,dc=lan"
              bindPassword="P@ssword01!">
    <customFilters userIdMap="*:uid"
                   groupIdMap="*:cn"
                   userFilter="(&amp;(uid=%v)(objectclass=person))"
                   groupFilter="(&amp;(cn=%v)(|(objectclass=posixGroup)))"
                   groupMemberIdMap="posixGroup:memberUid">
    </customFilters>
</ldapRegistry>

Here is the LDIF information:

  1. User 'Roy McRoy"
[root@LDAP01 ~]# ldapsearch -xLLL -D "cn=Manager,dc=foosupport,dc=lan" -W "(uid=roy)"
Enter LDAP Password: 
dn: cn=roy,ou=foousers,dc=foosupport,dc=lan
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
uid: roy
sn: Analyst
displayName: Roy McRoy
mail: fred@foosupport.lan
userPassword:: UEBzc3dvcmQwMSE=
cn: roy
  1. Group "Controlled"
[root@LDAP01 ~]# ldapsearch -xLL -D "cn=Manager,dc=foosupport,dc=lan" -W "(&(objectClass=posixGroup)(cn=Controlled))"
Enter LDAP Password: 
version: 1

dn: cn=Controlled,ou=fooGroups,dc=foosupport,dc=lan
gidNumber: 259
cn: Controlled
objectClass: posixGroup
objectClass: top
memberUid: bill
memberUid: fred
memberUid: roy
  1. My own ldap search to see if roy is a member of group Controlled works fine:
[root@LDAP01 ~]# ldapsearch -xLL -D "cn=Manager,dc=foosupport,dc=lan" -W "(&(objectClass=posixGroup)(memberuid=roy))"
Enter LDAP Password: 
version: 1

dn: cn=Analyst,ou=fooGroups,dc=foosupport,dc=lan
gidNumber: 257
cn: Analyst
objectClass: posixGroup
objectClass: top
memberUid: roy
memberUid: fred
memberUid: bill

dn: cn=Controlled,ou=fooGroups,dc=foosupport,dc=lan
gidNumber: 259
cn: Controlled
objectClass: posixGroup
objectClass: top
memberUid: bill
memberUid: fred
memberUid: roy

[root@LDAP01 ~]#

How can I make Liberty search for Group memberships, like my own ldapsearch commend searches?

There is no scope to change the LDAP database, it belongs to a Federal govt organization with thousands of users, hundreds of offices, and many other LDAP-consuming applications. I have to make Liberty work with the LDAP server, not vice versa.

Very grateful for any assistance!

Solution

  • In the end, we opened a PMR with IBM so the WebSphere SMEs could look at it. Their answer: it can't be done in Liberty. Liberty will ALWAYS search for group membership using full DN, you can't force it to use a truncated uid value.

    Arguably the underlying problem is ambiguity in RFC 2307. It defines memberUid in the schema, but doesn't say what data should go in the memberUid value. One implementation could use plain uid, another implementation use the full DN. They're both "RFC-compliant" - but incompatible.

    So we're giving up on LDAP and looking at client certificate authentication instead.