This project has moved and is read-only. For the latest updates, please go here.

displayName not saving properly

Mar 17, 2015 at 8:31 PM
I am able to query users, and I see the expecting results, when hovering over the user also. But when I add the user, the name comes in as system.byte[] instead of the displayname.
Mar 17, 2015 at 9:28 PM
Did some more testing and changed the attribute to display from "displayName" to "cn". Now it works as expected. I see the cn in the upper right corner of SharePoint and on the user information list, I see the cn populating the name property.

So whey is the displayName not coming back properly from AD LDS. I ran across this post and it seems to make sense, but how to fix it or is is known.
Mar 18, 2015 at 12:23 AM
This is kind of related to above. How do I get the displayName to display in the results without the attribute prefix? For example I have "Query LDAP with specified attribute and create permission with specified claim type" claims, they are green but not bold. I can search on them just fine, but all the results have the attribute in parenthesis, that shows up in the display name.

example. I search by sn for smith and I get (sn) Smith, John. I want to get just Smith, John, not matter what attribute I search on.
Jul 16, 2015 at 10:01 PM
We are having the same problem on the UPN as this error.

Has anyone found a solution, even temporary?
Jul 17, 2015 at 10:20 AM

only LDAP results that match (or are linked to) the identity claim type show without parenthesis.
You see "(sn) Smith" because you mapped LDAP attribute "sn" to a claim type (that is not identity claim type).
This looks bad because sn is not guaranteed to be unique in AD, so it's a user permission (not a group) but you cannot be sure that it is unique to 1 user.

What you can do is to remove line "sn" in "claims table" page and create a new entry of type "Query LDAP with specified attribute and create permission with the attribute linked to identity claim".
That will display sn attribute with no parenthesis but you must understand what it means:
  • New permission will actually be created with LDAP attribute linked to identity claim type (not with the sn LDAP attribute).
  • Previous permissions on sn will not resolve anymore if you open them in the people picker because claim type was removed in LDAPCP config (but will continue to be effective if user connects)
To summarize, you can probably achieve what you want but you will make changes in the way permissions are created, it's simple to do but it may cause side effects, so be careful when you change it and run test to avoid bad surprises.

Jul 20, 2015 at 2:36 PM
The interesting thing is once we rebooted the farm, the lookup is working again.

I really have no answer for why it is doing this.