[Bug] ActiveDirectoryRealm escapes full DN usernames in Shiro 2.2.1 causing LDAP authentication failures

[wanguttiz]

Search before asking

• I had searched in the issues, including closed issues and found no similar issues.

Environment

Description

After upgrading Apache Shiro from 2.1.0 to 2.2.1, Active Directory authentication fails with:

javax.naming.AuthenticationException:
[LDAP: error code 49 - 80090308: LdapErr: DSID-0C0905AC,
comment: AcceptSecurityContext error, data 52e, v65f4?]

The issue occurs when using a full Distinguished Name (DN) as the username/principal.

Environment
Apache Shiro 2.2.1
Java 21.0.6
Active Directory LDAP authentication
ActiveDirectoryRealm
Custom subclass of ActiveDirectoryRealm (does not override authentication methods)

The same configuration works correctly with Apache Shiro 2.1.0.

Steps to reproduce

Use a username/principal containing a complete DN:

CN=my_name,OU=Development service accounts,OU=Special Accounts,DC=mycompany,DC=com

Authenticate using:

UsernamePasswordToken token =
new UsernamePasswordToken(username, password);

subject.login(token);
Expected behavior

The LDAP bind should use the supplied DN unchanged:

CN=my_name,OU=Development service accounts,OU=Special Accounts,DC=mycompany,DC=com
Actual behavior

In Shiro 2.2.1, ActiveDirectoryRealm#getUsernameWithSuffix() modifies the DN:

protected String getUsernameWithSuffix(String username) {
String sanitizedUsername = Rdn.escapeValue(username);
return this.principalSuffix != null &&
!sanitizedUsername.toLowerCase(Locale.ROOT)
.endsWith(this.principalSuffix.toLowerCase(Locale.ROOT))
? sanitizedUsername + this.principalSuffix
: sanitizedUsername;
}

The call to:

Rdn.escapeValue(username)

changes the DN into:

CN=my_name,OU=Development service accounts,OU=Special Accounts,DC=mycompany,DC=com

This escaped value is then passed as Context.SECURITY_PRINCIPAL to JNDI LDAP authentication.

Active Directory rejects this bind with:

LDAP error code 49 / data 52e
Root cause

Rdn.escapeValue() escapes an RDN attribute value, not an already formatted LDAP distinguished name.

For example, escaping:

John, Smith

is correct:

John, Smith

However, escaping:

CN=John,OU=Users,DC=example,DC=com

corrupts the DN structure.

Suggested fix

Do not call Rdn.escapeValue() when the supplied username is already a DN.

Possible approaches:

Detect DN input and skip escaping.
Only escape when constructing a DN from a username value.
Preserve the behavior from Shiro 2.1.0 for full DN principals.
Additional notes

The issue was confirmed by debugging JndiLdapContextFactory#getLdapContext(). The principal argument is already escaped before reaching the context factory.

Shiro 2.1.0:

CN=my_name,OU=Development service accounts,OU=Special Accounts,DC=mycompany,DC=com

Shiro 2.2.1:

CN=my_name,OU=Development service accounts,OU=Special Accounts,DC=mycompany,DC=com

Shiro version

2.2.1

What was the actual outcome?

The call to:

Rdn.escapeValue(username)

changes the DN into:

CN=my_name,OU=Development service accounts,OU=Special Accounts,DC=mycompany,DC=com

This escaped value is then passed as Context.SECURITY_PRINCIPAL to JNDI LDAP authentication

What was the expected outcome?

Do not call Rdn.escapeValue() when the supplied username is already a DN.

How to reproduce

Use a username/principal containing a complete DN:

CN=my_name,OU=Development service accounts,OU=Special Accounts,DC=mycompany,DC=com

Authenticate using:

UsernamePasswordToken token =
new UsernamePasswordToken(username, password);

subject.login(token);

Debug logs

No response

[lprimak]

Hi,
The change was introduced in response to security vulnerability described here:
https://shiro.apache.org/security-reports.html#cve_2026_49268

The suggested fix you provided effectively reverts this remediation, or introduces additional risks.
If you can suggest a more workable fix, or, even better a PR with a workable fix that doesn't break the remediation,
we can gladly take a look at that.