What rights does "Replicating Directory Changes" actually grant in Active Directory?
Solution 1:
http://support.microsoft.com/kb/303972
Note Using either method, setting the Replicating Directory Changes permission for each domain within your forest enables the discovery of objects in the domain within the Active Directory forest. However, enabling discovery of the connected directory does not imply that other operations can be performed.
To create, modify, and delete objects within Active Directory using a non-administrative account, you may need to add additional permissions as appropriate. For example, for Microsoft Metadirectory Services (MMS) to create new user objects in an Organizational Unit (OU) or container, the account that is being used must be explicitly granted the Create All Child Objects permission, as the Replicating Directory Changes permission is not sufficient to allow the creation of objects.
In a similar fashion, the deletion of objects requires the Delete All Child Objects permission.
It is possible that there are limitations on other operations, such as attribute flow, depending on the specific security settings that are assigned to the object in question, and whether or not inheritance is a factor.
Solution 2:
The existing answer didn't satisfy my curiosity and I didn't want people getting more than they needed from my directory. So I did a little more digging.
Main Info here:
http://support.microsoft.com/kb/891995
Breakdown:
If you want to synchronize your program's database with AD (like sharepoint/FIM) you have two ways of asking AD what's changed since your last query.
You can use the "DirSync" control (LDAP protocol extension) OR you can go kinda ghetto and just use uSNChanged polling - but there are limitations there.
"A DirSync control search returns all the changes that are made to an Active Directory object regardless of the permissions that are set on the object." It will even return tombstoned objects.
So to use the DirSync LDAP control you need the "Replicating Directory Changes", or be a domain admin.
From what I was able to gather, the only thing scary is that they can pretty much read anything in the directory partition, regardless of standard permissions. They cannot change anything.
However - you may have some attributes that are senstivite in your directory.
More on the DirSync Control Extension here:
https://msdn.microsoft.com/en-us/library/ms677626(v=vs.85).aspx
True Test: Connecting to AD using the DirSync control
And here's the true way for you to find out for yourself. This guy is the man. If you want to see for yourself - adapt this powershell example, run it as the user you granted the right to, and query for a user object (or something else).
http://dloder.blogspot.com/2012/01/powershell-dirsync-sample.html
I checked with our Sharepoint account to see what I could get back. Before I granted the permission, I got an access denied exception when trying to use the DirSync control.
Once I did I got back almost everything on a user account:
Notable security related attributes that came back in a user query that I'm pretty sure you can't normally see without elevated permissions:
- userAccountControl
- userparameters
- msexchuseraccountcontrol
- pwdlastset
- unicodePwd (BLANK. So no hashed domain pw is returned)
- lockouttime
- accountexpires
- unixuserpassword (YIKES. If you are using this - it IS visible but it's hashed. Do some reading here if you are paranoid or use services for unix password sync.)
I also checked out a computer account that had a bitlocker recovery password attached to it and that attribute was not available in the returned results.
If you ever had Services for Unix in your environment and synced pw's - you could have leftover data in here. One of our users that had been around for a long time had this set on his account. It's feasible that cracking this pw could lead to a current day password by just trying variations on it.
This had been removed from our environment, so newer users didn't have any data here.