[Samba] several offices: home dirs, local resources, ...

Michael Tokarev mjt at tls.msk.ru
Tue Nov 22 19:21:27 UTC 2022


22.11.2022 20:44, Rowland Penny via samba wrote:
..
>> 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

I only need read access, and "default permissions" is sufficient
for msdfs-root, - root:root, 0755 for dir and for two symlinks in
there. There's no other permissions to set there.  I don't need
the "Security" file properties tab to work in windows for this
share, either.  No locking, no GPO, no advanced permissions.. and
the most important is that it Just Works. I think I'm all set ;)

> 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.

It is *very* common for an AD to have distributed storage starting
with \\domain.tld\ - which points to the DC and only to the DC.
The actual files might be located elsewhere, the DC is here just
to find them, - actual servers with actual shares.  And the DC is
doing this job perfectly.  It doesn't matter *at all* how different
the ad is compared with NT4 "domain", - this filesystem root tree
is actually *specific* to the AD, it is not NT4-domain property.

Can we agree samba can serve an MSDFS root share on an AD? Because
it is THE way to handle files in an AD (different servers providing
file services is the stone age, replaced with domain-level storage
hierarchy in AD), because it does not need anything fancy fancy at
all, just a very basic functionality which actually works, and it
is implemented in vfs_samba4.

If not, this functionality is quite significant AD-specific, and
I think all bugs which prevents samba from doing this should be
identified and fixed..

It does not look like it is a good idea to step back from AD-specific
functionality and terms back to 10 years ago, and do things in some
very custom, specific to samba bugs, way.

..
>> 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

On the primary DC, for some strange reason, these two got different
IDs in idmap.tdb - DA was first, LA second, while on all new DCs
joining thi domain, this is in reverse, or something like that.

The fact that sysvolcheck does not report error after rsync but start
to report error after sysvolreset tells me there's a bug somewhere
in samba-tool - because sysvolcheck and sysvolreset disagrees.  I
know where this disagreement comes from in my data (the idmap thing),
but nevertheless check and reset should not disagree with each other.

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

svdcp:/# ls -lad /var/lib/samba/sysvol/tls.msk.ru/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
drwxrwx---+ 4 root TLS\domain admins 4096 фев  3  2022 /var/lib/samba/sysvol/tls.msk.ru/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/

svdcp:/# getfacl /var/lib/samba/sysvol/tls.msk.ru/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
# file: var/lib/samba/sysvol/tls.msk.ru/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
# owner: root
# group: TLS\\domain\040admins
user::rwx
user:root:rwx
user:NT\040Authority\\authenticated\040users:r-x
user:NT\040Authority\\system:rwx
user:TLS\\enterprise\040admins:rwx
user:NT\040Authority\\enterprise\040domain\040controllers:r-x
group::rwx
group:TLS\\domain\040admins:rwx
group:NT\040Authority\\authenticated\040users:r-x
group:NT\040Authority\\system:rwx
group:TLS\\enterprise\040admins:rwx
group:NT\040Authority\\enterprise\040domain\040controllers:r-x
mask::rwx
other::---
default:user::rwx
default:user:root:rwx
default:user:NT\040Authority\\authenticated\040users:r-x
default:user:NT\040Authority\\system:rwx
default:user:TLS\\enterprise\040admins:rwx
default:user:NT\040Authority\\enterprise\040domain\040controllers:r-x
default:group::---
default:group:TLS\\domain\040admins:rwx
default:group:NT\040Authority\\authenticated\040users:r-x
default:group:NT\040Authority\\system:rwx
default:group:TLS\\enterprise\040admins:rwx
default:group:NT\040Authority\\enterprise\040domain\040controllers:r-x
default:mask::rwx
default:other::---

svdcp:/# getfacl -n /var/lib/samba/sysvol/tls.msk.ru/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
# file: var/lib/samba/sysvol/tls.msk.ru/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
# owner: 0
# group: 3002
user::rwx
user:0:rwx
user:3000007:r-x
user:3000014:rwx
user:3000016:rwx
user:3000018:r-x
group::rwx
group:3002:rwx
group:3000007:r-x
group:3000014:rwx
group:3000016:rwx
group:3000018:r-x
mask::rwx
other::---
default:user::rwx
default:user:0:rwx
default:user:3000007:r-x
default:user:3000014:rwx
default:user:3000016:rwx
default:user:3000018:r-x
default:group::---
default:group:3002:rwx
default:group:3000007:r-x
default:group:3000014:rwx
default:group:3000016:rwx
default:group:3000018:r-x
default:mask::rwx
default:other::---


This is after sysvolRESET.  After rsync from primary, which makes sysvolcheck happy:

svdcp:/# ls -lad /var/lib/samba/sysvol/tls.msk.ru/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
drwxrwx---+ 4 3000057 3000057 4096 фев  3  2022 /var/lib/samba/sysvol/tls.msk.ru/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/

svdcp:/# getfacl /var/lib/samba/sysvol/tls.msk.ru/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
# file: var/lib/samba/sysvol/tls.msk.ru/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
# owner: 3000057
# group: 3000057
user::rwx
user:TLS\\guest:rwx
user:3000011:r-x
user:3000034:rwx
user:3000035:r-x
group::rwx
group:TLS\\guest:rwx
group:3000011:r-x
group:3000034:rwx
group:3000035:r-x
group:3000057:rwx
mask::rwx
other::---
default:user::rwx
default:user:TLS\\guest:rwx
default:user:3000011:r-x
default:user:3000034:rwx
default:user:3000035:r-x
default:user:3000057:rwx
default:group::---
default:group:TLS\\guest:rwx
default:group:3000011:r-x
default:group:3000034:rwx
default:group:3000035:r-x
default:group:3000057:rwx
default:mask::rwx
default:other::---

svdcp:/# getfacl -n /var/lib/samba/sysvol/tls.msk.ru/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
# file: var/lib/samba/sysvol/tls.msk.ru/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
# owner: 3000057
# group: 3000057
user::rwx
user:3000003:rwx
user:3000011:r-x
user:3000034:rwx
user:3000035:r-x
group::rwx
group:3000003:rwx
group:3000011:r-x
group:3000034:rwx
group:3000035:r-x
group:3000057:rwx
mask::rwx
other::---
default:user::rwx
default:user:3000003:rwx
default:user:3000011:r-x
default:user:3000034:rwx
default:user:3000035:r-x
default:user:3000057:rwx
default:group::---
default:group:3000003:rwx
default:group:3000011:r-x
default:group:3000034:rwx
default:group:3000035:r-x
default:group:3000057:rwx
default:mask::rwx
default:other::---

> Does Domain Admins have a gidNumber ?

It looks like it is, yes.  It was my unsuccessful attempt to make uid/gid of sysvol
to be the same across all DCs.  It didn't work.  I see some of the numbers in there
comes from gidNumber for the domain groups.

But as I mentioned already, this is not a problem and it is not important, - I'd
figure it out anyway, later, once the sites will work (and I'll have some rest).

For me, it is much more important to understand whenever we can use samba4 for MSDFS
root or not (the AD-specific, modern \\domain.tld\resource way to specify file
hierarchies).

Thanks,

/mjt



More information about the samba mailing list