samba - Nov 2022 - several offices: home dirs, local resources, ...

22.11.2022 19:46, Kees van Vloten via samba wrote:
>> 2. why samba4 offers SYSVOL *file* share when using it as a file server
is not
>> ?a good idea, why not use reglar non-dc samba server for it?
> 
> SYSVOL is a special share which must be on the DC (and so is the netlogon
share). You should take care of replications of the files yourself, the DC
> replication does not handle. The wiki describes multiple solutions to get
it done (I am using the osync method with works well for my situation).
> Permissions on the SYSVOL share are very critical, if not exactly right
Windows will not be able to pick up GPOs properly for example.
> 
> samba-tool can reset the permissions in case they got messed up.
Sometimes I don't understand which language we're using.

I do know full well that the sysvol replication is not implemented and should
be done externally (got that yesterday when, after adding a new DC, users
complained their usual drive letters wern't mapped because I forgot to
replicate
GPO in sysvol).  I know what wiki describes, I corrected quite some data there
already and have other corrections too.  I know about permissions of SYSVOL,
and I know more: permissions of SYSVOL (actually ACLs) should match *local*
idmap.db file, which should be replicated too but it is not mentioned in
the wiki.  I know well about sysvolreset and sysvolcheck too, -- found it
the hard way, used them many times.

But how it all is related to my question?

I asked why, if a source4 fileserver is not operational, why it is used for
sysvol share instead of some other fileserver?  And if, despite all the claims
by you and Rowland in this thread (you both claimed using a fileserver in
source4 is not a good idea), it is actually is good enough to serve SYSVOL
share, why it is ALSO not good enough to serve single read-only MSDFS-root
share with 2 files within?

How all the sysvol permission and replication stuff answers to this question?

And now I really wonder: am I asking something fantastically stupid, illogical,
random, or maybe I'm phrasing my question in somehow difficult to understand
form, - why my question can't be understood, how *else* can I rephrase it?

And now, for fun side, once you mention sysvolcheck and sysvolreset stuff,
here's another twist:

