LDAP DNs are treated as case-sensitive in Minio, should be case-insensitive

[drivera-armedia]

Expected Behavior

When attaching a policy to a group using lowercase attributes in the admin group's DN (i.e. cn=ARKCASE_ADMINISTRATOR,cn=Users,dc=dev,dc=arkcase,dc=com), Minio's LDAP engine expects the attributes to be in uppercase (i.e. CN=ARKCASE_ADMINISTRATOR,CN=Users,DC=dev,DC=arkcase,DC=com).

Both DNs are equivalent per RFCs, and granting the policy to either should yield the same result.

Steps to Reproduce (for bugs)

1. Configure LDAP bindings for Minio, including for group search
2. Grant the consoleAdmin role to any of the groups (that has at least one member), using the lowercase attributes in the DN (as explained above)
3. Attempt to authenticate as a member of that group
4. Access is denied because the attributes on the policy assignment were lowercased, while the engine expects them to be uppercased.

Context

This increases the difficulty of initialization and configuration for an integrated Minio container that's part of a larger app. Granting the role to the same DN, but with the attribute names in uppercase, works perfectly. It appears that the minio code expects the DNs to match the case from LDAP exactly, which is incorrect behavior.

Per ldap.com:

For example, all of the following are valid ways of representing the same DN:

dc=example,dc=com
dc=example, dc=com
dc = example , dc = com
DC=EXAMPLE,DC=COM
0.9.2342.19200300.100.1.25=Example,0.9.2342.19200300.100.1.25=Com

Your Environment

• Version used (minio --version): RELEASE.2023-06-02T23-17-26Z
• Server setup and configuration: Custom docker container using the above version
• Operating System and version (uname -a): Linux test-env-0 5.19.0-42-generic List buckets response should be nested xml buckets #43~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Apr 21 16:51:08 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

[Schmashlafu]

One behaviour, that makes this bug more frustrating:

The command mc idp ldap policy attach mycloud consoleAdmin --group='cn=Minio-Admins,ou=Administration,dc=net' will succeed.

Issuing this : mc idp ldap policy attach mycloud consoleAdmin --group='CN=Minio-Admins,OU=Administration,DC=net' afterwards will fail.

mc: <ERROR> Unable to make LDAP policy association. The specified policy change is already in effect. (Specified policy update has no net effect).
This means Minio claims to be case insensitive. Yet it is case sensitive. The internal logic for interpreting LDAP is inconsistent.

[harshavardhana]

This means Minio claims to be case insensitive. Yet it is case sensitive. The internal logic for interpreting LDAP is inconsistent.

It's a bit nuanced

CN, OU, DC are always based on the case provided by you to our search strings.

We do not fully support case insensitivity for the values of these fields. So what you are seeing is expected.

Use the correct capitalization based on your user/group DN parameters

[drivera-armedia]

The RFCs beg to differ.

In particular: querying with DC= or dc= or Dc= or dC= on any LDAP directory yields the same result. There's no reason minio should be performing that filtering itself ahead of the LDAP directory.

[harshavardhana]

In particular: querying with DC= or dc= or Dc= or dC= on any LDAP directory yields the same result. There's no reason minio should be performing that filtering itself ahead of the LDAP directory.

@drivera-armedia I am not talking about whether RFC is correct, not even trying to defend our implementation. We haven't implemented it the way LDAP might want case insensitivity and that is the whole point of this issue.

When this gets fixed it will be in accordance with the LDAP RFC for LDAP hierarchies until then this is an open item.

[harshavardhana]

If it's a pressing need feel free to send a PR and we are happy to accept contributions in this area - if not wait for us to get some free cycles to fix this correctly.

// cc @donatello

[jenkins-armedia]

Fair enough ... a possible solve, since the most immediate impact has to do with policies, is to simply make the entire string comparison case-insensitive since we'll be comparing DNs and, as the RFC stated, DNs should always be case-insensitive (and I have observed them to be).

I'll look into this, and may post a PR in the coming days.

[harshavardhana]

@donatello, is this issue fixed with the new normalization of LDAP DNs?

[drivera-armedia]

@donatello, is this issue fixed with the new normalization of LDAP DNs?

Works much better, thank you! But there may still be some rough edges:

bash-4.4$ mcli idp ldap policy entities --group cn=ADMINISTRATOR,OU=Groups,ou=Operations,dc=my-test-domain,dc=com local
Query time: 2024-05-22T20:09:29Z

bash-4.4$ mcli idp ldap policy entities --group CN=ADMINISTRATOR,ou=Groups,ou=Operations,dc=my-test-domain,dc=com local
Query time: 2024-05-22T20:09:35Z

bash-4.4$ mcli idp ldap policy entities --group cn=ADMINISTRATOR,ou=Groups,ou=Operations,dc=my-test-domain,dc=com local
Query time: 2024-05-22T20:09:43Z
Group -> Policy Mappings:
  Group: cn=ADMINISTRATOR,ou=Groups,ou=Operations,dc=my-test-domain,dc=com
    consoleAdmin
    readwrite

bash-4.4$ mcli idp ldap policy entities --group cn=administrator,ou=Groups,ou=Operations,dc=my-test-domain,dc=com local
Query time: 2024-05-22T20:09:55Z

As you can see, we get different results if we change the case of some elements and values, so the case sensitivity is still there... at least from the policy query tool.

That said, I can log in using LDAP users which are members of that group, and the consoleAdmin role does seem to be applied, so it appears that the engine itself is working fine, and this is likely the CLI tool not having been updated to meet these latest normalization changes.

Cheers!