Failing to authenticate users that have commas in CN that is included in DN

[mikecat]

When an user has DN that contains commas in CN like

CN=john, due,DC=example,DC=com

Authentication of this user in Admin authenticate mode fails even if correct password is used.

It looks like \ should be added before the comma in CN like

CN=john\, due,DC=example,DC=com

To correctly perform authentication.

[shaozi]

according to this stack overflow answer, , is not allowed in an entity name. Some other special chars are not allowed too.

Is this a real case?

[mikecat]

I actually encountered this problem while communicating with real LDAP server.

Reading the documents linked from the answer, the ban of , looks like for Windows logon names (sAMAccountName), DNS names, and security principal names, not for general DN.

Active Directory: Requirements For Creating Objects | Microsoft Learn says:

The RDN for the user, group, computer, contact, and container objects is the value of the cn attribute (the "Common Name").

Certain characters in the Relative Distinguished Names of objects must be escaped using the backslash, "\, escape character. The characters that must be escaped are: , \ # + < > ; " =

This looks like suggesting that using , in CN attribute is allowed (with escaped).

Object names: Active Directory | Microsoft Learn says:

Relative distinguished names must be unique in that users cannot have the same name within an organizational unit.

An administrator needs to provide names for security principal objects (user accounts, computer accounts, and groups) that are unique within a domain.

This is suggesting that relative distinguished names (that is CN for users) are different things than security principal names because their requirements of uniqueness differ.

Therefore, the limitations for security principal names shouldn't apply for relative distinguished names.

RFC2253 says:

If the UTF-8 string does not have any of the following characters which need escaping, then that string can be used as the string representation of the value.

• a space or "#" character occurring at the beginning of the string
• a space character occurring at the end of the string
• one of the characters ",", "+", """, "\", "<", ">" or ";"

Implementations MAY escape other characters.

If a character to be escaped is one of the list shown above, then it is prefixed by a backslash ('\' ASCII 92).

This looks like saying not that strings containing "," cannot be used in string representations, but that strings that doesn't contain "," nor other special characters can be used as-is (without escaping) in string representations.

The BNF shown later is also showing that , with escaping with \ can be used in attributeValue.

[shaozi]

In this case, we can add escape to all the special characters.

There are some ambiguity in certain uncommon cases. For example, with this input: CN=John,DC=www,DC=example,DC=com, where should we stop? It can be CN=John, or CN=John\,DC\=www, or ... Where should we stop?

We can safely assume that nobody in their right mind will use ,DC= or ,OU= in their CN. If that is true, then we can stop before the first DC= or OU=.

Then we also need to consider the case that the user provides a CN with \ escape.