Tuesday, October 18, 2011

SharePoint People Picker Filters Strike Back

Yay, Free Integration

One of the benefits of rolling out SharePoint in intranet environments is that it marries pretty well with Active Directory (and other LDAPs). An example of this is the People Picker. It allows you resolve (or look up) any user in the LDAP that you’re authenticating against.

Since LDAPs often get pretty dated/polluted there’s often a need to filter out certain sections of the LDAP or a certain genre of results. These might be old employees who have left the company, or users from a section of the organization that just aren’t relevant to the web application at hand.

An example of a filter at the Organizational Unit is below. The following filter ensures that the people pickers in the given web application only pull users from the Employees organizational unit (OU).

stsadm -o setsiteuseraccountdirectorypath -url http://webApplicationUrl -path "OU=Employees,DC=fullly,DC=quallified,DC=domain,DC=com"

Should you change your mind later, the following removes the filter above. In general, no application pool recycle or IISReset is required.

stsadm -o setsiteuseraccountdirectorypath -url http://webApplicationUrl -path ""

It’s worth mentioning that these filters don’t affect existing accounts in the site collection that have already been added. They only stop future users additions that would collide with the give filter.

There are some pretty expressive filters available out there. Many can target specific LDAP properties like title, name, organization, etc… or other fields. Examples can be found at:

The Resulting Errors

The problem with these filters is that its easy to forget about them and remember that they’re still in play. Specifically when adding users to a group, administrators/site owners are sometimes greeted with:

The user does not exist or is not unique. at Microsoft.SharePoint.Library.SPRequestInternalClass.UpdateMembers(String bstrUrl, Guid& pguidScopeId, Int32 lGroupID, Int32 lGroupOwnerId, Object& pvarArrayAdd, Object& pvarArrayAddIds, Object& pvarArrayLoginsRemove, Object& pvarArrayIdsRemove, Boolean bSendEmail) at Microsoft.SharePoint.Library.SPRequest.UpdateMembers(String bstrUrl, Guid& pguidScopeId, Int32 lGroupID, Int32 lGroupOwnerId, Object& pvarArrayAdd, Object& pvarArrayAddIds, Object& pvarArrayLoginsRemove, Object& pvarArrayIdsRemove, Boolean bSendEmail)

Which is an awfully confusing error. When you get the above, make sure that there aren’t any filters in play that would normally preclude the given user from resolving as they can cause this error.

You can check the existence of a directory path filter by running the following stsadm command:

stsadm -o getsiteuseraccountdirectorypath -url https://webApplicationUrl

If there are, remove them first and then try again. This is a step that should often be done before getting too far into a troubleshoot.

Hope that helps.

My Best,
Tyler

2 comments:

Henry Ong said...

Hi Tyler, would you happen to have any ideas as to why the error message you mentioned would occur if there are not directory path filters?

Sharepoint developer said...

I was once having a issue with People Picker, it was not allowing me to pick the security group whereas SharePoint queries AD, it was using the display name. Finally I found that the display name shouldn't be same as the account name, they both should be different.