LDAP groups - does not store name in LDAP directory

I’m using an LDAP server, where the group membership only includes the user Id as the group member, so I end up with my group members shown as

uid1@domain

uid2@domain

and so on, instead of a name. I was debugging the LdapGroupProvider class and was wondering how to address this problem.

I guess there are two options

  1. Make the user manager grab the user Id when it fetches users from ldap and the group provider can correlate against the local user cache

  2. Make the group provider do a lookup of the user by it’s group membership id.

Neither of these are trivial, (1) would require changes to the user management - I’m not sure the size of this and (2) would require some way to configure this operation mode and then further searches to lookup the memberships.

Even having done this, I’m not sure of the implications of group handling in the rest of Openfire and also the issue of performance might make this impractical.

Does anyone have any comments on whether there is a simpler way to address this or what might be the best approach. The LDAP server is cast in stone, so there’s nothing that can be done there.

Thanks

Antony

Can you provide a dump of a sample user object and group objects including attribute names? How do DNs look like?

Hi Marcin,

Here’s a user object

dn: cn=Test One,l=Sydney,o=Teamware,c=AUmail: t1@officea.teamw.com
twId: VBEAAAAAAAAAFAAAZAABIfRXAeRU
twOId: VBEAAAAAAAAAEwAAZAABIfRXAeRU
twHSId: VDUAAAAAAAAAAQAAZAABIfRXAeRU
twHAId: VIf//////////QAAZAABIfRXAeRU
twEACL: 0
twUT: 1
twSYSN: TW
twUS: 1
twUS: 2
twUS: 4
twUS: 5
twLN: t1
twHOId: VIn//////////gAAZAABIfRXAeRU
twV: TW5
twCAS: 0
twPId: VIf//////////QAAZAABIfRXAeRU
twBAN: 504c$1
twGC: 44
twPDM: 7
twLM: 1297228151
objectClass: twPerson
objectClass: twObject
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Test One
sn: Test
givenName: One

and this is a group object

dn: cn=All test users,l=Sydney,o=Teamware,c=AU
twId: VBUAAAAAALwAOgAAZAABIfRXAeRU
twOId: VBEAAAAAAAAAEwAAZAABIfRXAeRU
twHSId: VDUAAAAAAAAAAQAAZAABIfRXAeRU
twHAId: VIf//////////QAAZAABIfRXAeRU
twEACL: 0
twHOId: VIn//////////gAAZAABIfRXAeRU
twV: TW5
twGT: 0
twGMAS: 0000$VBEAAAAAAAAAGwAAZAABIfRXAeRU$$2
twGMAS: 0001$VBEAAAAAAAAAGAAAZAABIfRXAeRU$$2
twGMAS: 0002$VBEAAAAAAAAAFwAAZAABIfRXAeRU$$2
twGMAS: 0003$VBEAAAAAAAAAHAAAZAABIfRXAeRU$$2
twGMAS: 0004$VBEAAAAAAAAAFAAAZAABIfRXAeRU$$2
twGMAS: 0005$VBEAAAAAAAAAGgAAZAABIfRXAeRU$$2
twGMAS: 0006$VBEAAAAAAAAAGQAAZAABIfRXAeRU$$2
twGMAS: 0007$VBEAAAAAAAAAHQAAZAABIfRXAeRU$$2
twGMAS: 0008$VBEAAAAAAAAAFgAAZAABIfRXAeRU$$2
twGMAS: 0009$VBEAAAAAAAAAFQAAZAABIfRXAeRU$$2
twGST: 0
twPId: VIf//////////QAAZAABIfRXAeRU
twGP: 0
twGC: 1
twM: VBEAAAAAAAAAFAAAZAABIfRXAeRU
twM: VBEAAAAAAAAAFQAAZAABIfRXAeRU
twM: VBEAAAAAAAAAFgAAZAABIfRXAeRU
twM: VBEAAAAAAAAAFwAAZAABIfRXAeRU
twM: VBEAAAAAAAAAGAAAZAABIfRXAeRU
twM: VBEAAAAAAAAAGQAAZAABIfRXAeRU
twM: VBEAAAAAAAAAGgAAZAABIfRXAeRU
twM: VBEAAAAAAAAAGwAAZAABIfRXAeRU
twM: VBEAAAAAAAAAHAAAZAABIfRXAeRU
twM: VBEAAAAAAAAAHQAAZAABIfRXAeRU
twLM: 1301537882
objectClass: twObject
objectClass: twGroup
objectClass: top
cn: All test users

The twM attribute in the group object is the reference to the twId attribute in the user object.

Can you show me your ldap.* properties? I assume you are running with ldap.posixMode=true

Basically the LDAP manager does follow the process you have described (it loads user entry for each group member out of cache or the server), it just uses ldap.usernameField to construct JID (username@domain). In case of local groups (what I have) only userid (local part of JID) is shown, not even a name.

Do I understand correctly - you’d like to have ldap.nameField displayed in addition to the userid?

Here are the ldap.* properties (not vcard). Yes, posixMode is true.

ldap.adminDN                    cn=TeamWARE Directory Manager,ou=coreb,ou=twadmin,o=Teamware
ldap.adminPassword              hidden
ldap.autoFollowAliasReferrals   true
ldap.autoFollowReferrals        true
ldap.baseDN                     l=Sydney,o=Teamware,c=AU
ldap.clientSideSorting          true
ldap.connectionPoolEnabled      true
ldap.debugEnabled               true
ldap.emailField                 mail
ldap.encloseDNs                 true
ldap.groupDescriptionField      description
ldap.groupMemberField           twM
ldap.groupNameField             cn
ldap.groupSearchFilter          &(objectClass=twGroup)
ldap.host                       coreb
ldap.ldapDebugEnabled           true
ldap.nameField                  cn
ldap.override.avatar            false
ldap.port                       389
ldap.posixMode                  true
ldap.searchFields               Username/twLN,Email/mail
ldap.sslEnabled                 false
ldap.usernameField              twLN

The following is the behaviour I am looking for:

The twM group member attribute in the group needs to cause a seach of that member for a matching twId attribute, which may be a user, or it may be a nested group object. If it is a user object, it should then either be able to get the ldap.usernameField or the ldap.emailField, which is then the user part of the JID. If using email, of course it will have to use the LHS of the mail address - I know Openfire can and will only support a single domain.

Currently we are using ldap.usernameField to make the JID, but in practice, we’d want to use the LHS of the mail address, which is something I don’t think we can do.

It’s not so important to have the name displayed in the admin console for group members, that’s not our issue.

I suppose changing ldap.usernameField to mail won’t make it?

I guess what could be done in this case is to ask GroupManager to store some structure instead of just JIDs in the list of group members. This would have to be changed across all group management implementations, not only LDAP’s

Using mail as the username field does not work. You cannot add any admin users. If you use the left hand side of the mail address, it can’t find it and if you use the full email address it gives an exceptio onscreen saying it’s an invalid JID

It does not seem possible to use admin either.