The People picker and domain trusts

by Robi 30. January 2014 21:58

In the last couple of projects on SharePoint I was working with environments, where company was associated with couple of domains. Since SharePoint has to be configure to work in such environments, I decided to introduce the issue on two typical scenarios and explain in what way it is then necessary to set up a SharePoint site, to make it possible to resolve users in people picker from other domains.

Scenario 1 – "Two way trust"

The characteristic of "Two Way Trust" is that users from domain 1 have rights to access resources in domain 2 and vice versa. This means that users from a domain 1 can read data in the Active Directory of domain 2 and users from a domain 2 can read data from AD in domain 1. This is very important information, since configuration of SharePoint Server depends on these characteristic.

Figure 1 shows the scenario where we have set up 2 way trust between the domain 1 and domain 2. In domain 1 SharePoint Server is placed, which can be used by users from domain 1 and domain 2. The Problem, which in this case refers to the People picker is that people picker by default search only in Active Directory domain in which the SharePoint Server is installed. So, if you want to add users from other domains, we need to fix some of the settings on the SharePoint Server.

Settings that must be set in this case refers to the entire web application. Of course, these settings cannot be set in the user interface, so it is necessary in this case to open SharePoint 2013 Management Shell and enter a couple of lines of code.

$wa = Get-SPWebApplication http://portal.domena1.loc

 

# List the current values for a web application

$wa.PeoplePickerSettings.SearchActiveDirectoryDomains

 

 

<# ====================================

 

Portal web app

 

===================================== #>

 

 

 

 

<####################################  

 

Domain 1

 

####################################>

$newdomain1 = new-object Microsoft.SharePoint.Administration.SPPeoplePickerSearchActiveDirectoryDomain

 

### #### ### Register FQDN ### ### ###

$newdomain1.DomainName ='domena1.loc ';

 

### #### ### Register netbios name ### ### ###

$newdomain1.ShortDomainName ='domena1';

$wa.PeoplePickerSettings.SearchActiveDirectoryDomains.Add($newdomain1)

 

<####################################  

 

Domain 2

 

####################################>

$newdomain2= new-object Microsoft.SharePoint.Administration.SPPeoplePickerSearchActiveDirectoryDomain

 

 

### ### ### Register FQDN ### ### ###

$newdomain2.DomainName ='domena2.loc';

 

### #### ### Register netbios name ### ### ###

$newdomain2.ShortDomainName ='domena2';

 

$wa.PeoplePickerSettings.SearchActiveDirectoryDomains.Add($newdomain2)

 

 

$wa.Update ()

For setting the "People Picker" control, first we need to save the web application object in a new variable. The current value of the variable can be listed with the following command $wa.PeoplePickerSettings. SearchActiveDirectoryDomains.

In order to be able to add new values to search other domains, we have to make a new object of type Microsoft. SharePoint. Administration. SPPeoplePickerSearchActiveDirectoryDomain, and then set the value. The first value is the FQDN of the domain and the second value is the NetBIOS name, for a short domain name. The same procedure must be repeated for all the domains that you want to allow in the people picker.

At the end we have to, of course, save the changes that are stored in the web application object. We have to repeat the procedure on all web applications on which we want to change the behavior of the people picker, including the Central Administration.

Scenario 2 – "a One way trust"

»One way trust" is a way of linking domains where one domain trusts another domain. For example, I used a one way trust between domain 1 and domain 2, where domain1 trusts domain 2, while domain 2 does not trust domain 1. To make it simple, we could say that the users from domain 2 can access data in the domain 1 while domain 1 users cannot access the data in the domain 2. Such a scenario is widely used among intranet and extranet environments, where users from the intranet domain can access extranet domain, while the reverse is not possible.

   

In a scenario where you use one way trust ", we can use the same script that we used in bidirectional trusts, with the difference that you need to provide some sort of access. These parameters are the username and password of the user who will be able to access resources in the domain 2.

 

<####################################

 

Creating a password app

 

####################################>

 

Stsadm –o setapppassword –password 'Pa$$w0rd'

 

# ========================================================

 

$wa = Get-SPWebApplication http://portal.domena1.loc

 

# List the current values for a web application

$wa.PeoplePickerSettings.SearchActiveDirectoryDomains

 

 

<# ====================================

 

Portal web app

 

===================================== #>

 

 

 

 

<####################################  

   

Domain 1

                     

####################################>

$newdomain1= new-object Microsoft.SharePoint.Administration.SPPeoplePickerSearchActiveDirectoryDomain

 

### #### ### Register FQDN ### ### ###

$newdomain1.DomainName ='domena1.loc';

 

### #### ### Register netbios name ### ### ###

$newdomain1.ShortDomainName ='domena1';

$wa.PeoplePickerSettings.SearchActiveDirectoryDomains.Add($newdomain1)

 

<####################################  

   

Domain 2

                     

####################################>

$newdomain2 = new-object Microsoft.SharePoint.Administration.SPPeoplePickerSearchActiveDirectoryDomain

 

### ### ### Accounta rights Settings ### ### ###

$user="domena2\accountPravice"

$pass=convertto-securestring 'Pa$$w0rd' –AsPlainText -Force

$credentials=new-object –typename System.Management.Automation.PSCredential –argumentlist $user,$pass

$newdomain1.LoginName=$credentials.UserName

$newdomain1.SetPassword($credentials.Password)

 

 

### ### ### Register FQDN ### ### ###

$newdomain2.DomainName ='domena2.loc';

 

### #### ### Register netbios name ### ### ###

$newdomain2.ShortDomainName='domena2';

 

$wa.PeoplePickerSettings.SearchActiveDirectoryDomains.Add($newdomain2)

 

 

$wa.Update()

 

Because in this scenario, the application pool account does not have rights to access resources that are in a domain 2, we need to set the username and password for access to Active Directory objects in domain 2.

The first step is to create the app password for storing credentials on all server in our farm. Command Stsadm –o setapppassword –password 'Pa$$w0rd' creates a registry key where app pool account can read credential key from.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\15.0\Secure

The next step is to create a connection for each domain specifically and also set up a user account for connecting to the specified domain.

For these purpose, you can use the account that synchronize data between SharePoint Server and Active Directory, provided that we have a SharePoint Server and the User Profile Synchronization Service. Otherwise, you can create normal service account, which will be exclusively used for reading data from the specified domain.

The last step is to set up application pool account permissions to read AppCredentialKey. AppCredentialKey registry key is limited to certain local server groups and if the permissions are not correctly set up, Event Logs are full of "Registry access is not allowed" errors and users are not getting resolved in the people picker. Users and groups that have access to registry key by default are:

  • System
  • Network Service
  • WSS_Restricted_WPG_V4
  • Administrators

In order to grant access for application pool to the AppCredentialKey, you can add service account to WSS_Restricted_WPG_V4 group. Accounts, which must be in this group are:

  • Application pool account for the web application
  • The Sandbox service account
  • The service account of the Central Administration – provided that it is not in the Administrators group.

SharePoint configuration can be quite challenging in some scenarios so I hope that this post will help SharePoint admins ease their work and enhance their understanding of SharePoint. This configuration also applies for SharePoint 2010.

 

Rob Vončina

SharePoint Server MVP

Tags:

SharePoint 2010 | SharePoint 2013 | SharePoint - Administration | PowerShell

Add comment

Calendar

<<  July 2018  >>
MonTueWedThuFriSatSun
2526272829301
2345678
9101112131415
16171819202122
23242526272829
303112345

View posts in large calendar

Page List

Month List