After upgrading to 1.4.2, we cannot authenticate users with our AD server. The same configuration works with 1.4.1, we have downgraded until the issue is resolved.

The AD error code within the thrown NamingException is as follows: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903AA, comment: AcceptSecurityContext error, data 525, v1772 . According to Microsoft documentation this means the user's supplied principal and password could not be authenticated.

The distinguished name being supplied appears as follows: cn=LastName, FirstName,dc=directory,dc=mycompany,dc=com; notice the comma between LastName and FirstName. This comma could break a parser that expects each dn component to be comma separated.

The order in which the user dn and common name are retrieved in 1.4.2 has changed. Our issue was partially caused by an incorrect security principal in ad.properties. Before, the dn would be defined by the LDAP search (i.e. LDAPAuthenticationModule#parseSearchResults) and the manual case would never be executed. As of 1.4.2, that changed and now the manual dn case is used. We've since fixed the ad.properties file and I believe with this patch either case will work, search or manual generation.

The attached patch modifies the way a context is created when a directory search for the user dn is not used. When a dn is manually created from the ad.properties security context and the cn is replaced with the user principal, this ensures that any commas in the common name are escaped (i.e. "McCrary, Tony" becomes "McCrary\, Tony"). This ensures that the user dn doesn't have any parse errors, because components in a dn are comma delimited.