When you’re provisioning the User Profile Service (UPS), you can synchronize user profile information using the User Profile Synchronization Service. This TechNet article describes the steps required for configuring profile synchronization in SharePoint Server 2010.
Synchronization between AD and SharePoint should be done using a domain account, called the synchronization account, i.e. DOMAIN\SP_UserSync.
This synchronization account requires Replicate Directory Change permissions on the domain, in order to interrogate AD about “what has changed since X”, of the partitions being synchronized.
Myths about Replicate Directory Change
There are a few myths I’d like to bust about these permissions:
The Synchronization Account will be able to modify AD!
This is not the case: a holder of the Replicate Directory Change permissions cannot modify or delete data and objects in AD using these permissions.
The Synchronization Account will be able to retrieve passwords!
This is not the case: The holder can read all data for the domain, with the exception of passwords. It should be noted that most of this information is readable by everyone by default.
My sensitive information in AD, such as pay-levels, will be exposed by this!
Only if you want it to: SharePoint doesn’t map custom AD data out-of-the-box. You’ll have to explicitly map and import this data into SharePoint if you want to expose it in user profiles.
Things to keep in mind
If the NetBIOS name differs from the Fully Qualified Domain Name (FQDN), you should also give the Replicate Directory Changes permission on the cn=configuration container and you must configure the Service Application to support this. You can run the following Windows PowerShell script for this:
$upsa = Get-SPServiceApplication –Id <GUID of User Profile Service Application> $upsa.NetBIOSDomainNamesEnabled=1 $upsa.Update() # To get the GUID of the User Profile Service Application run Get-SPServiceApplication.
(To copy this code, double-click the anywhere in the code and press CTRL/Cmd+C to copy it)
If the Domain Controller is running under Windows 2003 or earlier functional level, you’ll also need to make the synchronization account a member of the Pre Windows 2000 compatible access built-in group.
The synchronization account should only be used for synchronization between AD and SharePoint. You shouldn’t be using it to run services or as an Application Pool identity!
Writing back to AD
If you also want to wrote back to AD from SharePoint, you’ll need to grant the synchronization account the Create Child Objects and Write permissions in the OU you’re syncing with.
For more information on how to set this up, refer to this excellent article on harbar.net.