Partilhar via

SharePoint 2013: People Picker Changes

  • Artigo

I recently came across an issue where when I was performing a people picker search for a user's email address however it would not return search results. I did some digging and appears there has been some changes in how we lookup users in AD using LDAP. In SharePoint 2007 and SharePoint 2010, we sent an LDAP request to the Domain Controllers using the application pool account using the following filters for the SearchRequest.

(&(objectCategory=person)(objectClass=user)(!(BIT_AND:
(userAccountControl)&2))(|(name=adam*)(displayName=adam*)(cn=adam*)(mail=adam*)(sn=adam*)(SamAccountName=adam*)(proxyAddresses=SMTP:adam)(proxyAddresses=sip:adam)))

 
(&(objectCategory=group)(BIT_AND:
(groupType)&2147483648)(|(name=adam*)(displayname=adam*)(cn=adam*)(SamAccountName=adam*)))

 

However in SharePoint 2013, even though we still use the application pool account and still using LDAP request, our filter has changed.

 
(&(objectCategory=person)(|(anr=adam*)(SamAccountName=adam*)))

(&(objectCategory=group)(BIT_AND:
(groupType)&2147483648)(|(anr=adam*)(SamAccountName=adam*)))

 

So per our documentation at https://technet.microsoft.com/en-us/library/cc978014.aspx the ANR attribute stands for Ambiguous Name Resolution and is a set of attributes that Active Directory evaluates when it receives an LDAP Search Request. By default, the following attributes are associated with ANR.

 

  • givenName (first name)
  • sn (surname, or last name)
  • displayName (the name given the object when it is created)
  • RDN (the relative distinguished name of the object)
  • legacyExchangeDN (for enterprises that have upgraded a Microsoft® Exchange installation to a later version of Exchange that is synchronized with Active Directory, the distinguished name of the old Exchange mailbox that corresponds to the user in Active Directory)
  • physicalDeliveryOfficeName (for example, Building A, Suite 1234)
  • proxyAddresses (the collection of e-mail addresses over all e-mail address spaces that the Exchange server knows about)

 

So this definitely can cause some issues in SharePoint 2013 if your SharePoint 2007 or SharePoint 2010 environments were previously resolving usernames based on their mail attribute in AD. In order to fix this, you need to perform the following:

 

 

  1. On the DC, open RUN and type REGSVR32 SCHMMGMT.DLL to register the Active Directory Schema Snap-in
  2. Open MMC console via RUN command
  3. Navigate to File > Add/Remove Snapin and load the Active Directory Schema MMC
  4. Expand Active Directory Schema [ServerName.Domain.Com] and select Attributes
  5. Locate the mail attribute and right-click properties
  6. Check 'Ambiguous Name Resolution (ANR)' and select Apply. Select OK
  7. Right-Click on 'Active Directory Schema[ServerName.Domain.Com] and select 'Reload the Schema'

 

Now you should be able to perform a search for value stored in the mail attribute in SharePoint 2013 and return results! The cool thing about this type of configuration is that you can easily extend your Active Directory schema using the same steps above to allow SharePoint to query other attributes in your domain environment without having to write your own custom SharePoint queries as previous with older versions of SharePoint.

 

Hope this helps!

Comments

  • Anonymous
    January 01, 2003
    Good job.

  • Anonymous
    January 01, 2003
    Good story

  • Anonymous
    January 16, 2014
    Nice!I need to give this a try with employeeID attribute. It appear people picker wont pick this attribute when you set a custom filter for employeeID!!