The SuperGuide To User Profile Sync and People Picker in a Heavily-Firewalled Network
pplpickerblog

The SuperGuide To User Profile Sync and People Picker in a Heavily-Firewalled Network

Posted by on Friday, May 9th, 2014  

 

Are you struggling to get User Profile Service to synchronize in your environment… particularly when there are firewalls involved? How about that troublesome People Picker?

 

We recently had to do quite a bit of research into this topic. I’m pulling it all together here for you. For this example, let’s assume that you have a SharePoint 2013 farm in one domain and your users belong to many other domains. Let’s also assume your primary domain has a two-way trust with the other domains.

User Profile Synchronization Service

 

There’s a few gotchas here with the User Profile Sync Service. Namely, we learned that if you use a single Active Directory synchronization connection to multiple domains you may find yourself backing out of that approach. You may want to create a different connection for each domain. If there are any failures with the other domains during synchronization you can isolate the failures and deal with them on a per-domain basis.

 

Since you have a two-way trust going on you can use the same account to run the User Profile Synchronization connection. That’s good news. Start with the Active Directory permissions though. You’ll have to set those up in the guide located here:

 

http://technet.microsoft.com/en-us/library/hh296982.aspx

 

Let me summarize the ones that are really important. You must do this for the synchronization account on every Active Directory domain that will be in the User Profile Service for SharePoint 2013. You’ll be setting up the very-scary-sounding “Replicate Directory Changes” permission on the domain. No, you are not allowing this service account to make changes to Active Directory.

 

The Replicate Directory Changes permission enables the synchronization account to read AD DS objects and to discover AD DS objects that have been changed in the domain. The Grant Replicate Directory Changes permission does not enable an account to create, modify or delete AD DS objects.

 

To grant Replicate Directory Changes permission on a domain 

 

  1. On the domain controller, click Start, click Administrative Tools, and then click Active Directory Users and Computers. 
  2. In Active Directory Users and Computers, right-click the domain, and then click Delegate Control. 
  3. On the first page of the Delegation of Control Wizard, click Next.
  4. On the Users or Groups page, click Add. 
  5. Type the name of the synchronization account, and then click OK.
  6. Click Next. 
  7. On the Tasks to Delegate page, select Create a custom task to delegate, and then click Next. 
  8. On the Active Directory Object Type page, select This folder, existing objects in this folder, and creation of new objects in this folder, and then click Next. 
  9. On the Permissions page, in the Permissions box, select Replicating Directory Changes (select Replicate Directory Changes on Windows Server 2003), and then click Next.
  10. Click Finish. 

 

Add the account to the Pre-Windows 2000 Compatible Access group 

 

Use this procedure to add an account to the Pre-Windows 2000 Compatible Access group.

 

  1. To add an account to the Pre-Windows 2000 Compatible Access group, on the domain controller, click Start, click Administrative Tools, and then click Active Directory Users and Computers. 
  1. In Active Directory Users and Computers, expand the domain, expand Builtin, right-click Pre-Windows 2000 Compatible Access, and then click Properties.
  1. In the Properties dialog box, click the Members tab, and then click Add.
  1. Type the name of the synchronization account, and then click OK.
  1. Click OK.

 

Grant Replicate Directory Changes permission on the cn=configuration container 

 

Use this procedure to grant Replicate Directory Changes permission on the cn=configuration container to an account.

 

  1. To grant Replicate Directory Changes permission on the cn=configuration container, on the domain controller, click Start, click Run, type adsiedit.msc, and then click OK. 
  2. If the Configuration node is not already present, do the following:
  3. In the navigation pane, click ADSI Edit. 
  4. On the Action menu, click Connect to. 
  5. In the Connection Point area of the Connection Settings dialog box, click Select a well know Naming Context, select Configuration from the drop-down list, and then click OK.
  6. Expand the Configuration node, right-click the CN=Configuration… node, and then click Properties. 
  7. In the Properties dialog box, click the Security tab.
  8. In the Group or user names section, click Add. 
  9. Type the name of the synchronization (HCO\SP_I_Prod_UPS) account, and then click OK.
  10. In the Group or user names section, select the synchronization account.
  11. In the Permissions section, select the Allow check box next to the Replicating Directory Changes (Replicate Directory Changes on Windows Server 2003) permission, and then click OK.

 

Firewall Requirements for UPS

The server running the UPS Synchronization Service needs access to domain controllers over the following ports (usually an app server):

