[Samba] Avoiding uid conflicts between rfc2307 user/groups and computers
rpenny at samba.org
Mon Jan 15 14:05:14 UTC 2018
On Mon, 15 Jan 2018 14:55:55 +0100
Marco Gaiarin via samba <samba at lists.samba.org> wrote:
> Mandi! L.P.H. van Belle via samba
> In chel di` si favelave...
> > > It is not the SYSTEM user (that is a local user to the
> > > workstation, so clearly does not exist on the domain).
> > Yes it does. Look at "Builtin\system" which is also "NT
> > Authority\System.
> Ahem, clearly every machine (workstation, server; i suppose also the
> domain) have a SYSTEM account, but they are ''different'':
> MY_SERVER\SYSTEM, MY_DOMAIN\SYSTEM and KAIN\SYSTEM are different
> account, and i think have not to be mapped each other...
> > > But still windows workstation, when accessing some shares with the
> > > SYSTEM user, try to logon with the machine account.
> > Correct, thats by design, and if you get access denied, you did hit
> > the "winbind" "user SYSTEM" bug(s). Fix, use acl_xattr:ignore
> > system acl = yes for now.
> ?! Reading the manpage:
> acl_xattr:ignore system acls = [yes|no]
> When set to yes, a best effort mapping from/to the POSIX
> ACL layer will not be done by this module. The default is no, which
> means that Samba keeps setting and evaluating both the system ACLs
> and the NT ACLs. This is better if you need your system ACLs be set
> for local or NFS file access, too. If you only access the data via
> Samba you might set this to yes to achieve better NT ACL
> seems me unrelated.
> What i'm speaking about is that, in Microsoft Server OS (and i suppose
> on Samba too ;) access done by local SYSTEM user to a share, trigger
> access via the respective machine account.
> Some docs corroborate this:
> The LocalSystem account is a predefined local account used by
> the service control manager. [...]
> It has extensive privileges on the local computer, and acts as
> the computer on the network.
> When a service runs under the LocalSystem account on a
> computer that is a domain member, the service has whatever network
> access is granted to the computer account, or to any groups of which
> the computer account is a member.
> So, on samba, it is not (only) a matter of ACL: machine account have
> to had an UID, to write (or read also...) to a share!
> Probably i'm missing somethin really ''basic'', but seems obvious to
> me... if i use rfc2307, in a domain member (if i use RID backend, or
> if i'm in a domain controller, some sort of automatic mapping is in
> place...) the only way to have non-anonymous access to shares by
> local workstation SYSTEM account is to add UID to machine account...
> > > If KAIN$ account have no UID (and 'Domain Computers' have no GID),
> > > clearly share acess fail.
> > No, the computer uses system, but if you test manualy it sets the
> > computername.
> No, sorry i've not understood what you mean...
'SYSTEM' is a windows account, there is no concept of the 'SYSTEM'
account on Unix, this includes Samba.
Please read this:
More information about the samba