[MGNLLDAP-53] UserID needs to be escaped when substituted into a DN string Created: 09/Jun/11  Updated: 12/Aug/11  Resolved: 10/Aug/11

Status: Closed
Project: LDAP Connector
Component/s: None
Affects Version/s: 1.4.2
Fix Version/s: 1.4.3

Type: Bug Priority: Major
Reporter: Tony McCrary Assignee: Magnolia International
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File ConnectionFactory.java.patch     Text File error-stacktrace.txt    
Issue Links:
causality
caused by MGNLLDAP-54 Allow extending login modules to iter... Closed
relation
is related to MAGNOLIA-5815 LDAP groups can have names which are ... Closed
is related to MGNLLDAP-56 Incorrect change in lookup order brea... Closed
supersession
Template:
Patch included:
Yes
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

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.



 Comments   
Comment by Magnolia International [ 09/Jun/11 ]

More characters need to be escaped: , (comma), = (equals), + (plus), < (less than), > (greater than), # (number sign), ; (semicolon), \ (backslash), and " (quotation mark, ASCII 34).

Comment by Magnolia International [ 09/Jun/11 ]

Need to review r43619 before resolving this.

Comment by Magnolia International [ 10/Aug/11 ]

r43619 reviewed and fixed with MGNLLDAP-56

Generated at Mon Feb 12 02:21:07 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.