Welcome to MSDN Blogs Sign in | Join | Help

Cross Forest, Multi Forest Configuration and Additional Info

I’ve been pinged a couple of times recently about multi forest environments.  This *does* work.  It *was* tested.  You do need *at least* a one way trust.  Thanks Shaofeng and Venky.

 

This is an update to the people picker post I did a while back. 

 

Background

 

The people picker works in cross domain or cross forest environment. It works in both-way trust and one-way trust environment.

 

Out of the box, if the admin does not do any configuration, the people picker will issue queries to all two-way trusted domains and two-way trusted forests to search people & groups.

 

The people picker uses the application pool account to search the target domains and forests. If the application pool account does not have permission to the target domains or forests, or the admin want to use different account to search the target domains or forests, the admin could should use

 

How to Configure

 

Don’t forget to run stsadm.exe –o setapppassword –password <somekey> on all machines in the farm where SharePoint is installed

 

1.     Run on every WFE.

stsadm.exe -o setapppassword -password <somekey>

 

2.     Run on one WFE

 

stsadm.exe -o setproperty -url ...

 

Additional details on the commands

 

Stsadm.exe -o setapppassword -password <somekey>

to set a key that will be used to encrypt/decrypt the password

then run

 

stsadm.exe –o setproperty –pn peoplepicker-searchadforests –pv <list of forests or domains> -url <webapp>

 

The format of <list of forests or domains> is a list of

 

             forest:DnsName,LoginName,Password

or

             domain:DnsName,LoginName,Password

 

separated by semicolon.

 

If they are trusted domains/forests, then it is not necessary to passin the LoginName or Password, just in the format of

             forest:DnsName

or

             domain:DnsName

 

Please note that if the Password is specified in the forest:DnsName,LoginName,Password or domain:DnsName,LoginName,Password, admin must  run stsadm.exe -o setapppassword -password <somekey> on every web front end. <somekey> could be any string. We will use <somekey> to encrypt the Password in domain:DnsName,LoginName,Password or forest:DnsName,LoginName,Password and stored the encryped Password in the database. Also, please run stsadm.exe -o setapppassword -password <somekey> on every web frontend machines with the same <somekey> in the same farm. For different web farm, please use different <somekey>.

 

Having problems?

 

1.     Does server domain trust target forest? There must be at least one-way trust.

 

2.     The app pool account is not necessary from the target forest. It could be in Server’s domain. If the app pool account is in server domain and the target forest does not trust server domain, please specify an account that has permission to target forest in

 

             forest:DnsName,LoginName,Password

3.     Did you run both commands?

 

I understand there isn’t much documentation on this yet, I am working with the TechNet SharePoint IT Pro technical documentation team to post more detailed information on this.

Published Thursday, March 08, 2007 7:54 PM by joelo

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# End Lands &raquo; Cross Forest, Multi Forest Configuration and Additional Info

Tuesday, April 03, 2007 9:13 AM by Tim G.

# re: Cross Forest, Multi Forest Configuration and Additional Info

Are there any guides floating around on how to trim the people picker results?  I would like to do something similar to how we use a basic LDAP query to trim the profile import.  As it is, however, I end up with a lot of disabled accounts and accounts from trusted domains that we do not want visable to our users through the people picker.

A filter such as this along with explicit domain inclusion would be ideal:

  (&(&(objectCategory=Person)(objectClass=User)(employeeid=*))(!UserAccountControl:1.2.840.113556.1.4.803:=2))

Wednesday, April 11, 2007 5:21 PM by C. Allen

# re: Cross Forest, Multi Forest Configuration and Additional Info

I just completed a Microsoft Support ticket for our problems with the People Picker not working correctly in a one-way forest trust situation. They reveiwed all of our efforts and indicated the recommended solution is to only use a two-way trust. No chance of that happening in our security environment! If this is truly the MS party line on this issue, please pass on to the SharePoint team that they should dig a bit deeper into the problems of cross-forest support.

Wednesday, April 11, 2007 10:13 PM by joelo

# re: Cross Forest, Multi Forest Configuration and Additional Info

Product support is likely wanting to see the product documentation on this.  Let's say it's a feature in the product, but since the tech documentation team hasn't gotten to cross forest yet, they don't know how to support it.

Monday, May 28, 2007 7:58 AM by Kevin Parks

# re: Cross Forest, Multi Forest Configuration and Additional Info

Thanks, it worked like a charm in my multi forest, multi domain solution.  

If you are using 1 way trust, you must use the password option.  

Run the setpassword on each front end.

Run the peoplepicker with all of your domain/forests in the list, with password to those domains in the list on each front end.  Do this for each app pool url you have.

I have many urls so I set up a batch file.  Unfortuately I can't upload it here.  Now when I need to add another domain, I just update the batch file and run it on all my frontends.

Leave a Comment

(required) 
required 
(required) 

  
Enter Code Here: Required
 
Page view tracker