Sharepoint People Picker

[Anon Anon]

Has anyone had any luck with using the Sharepoint 2013 People Picker when integrated with the Sharepoint SSO web agent?

 

Our user store is LDAP and the Sharepoint People Picker leverages the policy server to reach back into the user store for user searches.  When searching for users, we are getting odd displays in the search results and the result set itself is incorrect.

 

We have the following User Directory attribute mappings:

useridentifier --> uid

smuserdisplayname --> fullname

smuserlastname --> sn

 

When I search for my lastname "mulligan", I see the following in the Policy Server (R12 SP3) trace log:

[LDAP search of (&(|(uid=mulligan*))(|(objectclass=inetOrgPerson)(objectclass=organizationalPerson)(objectclass=person))) took 0 seconds and 2167 microseconds][][][][][][][][][][][][][][][][]

[Ldap Search callout succeeds.][][][][][][][][(Search) Base: 'o=raytheon.com,c=US', Filter: '(&(|(uid=mulligan*))(|(objectclass=inetOrgPerson)(objectclass=organizationalPerson)(objectclass=person)))'. Status: 3 entries][][][][][][][][]

 

[LDAP search of (&(|(fullname=mulligan*))(|(objectclass=inetOrgPerson)(objectclass=organizationalPerson)(objectclass=person))) took 0 seconds and 843 microseconds][][][][][][][][][][][][][][][][]

[Ldap Search callout succeeds.][][][][][][][][(Search) Base: 'o=raytheon.com,c=US', Filter: '(&(|(fullname=mulligan*))(|(objectclass=inetOrgPerson)(objectclass=organizationalPerson)(objectclass=person)))'. Status: 0 entries][][][][][][][][]

 

[LDAP search of (&(|(sn=mulligan*))(|(objectclass=inetOrgPerson)(objectclass=organizationalPerson)(objectclass=person))) took 0 seconds and 7320 microseconds][][][][][][][][][][][][][][][][]

[Ldap Search callout succeeds.][][][][][][][][(Search) Base: 'o=raytheon.com,c=US', Filter: '(&(|(sn=mulligan*))(|(objectclass=inetOrgPerson)(objectclass=organizationalPerson)(objectclass=person)))'. Status: 12 entries][][][][][][][][]

 

So from the above searchs to LDAP, I should see 15 items in the search result on the Sharepoint People Picker.

 

What do I actually see?  5

 

I see the 3 from the (uid=mulligan) search.  What displays for these 3 users is their fullname, which is nice because I can see who they really are.

 

The other 2 items in the search result just say "MULLIGAN".

 

So the search results show this:

John Mulligan

Pam Mulligan

Richard Mulligan

MULLIGAN

mulligan

 

This is completely contradictory to what the LDAP search actually finds (15 entries, not 5).

 

And I am completely confused why the mix display of the names coming back in the People Picker.

 

Anyone else run into this?  Thank you!

[Legacy User]

Mike

 

SharePoint PeoplePicker has a loopback feature which displays the exact value which was keyed into PeoplePicker. These steps are from SP2010. However they should be more or less similar for SP2013 too. Disable this and you should see only exact search results from Policy Server.

 

Disable Client Loopback

If you do not need to add attributes using the SharePoint people picker before they exist in your user directories, disable the client loopback feature. Leaving client loopback enabled when the directory attributes exist returns duplicates in the SharePoint people picker.

Follow these steps:

1. Log in to your SharePoint central administration server.

2. Click Start, All Programs, Microsoft SharePoint 2010 Products, SharePoint 2010 Management Shell.

The management shell command-line window opens.

3. Navigate to the following directory:

C:\Program Files\CA\SharePointClaimsProvider\scripts

4. Enter the following command:

.\Set-SMClaimProviderConfiguration.ps1 -DisableLoopBackSearch

Loopback search is disabled.

 

 

Let know if this helped.

 

Regards

 

Hubert

[Legacy User]

Hubert,

 

while  i agree if that has  not been done it should, i would  not  expect that to be the full fix.

 

Mike,

 

If you open a case, the people i trained as i left have moved  on, so i have no clue how hoelpful the current ones on the front line will be. If you open and have any doubts on their ability to grasp the issue, i believe my cohort in proofing the 2010 agent this is still there, so ask for Rick.

 

-Josh

[Legacy User]

Josh JoshPerlmutter

 

This is just my curiosity. Could I seek your thoughts on why is that not a full fix? Just trying to see your perspective to see where we could improve.

 

 

 

From my thought, the valid search is only one from the list of 3 [UID, FIRSTNAME and LASTNAME] i.e. using UID.

 

