Bug 12497 - Replication of ACLs down subtree on AD Directory not automatic
Replication of ACLs down subtree on AD Directory not automatic
Status: NEW
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB
4.5.2
x64 Linux
: P4 major
: ---
Assigned To: Andrew Bartlett
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-01-04 18:58 UTC by acrow
Modified: 2017-03-06 02:49 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description acrow 2017-01-04 18:58:43 UTC
The main issue is that applying a new ACL to directory objects only fully propagates down the tree on the server on which the ACL modification was performed. On other DCs replication only seems to propagate the new ACLs down one or two levers at most. This affects delegation in ADUC as well. The only solution is to run a samba-tool drs replicate --full-sync on the other DCs. I post below the posts I've sent to the ML with no response so far:

>> I've been testing Samba 4.5.1 extensively as an AD DC. We have 3 DC set up, and replication of users, groups, OUs, DNS etc has been working fine.
>>
>> However we wanted to add some custom attributes and a class to the schema (an assortment of string and numericalString) for our own purposes. This also worked fine (and the Schema replication worked), but some oddness happened when we wanted to restrict access to one of these attributes.
>>
>> The class was added to the "user" AD class as an auxiliary, and then the following procedure was used:
>>
>> https://support.microsoft.com/en-us/kb/320528
>>
>> To add anonymous access to the Public Information, Phone and Mail, and our additional attributes (excepting the restricted one). Then a deny ACL for "Everyone" and "Anonymous Logon" was added recursively for the restricted attribute at the root of the domain tree on descendent User objects.
>>
>> This seemed to work on the server that ADSI edit was connected to when tested with ldapsearch, but *not* on the other two DCs. They behaved as if no ACLs had been changed. When I connected ADSI edit to the other DCs I could see that the ACLs seemed to be present at the domain root, but were not propagating down the tree even though the inherit box was checked on subordinates.
>>
>> I had to do:
>>
>> samba-tool drs replicate s4-dc-01 s4-dc-02 DC=my,DC=ifa,DC=net --full-sync
>>
>> (where s4-dc-02 was the "working" DC) and all seemed to be fixed, both using ldapsearch and ADSI Edit.
>>
>> Is it a known issue that ACLs aren't completely replicated? Or is it that "custom" attributes cause problems with ACLs (even though they are applied as auxiliary to the "user" AD class.
>>
>> Otherwise everything is working 100% correctly (showrepl gives no errors).
>>
>>
>> Cheers,
>>
>> Alex
>>
>

Another update on this problem:

This seems only to occur if ACLs on directory objects or delegation is changed /after/ DCs have been joined to the domain.

A fresh DC will get all of the ACLs correct as it does seem to do a full sync of objects from an existing DC when joined.

However if we change, say, delegation in ADUC, we will seem to get some part of the corresponding ACLs not replicated on other existing DCs (sometimes it's all the others than the one the change hit, sometimes just one). For instance, we delegated control of user objects below a certain ou (to all descendant user objects) and this is visible from ADUC in the descendant objects on two DCs, but on a third, the ACL only shows on that ou itself - and despite it indeed saying it applies to all descendant user objects in ADUC, when we look at any entry in the tree below, it is not applied in the list of ACLs.
Comment 1 acrow 2017-02-16 18:50:06 UTC
This is still affecting us. Every time we need to enable additional access to any attribute we need to perform this workaround. 

Does anyone have any input or similar experience?
Comment 2 Andrew Bartlett 2017-03-03 20:39:58 UTC
I think the fundemental issue is that the descriptor module is above repl_meta_data in the list in samba_dsdb.  This means that the recursive SD propagation does not happen for changes that come over replication.

Because DSDB_CONTROL_SEC_DESC_PROPAGATION_OID is set by the descriptor module, the repl_meta_data module does not update the metadata for the child objects, so the changes made to nTSecurityDescriptor are not seen by other DCs until a full sync.
Comment 3 Stefan Metzmacher 2017-03-05 22:31:37 UTC
(In reply to Andrew Bartlett from comment #2)

dsdb_module_schedule_sd_propagation() uses DSDB_FLAG_TOP_MODULE, so it's likely
to be something else.
Comment 4 Andrew Bartlett 2017-03-06 02:49:16 UTC
(In reply to Stefan Metzmacher from comment #3)
OK, that makes things more difficult.

Thanks for the pointer.