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:
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:
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).
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:
- unicodePwd (BLANK. So no hashed domain pw is returned)
- 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.