joeware - never stop exploring... :)

[Updated: 2018/07/07]

There are a series of control access rights (CARs) that are specifically tied to granting permissions for returning “Replicated Changes” which are changes to the Directory Service (DS) that would be (and are if everything is working properly) replicated to other Directory Service Agents (aka DSAs / domain controllers or ADLDS instances). There isn’t a lot of documentation for these and quite a bit of confusion. I know I was confused by it for a while myself thinking this doesn’t seem right and so I looked at the Windows Source code to get the authoritative answer.

These permissions are granted to the DSAs and can also be granted to other security principals (groups/users/computers) to allow them to pull the changes via the LDAP DIRSYNC control and/or the RPC based DRSGetNCChanges. A common example of an application that has these permissions granted is FIM or MIM for syncing changes from Active Directory. An even more common example is Azure Active Directory Connector which ties your on premises Active Directory to your Azure Active Directory, note that it is simply (at the time of this writing) a specialized version of FIM/MIM. SharePoint is another app like that likes to do things with this functionality.

I am writing this post because there is regularly confusion over what the different versions of the permissions are and what has to be applied for something to work at all.

So to start, here are the specific Control Access Rights we are talking about:

[Thu 05/24/2018 22:44:20.45]
E:\>adfind -hh k16tst-dc1.k16tst.test.loc -config -f displayname=*replicating* rightsguid name displayname -nodn -jtsv2
1131f6aa-9c07-11d1-f79f-00c04fc2dcd2    DS-Replication-Get-Changes      Replicating Directory Changes
1131f6ad-9c07-11d1-f79f-00c04fc2dcd2    DS-Replication-Get-Changes-All  Replicating Directory Changes All
89e95b76-444d-4c62-991a-0facbeda640c    DS-Replication-Get-Changes-In-Filtered-Set      Replicating Directory Changes In Filtered Set

The permissions in Active Directory should all be at the ROOT of the naming context and do not have to (and shouldn’t be configured to) be inherited down to the rest of the directory. They are CAR permissions so you need the Control Access (represented as CR in SDDL strings and CTL in AdFind enhanced Security Descriptor output) permission granted and not a ReadProp/WriteProp kind of thing. The permissions in a standard configuration will look something like:

[Thu 05/24/2018 22:45:19.41]
E:\>adfind -hh k16tst-dc1.k16tst.test.loc -s base -jsdenl ;;;replicating

AdFind V01.51.00cpp Joe Richards (support@joeware.net) October 2017

Using server: K16TST-DC1.k16tst.test.loc:389
Directory: Windows Server 2016
Base DN: DC=k16tst,DC=test,DC=loc

dn:DC=k16tst,DC=test,DC=loc
[DACL] OBJ ALLOW;;[CTL];Replicating Directory Changes;;K16TST\Enterprise Read-only Domain Controllers
[DACL] OBJ ALLOW;;[CTL];Replicating Directory Changes All;;K16TST\Domain Controllers
[DACL] OBJ ALLOW;;[CTL];Replicating Directory Changes In Filtered Set;;BUILTIN\Administrators
[DACL] OBJ ALLOW;;[CTL];Replicating Directory Changes;;BUILTIN\Administrators
[DACL] OBJ ALLOW;;[CTL];Replicating Directory Changes All;;BUILTIN\Administrators
[DACL] OBJ ALLOW;;[CTL];Replicating Directory Changes In Filtered Set;;NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS
[DACL] OBJ ALLOW;;[CTL];Replicating Directory Changes;;NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS

1 Objects returned

So what do they do? We will start with the most powerful and work our way back…

“Replicating Directory Changes All”  – This permission allows you to replicate ANYTHING. Secrets (like password hashes), Filtered Attributes (RODC FAS), and any other attribute/object you want to check out. Note that from what I have so far been able to ascertain, you cannot get the secrets via the LDAP interface; it requires using the RPC interface. I could be wrong here, if you know for sure, please let me know.

“Replicating Directory Changes In Filtered Set” – This permission allows you to replicate things in the RODC FAS but NOT secrets like password hashes etc.

“Replicating Directory Changes” – This is the lowest level permission HOWEVER you need this to use the RPC and LDAP DIRSYNC replicating changes mechanisms period. I.E. if you don’t have this you don’t have anything[1].

You might think I’m crazy… err no… You might think (and it makes it nice and clean for delegation models) that you could just set “Replicating Directory Changes All” and be done with it but no, the way the code is written, you must also have the base level “Replicating Directory Changes” as well. Basically the functional flow is something like:

1. Do you have “Replicating Directory Changes” permissions on the NC Head object you are using these special mechanisms with?
    A. No – Get out, here is your ERROR_DS_DRA_ACCESS_DENIED (error 8453) for your troubles.
2. Are you asking for any RODC FAS attributes?
    A. Yes.
       I. Do you have “Replicating Directory Changes In Filtered Set”?
          a. No.
             i. Do you have “Replicating Directory Changes All”?
                1. No – Get out, here is your ERROR_DS_DRA_ACCESS_DENIED (error 8453) for your troubles.
3. Are you asking for Secrets (like password hash) and do you have “Replicating Directory Changes All”?
    A. No – Get out, here is your ERROR_DS_DRA_ACCESS_DENIED (error 8453) for your troubles.
4. [This bit is a guess based on testing so far] Are you using LDAP DIRSYNC and asking for Secrets
    A. Yes. You get your output but secrets (like password) will come through blank.
5. Yay, you have access, here is the output for your request.   

Again if I had written this I very likely (depends on the actual requirements documentation) would have checked for “Replicating Directory Changes All” first and then if that was there just return TRUE for the function. Next check for “Replicating Directory Changes in Filtered Set” and if they weren’t asking for Secrets return TRUE for the function. And finally if those failed check the base level “Replicating Directory Changes” and if they weren’t asking for FAS/Secret stuff return TRUE for the function. Written my way the delegation is simpler. You need the one Grant ACE to do what you need to do, not two. 

    joe

[1] There is an exception for DIRSYNC called “Per Object” mode to access DIRSYNC without needing the Replicating* permissions. There is little to no documentation that I have found regarding this functionality. Perhaps at some point I will tackle it. If you are aware of any good documentation, let me know and I will check it out and likely share it.