[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: |
|
||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||
| 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 |