Possible encoding problem with groups about ldapcp

[Yvand]

I tested your scenario:

• I created a group "group\ba-*" in AD
  In the people picker:
• If I type "group\b": LDAPCP searches "group\b*" and AD does not find the result
• If I type "group\ba": LDAPCP searches "group\ba*" and AD finds the result, but LDAPCP excludes it
  So there is a problem in both AD and LDAPCP side with this characters, but I don't know if there is an easy solution to fix this...

[Lightscatterer]

Thank you for the reply.

The behaviour of the AD when sending the "\b" search is a bit strange, but possibly a deviation from the RFC.

To our understanding it should work, if the query string sent to the LDAP escapes the "" to "\5C". This should suffice for all LDAP-Server, not only AD.

[Lightscatterer]

Do you have the opportunity to check the proposed change?

[Yvand]

To be honest, no, sorry.
Can you please give clear example(s) of how LDAPCP should change the input (before/after)?
Can you also test your proposed change using the PowerShell script here and confirm if it works?

[Lightscatterer]

We got to test the changes with the script:

We are using the admindisplayname for filtering, but the problem is independent from it. As soon as a "" followed by a hexadecimal character is in the searched string, the search fails. Replacing of "" to "\5c" solves the issue.

Therefore we recommend a general replacement of the "" character in the searched strings for attributes with "\5c".

[Lightscatterer]

Is the provided information sufficient and clear?

[Yvand]

I created a group with the name "group\specialchar":
In AD it was created with following properties:

• LDAP attribute "name" = group\specialchar
• LDAP attribute "sAMAccountName" = group_specialchar

I made following tests using this PowerShell script:
$filter = "(&(objectClass=group)(name=group\special*))"
=> Returns the group as expected

$filter = "(&(objectClass=group)(name=group\5cspecial*))"
=> Returns the group as expected

So it's still not clear to me what scenario is not working, and if you could provide text examples instead of screenshots, it will be far more easier for me to understand.

[Lightscatterer]

As mentioned earlier, the problem only occurs, when after the \ the group starts with a hexadecimal character (0-9a-f). So "group\specialchar" works fine (even though according the standard this should not work either, because all \ have to be encoded).
A better example would be: "group\acharacter". Searching "group\achar*" will yield nothing and "group\5cachar*" will yield the group.

The encoding of special characters can be found for example in
https://ldap.com/ldap-dns-and-rdns/

If someone wants to go crazy, the other characters would be nice to, to be encoded too. But \ should cover most of the cases.

[Lightscatterer]

I just realized all my "\" got replaced to "" after sending. Sorry if that made earlier text a bit confusing.

[Yvand]

Ok, now I can reproduce your scenario.
I made some changes in LDAPCP and fix this scenario if the corresponding ClaimTypeConfig doesn't have property ClaimValuePrefix set with dynamic tokens {domain} or {fqdn}. Are you using them?

[Lightscatterer]

The person who has configurated the settings is on vaccation and we currently can't find the corresponding settings. But a colleague thinks we use the {domain} token.

[Yvand]

I just fixed this bug in commit 57d6397, which actually handles all special LDAP characters, not only '\'

[tollertenya]

Hello,
thanks for fixing - we tested the fix and search result now is working fine.

But now we have issue that there is \ as prefix before domain - useraccount is written in SharePoint in form \fqdn\groupname