[Samba] Avoiding uid conflicts between rfc2307 user/groups and computers

[Rowland Penny]

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
> compatibility.
> 
> 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:
> 
> 	https://msdn.microsoft.com/en-us/library/ms684190(VS.85).aspx
> 	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.
> 
> 	https://msdn.microsoft.com/en-us/library/ms677973(VS.85).aspx
> 	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:

https://wiki.samba.org/index.php/The_SYSTEM_Account

Rowland