samba - Nov 2016 - Replication of permissions on AD Directory not automatic

Hi All,

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

--
This message is intended only for the addressee and may contain
confidential information. Unless you are that person, you may not
disclose its contents or use it in any way and are requested to delete
the message along with any attachments and notify us immediately.
This email is not intended to, nor should it be taken to, constitute advice.
The information provided is correct to our knowledge & belief and must not
be used as a substitute for obtaining tax, regulatory, investment, legal or
any other appropriate advice.

"Transact" is operated by Integrated Financial Arrangements Ltd.
29 Clement's Lane, London EC4N 7AE. Tel: (020) 7608 4900 Fax: (020) 7608
5300.
(Registered office: as above; Registered in England and Wales under
number: 3727592). Authorised and regulated by the Financial Conduct
Authority (entered on the Financial Services Register; no. 190856).

On 16/11/16 14:17, Alex Crow via samba wrote:
> Hi All,
>
> 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
>
Does anyone have any ideas on this?

Regards,

Alex
--
This message is intended only for the addressee and may contain
confidential information. Unless you are that person, you may not
disclose its contents or use it in any way and are requested to delete
the message along with any attachments and notify us immediately.
This email is not intended to, nor should it be taken to, constitute advice.
The information provided is correct to our knowledge & belief and must not
be used as a substitute for obtaining tax, regulatory, investment, legal or
any other appropriate advice.

"Transact" is operated by Integrated Financial Arrangements Ltd.
29 Clement's Lane, London EC4N 7AE. Tel: (020) 7608 4900 Fax: (020) 7608
5300.
(Registered office: as above; Registered in England and Wales under
number: 3727592). Authorised and regulated by the Financial Conduct
Authority (entered on the Financial Services Register; no. 190856).

On 30/11/16 12:38, Alex Crow via samba wrote:
> On 16/11/16 14:17, Alex Crow via samba wrote:
>> Hi All,
>>
>> 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.

This is a very odd problem and seems like it may be a bug.

Regards

Alex
--
This message is intended only for the addressee and may contain
confidential information. Unless you are that person, you may not
disclose its contents or use it in any way and are requested to delete
the message along with any attachments and notify us immediately.
This email is not intended to, nor should it be taken to, constitute advice.
The information provided is correct to our knowledge & belief and must not
be used as a substitute for obtaining tax, regulatory, investment, legal or
any other appropriate advice.

"Transact" is operated by Integrated Financial Arrangements Ltd.
29 Clement's Lane, London EC4N 7AE. Tel: (020) 7608 4900 Fax: (020) 7608
5300.
(Registered office: as above; Registered in England and Wales under
number: 3727592). Authorised and regulated by the Financial Conduct
Authority (entered on the Financial Services Register; no. 190856).