Active Directory Target account with comma in DN
Article ID: 263958
Updated On:
Products
Issue/Introduction
You have a web portal that needs the domain name in front of the username to login, i.e. you have to provide user name "example\pamaccount1" and not just "pamaccount1". But when you change the target account name from "pamaccount1" to "example\pamaccount1", you no longer can verify or update the account. The tomcat log shows the following authentication error:
com.cloakware.cspm.server.app.ApplicationException: Failed authentication to Active Directory using distinguished name 'CN=Account 1\, PAM,OU=PAM Standard,OU=Privileged Accounts,DC=example,DC=com' for account 'example\pamaccount1' due to error '[LDAP: error code 49 - 80090308: LdapErr: DSID-0C09044E, comment: AcceptSecurityContext error, data 52e, v2580]'
at com.cloakware.cspm.server.plugin.targetmanager.WindowsDomainServiceTargetManager.loginToActiveDirectoryServer(WindowsDomainServiceTargetManager.java:1276)
"CN=Account 1\, PAM,OU=PAM Standard,OU=Privileged Accounts,DC=example,DC=com" is the distinguished name of the user as shown by the attribute editor in Active Directory Users and Computers. The actual display name and full name is "Account 1, PAM".
Environment
Affects any PAM release.
Cause
The AD attribute editor adds a backslash character in front of the comma within the common name of the user, because the comma also is a field separator. But the backslash is not really part of the distinguished name and including it as if it was will cause an authentication error. If the login using the DN doesn't work, PAM will retry with the User Principal Name (UPN). The UPN is not configured directly in the target account. PAM uses syntax <target account name>@<domain name>, where <domain name> is the name of the domain configured in the Active Directory target application that the account is associated with. This should match the UPN defined in AD, if the account name is configured as "pamaccount1" without the domain prefix, yielding UPN "[email protected]", but it will fail once the prefix is added, since "example\[email protected]" is not a valid UPN.
Resolution
Do NOT use the backslash character to escape the comma within the common name. Configuring the target account without it should resolve this problem:
Additional Information
If you use an account name that does not match the name in the UPN, then feature Track Account Movement Across Active Directory OUs may not work, as the DN is the only way we can connect to Active Directory.
Note added Mar 8, 2024:
There was a problem with using the UPN as a fall-back in recent releases. That problem is fixed in hotfix 4.1.6.03 for 4.1.6, and the fix will be included in the 4.1.7 and 4.2 releases.
Aside from that, there was a remaining problem with processing DNs that have a comma in the common name, even when the backslash character was removed from the DN configured in the target account. After a successful login during a password update process, either by the account itself, or by another account configured for the password update, PAM would retrieve the DN from Active Directory with the backslash character included, but would not recognize it as an escape character. That problem is fixed for 4.1.6 in published hotfix 4.1.6.05. With the new hotfix applied it is ok to keep the backslash in the DN configured in the target account. This fix will be included in the upcoming 4.1.7 and 4.2 releases as well.
Feedback
