On 2017-08-24 12:27, Rowland Penny via samba wrote:> On Thu, 24 Aug 2017 12:03:42 +0200 > Sven Schwedas via samba <samba at lists.samba.org> wrote: > >>> root at graz-dc-1b:~# samba --version >>> Version 4.5.8-Debian >>> root at graz-dc-1b:~# samba-tool ntacl sysvolreset && echo "no error" >>> no error >>> root at graz-dc-1b:~# samba-tool ntacl sysvolcheck >>> ERROR(<class 'samba.provision.ProvisioningError'>): uncaught >>> exception - ProvisioningError: DB ACL on GPO >>> directory /var/lib/samba/sysvol/ad.tao.at/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 >>> 176, in _run return self.run(*args, **kwargs) File >>> "/usr/lib/python2.7/dist-packages/samba/netcmd/ntacl.py", line 270, >>> in run lp) File >>> "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py", >>> line 1723, in checksysvolacl direct_db_access) File >>> "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py", >>> line 1674, in check_gpos_acl domainsid, direct_db_access) File >>> "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py", >>> line 1621, in check_dir_acl raise ProvisioningError('%s ACL on GPO >>> directory %s %s does not match expected value %s from GPO object' % >>> (acl_type(direct_db_access), path, fsacl_sddl, acl)) >> >> Where does the error come from, and why doesn't sysvolreset fix it? >> > > Mainly because (from my testing) sysvolcheck/sysvolreset is broken. I > do not write 'C' code and the problem seems to be in set_nt_acl from > source3/smbd/posix_acls.c > It doesn't set the correct ACL. > > I have opened a bug for this: > > https://bugzilla.samba.org/show_bug.cgi?id=12924Ah, crap.> Even when this gets fixed, the python code will need work, because it > doesn't do what windows does, also anybody who has set a gidNumber on > Domain Admins, will need to remove it, the group needs to own things in > sysvol and with a gidNumber it cannot.Does this apply only to sysvolreset or also when fixing ACLs from Windows?> The recommendation at the moment is to not use either sysvolreset or > sysvolcheck. Do everything from windows.I presume with this?> https://support.microsoft.com/en-us/help/2838154/-permissions-for-this-gpo-in-the-sysvol-folder-are-inconsistent-with-tOr some other way? -- Mit freundlichen Grüßen, / Best Regards, Sven Schwedas, Systemadministrator Mail/XMPP sven.schwedas at tao.at | Skype sven.schwedas TAO Digital | Lendplatz 45 | A8020 Graz https://www.tao-digital.at | Tel +43 680 301 7167
On Thu, 24 Aug 2017 12:41:36 +0200 Sven Schwedas via samba <samba at lists.samba.org> wrote:> On 2017-08-24 12:27, Rowland Penny via samba wrote: > > On Thu, 24 Aug 2017 12:03:42 +0200 > > Sven Schwedas via samba <samba at lists.samba.org> wrote: > > > >>> root at graz-dc-1b:~# samba --version > >>> Version 4.5.8-Debian > >>> root at graz-dc-1b:~# samba-tool ntacl sysvolreset && echo "no error" > >>> no error > >>> root at graz-dc-1b:~# samba-tool ntacl sysvolcheck > >>> ERROR(<class 'samba.provision.ProvisioningError'>): uncaught > >>> exception - ProvisioningError: DB ACL on GPO > >>> directory /var/lib/samba/sysvol/ad.tao.at/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 > >>> 176, in _run return self.run(*args, **kwargs) File > >>> "/usr/lib/python2.7/dist-packages/samba/netcmd/ntacl.py", line > >>> 270, in run lp) File > >>> "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py", > >>> line 1723, in checksysvolacl direct_db_access) File > >>> "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py", > >>> line 1674, in check_gpos_acl domainsid, direct_db_access) File > >>> "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py", > >>> line 1621, in check_dir_acl raise ProvisioningError('%s ACL on GPO > >>> directory %s %s does not match expected value %s from GPO object' > >>> % (acl_type(direct_db_access), path, fsacl_sddl, acl)) > >> > >> Where does the error come from, and why doesn't sysvolreset fix it? > >> > > > > Mainly because (from my testing) sysvolcheck/sysvolreset is broken. > > I do not write 'C' code and the problem seems to be in set_nt_acl > > from source3/smbd/posix_acls.c > > It doesn't set the correct ACL. > > > > I have opened a bug for this: > > > > https://bugzilla.samba.org/show_bug.cgi?id=12924 > > Ah, crap.I actually used worse words when I found out why I couldn't get my work on the python code to work. ;-)> > > Even when this gets fixed, the python code will need work, because > > it doesn't do what windows does, also anybody who has set a > > gidNumber on Domain Admins, will need to remove it, the group needs > > to own things in sysvol and with a gidNumber it cannot. > > Does this apply only to sysvolreset or also when fixing ACLs from > Windows?On a Samba AD DC, 'Domain Admins' is mapped to 'ID_TYPE_BOTH' in idmap.ldb, this makes it able to own files and dirs in sysvol. The moment you give 'Domain Admins' a gidNumber, you break this mapping and the group becomes just a group and cannot own anything on a Unix machine, so my recommendation is to not give the group a gidNumber, create another group 'Unix Admins' ? give this group a gidNumber and make this group a member of 'Domain Admins'> > > The recommendation at the moment is to not use either sysvolreset or > > sysvolcheck. Do everything from windows. > > I presume with this? > > > https://support.microsoft.com/en-us/help/2838154/-permissions-for-this-gpo-in-the-sysvol-folder-are-inconsistent-with-t > > Or some other way? >Not sure, I actually don't use GPOs ;-) Louis is your man, he is the expert here. Rowland
On 2017-08-24 13:00, Rowland Penny via samba wrote:> On Thu, 24 Aug 2017 12:41:36 +0200 > Sven Schwedas via samba <samba at lists.samba.org> wrote: > >> On 2017-08-24 12:27, Rowland Penny via samba wrote: >>> On Thu, 24 Aug 2017 12:03:42 +0200 >>> Sven Schwedas via samba <samba at lists.samba.org> wrote: >>> >>>> >>>> Where does the error come from, and why doesn't sysvolreset fix it? >>>> >>> >>> Mainly because (from my testing) sysvolcheck/sysvolreset is broken. >>> I do not write 'C' code and the problem seems to be in set_nt_acl >>> from source3/smbd/posix_acls.c >>> It doesn't set the correct ACL. >>> >>> I have opened a bug for this: >>> >>> https://bugzilla.samba.org/show_bug.cgi?id=12924 >> >> Ah, crap. > > I actually used worse words when I found out why I couldn't get my work > on the python code to work. ;-) > >> >>> Even when this gets fixed, the python code will need work, because >>> it doesn't do what windows does, also anybody who has set a >>> gidNumber on Domain Admins, will need to remove it, the group needs >>> to own things in sysvol and with a gidNumber it cannot. >> >> Does this apply only to sysvolreset or also when fixing ACLs from >> Windows? > > On a Samba AD DC, 'Domain Admins' is mapped to 'ID_TYPE_BOTH' in > idmap.ldb, this makes it able to own files and dirs in sysvol. The > moment you give 'Domain Admins' a gidNumber, you break this mapping and > the group becomes just a group and cannot own anything on a Unix > machine, so my recommendation is to not give the group a gidNumber, > create another group 'Unix Admins' ? give this group a gidNumber and > make this group a member of 'Domain Admins'Does removing the gidNumber retroactively allow it to work? (That is, once I figured out how to reset the ACLs from within Windows.)>>> The recommendation at the moment is to not use either sysvolreset or >>> sysvolcheck. Do everything from windows. >> >> I presume with this? >> >>> https://support.microsoft.com/en-us/help/2838154/-permissions-for-this-gpo-in-the-sysvol-folder-are-inconsistent-with-t >> >> Or some other way? >> > > Not sure, I actually don't use GPOs ;-) > Louis is your man, he is the expert here. > > Rowland > > >-- Mit freundlichen Grüßen, / Best Regards, Sven Schwedas, Systemadministrator Mail/XMPP sven.schwedas at tao.at | Skype sven.schwedas TAO Digital | Lendplatz 45 | A8020 Graz https://www.tao-digital.at | Tel +43 680 301 7167
On Thu, 24 Aug 2017, Rowland Penny via samba wrote:> On Thu, 24 Aug 2017 12:41:36 +0200 > Sven Schwedas via samba <samba at lists.samba.org> wrote: > >> On 2017-08-24 12:27, Rowland Penny via samba wrote: > > I actually used worse words when I found out why I couldn't get my work > on the python code to work. ;-) > >> Does this apply only to sysvolreset or also when fixing ACLs from >> Windows? > > On a Samba AD DC, 'Domain Admins' is mapped to 'ID_TYPE_BOTH' in > idmap.ldb, this makes it able to own files and dirs in sysvol. The > moment you give 'Domain Admins' a gidNumber, you break this mapping and > the group becomes just a group and cannot own anything on a Unix > machine, so my recommendation is to not give the group a gidNumber, > create another group 'Unix Admins' ? give this group a gidNumber and > make this group a member of 'Domain Admins'So I have 2 Samba AD DCs running 4.7.0rc5 and 2 member file servers running samba-4.6.2-8.el7.x86_64 on Centos 7.4. In setting up shares on the file servers I see that https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs says to grant SeDiskOperatorPrivilege to the Domain Admins group. If I follow Rowland's advice above and make a unix admins group, do I still grant SeDiskOperatorPrivilege to Domain Admins or do I grant SeDiskOperatorPrivilege to Unix Admins? I am thinking "Unix Admins" group needs SeDiskOperatorPrivilege but I want to be sure. Also When I create the shares do I set the permissions to root:Unix Admins? If I do getent group "domain admins" nothing returns. Which I believe is because Domain Admins does not have a unix GID assigned. If I do: (vfs2 pts4) # getent group "unix admins" unix admins:x:10001: (vfs2 pts4) # That works. Since unix admins is a member of domain admins is that good enough? I am trying very hard to get this right but given all of these special cases and documentation that gives different advice, it is difficult at best. I would not have any chance of getting this working without all of the help on this list. Thank You!! Regards, -- Tom me at tdiehl.org Spamtrap address me123 at tdiehl.org