Type: Regression Bug
Affects Version/s: 7.0.0 DXP FP39, Master
Component/s: Application Security > LDAP
This bug is only reproduced using OpenLDAP
This bug was caused by --
user-usergroup assignments are not exported from OpenLDAP in case of DN from LDAP user entry has a comma or other special character:
Steps to reproduce
- Configure an OpenLDAP server (other LDAPs work fine)
- Go to LDAP and create a user with a comma in its name, ex: User, with, commas
- Check that its DN has a escaped comma, ex: cn=User\, with \, comas,ou=users,dc=example,dc=com or cn=User\2c with \2c comas,ou=users,dc=example,dc=com
- Also create a user without any comma in its name, ex: User without commas
- In LDAP, create a group called "Test"
- In LDAP, add both created users to "Test" group.
- Configure Liferay to import users and groups from LDAP using "User" Import Method.
- Wait until Liferay imports the users and groups from LDAP
- : Usergroup and users are created in Liferay side and both users are included into the new usergroup
- : Usergroup and users are created in Liferay side but only *User without commas is included into the new usergroup
Note: To avoid portal screenName errors configure LDAP server mapping and exchange ScreenName<->FirstName mapping (screenName->givenName and firstName->cn).
Root cause of the issue
According to LDAP RFC-4514, the problematic characters ' ', '"', '#', '+', ',', ';', '<', '=', '>', and '\' can be encoded in two ways:
Each octet of the character to be escaped is replaced by a backslash
and two hex digits, which form a single octet in the code of the
character. Alternatively, if and only if the character to be escaped
is one of
' ', '"', '#', '+', ',', ';', '<', '=', '>', or '\'
(U+0020, U+0022, U+0023, U+002B, U+002C, U+003B,
U+003C, U+003D, U+003E, U+005C, respectively)
it can be prefixed by a backslash ('\' U+005C).
So ',' comma character, can be encoded in two ways: \, and \2c
In LDAPUserImporterImpl.java, in order to solve --
LPS-73915--, we replaced following call:
Both methods returns the full DN of the user:
- _ concatenates binding.getName() + ldapServerConfiguration.baseDN()
- binding.getNameInNamespace() gets the full DN directly from the object.
The problem is behavior of Java LDAP API is not consistent:
- Java LDAP API returns the special characters encoding in different ways:
- binding.getName() method, always returns the special character encoded in the simplify mode: backslash + character
- binding.getNameInNamespace() method, returns the special character encoded using the format received from LDAP server (backslash + character or backslash + hex code)
- OpenLDAP internally encodes the special characters encoded in the hex mode: backslash + hex code.
- But when we query OpenLDAP from java side for the groups of a user with the special character, only the queries with the encoding (backslash + character) works, because LDAPUserImporterImpl.escapeValue only scapes some characters
- So because of --
LPS-73915-- changes and Java LDAP API behavior, we are creating LDAP queries that returns zero results, because the encoding of special characters in the query are not correct: "\2c" instead of "\,"
As a solution, we have to modify the escape logic of LDAP queryies