There seems to be a degree of uncertainty as to whether or not a SharePoint farm in domain A can be accessed by users in domain B, when the two domains are in different forests and there is a one way trust between the forests (such that forest A trusts forest B).
We have recently deployed SharePoint 2010 to a global financial services organisation with exactly this scenario. I can categorically say that it does work, but that careful planning is needed. In particular the following need to be taken into account:
- If you want to use Kerberos (and you should unless you have a very good reason not to) then as well as doing all the normal SPN work, make sure that you set up name suffix routing in your trust relationship so that domain B users are able to get a ticket from a domain controller in domain A.
- Use fully qualified service names http://intranet.domaina.com not http://intranet or the above cannot work.
- For the user profile import, use a service account in domain B to import users in domain B.
Configure the people picker to show users from both domains, as follows:
On all servers run: stsadm –o setapppassword –password <AnyKeyPhrase>
This will create a key that is used to encrypt and decrypt the credentials coming next.
On a WFE run: stsadm –o setproperty –url http://<qualifiedaddressofwebapplication> –pn peoplepicker-searchadforests –pv “domain:<qualifiednameofdomainA>;domain:<qualifiednameofdomainB>,<domainb>\<serviceaccounttouse>,<serviceaccountpassword>
This configures the people picker to search both domains. Note that you only need to supply an account and password for domain B, since the process is running under an account in domain A and therefore can access domain A. Note that either or both of the “domain:” terms in the above query can be replaced with “forest:”. I believe this will cause the people picker to use the forest global catalog rather than querying the domain. If you’ve got single domain forests then it probably doesn’t make much difference which you use but if you’ve got multiple domains in a forest then using the global catalog may be quicker.
On all servers go to the “HKLM\Software\Microsoft\Shared Tools\Web Server Extensions\14.0\Secure” registry key and ensure the following permissions are in place and are being inherited in the sub-keys:
- WSS_WPG Read permission
- WSS_Admin_WPG Full Control
WSS_RESTRICTED_WPG_V4 Full Control
This seems to be a bit of a hack but it’s necessary. I guess Microsoft might fix it in a patch. Thanks to this post http://www.agrypnia.com/blog/2010/12/22/sharepoint-2010-there-was-an-error-in-the-callback.html who found out about the registry permissions settings from a Microsoft call. Note that this post also advises that the farm account needs to be a member of the administrators group (don’t like that but the author was following Microsoft instructions so fair enough). However in my tests I didn’t find that to be necessary.
- Bear in mind that you will not be able to write or use any applications that use delegation. Any service running under a domain A account will not be able to delegate a domain B account – this is a consequence of the one way trust.
In summary, plan what you are doing very carefully and make sure you understand what you are doing or speak to someone who does! You won’t get it working by hacking around and relying on trial and error! J