Geeks With Blogs
Points To Share Mostly SharePoint

© 2011 By: Dov Trietsch. All rights reserved

finding a person in the forest or Limiting the AD result in SharePoint People Picker

There are times when we need to limit the SharePoint audience of certain farms or servers or site collections to a particular audience. One of my experiences involved limiting access to US citizens, another to a particular location.

Now, most of us – your humble servant included – are not Active Directory experts – but we must be able to handle the “audience restrictions” as required. So here is how it’s done in a nutshell.

Important note. Not all could be done in PowerShell (at least not yet)! There are no Windows PowerShell commands to configure People Picker.

The stsadm command is:

stsadm -o setproperty -pn peoplepicker-searchadcustomquery -pv ADQuery –url http://somethingOrOther

Note the long-hyphenated property name. Now to filling the ADQuery.

 

LDAP Query in a nutshell

Syntax

LDAP is no older than SQL and an LDAP query is actually a query against the LDAP Database. LDAP attributes are the equivalent of Database columns, so why do we have to learn a new query language? Beats me! But we must, so here it is.

The syntax of an LDAP query string is made of individual statements with relational operators including:

= Equal
<= Lower than or equal
>= Greater than or equal… and
memberOf – a group membership.
! Not
* Wildcard
Equal and memberOf are the most commonly used.

Checking for absence uses the ! – not and the * - wildcard

Example: (SN=Grant) All whose last name – SurName – is Grant
Example: (!(SN=Grant)) All except Grant
Example: (!(SN=*)) all where there is no SurName i.e SurName is absent (probably Rappers).
Example: (CN=MyGroup) Common Name is MyGroup. 
Example: (GN=J*) all the Given Names that start with J (JJ, Jane, Jon, John, etc.)
The cryptic SN, CN, GN, etc. are
attributes and more about them later

All the queries are enclosed in parentheses (Query).

Complex queries are comprised of sets that are in AND or OR conditions. AND is denoted by the ampersand (&) and the OR is denoted by the vertical pipe (|).

The general syntax is that of the Prefix polish notation where the operand precedes the variables. E.g +ab is the sum of a and b.

In an LDAP query (&(A)(B)) will garner the objects for which both A and B are true.
In an LDAP query (&(A)(B)(C)) will garner the objects for which A, B and C are true. There’s no limit to the number of conditions.

In an LDAP query (|(A)(B)) will garner the objects for which either A or B are true.
In an LDAP query (|(A)(B)(C)) will garner the objects for which at least one of A, B and C is true. There’s no limit to the number of conditions.

More complex queries have both types of conditions and the parentheses determine the order of operations.

Attributes

Now let’s get into the SN, CN, GN, and other attributes of the query

SN – is the SurName (last name)
GN – is the Given Name (first name)
CN – is the Common Name, usually GN followed by SN
OU – is an Organization Unit such as division, department etc.
DC – is a Domain Content in the AD forest
l – lower case ‘L’ stands for location. Jerusalem anybody? Or Katmandu.
UPN – User Principal Name, is usually the first part of an email address. By nature it is unique in the forest. Most systems set the UPN to be the first initial followed by the SN of the person involved. Some limit the total to 8 characters. If we have many ‘jsmith’ we have to somehow distinguish them from each other.
DN – is the distinguished name – a name unique to AD forest in which it lives. Usually it’s a CN with some domain or group distinguishers. DN is important in conjunction with the memberOf relation. Groups have stricter requirement. Each group has to have a unique name - its CN and it has to be unique regardless of its place. See more below.

All of the attributes are case insensitive. CN, cn, Cn, and cN are identical.

objectCategory is an element that requires special consideration. AD contains many different object like computers, printers, and of course people and groups. In the queries below, we’re limiting our search to people (person).

Putting it altogether

Let’s get a list of all the Johns in the SPAdmin group of the Jerusalem that local domain.

(&(objectCategory=person)(memberOf=cn=SPAdmin,ou=Jerusalem,dc=local))

The memberOf=cn=SPAdmin uses the cn (Common Name) of the SPAdmin group. This is how the memberOf relation is used. ‘SPAdmin’ is actually the DN of the group. Also the memberOf relation does not allow wild cards (*) in the group name. Also, you are limited to at most one ‘OU’ entry.

Let’s add Marvin Minsky to the search above.

|(&(objectCategory=person)(memberOf=cn=SPAdmin,ou=Jerusalem,dc=local))(CN=Marvin Minsky)
Here I added the or pipeline at the beginning of the query and put the CN requirement for Minsky at the end. Note that if Marvin was already in the prior result, he’s not going to be listed twice.

One last note: You may see a dryer but more complete list of attributes rules and examples in: http://www.tek-tips.com/faqs.cfm?fid=5667

And finally (thus negating the claim that my previous note was last), to the best of my knowledge there are 3 more ways to limit the audience.

One is to use the peoplepicker-searchadcustomfilter property using the same ADQuery. This works only in SP1 and above.

The second is to limit the search to users within this particular site collection – the property name is peoplepicker-onlysearchwithinsitecollection and the value is yes (-pv yes)

And the third is –pn peoplepicker-serviceaccountdirectorypaths –pv “OU=ou1,DC=dc1…..”

Again you are limited to at most one ‘OU’ phrase – no OU=ou1,OU=ou2…

And now the real end. The main property discussed in this sprawling and seemingly endless monogram – peoplepicker-searchadcustomquery - is the most general way of getting the job done. Here are a few examples of command lines that worked and some that didn’t. Can you see why?

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN>stsa
dm -o setproperty -url http://somethingOrOther -pn peoplepicker-searchadcustomfi
lter -pv (Title=David)

Operation completed successfully.

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN>stsa
dm -o setproperty -url http://somethingOrOther -pn peoplepicker-searchadcustomfi
lter -pv (!Title=David)

Operation completed successfully.

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN>stsa
dm -o setproperty -url http://somethingOrOther -pn peoplepicker-searchadcustomfi
lter -pv (OU=OURealName,OU=OUMid,OU=OUTop,DC=TopDC,DC=MidDC,DC=BottomDC)

Command line error. Too many OUs

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN>stsa
dm -o setproperty -url http://somethingOrOther -pn peoplepicker-searchadcustomfi
lter -pv (OU=OURealName)

Operation completed successfully.

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN>stsa
dm -o setproperty -url http://somethingOrOther -pn peoplepicker-searchadcustomfi
lter -pv (DC=TopDC,DC=MidDC,DC=BottomDC)

Operation completed successfully.

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN>stsa
dm -o setproperty -url http://somethingOrOther -pn peoplepicker-searchadcustomfi
lter -pv (OU=OURealName,DC=TopDC,DC=MidDC,DC=BottomDC)

Operation completed successfully.

 

That’s all folks!

 

 

Posted on Wednesday, November 16, 2011 1:51 PM | Back to top


Comments on this post: Finding a person in the forest

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © PointsToShare | Powered by: GeeksWithBlogs.net