All you want to know about People Picker in SharePoint ( Functionality | Configuration | Troubleshooting ) Part-1
The people-picker is a SharePoint interface responsible for querying repositories for identities or groups in order to grant them permission in the SharePoint application. Site administrators and other users use the People Picker Web control to select people and groups when assigning permissions. There are two possible ways to add users, via the checkname or via the browse feature.
The checkname is the icon with a messenger guy and a checkmark :
The browse feature is the book icon:
Let's get's into the internals of what happens when you go add a user /Group & say Checkname or Browse
Default Configuration , How this works
- Site administrator or other users submit a query to the people-picker web control.
- The WFE performs a DNS query in order to locate a domain controller hosting the Global Catalog Service.
- Once located it tries to connect to it . This first connection, which is anonymous, will report to the SharePoint server extra information over the DC it contacted. It will include various LDAP information, the its exact capabilities as well as the authentication mechanism it supports. This entry point is known as the “Root” or “RootDSE” .
- If the AD requires authentication, which is by default the case, SharePoint will authenticate using the context of the IIS application pool the SharePoint web application runs under. It can be Local system or Network Service or a specified domain user .
- The WFE sends an LDAP Global Catalog Search Request to the DC asking for any match in the whole subtree for user or group objects with attributes that contain the search string (a wildcard search version of the User display name) in one of the following attributes:
# User objects: 'name', 'displayName', 'cn', 'sn', 'SamAccountName', 'mail', SMTP or sip 'proxyAddresses' attributes.
# Group objects: 'name', 'displayName', 'cn', or 'SamAccountName' attributes.
Here is how the frame looks like a Network capture ( filtered for LDAP traffic ) , searching for a string " Teds" which is for a user name Ted Simpson . Check out list of attributes requested to be returned for each record & server Controls Specified . The Browse feature will use the LDAP filter to search for a user .
The Check name option will try to connect to one of the dc’s in its domain & tries to do a SID lookup using the windows API LsarLookupNames4 .The LsarLookupNames4 method translates a batch of security principal names to their SID form. This traffic is encrypted and the Web server and domain controller talks via RPC. If unsuccessful it falls back to LDAP query as used by Browse ( The LDAP Query Filter used is the same as described below but without the wildcard expression ‘ * ’ ).
LDAP Query Filter
(&(objectCategory=person)(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(|(name={teds}*)(displayName={teds}*)(cn={teds}*)(mail={teds}*)(sn={teds}*)(SamAccountName={1}*)(proxyAddresses=SMTP:{teds})(proxyAddresses=sip:{teds}){2}))", "(&(objectCategory=person)(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(|(name={teds})(displayName={teds})(cn={teds})(mail={teds})(samAccountName={teds})(proxyAddresses=SMTP:{teds})(proxyAddresses=sip:{teds})))", "(&(objectCategory=person)(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(|(mail={teds})(proxyAddresses=SMTP:{teds})))"), new SearchParameter("(&(objectCategory=group)(|(name={teds}*)(displayname={teds}*)(cn={teds}*)(SamAccountName={1}*)(mail={teds}*)(proxyAddresses=SMTP:{teds}){2}))", "(&(objectCategory=group)(|(name={teds})(displayname={teds})(SamAccountName={teds})(mail={teds})(proxyAddresses=SMTP:{teds})))", "(&(objectCategory=group)(|(mail={teds})(cn={teds})(proxyAddresses=SMTP:{teds})))"), new SearchParameter("(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483648)(|(name={teds}*)(displayname={teds}*)(cn={teds}*)(SamAccountName={1}*){2}))", "(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483648)(|(name={teds})(displayName={teds})(cn={teds})(samAccountName={teds})))
The query conditions as seen in the above LDAP query Filter are :
- We are searching for a user or a group
- If it is user, it must not be disabled & at least one of the following attribute must begin with the input the user provided: name, displayName, cn, mail, sn, SamAccountName, proxyAddresses etc
- If it is a group, at least of the following attribute must begin with the input the user provided: name, displayname, cn, SamAccountName
- if it is a group, it must be a security group (domain local, global or universal), not a distribution group
6. The DC responds with an LDAP Global Catalog Search Response containing both user and group objects that match the search string & results are displayed . Check out the responses to the list of attributes request in the search query
After the Successful LDAP response in either case ( Browse or Checkname ) we go & verify the user based on the SID value ( Value of Object Sid ) obtained as a result of the query using the Windows API LsarLookupSids3 . The LsarLookupSids3 method translates a batch of security principal SIDs to their name forms. Once this is successful we move forward in the query process else fail to display names.
After the the LDAP response is received & successful verification of the user via ObjectSid , a lot more is done before the result is displayed in the PeoplePicker UI . For details on what is the actual process flow & stuff happening in the SQL server in terms of Stored procedures being executed in the background etc, please refer to the following links from Microsoft TechNet .
Active Directory: People Picker Check Name UI
Active Directory: People Picker Browse Display UI
References :
How to query Active Directory by using a bitwise filter
Searching for Groups by Scope or Type in a Domain
I will be covering how to configure PeoplePicker to query Additional forest or Domains in the next post & Troubleshooting People Picker Issues in the subsequent ones . So keep watching for this Space