When I search for my lastname "mulligan", I see the following in the Policy Server (R12 SP3) trace log:

[LDAP search of (&(|(uid=mulligan*))(|(objectclass=inetOrgPerson)(objectclass=organizationalPerson)(objectclass=person))) took 0 seconds and 2167 microseconds][][][][][][][][][][][][][][][][]

[Ldap Search callout succeeds.][][][][][][][][(Search) Base: 'o=raytheon.com,c=US', Filter: '(&(|(uid=mulligan*))(|(objectclass=inetOrgPerson)(objectclass=organizationalPerson)(objectclass=person)))'. Status: 3 entries][][][][][][][][]

 

 

The reason being we have the following User Directory attribute mappings:

useridentifier --> uid.

 

The FIRSTNAME and LASTNAME simply just to present the UID search result, in a human readable form. Therefore they are just supportives and not being used to search the User. The User is searched only using UID i.e. useridentifier.

 

Therefore the SM Claims Provider on SharePoint when it makes a call to ClaimsWS on SPAgent; it is going to build a search query using "useridentifier". Thus we know the legit search count is going to be returned as "3" users found in SM User Directory.

 

The Additional Loopback is a SharePoint feature. It is nothing to do with SM. Though I do have a dilemma why "mulligan" was returned twice i.e. once in CAPS and once in small. The Loopback only displays what was keyed in i.e. "mulligan"; therefore it should have been only once and hence should have displayed only "4". 

 

 

 

Hope this helps.

 

 

 

Regards

 

Hubert

[Legacy User]

the number of returns.

when i was at CA, loopback only had 1 return: the EXACT of what was typed.

instead he gets a caps and lower version.

 

either loopback has been changed,  or the 12, even if there are 3 duplicates from the previous, is somehow off.

 

either way i suspect there is more and have neither the time nor the logs nor CA resources to do more than  to point out that this is going to be quite complicated and likely a good candidate for a case.

[Legacy User]

Thank You Josh JoshPerlmutter Glad we are on same page. Phew!

Yes loopback returns only 1; i.e. EXACT of what was typed. Hence in this case we should have seen....

 

WITH LOOPBACK ENABLED [Default SharePoint Behavior].

John Mulligan

Pam Mulligan

Richard Mulligan

mulligan

 

WITH LOOPBACK DISABLED.

John Mulligan

Pam Mulligan

Richard Mulligan

 

 

 

Circling back to Mike.

Mike - Do you know OR did you create a local user [as MULLIGAN] on the machine which has SharePoint installed. It looks like SharePoint PeoplePicker is resolving to an extra value i.e. in CAPs [MULLIGAN]. Kindly disable the loopback using the steps above. Then advice on the search results that is returned. This would suggest, if you'd need to go ahead with CA Support. Also kindly enable the ClaimWebServices logging on SharePointAgent, to see what results are being returned by SM Policy Server to SM SharePoint Agent.

Another way to debug this, is to associate a Trusted Identity Token Issuer to a Claim Enabled Website. Then before you associate the SM Claim Provider to the Trusted Identity Token Issuer; do a search for the user. If this search returns two values (it won't initiate a search to ClaimWS as it is still not associated) i.e. one is Loopback (exact value which you entered) and an another value in a different case. We'll know for sure 100% that something in the SharePoint Setup / Local AD is causing this. It is purely outside the remit of SiteMinder, as you have not yet associated the SM ClaimProvider to Trusted Identity Token Issuer.

 

 

Regards

 

Hubert

[Legacy User]

Hubert,

 

as i stated the fact he has 2 unexplained that do not  come from the 12 that seem unreturned and not one makes me suspect loopback is not the full  fix.

further  if i remember correctly the feature is off by default

 

hence this is likely more  complicated than just the loopback state and, if you noticed, none of the returns are Mike.

 

thus i can conclude he may need a case as this is likely quite complicated.

 

...

[Legacy User]

I guess I would wait for Mike to review the content and then decide.

 

Josh - Loopback is enabled by default. Pretty sure on this one

 

 

Three actions for Mike .....

 

Action-1 : Try disabling loopback. Then advice on the search results.

 

Action-2 : How many users are in the SM User Directory, whose sn=mulligan* have uid=mulligan*

My gut feeling based on Mike's initial comment suggests that there are only 3; even though a search with surname gives a count of 12 (including user name "Mike Mulligan" i.e. if the Store has a user with that SN). Nevertheless, just a speculation which again only Mike could confirm.

 

Action-3 :

How many Claims have been configured on the Trusted Identity Token Issuer?

 

 

 

Would prefer Mike to have all the info as possible in hand, before connecting with Support as these would be vital inputs.

 

 

 

Regards

 

Hubert

[Legacy User]

That would be a change. a deviation from how SM used to be.

 

The  ability to use loopback was added. i remember when. i remember being on those calls.

as it was  added and would change functionality the decision at addition was to have it off by default.

i was asked for my  opinion on that. so  was Rick.

[Anon Anon]

There is no local user 'mulligan' on the Sharepoint environment.

 

I am waiting to hear back from the Sharepoint team on Option #1 (disabling loopback).

 

Will report back on the result of that change.

 

Thank you to everyone so far.

[Anon Anon]

This sounds promising.  I have forwarded this info to the SharePoint team.  Will let you know how it goes.

 

I did open a Tech Support case earlier today as well.

[Per Aagren]

Hi,

 

I had a similar problem, and that was because we had set Max Results in the Userdirectory too low.

Just want you to check that.

[Anon Anon]

Our LDAP Max is 2,000 rows.  That's shouldn't be the problem here. Thanks.

[Legacy User]

With LoopBack Enabled. Just prints back what was keyed in, exactly the same way.

 

Just for Info.

 

[Anon Anon]

This is going to get interesting.  Sharepoint team said the loopback was already disabled.

 

[Legacy User]

Thanks Mike for confirming.

 

You may want to isolate between these 2 issues then....

 

A] Is it a search issue via SPAgent-PolicyServer-LDAP

 

