Allow forcing "group object class" / "memberAttribute" for LDAP auth

[RustyDust]

I'm trying to run the LDAP authentication against a Univention Corporate Server. While this basically works I'm unable to successfully use the LDAP group to role mapping. Looking at the logs I see a couple lines saying:

2015-09-20T12:55:13.523+02:00 WARN [LdapConnector] Unable to auto-detect the LDAP group object class, assuming 'member' is the correct attribute.

The reason for this is that UCS doesn't use the objectClass "groupOfUniqueNames" as expected by the LDAP connector (/org/graylog2/security/ldap/LdapConnector.java:236) and while the LDAP entry actually has the uniqueMember attribute Graylog makes the wrong choice here. Here's what I get when querying the LDAP directory for a group (shortened for brevity):

uniqueMember: cn=user-01,cn=users,dc=example,dc=muc
uniqueMember: cn=user-02,cn=users,dc= example,dc=com
uniqueMember: cn=user-03,cn=users,dc= example,dc=com
uniqueMember: cn=user-04,cn=users,dc= example,dc=com
uniqueMember: cn=team-01,cn=groups,dc= example,dc=com
uniqueMember: cn=team-02,cn=groups,dc= example,dc=com
uniqueMember: cn=team-02,cn=groups,dc= example,dc=com
(...)
objectClass: top
objectClass: posixGroup
objectClass: univentionGroup
objectClass: sambaGroupMapping
objectClass: univentionObject

Now if I could tell Graylog what objectClass filter to use (univentionGroup) or what the memberAttribute is (uniqueMember) the problem would be easily solved I guess. An alternative would be to add another check for "univentionGroup" to the LdapConnector.java. But I think in the long run a user definable option would make more sense than possibly adding tons of different and maybe conflicting tests there.

[andham]

Having memberAttribute configurable would also solve #1436.

[tr31z]

I'm running into the same issue as my ldap groups are configured like this :

dn: cn=Domain Users,ou=groups,dc=example,dc=com
objectClass: top
objectClass: posixGroup
objectClass: sambaGroupMapping
gidNumber: 513
cn: Domain Users
(....)
memberUid: user1
memberUid: user2
...

So it would be nice if there was a way to specify the memberUid attribute :)

[bernd]

Thank you for the reports! We improved the detection of the member attribute in #1494 which should help with the reported cases.

These changes will be in the upcoming 1.2.2 release.

I will leave this ticket open and mark it as feature request for the next major release. The member attribute should be configurable, we just cannot do that for the stable release right now.

I hope this works for you. 😃

[tr31z]

Many thanks to you for fixing that !

[bernd]

This has been fixed a long time ago. 😄