Thursday, May 5, 2011

SharePoint 2010 - Multiple Domains - People picker

The other day I had to configure a SharePoint 2010 server to support 2 AD using a one way trust. The AD the server it self resides in and a customer AD. I found out that you need to tell SharePoint to look search in other Domains too. Fortunately this is quite simple.

You need to run 2 stsadm commands.

stsadm -o setapppassword -password <yourkey>

Replace <yourkey> with your own key. This key is used to encrypt things(I'll explain what later on). This command should be run on each server  in the farm with the exact same Key.

Next you register all the domains you want searched (except the on your server is in). You'll need to do this for each web application, not for each server.

stsadm -o setproperty -pn peoplepicker-searchadforests -pv domain:domainA.local,domainA\account,password -url http://webapplication

Running this command overwrites the previous entry. Fortunately the commands support adding multiple domains. You do that like this:

stsadm -o setproperty -pn peoplepicker-searchadforests -pv domain:domainB.local,domainB\account,password;domain:domainA.local,domainA\account,password -url http://webapplication

<domain:domainA.local> -  this is how you specify what domains to tell SharePoint to search in. You separate different domains with a ";"

<domainA\account,password>  - is used to give SharePoint an account to traverse a domain to look for accounts. This is needed to find people by the people picker. The user account needs read rights and rights to traverse the AD tree. Now here the Key set in the first stsadm command comes into play. The key is used as an encryption key to encrypt the password during communication between the SharePoint server and the AD.

It is also possible to add a Forest instead of a domain. You do that like this:

stsadm -o setproperty -pn peoplepicker-searchadforests -pv
forest:domainA.local,domainA\account,password -url http://webapplication

You could combine forests and domains like this:

stsadm -o setproperty -pn peoplepicker-searchadforests -pv
forest:domainA.local,domainA\account,password;domain:domainB.local,domainB\account,password -url http://webapplication

If the domains or forests are trusted, it is not necessary to pass in the loginname or password (if you don't mind not finding people from the trusted domain in the people picker). You could then skip that part and your command would look something like this:

stsadm -o setproperty -pn peoplepicker-searchadforests -pv
forest:domainA.local;domain:domainB.local -url http://webapplication

That's about it I think.

14 comments:

  1. Thank you very much! I checked more than 20 posts and your post was the one that helps me!

    ReplyDelete
  2. You're welcome. Glad to help.

    ReplyDelete
  3. Hi martin,
    I am facing issues in people picker with ceratin urls:
    It is working fine in ssp and on other sites it is not findin the result of the forest domain.
    please help if possible.

    ReplyDelete
  4. Awesome article! I tried your approach however the people picker still can't find the user. Here is what I did:

    1. Created a encryption key with
    stsadm -o setapppassword -password

    2. Registered the domain with
    stsadm -o setproperty -pn peoplepicker-searchadforests -pv domain:domain2.company.com, domain2\testuser, mykey -url http://testwebapplication:portnumber

    The test user has read permission.

    The command returned successful. However when I went to the test web application and tried to add a user to the administrator group with people picker it still couldn't find it. Is there something wrong with the command I used, or there is something I missed?

    I also tried registering both domains but still no luck :(

    Thanks very much. Any feedback is appreciated!

    ReplyDelete
  5. Hello Levine,

    I think your seccond command is wrong.

    stsadm -o setproperty -pn peoplepicker-searchadforests -pv domain:domain2.company.com, domain2\testuser, mykey -url http://testwebapplication:portnumber


    mykey should be the password for your testuser. Not the key set in the first command.

    ReplyDelete
  6. Hi Martin,

    Thanks for pointing that out. So when will be the key created in the first command be used? Is the first step required?

    Thanks,

    ReplyDelete
  7. Hello Levine,

    The key is used to encrypt the password you send in your second command. It ensures security. You don't use it yourself however the system does it for you.

    ReplyDelete
  8. Hi Martin,

    Thanks a lot for your reply. Sorry one more dumb question: Before registering the 2nd AD, do you need to open some ports between the Sharepoint servers and the domain controller of this AD (DC2)? Or you just need to open those ports between the DC1 and DC2, and then DC2 will be able to communicate with the sharepoint servers via DC1? There is a one way trust in which DC1 trusts DC2.

    ReplyDelete
  9. What steps in excess of the sharepoint configuration are required if the secondary domain demands that LDAP over SSL is used?

    ReplyDelete
    Replies
    1. Hello Fahim,

      I have never done that so I don't know. Sorry.

      Delete
  10. You need ports (TCP presumably) 88, 139 and 445 open according to this post:

    http://martijnschouten.wordpress.com/2010/06/02/sharepoint-2010-domain-trusts-people-picker/

    ReplyDelete
  11. I tried the commands and at I really don't know why it's not working =( I did almost everything there is by the book and still, nothing happens.

    This used to work with our previous setup until the trust connection broke for some reason. When out tech group fixed the trust connection, the people picker failed to work again but I can search the users from Domain2 just fine.

    I set the people picker settings back to default then did the 2-way trust setup once more but it's just not working. I tried countless IISRESET, Profile Syncs, Restarts but still, nothing doing,

    Any ideas on what I'm missing?

    ReplyDelete
  12. I don't see where "yourkey" is used once it is created. Shouldn't be passed along somewhere?
    And is there a way to determine whether there is already a key there? I would hate to cause other services to fail because I overwrote a key...

    ReplyDelete
  13. I'm finding that you need quotes around the property value in order for the command to work.

    ReplyDelete