or

 

B] Is it something specifically on SharePoint Server.

 

 

Confirming [A] should be easier with LDAP Search Query and ClaimsWS log + Policy Server trace. If we can confirm that only 3 entries have the UID as "mulligan*"; then we can focus our attention to [B] SharePoint Server / PeoplePicker.

 

Incase of [B] is it difficult to gauge here unless I have a look at your configuration on SharePoint Server. As Josh suggested, please liaise with support.

 

 

Regards

 

Hubert

[Legacy User]

Mike rtnmike

 

Were we able to find out anything via CA Support Ticket?

 

 

Regards

 

Hubert

[Anon Anon]

CA Tech Support has not been much help so far.  We are supposed to have a screen sharing session today.

[Legacy User]

Could I get the ticket number on private message (if deemed appropriate), so that I could locate it internally.

[Legacy User]

Mike rtnmike

 

What browser is being used? IE or something else.

 

Agent for SharePoint Integrated Documents

 

 

Regards

 

Hubert

[Anon Anon]

IE.

[Legacy User]

Thank You Mike for sharing the requested Info

 

• Could we ask the SharePoint Team to send a screenshot of the PeoplePicker search result [see the above screenshot I pasted from my SharePoint Server]. What I am particularly interested is the Search Count value corresponding to each Claim in the PeoplePicker Window [see above screenshot, against mail (1) and useridentifier (1) and TIP Name i.e. CA SiteMinder (2) ].

 

• Also I would like to know when SharePoint Team searches for a User, do they select "All Search Results i.e. Top Root" or do they select "ClaimsProvider TIP associated with CA SiteMinder ClaimsProvider" before hitting Search Icon.

 

• Another odd thing, may be just me, I'd have used a different nomenclature just to segregate SM specific claims (which the product uses) and application specific claims. I am hinting at smuserlastname.
  • NOTE:
    • smuserdisplayname is correct and hardcoded into CA ClaimProvider, which CA ClaimsProvider uses internally to populate and display friendly usernames again gibberish UIDs or CNs.
    • smusergroups is the other one which is hardcoded into the ClaimsProvider to display friendly names for gibberish Groups.
    • Hence just to be clear and neat; do not use sm********* nomenclature unless otherwise recommended.

 

• Has the SharePoint Team searched with another string other than "mulligan". Does it return the same result i.e. additional 2 values (one in small and other in caps).

 

• Is there anyway, we could collect the SharePoint Server logs for the duration of PeoplePicker Search only (in verbose mode) and upload it to the Ticket i.e. Open a PeoplePicker window, in a separate browser open Central Administration UI and enabled verbose logging, then return to PeoplePicker window and search for "mulligan". Then turn off verbose.

 

 

Regards

 

Hubert

[Legacy User]

Mike rtnmike

 

I think the problem is smuserlastname (this is my haunch based on reading the ClaimsWS Trace Log).

 

Check the ClaimsWSTraceLog for the search results for smuserlastname. Search result for smuserlastname returns multiple results from LDAP (16 entries) i.e. however they are only of 2 types i.e smuserlastname=Mulligan and one returns smuserlastname=MULLIGAN.

 

