On 20/02/15 21:27, Davor Vusir wrote:> > Rowland Penny skrev den 2015-02-19 18:15: >> OK, there is a discussion over on samba-technical about nss_winbind >> and the question about Administrator being mapped to 0 was raised. >> Now I have always thought that it should, but in fairness, I decided >> to see what happens when it isn't, so I removed Administrator from >> idmap.ldb and restarted samba. Before restarting samba, I checked a >> few things, on the DC, getfacl returned this for /var/lib/samba/sysvol/ >> > > I've followed the thread with serious interest and I have until, some > time ago, thought that the this idmapping was a Sambas way of making > Linux and Samba (as an AD DC) become a domain controller "the > Microsoft/Windows way". With this I mean, when you promote a Windows > server to a domain controller, the server seize to exist and becomes > the Windows domain. Windows OS becomes a vessel for the the domain in > some sense. > > The more I have been thinking about this I believe it is the wrong > way. I like it, but it is wrong. Perhaps not do-able. > On Ubuntu DOMAIN\Administrator is mapped to root and DOMAIN\Domain > users is mapped to users (100). But no other domain group or user is > mapped to a corresponding group or user. Why? Because there are no > such users or groups in Linux. I hope I'm wrong. The xidNumbers you > list below is, to me, a clever way to get the AD DC to function but > belongs to the AD DC and can not reach out of the it. Winbind on the > AD DC in the 4.0 and 4.1 series can't read neither uid- and gidNumbers > nor xidNumbers and winbind on the file-/printserver can't read > xidNumbers. There is a mismatch and that's probably the main reason > for the advice not to use the AD DC as a combined AD DC and > file-/printserver. xidNumbers are local to the AD DC. > > Perhaps Samba, both as a AD DC and file-/printserver, should be looked > upon as a virtual guest where Linux OS is the virtual host. Where > Samba utilizes all the techniques that Linux offers. > > >> getfacl: Removing leading '/' from absolute path names >> # file: var/lib/samba/sysvol/ >> # owner: root >> # group: 3000000 >> user::rwx >> user:root:rwx >> user:3000000:rwx >> user:3000001:r-x >> user:3000002:rwx >> user:3000003:r-x >> group::rwx >> group:3000000:rwx >> group:3000001:r-x >> group:3000002:rwx >> group:3000003:r-x >> mask::rwx >> other::--- >> default:user::rwx >> default:user:root:rwx >> default:user:3000000:rwx >> default:user:3000001:r-x >> default:user:3000002:rwx >> default:user:3000003:r-x >> default:group::--- >> default:group:3000000:rwx >> default:group:3000001:r-x >> default:group:3000002:rwx >> default:group:3000003:r-x >> default:mask::rwx >> default:other::--- >> >> And the settings as seen from a windows client: >> >> Share permissions: Everyone >> >> Security: >> root >> Authenticated Users >> Server Operators (EXAMPLE\Server Operators) >> SYSTEM >> >> After samba restarted, I went to sysvol permissions on a windows >> client as Administrator, but couldn't change anything, as the 'Add' >> button was greyed out, going to the 'share permissions' tab and >> adding Administrator with full permissions cured this. >> >> Once this was done, getfacl now returns: >> >> getfacl: Removing leading '/' from absolute path names >> # file: var/lib/samba/sysvol/ >> # owner: EXAMPLE\134Administrator >> # group: 3000000 >> user::rwx >> user:3000000:rwx S-1-5-32-544 Administrators group >> user:3000001:r-x S-1-5-32-549 Server Operators builtin group >> user:3000002:rwx S-1-5-18 Local System account >> user:3000003:r-x S-1-5-11 Authenticated Users group >> user:EXAMPLE\134Administrator:rwx >> group::rwx >> group:3000000:rwx >> group:3000001:r-x >> group:3000002:rwx >> group:3000003:r-x >> mask::rwx >> other::--- >> default:user::rwx >> default:user:3000000:rwx >> default:user:3000001:r-x >> default:user:3000002:rwx >> default:user:3000003:r-x >> default:user:EXAMPLE\134Administrator:rwx >> default:group::--- >> default:group:3000000:rwx >> default:group:3000001:r-x >> default:group:3000002:rwx >> default:group:3000003:r-x >> default:mask::rwx >> default:other::--- >> >> 'root' had been replaced with 'EXAMPLE\134Administrator' >> >> Now this lead me to start thinking, why is a user also a group and >> vice-versa ? >> >> Checking idmap.ldb, I found that the 4 user/groups?? were all >> described as 'ID_TYPE_BOTH', so I altered them to be what they >> actually are i.e. a UID or GID >> >> reset sysvol 'samba-tool ntacl sysvolreset' and getfacl now returns: >> >> getfacl: Removing leading '/' from absolute path names >> # file: var/lib/samba/sysvol/ >> # owner: EXAMPLE\134Administrator >> # group: 3000000 >> user::rwx >> user:3000002:rwx >> user:EXAMPLE\134Administrator:rwx >> group::rwx >> group:3000000:rwx >> group:3000001:r-x >> group:3000003:r-x >> mask::rwx >> other::--- >> default:user::rwx >> default:user:3000002:rwx >> default:user:EXAMPLE\134Administrator:rwx >> default:group::--- >> default:group:3000000:rwx >> default:group:3000001:r-x >> default:group:3000003:r-x >> default:mask::rwx >> default:other::--- >> >> Which to me is more like what windows expects it to be. >> >> What the numbers mean: >> 3000002 = S-1-5-18 Local System account >> 3000000 = S-1-5-32-544 Administrators group >> 3000001 = S-1-5-32-549 Server Operators builtin group >> 3000003 = S-1-5-11 Authenticated Users group >> >> This all leads me to my questions, why, when it comes to idmap.ldb, >> can a user also be a group and a group can also be a user and why was >> it setup like this in the first place ? , there must be a reason for it. >> > > I've seen similar behaviour in Big Iron (enterprise) storage. I think > this is a bug. > > /Davor > >> Rowland >I am now beginning to think along the same lines, to me a user is a single entity and a group is a collection of entities, so how can a group also be a user?? and how can a user also be a group?? Would one of the devs care to comment on why this was done? Andrew Bartlett for instance. The use of 'ID_TYPE_BOTH' cannot be right, can it? Take the example of a *USER* I created on my test DC: If I run 'getent passwd nfs-user' I get this: EXAMPLE\nfs-user:*:3000040:10000::/home/EXAMPLE/nfs-user:/bin/bash And if I look it the record for '3000040' in idmap.ldb, I find this: dn: CN=S-1-5-21-2025076216-3455336656-3842161122-1117 cn: S-1-5-21-2025076216-3455336656-3842161122-1117 objectClass: sidMap objectSid: S-1-5-21-2025076216-3455336656-3842161122-1117 type: ID_TYPE_BOTH xidNumber: 3000040 distinguishedName: CN=S-1-5-21-2025076216-3455336656-3842161122-1117 If I now look at the record in AD for 'nfs-user', I find these objectclasses: objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user I know the user is a user, AD knows that the user is a user but samba seems to think that it is a user and a group *WHY?* Rowland
Rowland Penny skrev den 2015-02-21 10:35:> On 20/02/15 21:27, Davor Vusir wrote: >> >> Rowland Penny skrev den 2015-02-19 18:15: >>> OK, there is a discussion over on samba-technical about nss_winbind >>> and the question about Administrator being mapped to 0 was raised. >>> Now I have always thought that it should, but in fairness, I decided >>> to see what happens when it isn't, so I removed Administrator from >>> idmap.ldb and restarted samba. Before restarting samba, I checked a >>> few things, on the DC, getfacl returned this for /var/lib/samba/sysvol/ >>> >> >> I've followed the thread with serious interest and I have until, some >> time ago, thought that the this idmapping was a Sambas way of making >> Linux and Samba (as an AD DC) become a domain controller "the >> Microsoft/Windows way". With this I mean, when you promote a Windows >> server to a domain controller, the server seize to exist and becomes >> the Windows domain. Windows OS becomes a vessel for the the domain in >> some sense. >> >> The more I have been thinking about this I believe it is the wrong >> way. I like it, but it is wrong. Perhaps not do-able. >> On Ubuntu DOMAIN\Administrator is mapped to root and DOMAIN\Domain >> users is mapped to users (100). But no other domain group or user is >> mapped to a corresponding group or user. Why? Because there are no >> such users or groups in Linux. I hope I'm wrong. The xidNumbers you >> list below is, to me, a clever way to get the AD DC to function but >> belongs to the AD DC and can not reach out of the it. Winbind on the >> AD DC in the 4.0 and 4.1 series can't read neither uid- and >> gidNumbers nor xidNumbers and winbind on the file-/printserver can't >> read xidNumbers. There is a mismatch and that's probably the main >> reason for the advice not to use the AD DC as a combined AD DC and >> file-/printserver. xidNumbers are local to the AD DC. >> >> Perhaps Samba, both as a AD DC and file-/printserver, should be >> looked upon as a virtual guest where Linux OS is the virtual host. >> Where Samba utilizes all the techniques that Linux offers. >> >> >>> getfacl: Removing leading '/' from absolute path names >>> # file: var/lib/samba/sysvol/ >>> # owner: root >>> # group: 3000000 >>> user::rwx >>> user:root:rwx >>> user:3000000:rwx >>> user:3000001:r-x >>> user:3000002:rwx >>> user:3000003:r-x >>> group::rwx >>> group:3000000:rwx >>> group:3000001:r-x >>> group:3000002:rwx >>> group:3000003:r-x >>> mask::rwx >>> other::--- >>> default:user::rwx >>> default:user:root:rwx >>> default:user:3000000:rwx >>> default:user:3000001:r-x >>> default:user:3000002:rwx >>> default:user:3000003:r-x >>> default:group::--- >>> default:group:3000000:rwx >>> default:group:3000001:r-x >>> default:group:3000002:rwx >>> default:group:3000003:r-x >>> default:mask::rwx >>> default:other::--- >>> >>> And the settings as seen from a windows client: >>> >>> Share permissions: Everyone >>> >>> Security: >>> root >>> Authenticated Users >>> Server Operators (EXAMPLE\Server Operators) >>> SYSTEM >>> >>> After samba restarted, I went to sysvol permissions on a windows >>> client as Administrator, but couldn't change anything, as the 'Add' >>> button was greyed out, going to the 'share permissions' tab and >>> adding Administrator with full permissions cured this. >>> >>> Once this was done, getfacl now returns: >>> >>> getfacl: Removing leading '/' from absolute path names >>> # file: var/lib/samba/sysvol/ >>> # owner: EXAMPLE\134Administrator >>> # group: 3000000 >>> user::rwx >>> user:3000000:rwx S-1-5-32-544 Administrators group >>> user:3000001:r-x S-1-5-32-549 Server Operators builtin group >>> user:3000002:rwx S-1-5-18 Local System account >>> user:3000003:r-x S-1-5-11 Authenticated Users group >>> user:EXAMPLE\134Administrator:rwx >>> group::rwx >>> group:3000000:rwx >>> group:3000001:r-x >>> group:3000002:rwx >>> group:3000003:r-x >>> mask::rwx >>> other::--- >>> default:user::rwx >>> default:user:3000000:rwx >>> default:user:3000001:r-x >>> default:user:3000002:rwx >>> default:user:3000003:r-x >>> default:user:EXAMPLE\134Administrator:rwx >>> default:group::--- >>> default:group:3000000:rwx >>> default:group:3000001:r-x >>> default:group:3000002:rwx >>> default:group:3000003:r-x >>> default:mask::rwx >>> default:other::--- >>> >>> 'root' had been replaced with 'EXAMPLE\134Administrator' >>> >>> Now this lead me to start thinking, why is a user also a group and >>> vice-versa ? >>> >>> Checking idmap.ldb, I found that the 4 user/groups?? were all >>> described as 'ID_TYPE_BOTH', so I altered them to be what they >>> actually are i.e. a UID or GID >>> >>> reset sysvol 'samba-tool ntacl sysvolreset' and getfacl now returns: >>> >>> getfacl: Removing leading '/' from absolute path names >>> # file: var/lib/samba/sysvol/ >>> # owner: EXAMPLE\134Administrator >>> # group: 3000000 >>> user::rwx >>> user:3000002:rwx >>> user:EXAMPLE\134Administrator:rwx >>> group::rwx >>> group:3000000:rwx >>> group:3000001:r-x >>> group:3000003:r-x >>> mask::rwx >>> other::--- >>> default:user::rwx >>> default:user:3000002:rwx >>> default:user:EXAMPLE\134Administrator:rwx >>> default:group::--- >>> default:group:3000000:rwx >>> default:group:3000001:r-x >>> default:group:3000003:r-x >>> default:mask::rwx >>> default:other::--- >>> >>> Which to me is more like what windows expects it to be. >>> >>> What the numbers mean: >>> 3000002 = S-1-5-18 Local System account >>> 3000000 = S-1-5-32-544 Administrators group >>> 3000001 = S-1-5-32-549 Server Operators builtin group >>> 3000003 = S-1-5-11 Authenticated Users group >>> >>> This all leads me to my questions, why, when it comes to idmap.ldb, >>> can a user also be a group and a group can also be a user and why >>> was it setup like this in the first place ? , there must be a reason >>> for it. >>> >> >> I've seen similar behaviour in Big Iron (enterprise) storage. I think >> this is a bug. >> >> /Davor >> >>> Rowland >> > > I am now beginning to think along the same lines, to me a user is a > single entity and a group is a collection of entities, so how can a > group also be a user?? and how can a user also be a group?? > > Would one of the devs care to comment on why this was done? Andrew > Bartlett for instance. > > The use of 'ID_TYPE_BOTH' cannot be right, can it? > > Take the example of a *USER* I created on my test DC: > > If I run 'getent passwd nfs-user' I get this: > > EXAMPLE\nfs-user:*:3000040:10000::/home/EXAMPLE/nfs-user:/bin/bash > > And if I look it the record for '3000040' in idmap.ldb, I find this: > > dn: CN=S-1-5-21-2025076216-3455336656-3842161122-1117 > cn: S-1-5-21-2025076216-3455336656-3842161122-1117 > objectClass: sidMap > objectSid: S-1-5-21-2025076216-3455336656-3842161122-1117 > type: ID_TYPE_BOTH > xidNumber: 3000040 > distinguishedName: CN=S-1-5-21-2025076216-3455336656-3842161122-1117 > > If I now look at the record in AD for 'nfs-user', I find these > objectclasses: > > objectClass: top > objectClass: person > objectClass: organizationalPerson > objectClass: user > > I know the user is a user, AD knows that the user is a user but samba > seems to think that it is a user and a group *WHY?* > > Rowland > >Found this: http://samba.2283325.n4.nabble.com/Why-are-we-allocating-ID-TYPE-BOTH-on-a-user-or-machine-SID-type-td4655183.html /Davor
On 21/02/15 13:15, Davor Vusir wrote:> > Rowland Penny skrev den 2015-02-21 10:35: >> On 20/02/15 21:27, Davor Vusir wrote: >>> >>> Rowland Penny skrev den 2015-02-19 18:15: >>>> OK, there is a discussion over on samba-technical about nss_winbind >>>> and the question about Administrator being mapped to 0 was raised. >>>> Now I have always thought that it should, but in fairness, I >>>> decided to see what happens when it isn't, so I removed >>>> Administrator from idmap.ldb and restarted samba. Before restarting >>>> samba, I checked a few things, on the DC, getfacl returned this for >>>> /var/lib/samba/sysvol/ >>>> >>> >>> I've followed the thread with serious interest and I have until, >>> some time ago, thought that the this idmapping was a Sambas way of >>> making Linux and Samba (as an AD DC) become a domain controller "the >>> Microsoft/Windows way". With this I mean, when you promote a Windows >>> server to a domain controller, the server seize to exist and becomes >>> the Windows domain. Windows OS becomes a vessel for the the domain >>> in some sense. >>> >>> The more I have been thinking about this I believe it is the wrong >>> way. I like it, but it is wrong. Perhaps not do-able. >>> On Ubuntu DOMAIN\Administrator is mapped to root and DOMAIN\Domain >>> users is mapped to users (100). But no other domain group or user is >>> mapped to a corresponding group or user. Why? Because there are no >>> such users or groups in Linux. I hope I'm wrong. The xidNumbers you >>> list below is, to me, a clever way to get the AD DC to function but >>> belongs to the AD DC and can not reach out of the it. Winbind on the >>> AD DC in the 4.0 and 4.1 series can't read neither uid- and >>> gidNumbers nor xidNumbers and winbind on the file-/printserver can't >>> read xidNumbers. There is a mismatch and that's probably the main >>> reason for the advice not to use the AD DC as a combined AD DC and >>> file-/printserver. xidNumbers are local to the AD DC. >>> >>> Perhaps Samba, both as a AD DC and file-/printserver, should be >>> looked upon as a virtual guest where Linux OS is the virtual host. >>> Where Samba utilizes all the techniques that Linux offers. >>> >>> >>>> getfacl: Removing leading '/' from absolute path names >>>> # file: var/lib/samba/sysvol/ >>>> # owner: root >>>> # group: 3000000 >>>> user::rwx >>>> user:root:rwx >>>> user:3000000:rwx >>>> user:3000001:r-x >>>> user:3000002:rwx >>>> user:3000003:r-x >>>> group::rwx >>>> group:3000000:rwx >>>> group:3000001:r-x >>>> group:3000002:rwx >>>> group:3000003:r-x >>>> mask::rwx >>>> other::--- >>>> default:user::rwx >>>> default:user:root:rwx >>>> default:user:3000000:rwx >>>> default:user:3000001:r-x >>>> default:user:3000002:rwx >>>> default:user:3000003:r-x >>>> default:group::--- >>>> default:group:3000000:rwx >>>> default:group:3000001:r-x >>>> default:group:3000002:rwx >>>> default:group:3000003:r-x >>>> default:mask::rwx >>>> default:other::--- >>>> >>>> And the settings as seen from a windows client: >>>> >>>> Share permissions: Everyone >>>> >>>> Security: >>>> root >>>> Authenticated Users >>>> Server Operators (EXAMPLE\Server Operators) >>>> SYSTEM >>>> >>>> After samba restarted, I went to sysvol permissions on a windows >>>> client as Administrator, but couldn't change anything, as the 'Add' >>>> button was greyed out, going to the 'share permissions' tab and >>>> adding Administrator with full permissions cured this. >>>> >>>> Once this was done, getfacl now returns: >>>> >>>> getfacl: Removing leading '/' from absolute path names >>>> # file: var/lib/samba/sysvol/ >>>> # owner: EXAMPLE\134Administrator >>>> # group: 3000000 >>>> user::rwx >>>> user:3000000:rwx S-1-5-32-544 Administrators group >>>> user:3000001:r-x S-1-5-32-549 Server Operators builtin group >>>> user:3000002:rwx S-1-5-18 Local System account >>>> user:3000003:r-x S-1-5-11 Authenticated Users group >>>> user:EXAMPLE\134Administrator:rwx >>>> group::rwx >>>> group:3000000:rwx >>>> group:3000001:r-x >>>> group:3000002:rwx >>>> group:3000003:r-x >>>> mask::rwx >>>> other::--- >>>> default:user::rwx >>>> default:user:3000000:rwx >>>> default:user:3000001:r-x >>>> default:user:3000002:rwx >>>> default:user:3000003:r-x >>>> default:user:EXAMPLE\134Administrator:rwx >>>> default:group::--- >>>> default:group:3000000:rwx >>>> default:group:3000001:r-x >>>> default:group:3000002:rwx >>>> default:group:3000003:r-x >>>> default:mask::rwx >>>> default:other::--- >>>> >>>> 'root' had been replaced with 'EXAMPLE\134Administrator' >>>> >>>> Now this lead me to start thinking, why is a user also a group and >>>> vice-versa ? >>>> >>>> Checking idmap.ldb, I found that the 4 user/groups?? were all >>>> described as 'ID_TYPE_BOTH', so I altered them to be what they >>>> actually are i.e. a UID or GID >>>> >>>> reset sysvol 'samba-tool ntacl sysvolreset' and getfacl now returns: >>>> >>>> getfacl: Removing leading '/' from absolute path names >>>> # file: var/lib/samba/sysvol/ >>>> # owner: EXAMPLE\134Administrator >>>> # group: 3000000 >>>> user::rwx >>>> user:3000002:rwx >>>> user:EXAMPLE\134Administrator:rwx >>>> group::rwx >>>> group:3000000:rwx >>>> group:3000001:r-x >>>> group:3000003:r-x >>>> mask::rwx >>>> other::--- >>>> default:user::rwx >>>> default:user:3000002:rwx >>>> default:user:EXAMPLE\134Administrator:rwx >>>> default:group::--- >>>> default:group:3000000:rwx >>>> default:group:3000001:r-x >>>> default:group:3000003:r-x >>>> default:mask::rwx >>>> default:other::--- >>>> >>>> Which to me is more like what windows expects it to be. >>>> >>>> What the numbers mean: >>>> 3000002 = S-1-5-18 Local System account >>>> 3000000 = S-1-5-32-544 Administrators group >>>> 3000001 = S-1-5-32-549 Server Operators builtin group >>>> 3000003 = S-1-5-11 Authenticated Users group >>>> >>>> This all leads me to my questions, why, when it comes to idmap.ldb, >>>> can a user also be a group and a group can also be a user and why >>>> was it setup like this in the first place ? , there must be a >>>> reason for it. >>>> >>> >>> I've seen similar behaviour in Big Iron (enterprise) storage. I >>> think this is a bug. >>> >>> /Davor >>> >>>> Rowland >>> >> >> I am now beginning to think along the same lines, to me a user is a >> single entity and a group is a collection of entities, so how can a >> group also be a user?? and how can a user also be a group?? >> >> Would one of the devs care to comment on why this was done? Andrew >> Bartlett for instance. >> >> The use of 'ID_TYPE_BOTH' cannot be right, can it? >> >> Take the example of a *USER* I created on my test DC: >> >> If I run 'getent passwd nfs-user' I get this: >> >> EXAMPLE\nfs-user:*:3000040:10000::/home/EXAMPLE/nfs-user:/bin/bash >> >> And if I look it the record for '3000040' in idmap.ldb, I find this: >> >> dn: CN=S-1-5-21-2025076216-3455336656-3842161122-1117 >> cn: S-1-5-21-2025076216-3455336656-3842161122-1117 >> objectClass: sidMap >> objectSid: S-1-5-21-2025076216-3455336656-3842161122-1117 >> type: ID_TYPE_BOTH >> xidNumber: 3000040 >> distinguishedName: CN=S-1-5-21-2025076216-3455336656-3842161122-1117 >> >> If I now look at the record in AD for 'nfs-user', I find these >> objectclasses: >> >> objectClass: top >> objectClass: person >> objectClass: organizationalPerson >> objectClass: user >> >> I know the user is a user, AD knows that the user is a user but samba >> seems to think that it is a user and a group *WHY?* >> >> Rowland >> >> > Found this: > http://samba.2283325.n4.nabble.com/Why-are-we-allocating-ID-TYPE-BOTH-on-a-user-or-machine-SID-type-td4655183.html > > /DavorInteresting, even Jeremy Allinson wondered why a user could also be a group, the thread never actually said what files the group actually owned. Personally I have never known of a group owning files, they allow access to files, but actually owning files?? I am still wondering how a user can be a group, as far as I understand, a group is a group whether it is a linux group or a windows group, the same goes for users. I have found a small problem, which I believe is a bug. I found it after I ran 'samba-tool ntacl sysvolcheck' and got this: samba-tool ntacl sysvolcheck ERROR(<class 'samba.provision.ProvisioningError'>): uncaught exception - ProvisioningError: DB ACL on GPO directory /var/lib/samba/sysvol/example.com/Policies/{6AC1786C-016F-11D2-945F-00C04FB984F9} O:LAG:DAD:P(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED) does not match expected value O:DAG:DAD:P(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED) from GPO object File "/usr/lib/python2.7/dist-packages/samba/netcmd/__init__.py", line 175, in _run return self.run(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/samba/netcmd/ntacl.py", line 249, in run lp) File "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py", line 1726, in checksysvolacl direct_db_access) File "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py", line 1677, in check_gpos_acl domainsid, direct_db_access) The difference is here: 'O:LAG:DAD:P(A' , this is expected to be 'O:DAG:DAD:P(A'. If I run 'getent passwd Administrator' on the DC, I get this: EXAMPLE\Administrator:*:3000078:10000::/home/EXAMPLE/Administrator:/bin/bash 'getent passwd EXAMPLE\Administrator' returns nothing Both getent variants return nothing when run on a member server. The 'samba-tool ntacl sysvolcheck' error is telling me that the owner is 'local Administrator' and it is expected to be the 'domain Administrator' (or is that Domain Administrators, a group ?) I am now beginning to think that Administrator shouldn't have either an 'xidNumber' or a 'uidNumber', I think that by giving Administrator either, you are turning it into a local Unix user. I would point out that whilst 'samba-tool ntacl sysvolcheck' errors out, 'samba-tool ntacl sysvolreset' seems to work without error.