preceded \ in roles since last fix

[tollertenya]

hello,
since you fixed issue 53 new issue occured that a "" is before the role in Account. we use {fqdn}\ as claim value prefix.

[Yvand]

I don't reproduce this issue, results are returned as expected:
group claim type is configured with prefix "{fqdn}\" and if I type "group1", LDAPCP returns "xcontoso.local\group1" as expected:

In ULS logs:

LDAPCP	Claims Picking	1337	Verbose	[LDAPCP] Added entity: display text: '(Role) xcontoso.local\group1', claim value: 'xcontoso.local\group1', claim type: 'http://schemas.microsoft.com/ws/2008/06/identity/claims/role'	59b48b9e-e7ab-4061-2841-bb70bd4ba80a

Note: Sometimes the rendering of markdown removes the \ and you need to double it. Please pay attention about this as it makes the understanding of the issue difficult

[tollertenya]

here a extract of our ULSlog
we see correct encoded LDAP search with \5c - the queried server is ADLDS Server and filled in field is adminDisplayName.

[Yvand]

Sorry it's not clear:

• What is the expected value?
• What is the actual value?

[tollertenya]

expected is: ftest\groupname xy
actual is: \ftest\groupname xy

[Yvand]

I cannot reproduce the behavior.
I created group "group\charTest" in domain "contoso.local"

My group claim type is configured with prefix "{fqdn}\", as returned by this script:

Add-Type -AssemblyName "ldapcp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=80be731bc1a1a740"
$config = [ldapcp.LDAPCPConfig]::GetConfiguration("LDAPCPConfig")
$config.ClaimTypes.GetByClaimType("http://schemas.microsoft.com/ws/2008/06/identity/claims/role").ClaimValuePrefix
# output: {fqdn}\

I search for it and I get the entity created with expected claim value, as shown in the logs:

LDAPCP	Claims Picking	1337	Verbose	[LDAPCP] Added entity: display text: '(Group) contoso.local\group\charTest', claim value: 'contoso.local\group\charTest', claim type: 'http://schemas.microsoft.com/ws/2008/06/identity/claims/role'	23ddc67c-4996-0003-f4d9-dd239649d401

What am I missing?

[tollertenya]

we found solution that is working when we using {domain} instead of {fqdn}