Fresh Content on SharePointJoel.com SharePoint Ads
Subscribe in a reader
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
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
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.
PingBack from http://endlands.org/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))
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.
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.
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.
Have you tried this on ssl enabled application, everything works , exsept setting site admin in CA. Seems as if CA forgets allnames ?
For configuration steps of the farm refer to my blog
http://sharepoint2010blog.blogspot.com/2010/02/configuring-moss-farm-with-cross-domain.html
Regards
Juzar Bharmal
Hi Joel,
Quick question. If I have an internal forest with subdomains, is it sufficient to just point it to the root forest or do I have to include each domain? Will pointing it to the root forest allow it to work down through the sub domains?
Thanks,
Jake.