Majorbacon's guide to Correctly Granting Active Directory permissions for SharePoint Server 2013 One Way or Two Way profile synchronization

SharePoint user profiles are an important part of getting the most out of SharePoint social components and Managed Metadata Service. But to get it working correctly you'll need to correctly delegate permissions to the User Profile synchronization account so that it can safely penetrate Active Directory. There are several components depending on the nature of your synchronization model and your domain environment.

There are two methods to accomplish this, depending on a Production or Development environment:

Method 1: Production

Grant the granular, least privilege style permissions needed for the User Profile synchronization account to do its job of moving user attribute changes to and from Active Directory. There are four questions you have to ask yourself to know which steps you need to take?

Do I want to pull down changes from AD?
Then do Step 1 - Grant Replicate Directory Changes on the configuration Partition

Do I want to push up changes to AD from SharePoint?
Then do Step 2 – Grant Create Child Objects and Write Permissions on OUs
 
Does my NETBIOS domain name not match my DNS domain name?
Then do Step 3 – Grant Replicate Directory Changes on the configuration Partition

Do I have any 2003 Domain Controllers in AD?
Then do Step 4 – Add membership to the Pre-2000 Compatible Access group

Step 1: To grant "Replicate Directory Changes" permission on the domain

1. Launch Active Directory Users and Computers (ADUC) against a DC
2. Right-click the domain itself, and choose "Delegate Control"
3. Add: your User Profile synchronization account
4. Choose: "Create a custom task to delegate"
5. Choose: "This folder, existing objects in this folder, and creation of new objects in this folder"

Step 2: To grant Create Child Objects and Write permission on OUs

1. On the domain controller launch adsiedit.msc from Start
2. If the Default naming context node is not already present, do the following:
1. Select the root ADSI Edit node and from Action menu click “Connect to”
2. Under “Select a well know Naming Context” choose “Default naming context” and click OK.
3. Expand the domain and child nodes until reaching the OU to which you want to grant sync upload access, then right-click and select Properties.
4. Select the Security tab and click Advanced.
5. In Advanced Security select the User Profile synchronization account (which should be present from completing step 1). Ensure that its value in the Inherited From column is <not inherited> and then click Edit.
6. Under “Apply to” select “This object and all descendant objects” and then allow ”Write all properties” and “Create all child objects” permissions
7. Click OK and close dialog boxes
8. Repeat this process for all OUs where accounts will be modified by the User Synchronization account of SharePoint

Step 3: Grant "Replicate Directory Changes" permission on the configuration partition of AD

1. As an Enterprise Administrator open adsiedit.msc use the Action Menu to "Connect to" the "Configuration" naming context
2. Expand and right-click the CN=Configuration node and choose Properties
3. Select the Security tab.
4. Add the User Profile synchronization account and grant 
5. In the Group or user names section, select the synchronization account and allow "Replicating Directory Changes", click OK and close

Step 4: Add Sync Account to the Pre-Windows 2000 Compatible Access Group

1. In Active Directory Users and Computers expand the domain, and select “Builtin”.
2. Right-click the Pre-Windows 2000 Compatible Access group, and choose Properties.
3. Select the Members tab, and click Add
4. Add the User Profile Synchronization Account, click OK and close
   
    

Method 2: Development-Only

Quick and dirty, but does NOT conform to best practices of least privilege assignment: Just add the service user account of the User Profile synchronization account to the Enterprise Administrators group! This group has full control to the entirety of Active Directory, so this method works, but of course means that your service account, if compromised, could lay waste to your entire AD infrastructure. Only do this in isolated testing environments. (Oh, plus you'll still need to manage that Pre-Windows 2000 Compatible Access Group if you've got some legacy Windows 2003 domain controllers... but please tell me you don't!)