Fix LDAP DC case sensitivity

[kabassanov]

RFC 4519 says that for LDAP DCs, "the equality matching rule is case insensitive, as is today's DNS" (section 2.4). Sometimes, GLPI could get identical answers for groups from LDAP servers with different cases (lowercase and upercase) in the DC parts of the DN. Thus it will treat them as different entries and show them in the list of available group items for import.

Q	A
Bug fix?	yes
New feature?	no
BC breaks?	no
Deprecations?	no
Tests pass?	yes
Fixed tickets	#number

[trasher]

I can't test, and have almost no idea if the fix is correct or not.

Adding a test case would help to review

[kabassanov]

I can't test, and have almost no idea if the fix is correct or not.

Adding a test case would help to review

Imagine that your ldap server has these 2 records:

# myuser, People, Accounts, my.org
dn: uid=myuser,ou=People,ou=Accounts,dc=my,dc=org
memberOf: cn=mygroup,ou=groupOfUniqueNames,ou=Groups,dc=MY,dc=ORG

# mygroup, groupOfUniqueNames, Groups, my.org
dn: cn=mygroup,ou=groupOfUniqueNames,ou=Groups,dc=my,dc=org
objectClass: groupOfUniqueNames
cn: mygroup
uniqueMember: uid=myuser,ou=People,ou=Accounts,dc=my,dc=org

And that GLPI is configured to search for groups in both users and groups. As there are two distinct requests, GLPI will receive these groups:

cn=mygroup,ou=groupOfUniqueNames,ou=Groups,dc=MY,dc=ORG
cn=mygroup,ou=groupOfUniqueNames,ou=Groups,dc=my,dc=org

But as dc part is not case sensitive, GLPI must consider them as a simple entry. Without my commit, they both appeared in the table of groups available for import.

[trasher]

ok, thanks for the explanations. this should be tested anyway; to ensure fixed and legacy cases are ok (there are some existing tests about groups, I don't know if they rely on that part of code)

[trasher]

I can take a look at tests; but not before next week at least

[kabassanov]

I can take a look at tests; but not before next week at least

It is not urgent. I just try to avoid local patching on every GLPI update ;).

[trasher]

I'm not able to add tests

[cconard96]

I also tried making tests (last week). The LDAP server does not recognize the memberof attribute and apparently there is an overlay/module needed to add support but I've had no luck getting it working.

[kabassanov]

Hi, 12.8 in https://www.openldap.org/doc/admin24/overlays.html seems to explain how to add the overlay. Doesn't it work for you?

[cedric-anne]

The LDAP server does not recognize the memberof attribute and apparently there is an overlay/module needed to add support but I've had no luck getting it working.

I was able to load the memberof overlay on CI docker image using this patch, but it does not seems to permit to define the memberOf attribute manually. Indeed, as far as I understand from the documentation, this overlay is made to automatically update this attribute based on membership values. When I try to define it manually, I get a Constraint violation (19) additional info: memberOf: no user modification allowed error. With this overlay, if I explicitely require the memberof attrribute of user remi, I get cn=glpi2-group1,ou=groups,ou=usa,ou=ldap2,dc=glpi,dc=org value, which seems to be correct, but as it is set automatically, case is same as in group dn.

I do not know if it is possible to modify dn of an existing group, I did not find how to do it, but if we could do this, in our test suite, we may potentially be in an edge case where group dn does not use same case as memberof attribute of user.

[kabassanov]

Which openldap version is running in your docker? I don't know if it is related, but in my case group members are defined as uniqueMember and not member. As documentation says "The memberof overlay updates an attribute (by default memberOf) whenever changes occur to the membership attribute (by default member) of entries of the objectclass (by default groupOfNames) configured to trigger updates." I wonder if this is not the way we bypass this constraint...

[cedric-anne]

Which openldap version is running in your docker?

We use le latest one available on alpine, so I guess it is the 2.6.3 version.

I don't know if it is related, but in my case group members are defined as uniqueMember and not member. As documentation says "The memberof overlay updates an attribute (by default memberOf) whenever changes occur to the membership attribute (by default member) of entries of the objectclass (by default groupOfNames) configured to trigger updates." I wonder if this is not the way we bypass this constraint...

I really do not know, and as I do not have any skills in LDAP administration, I cannot really help.

[trasher]

Without tests or someone to confirm the fix is actually correct, this PR cannot be integrated; so I've removed the milestone right now.