Users from AD groups starting with \ are not added in the XWiki mapped group

[AndreeaChi]

Hi, I have tested in both 12.10.6 and 13.10.2 Jetty HSQLDB. Steps to reproduce:

1. Have an AD group called \#New Test with a user in it called XWikiUserOne

2. Install AD app and activate ldap DEBUG mode in logging.

3. Add an AD configuration in XWiki administration > Other > Active Directory

4. Go on Users & Rights > Groups and create a group called BackslashDiez

5. Associate the BackslashDiez group with \#New Test. The option to associate the groups is shown right next to the created XWiki groups.

6. Check AD Advanced configuration, in the group mapping:

Expected result XWiki.BackslashDiez > CN=\#New Test,CN=Users,DC=xwiki,DC=com

Actual result

• the mapping with \#New Test was shown as on the test from 13.10.2 with triple backslashes XWiki.BackslashDiez > CN=\\\#New Test,CN=Users,DC=xwiki,DC=com

7. Logged in with XWikiUserOne.

Expected result Successful login, the user goes in the mapped group.

Actual result It was a successful login, but the mapping was not done. The XWikiUserOne went in the XWikiAllGroup as done by default.

An extract of the logs showing the errors : extract-logs-attempt-login-mapping-triple-backslash.txt

[AndreeaChi]

A second way to reproduce the failed mapping

1. Tried as well without using the option "Associate" from XWiki Groups - wiki administration. I deleted the XWikiUserOne user page. Deleted the XWiki Groups: BackslashDiez and Slash and created a new one called SecondBackslashDiez and
2. This time I did not click on the Associate button to associate it with an AD group. I went on the AD configuration > Advanced configuration and added manually the group mapping: `XWiki.SecondBackslashDiez > CN=#New Test,CN=Users,DC=xwiki,DC=com ' and Saved
3. Tried to login with XWikiUserOne:

Expected result CN=#New Test,CN=Users,DC=xwiki,DC=com The login and mapping of XWikiUserOne are successful.

Actual result The backslash is not shown next to the expected \#New Test group : Looks like CN=#New Test,CN=Users,DC=xwiki,DC=com is not a DN, lets try filter or id The login was done but the mapping was not successful, the XWiki.BackslashDiez group remained with 0 users. The XWikiUserOne went in the XWikiAllGroup as done by default.

Log extract: extract-logs-attempt-login-manually-added-mapping-single-backslash.txt

[AndreeaChi]

An example of a successful mapping:

1. Create on XWiki the group called Slash and in Active Directory Slash/InName
2. In the AD group add the TestUser.
3. Associate the XWiki Group Slash with the AD group. The mapping is displayed as expected in AD app configuration page XWiki.Slash > CN=Slash/InName,CN=Users,DC=xwiki,DC=com and in the logs the frontslash is displayed correctly.
4. Log with TestUser that is in the Slash Group.

Result: The login and the mapping was successful. The TestUser went in the XWikiAllGroup as by default. The XWiki.Slash group has also been updated:

Logs describing the successful mapping with the XWiki group XWiki.Slash : 2022-01-27 11:54:42,990 [qtp668849042-390 - http://localhost:8080/xwiki/bin/loginsubmit/XWiki/XWikiLogin] DEBUG o.x.c.l.XWikiLDAPUtils - Adding user [XWiki.TestUser] to xwiki group [XWiki.Slash] 2022-01-27 11:54:43,199 [qtp668849042-390 - http://localhost:8080/xwiki/bin/loginsubmit/XWiki/XWikiLogin] DEBUG o.x.c.l.XWikiLDAPUtils - Finished adding user [XWiki.TestUser] to xwiki group [XWiki.Slash]

[ClemensRobbenhaar]

The "triple backslashes" are actually ok in the display of the group; if the name is CN=\#New Test , then both the backslash and the hash sign must be escaped in the full 'DN' as:

  CN=\\\#New Test,CN=Users,DC=xwiki,DC=com

However when I try to get the mapping done, the group sync instead looks for a group:

  CN=\#New Test,CN=Users,DC=xwiki,DC=com

which is not what the mapping says. I have to bring in six backslashes to get the proper mapping. So for some reason the proper escaping gets lost somewhere in between.

I have tested this with the plain "LDAP" connector, but from the logs it seems both this and the AD auth use the same group mapping code.

[AndreeaChi]

@ClemensRobbenhaar, thanks for testing and fixing the issue on the LDAP side: https://jira.xwiki.org/browse/LDAP-108

[ClemensRobbenhaar]

Thanks :) I have released "LDAP Application 9.5.7" just now. Rebuilding the AD extension with this new version as dependency should also fix the issue here. If it does not, let me know so I can give it another try.

[AndreeaChi]

I have tried a test to update the LDAP Authenticator to the 9.5.7 version on my local Jetty 13.10.2 where the AD app 1.13.1 is installed and the issue still reproduces. I can login with the user from the group \#New Test but it does not get mapped in the XWiki group BackslashGroup.

Logs: logs-trial-after-upgrade-LDAPAuthenticator-9.5.7.txt

[ClemensRobbenhaar]

Thanks for the feedback!

I have overlooked that the AD-Extension has a different way to handle the group mappings. The variable aDValue defined in this line https://github.com/xwikisas/application-activedirectory/blob/6c057e6205f43495be87ff6a810f4c44eb6f7069/application-activedirectory-ui/src/main/resources/ActiveDirectory/Code/Main.xml#L329 and the separatedNewContent (and probably separatedOldContent) https://github.com/xwikisas/application-activedirectory/blob/6c057e6205f43495be87ff6a810f4c44eb6f7069/application-activedirectory-ui/src/main/resources/ActiveDirectory/Code/Main.xml#L420

need to be handled to escape / unescape the separator and backslash in a similar way as in https://github.com/xwiki-contrib/ldap/commit/d525963ac3c2c8037bc5e167c90534333deca8d5

Unfortunately I have no working AD setup (and also I guess no write access to this repository), so I'd have a hard time contributing a fix for the issue in this project.

[trrenty]

After some investigation I found out that the faulty function was getGroupMappings of XWikiLDAPConfig class.

I'm going to walk through an example using Andreea's data:

• AD group called \#New Test with a user in it called XWikiUserOne
• XWiki group called BackslashDiez

When we associated BackslashDiez with #New Test, the mapping was done successfully as XWiki.BackslashDiez -> CN=\\\#New Test,CN=Users,DC=xwiki,DC=com (as Clemens stated) on windows server or XWiki.BackslashDiez -> CN=\23New Test,CN=Users,DC=xwiki,DC=com on an OpenLDAP server.

Whenever we tried to perform an action that would eventually call getGroupMappings, it would return our mapping as CN=\#New Test,CN=Users,DC=xwiki,DC=com (windows) or CN=23New Test,CN=Users,DC=xwiki,DC=com respectively (OpenLDAP). Performing any LDAP query/action with these values, would fail.

I also created a group inside OpenLDAP called New\#Group but the name was automatically converted to New#Group, thus working properly. New\\Group on the other hand was affected. Behaviour on windows AD might differ.

The group mappings are saved as a concatenation of strings using the separator |. The faulty function tries to avoid confusion between the separator and possible occurrences of the symbol (|) within the dn of the groups.

I made this simple modification to the function and it fixed the problem. It also didn't affect the proper generation of the group mapping. I tested it on the LDAP server as well as the windows AD.