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.
Thank you very much! I checked more than 20 posts and your post was the one that helps me!
ReplyDeleteYou're welcome. Glad to help.
ReplyDeleteHi martin,
ReplyDeleteI 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.
Awesome article! I tried your approach however the people picker still can't find the user. Here is what I did:
ReplyDelete1. 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!
Hello Levine,
ReplyDeleteI 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.
Hi Martin,
ReplyDeleteThanks for pointing that out. So when will be the key created in the first command be used? Is the first step required?
Thanks,
Hello Levine,
ReplyDeleteThe 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.
Hi Martin,
ReplyDeleteThanks 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.