svdcp:/# samba-tool ntacl sysvolcheck
svdcp:/# samba-tool ntacl sysvolreset
svdcp:/# samba-tool ntacl sysvolcheck
ERROR(<class 'samba.provision.ProvisioningError'>): uncaught
exception - ProvisioningError: DB ACL on GPO directory
/var/lib/samba/sysvol/tls.msk.ru/Policies/{31B2F340-016D-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/python3/dist-packages/samba/netcmd/__init__.py",
line 186, in _run
     return self.run(*args, **kwargs)
   File "/usr/lib/python3/dist-packages/samba/netcmd/ntacl.py", line
443, in run
     provision.checksysvolacl(samdb, netlogon, sysvol,
   File "/usr/lib/python3/dist-packages/samba/provision/__init__.py",
line 1876, in checksysvolacl
     check_gpos_acl(sysvol, dnsdomain, domainsid, domaindn, samdb, lp,
   File "/usr/lib/python3/dist-packages/samba/provision/__init__.py",
line 1826, in check_gpos_acl
     check_dir_acl(policy_path, dsacl2fsacl(acl, domainsid), lp,
   File "/usr/lib/python3/dist-packages/samba/provision/__init__.py",
line 1769, 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))

(This is a "second" DC).  So the permissions WERE okay after an rsync
from
"primary" DC.  And sysvolcheck reported no errors. So one might thing
sysvolreset will be a no-op - nope. After sysvolreset, sysvolcheck reports
errors, and no other sysvolreset fixes them. Only after another resync from
primary (which transfers ACLs too) sysvolcheck is quiet again.  This is
one more thing for me to debug, maybe it's idmap.tdb again (mentioned above
already), maybe something else, - it's not important by now.  Just another
fun data point in the new context you mentioned..

Thanks,

/mjt

On 22-11-2022 18:13, Michael Tokarev wrote:
> 22.11.2022 19:46, Kees van Vloten via samba wrote:
>
>>> 2. why samba4 offers SYSVOL *file* share when using it as a file 
>>> server is not
>>> ?a good idea, why not use reglar non-dc samba server for it?
>>
>> SYSVOL is a special share which must be on the DC (and so is the 
>> netlogon share). You should take care of replications of the files 
>> yourself, the DC replication does not handle. The wiki describes 
>> multiple solutions to get it done (I am using the osync method with 
>> works well for my situation). Permissions on the SYSVOL share are 
>> very critical, if not exactly right Windows will not be able to pick 
>> up GPOs properly for example.
>>
>> samba-tool can reset the permissions in case they got messed up.
>
> Sometimes I don't understand which language we're using.
>
> I do know full well that the sysvol replication is not implemented and 
> should
> be done externally (got that yesterday when, after adding a new DC, users
> complained their usual drive letters wern't mapped because I forgot to 
> replicate
> GPO in sysvol).? I know what wiki describes, I corrected quite some 
> data there
> already and have other corrections too.? I know about permissions of 
> SYSVOL,
> and I know more: permissions of SYSVOL (actually ACLs) should match 
> *local*
> idmap.db file, which should be replicated too but it is not mentioned in
> the wiki.? I know well about sysvolreset and sysvolcheck too, -- found it
> the hard way, used them many times.
>
> But how it all is related to my question?
>
> I asked why, if a source4 fileserver is not operational, why it is 
> used for
> sysvol share instead of some other fileserver?? And if, despite all 
> the claims
> by you and Rowland in this thread (you both claimed using a fileserver in
> source4 is not a good idea), it is actually is good enough to serve 
> SYSVOL
> share, why it is ALSO not good enough to serve single read-only 
> MSDFS-root
> share with 2 files within?
Sysvol is a special case. Windows expects it on the DC, there are no 
other options and hence source4 contains enough functionality to serve it.

As for MSDFS-root, I have never used it and can't answer any questions.
>
> How all the sysvol permission and replication stuff answers to this 
> question?
>
> And now I really wonder: am I asking something fantastically stupid, 
> illogical,
> random, or maybe I'm phrasing my question in somehow difficult to 
> understand
> form, - why my question can't be understood, how *else* can I rephrase 
> it?
>
> And now, for fun side, once you mention sysvolcheck and sysvolreset 
> stuff,
> here's another twist:
>
> svdcp:/# samba-tool ntacl sysvolcheck
> svdcp:/# samba-tool ntacl sysvolreset
> svdcp:/# samba-tool ntacl sysvolcheck
> ERROR(<class 'samba.provision.ProvisioningError'>): uncaught
exception
> - ProvisioningError: DB ACL on GPO directory 
>
/var/lib/samba/sysvol/tls.msk.ru/Policies/{31B2F340-016D-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/python3/dist-packages/samba/netcmd/__init__.py",
line
> 186, in _run
> ??? return self.run(*args, **kwargs)
> ? File "/usr/lib/python3/dist-packages/samba/netcmd/ntacl.py",
line
> 443, in run
> ??? provision.checksysvolacl(samdb, netlogon, sysvol,
> ? File
"/usr/lib/python3/dist-packages/samba/provision/__init__.py",
> line 1876, in checksysvolacl
> ??? check_gpos_acl(sysvol, dnsdomain, domainsid, domaindn, samdb, lp,
> ? File
"/usr/lib/python3/dist-packages/samba/provision/__init__.py",
> line 1826, in check_gpos_acl
> ??? check_dir_acl(policy_path, dsacl2fsacl(acl, domainsid), lp,
> ? File
"/usr/lib/python3/dist-packages/samba/provision/__init__.py",
> line 1769, 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))
>
> (This is a "second" DC).? So the permissions WERE okay after an
rsync
> from
> "primary" DC.? And sysvolcheck reported no errors. So one might
thing
> sysvolreset will be a no-op - nope. After sysvolreset, sysvolcheck 
> reports
> errors, and no other sysvolreset fixes them. Only after another resync 
> from
> primary (which transfers ACLs too) sysvolcheck is quiet again. This is
> one more thing for me to debug, maybe it's idmap.tdb again (mentioned 
> above
> already), maybe something else, - it's not important by now.? Just 
> another
> fun data point in the new context you mentioned..
Permissions are stored in xattrs, did you add the right options to rsync 
to replicate those?
>
> Thanks,
>
> /mjt

On 22/11/2022 17:13, Michael Tokarev via samba wrote:
> 22.11.2022 19:46, Kees van Vloten via samba wrote:
> 
>>> 2. why samba4 offers SYSVOL *file* share when using it as a file 
>>> server is not
>>> ?a good idea, why not use reglar non-dc samba server for it?
>>
>> SYSVOL is a special share which must be on the DC (and so is the 
>> netlogon share). You should take care of replications of the files 
>> yourself, the DC replication does not handle. The wiki describes 
>> multiple solutions to get it done (I am using the osync method with 
>> works well for my situation). Permissions on the SYSVOL share are very 
>> critical, if not exactly right Windows will not be able to pick up 
>> GPOs properly for example.
>>
>> samba-tool can reset the permissions in case they got messed up.
> 
> Sometimes I don't understand which language we're using.
English
> 
> I do know full well that the sysvol replication is not implemented and 
> should
> be done externally (got that yesterday when, after adding a new DC, users
> complained their usual drive letters wern't mapped because I forgot to 
> replicate
> GPO in sysvol).? I know what wiki describes, I corrected quite some data 
> there
> already and have other corrections too.? I know about permissions of 
> SYSVOL,
> and I know more: permissions of SYSVOL (actually ACLs) should match *local*
> idmap.db file, which should be replicated too but it is not mentioned in
> the wiki.
It is mentioned in the wiki.

 ? I know well about sysvolreset and sysvolcheck too, -- found
it
> the hard way, used them many times.
> 
> But how it all is related to my question?
> 
> I asked why, if a source4 fileserver is not operational, why it is used for
> sysvol share instead of some other fileserver?? And if, despite all the 
> claims
> by you and Rowland in this thread (you both claimed using a fileserver in
> source4 is not a good idea), it is actually is good enough to serve SYSVOL
> share, why it is ALSO not good enough to serve single read-only MSDFS-root
> share with 2 files within?
The Sysvol share was created to do one thing, hold GPO's, which until 
fairly recently, were only used by Windows, so the ACLs are crafted to 
match what Windows expects. This means that normal Unix tools cannot set 
these 'permissions', so you have to use samba-tool. The 'samba'
binary
was created around being an AD DC, so again, it doesn't like the 
standard Unix tools.
What this means is, if you create a share on a DC, it has to look like this:

[sharename]
     path = /path/to/directory/holding/share
     read only = no

you shouldn't add anything else and you MUST set the ACLs from Windows, 
you cannot use chmod, setfacl, etc

You sound like myself 10 years ago, I wanted to do things very similar 
to yourself, but once I got my head the fact that an AD domain does not 
work anything like an NT4-stye domain, it all became obvious.
> 
> How all the sysvol permission and replication stuff answers to this 
> question?
> 
> And now I really wonder: am I asking something fantastically stupid, 
> illogical,
> random, or maybe I'm phrasing my question in somehow difficult to 
> understand
> form, - why my question can't be understood, how *else* can I rephrase
it?
> 
> And now, for fun side, once you mention sysvolcheck and sysvolreset stuff,
> here's another twist:
> 
> svdcp:/# samba-tool ntacl sysvolcheck
> svdcp:/# samba-tool ntacl sysvolreset
> svdcp:/# samba-tool ntacl sysvolcheck
> ERROR(<class 'samba.provision.ProvisioningError'>): uncaught
exception -
> ProvisioningError: DB ACL on GPO directory 
>
/var/lib/samba/sysvol/tls.msk.ru/Policies/{31B2F340-016D-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
If you look very carefully, you will see that there is only one letter 
different, the start is:

O:LAG:DAD:P

against the expected:

O:DAG:DAD:P

'LA' is local administrator (or root)
'DA' is Domain Admins

What does 'ls -lad 
/var/lib/samba/sysvol/tls.msk.ru/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}'
return ?

Does Domain Admins have a gidNumber ?

Rowland