TCP/UDP 389 (LDAP service)

TCP/UDP 88 (Kerberos)

TCP/UDP 53 (DNS)

UDP 464 (Kerberos Change Password)

 

User Profile Service NetBIOSDomainNames

 

There’s another gotcha that I see in a lot of environments. Sometimes you’ll be trucking along and everything is fine. Suddenly you’ll start to notice that user profiles aren’t synchronizing. You look in miisclient.exe and discover that it’s throwing errors related to migration across domains.
If you’re in that boat… or if you have a domain that has a NetBIOS name that is completely different from the fully-qualified domain name, you must set “NetBIOSDomainNamesEnabled=1” in the User Profile Service. Here’s some code to do just that.

 

First:

 

Get-SPServiceApplication

 

Grab the GUID of your User Profile Service and copy it. Next, run this line by line:

 

$ups = get-SPServiceApplication -id <GUID of User Profile Service>
$ups.netbiosdomainnamesenabled=1
$ups.update()

 

…then run a full synchronization.

 

People Picker Firewall Requirements

 

People Picker needs the following ports opened to the domain controllers. The source of this traffic is the Web Front-Ends, so firewall traffic can be restricted to just those servers:

TCP/UDP 135, 137, 138, 139 (RPC)

TCP/UDP 389 by default, customizable (LDAP)

TCP 636 by default, customizable (LDAP SSL)

TCP 3268 (LDAP GC)

TCP 3269 (LDAP GC SSL)

TCP/UDP 53 (DNS)

TCP/UDP 88 (Kerberos)

TCP/UDP 445 (Directory Services)

TCP/UDP 749 (Kerberos-Adm)

TCP port 750 (Kerberos-IV)

 

People Picker Configuration

 

Now that you have the firewall in place, you can configure the People Picker to look at the other domains. By default, the People Picker will always look at the domain the SharePoint servers are installed into. If your SharePoint servers are in sharepoint.contoso.com, then your People Picker will work just fine for that domain. If you have Tokyo.contoso.com and another forest named adventureworks.com, then People Picker isn’t going to see them without some extra configuration.

 

Let’s pretend we have those two domains and one separate forest. Let’s also pretend we’re going to use the same account that we’re using on the User Profile Sync for accessing those directories. That account is “sharepoint\svc_ups” (svc_ups@sharepoint.contoso.com) and its password is “P@ssw0rd”.

 

Here’s how we’ll configure the People Picker.

 

  1. Run this command on all SharePoint servers in the farm to create a private encryption key. The passphrase is one of your choosing. We’ll just pretend the password is “SLothsRule”:
    1. Open a command prompt as administrator (or SharePoint Management Shell, because then you usually do not have to change directory straight to where stsadm.exe is located).
    2. Change directory to: C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\bin>
    3. Run this command:
                                                               i.      stsadm -o setapppassword -password SLothsRule
  1. Run this command on one of the SharePoint servers to configure the People Picker. This is a Web Application property, so you need to run this once for every Web Application that requires the configuration. Our Web Application here will be known as “sharepoint.contoso.com”:

 

stsadm -o setproperty -propertyname peoplepicker-searchadforests -propertyvalue “forest:adventureworks.com,SHAREPOINT\svc_ups,P@ssw0rd;domain:sharepoint.contoso.com,SHAREPOINT\svc_ups,P@ssw0rd;domain:Tokyo.contoso.com,SHAREPOINT\svc_ups,P@ssw0rd ” -url http://sharepoint.contoso.com


(Mind the wrap, folks).

 

Like I said, that is a Web Application property so you only need to run it on one server. The other servers should pick it up almost immediately and if your firewall configuration is right, you’re off to the races.

 

What if it doesn’t work? This is one of those situations where Fiddler and web browser developer tools do absolutely nothing for you. You need to learn how to use Microsoft Network Monitor or some other packet-capturing tool to look at the traffic on your servers. Look at what your server is doing and what ports it’s trying to use. In almost every situation I have seen, it’s any of the following:

 

  •          Permissions of the service account on the Active Directory
  •           Firewall ports aren’t open
  •          DNS is incorrect for the domain controllers (although if this is your problem, your issues are already way worse than what I’m addressing here).

 

Hope this helps you get your User Profile Sync and People Picker configurations in order. Enjoy!

 

Subscribe to RSS Feed

Sign Up for Newsletter