minio cannot handle special characters in LDAP distinguished names

[mcpride]

Expected Behavior

A policy can be assigned to a user with a matching DN using the mc idp ldap policy attach command.

Current Behavior

At least in minio for windows with filesystem storage DNs with some special characters included fails if you try to assign a policy with the mc idp ldap policy attach command.

Example:

mc idp ldap policy attach local consoleAdmin --user="CN=Mustermann\, Max,OU=Desktop Users,OU=Users,OU=BER,OU=EMEA,DC=ENTERPRISE,DC=corp"

Error in cmd:

mc.exe: <ERROR> Unable to make LDAP policy association. The specified user does not exist. (Specified user does not exist).

Error in wsl2 bash:

mc.exe: <ERROR> Unable to make LDAP policy association. Object name contains unsupported characters. (Object name invali
d: .minio.sys/config/iam/policydb/sts-users/CN=Mustermann\, Max,OU=Desktop Users,OU=Users,OU=BER,OU=EMEA,DC=ENTERPRISE,DC=corp.json
son).

Possible Solution

Minio needs to respect escaped characters in DNs (see also: https://www.rlmueller.net/CharactersEscaped.htm). At least for usage in file system based storages the usage of the raw DN needs to be sanitized or hashed.

Steps to Reproduce (for bugs)

1. Configure LDAP bindings for Minio, including for group search on a Windows based host with filesystem as storage
2. Grant the consoleAdmin policy to a user with a comma in it's CN

Context

A typical ActiveDirectory related configuration of the STS LDAP endpoint may not work correctly.

Regression

Your Environment

• Version used (minio --version): minio.exe version RELEASE.2024-01-18T22-51-28Z (commit-id=19387cafab76133c2e7642de4aac8c81b9f4f8c7) Runtime: go1.21.6 windows/amd64
• Windows 10 (wsl-2 for bash)
• Operating System and version (uname -a): Linux ****** 5.15.133.1-microsoft-standard-WSL2 1 SMP Thu Oct 5 21:02:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

[harshavardhana]

@mcpride can you provide the LDAP search output?

[mcpride]

@mcpride can you provide the LDAP search output?

I had to fake and shorten (3 dots) it a bit to not publish our company data ("Max Mustermann" is in germany like "John Doe") but here is the result of a typical ldapsearch command like ldapsearch -x -b <search_base> -H <ldap_host> -D <bind_dn> -W "(&(objectclass=user)(sAMAccountName=mmustermann))"

# extended LDIF
#
# LDAPv3
# base <DC=ENTERPRISE,DC=corp> with scope subtree
# filter: (&(objectclass=user)(sAMAccountName=mmustermann))
# requesting: ALL
#

# Mustermann\2C Max, Desktop Users, Users, BER, EMEA, ENTERPRISE.corp
dn: CN=Mustermann\, Max,OU=Desktop Users,OU=Users,OU=BER,OU=EMEA,DC=ENTERPRISE,DC=corp
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: Mustermann, Max
sn: Mustermann
c: DE
l: Berlin
st: BE
title: Software Architect (m/f/d)
postalCode: 12345
physicalDeliveryOfficeName: Berlin
telephoneNumber: +49301234567
givenName: Max
initials: MUM
distinguishedName: CN=Mustermann\, Max,OU=Desktop Users,OU=Users,OU=BER,OU=EMEA,
 DC=ENTERPRISE,DC=corp
...
whenChanged: 20240119033815.0Z
displayName: Mustermann, Max
otherTelephone: 89
uSNCreated: 138260
memberOf: ...
...
sAMAccountName: mmustermann
...
userPrincipalName: [email protected]
...
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=ENTERPRISE,DC=corp
...
mail: [email protected]
...

# search reference
ref: ldaps://DomainDnsZones.ENTERPRISE.corp/DC=DomainDnsZones,DC=ENTERPRISE,DC=corp

# search reference
ref: ldaps://ForestDnsZones.ENTERPRISE.corp/DC=ForestDnsZones,DC=ENTERPRISE,DC=corp

# search reference
ref: ldaps://ENTERPRISE.corp/CN=Configuration,DC=ENTERPRISE,DC=corp

# search result
search: 2
result: 0 Success

# numResponses: 5
# numEntries: 1
# numReferences: 3

[mcpride]

The error can be traced back relatively clearly to the different handling of the names of files or directories under Unix/Linux and Windows. Under Windows, the following characters are not allowed and lead to errors: \ / : * ? " < > |.
Under Linux, however, my tests ran without any problems!

This is also the reason why the AssumeRoleWithCertificate feature does not work under Windows, as a colon is used in the directory name for differentiation (see #18865). Minio needs a differentiated file system handling for different platforms (see also the following suggestion: https://stackoverflow.com/questions/1976007/what-characters-are-forbidden-in-windows-and-linux-directory-names/61448658#61448658).

At least the use of / (slash) in the CN of an LDAP/ActiveDirectory could also be a challenge for non-Windows platforms, e.g. cn=floor 3 / room 2

[jiuker]

@harshavardhana @donatello @klauspost We will save that json. But the path have "\," see

minio/cmd/object-api-utils.go

Lines 200 to 209 in 1d3bd02

	if runtime.GOOS == globalWindowsOSName {
	// Explicitly disallowed characters on windows.
	// Avoids most problematic names.
	if strings.ContainsAny(object, `\:*?"|<>`) {
	return ObjectNameInvalid{
	Bucket: bucket,
	Object: object,
	}
	}
	}

if we open that. The path will lose the first. will save as Max,OU=Desktop Users,OU=Users,OU=BER,OU=EMEA,DC=ENTERPRISE,DC=corp.json, Not CN=Mustermann\, Max,OU=Desktop Users,OU=Users,OU=BER,OU=EMEA,DC=ENTERPRISE,DC=corp.json in windows.
Maybe base64 could be ok. But that's not good for old data.

[mcpride]

Could a replacement with special unicode chars - as used here: https://github.com/DDR0/fuseblk-filename-fixer - be a solution?

[harshavardhana]

Could a replacement with special unicode chars - as used here: https://github.com/DDR0/fuseblk-filename-fixer - be a solution?

New release normalizes the LDAP DNs can you try our latest release? @mcpride

[ordnaelmedeiros]

Same problem with characters like ã, á, ç...
causing AcceptSecurityContext
Error example:

<?xml version="1.0" encoding="UTF-8"?>
<ErrorResponse xmlns="https://sts.amazonaws.com/doc/2011-06-15/">
    <Error>
        <Type></Type>
        <Code>InvalidParameterValue</Code>
        <Message>LDAP server error: LDAP auth failed for DN cn=Leandro,ou=Seguran\c3\a7a,dc=com,dc=br: LDAP Result
            Code 49 &#34;Invalid Credentials&#34;: 80090308: LdapErr: DSID-0C090449, comment:
            AcceptSecurityContext error, data 52e, v3839�</Message>
    </Error>
    <RequestId>17C7255A2A1EB657</RequestId>
</ErrorResponse>

if renamed the OU removing the ç authentication works.

[harshavardhana]

wait are you saying that AD is returning back this error? @ordnaelmedeiros so a normalized entity is failing the auth.

What we need to do is only save the normalized user but never perform LDAP query from it?

[ordnaelmedeiros]

weird behavior :)
AD logs everything is fine, shows authentication was successful.
But this authentication error appears in MinIO log.
Other applications authenticating with AD using the same user, for example GitLab, works fine.
If I remove the character, all problems end.
We are currently removing these characters. but that's not fun, :)

[harshavardhana]

Active Directory Error code52e - invalid credentials

So it is an error in authenticating the user.

[harshavardhana]

This should be already handled in the latest master, and also with the new release scheduled for today.