Also for smuserlastname I see the following error for every search result for each user. See from line 218 in the uploaded ClaimsWSTrace log e.g. line 220 and line 359.

 

Is it possible to remove smuserlastname and recreate the TIP. Then test search.

Then add a new Virtual Attribute namely "userlastname" and create a claim using the same nomenclature "userlastname". We'll need to recreate the TIP and Test.

 

At this moment I do not have an answer for; if search results finds 15 entries as userlastname=Mulligan and 1 entry as userlastname=MULLIGAN? Should PeoplePicker or ClaimsProvider display 2 values OR should it display16 values.

 

 

Regards

 

Hubert

[Legacy User]

Mike rtnmike

 

If you could get me the PeoplePicker screenshot (just as I have provided above) - it should help prove whether my haunch is correct or incorrect based on the Search Count value displayed against each Claim Name in PeoplePicker.

 

If we see useridentifier (3) and smuserlastname (2) in PeoplePicker screenshot then it atleast suggests my finding is good.

 

Excited to get that screenshot, waiting!

 

Regards

 

Hubert

[Anon Anon]

useridentifier is mapped to our LDAP user directory "uid" attribute.  This is needed and used when a SharePoint user searches with an employee number (uid) value.  We actually have 3 users whose LDAP:uid begins with "mulligan" and these are the 3 users that are displayed correctly in the People Picker search results.

 

smuserlastname is mapped to our LDAP user directory "sn" attribute.  This is needed for when a SharePoint user searches the People Picker with someone's lastname.  These are the results that are not working correctly, but are certainly needed.

 

I noticed this in the SharePoint trace log and there is an obvious difference in how these 2 attribute mappings work. useridentifier (uid) is out of the box functionality and it works correctly.  We are trying to add smuserlastname (sn) and it is not working correctly.  The documentation doesn't explain anything about adding additional attribute mappings.

 

[ FilterProperty = useridentifier return properties= useridentifier, smuserdisplayname]

[ FilterProperty = smuserlastname return properties= smuserlastname]

[Legacy User]

Mike rtnmike

 

What I am more than 100% sure

 

There can be multiple claims which could be issued. However only one claim could be used as an Identifier Claim.

 

Identifier Claim is something which the user sees at the top right corner when he logs into SharePoint.

 

User can login using any of configured claims (including IdentifierClaim and normal claims).

 

 

What my memory tells me

 

Point-1 :

I think the friendly name support via smuserdisplayname in CASiteMinderClaimsProvider is tagged only to IdentifierClaim. Hence we see [FilterProperty = useridentifier return properties= useridentifier, smuserdisplayname] because useridentifier is set as IdentifierClaim within the TrustedIdentityTokenIssuer in SharePoint. However smuserlastname is set as a normal additional claim (which could be used for login in too) in TrustedIdentityTokenIssuer.

 

Point-2:

Now here's the tricky piece, if we search using sn=mulligan; even if the search worked fine and there is no errors - tell me how would we differentiate which user if the people-picker shows 16 values as 'mulligan'. All its doing is returning what is present in LDAP directory i.e. sn.

[FilterProperty = smuserlastname return properties= smuserlastname]

There either needs to be a means to associate 'smuserdisplayname' to normal claims too inaddition to IdentifierClaim.

 

Now this may be an Enhancement Request. However I would recommend first confirming the above points [1] and [2] via Support into Engineering.

 

 

 

Neverthless, I would still recommend to change the smuserlastname to userlastname to segragate SM ones and non SM ones.

 

 

 

Its been a while I have worked deeply in SharePoint, so I am scratching my head when I am recollecting these info. So please excuse my terseness.

 

 

Regards

 

Hubert

[Legacy User]

But as of now it looks like it is truncating 15 values which are returned as sn=mulligan into one value i.e. "mulligan". Then for one user STEVE MULLIGAN which returns sn=MULLIGAN, this is independently set as "MULLIGAN". This is my interpretation.

 

Hence if CA Support is trying to reproduce the issue request them to test using the same Claim values (i.e. identifierclaim as useridentifier and additional claim smuserlastname) & five / six Users having same SN i.e. mulligan plus with one user having SN=MULLIGAN.

 

 

Regards

 

Hubert

[Anon Anon]

Finally an answer for CA Tech Support.

 

SharePoint People Picker doesn't work correctly for searching by lastname when the desire is to have each user with the lastname returned and to have each user displayed individually.

 

Will be opening an Enhancement Request.

[Anon Anon]

Was this enhancement made in the latest SharePoint Agent version? or still, search for multiple attributes (attributes other than the user identifier) not supported?