samba - Jan 2018 - Avoiding uid conflicts between rfc2307 user/groups and computers

> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens 
> Marco Gaiarin via samba
> Verzonden: maandag 15 januari 2018 13:03
> Aan: samba at lists.samba.org
> Onderwerp: Re: [Samba] Avoiding uid conflicts between rfc2307 
> user/groups and computers
> 
> Mandi! Rowland Penny via samba
>   In chel di` si favelave...
> 
> > You are clear in what you say, but I still do not think you 
> need the ID
> > numbers for computers, 'SYSTEM' does not exist on a Unix
machine.
It should ! 
See also my script : 
https://raw.githubusercontent.com/thctlo/samba4/master/samba-check-set-sysvol.sh
> 
> 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.
> 
> 
> 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. 
> 
> So, suppose i have a computer called KAIN, i spawn a cmd shell in
> SYSTEM context and then i try to write to \\my_server\share\text.txt;
> workstation at a fist glance, try to acess using KAIN$ account, and if
> fail, do a guest access.
Yes, which is totaly correct.
> 
> 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. 
> 
> 
> I hope i was clear now.
> 
> -- 
> dott. Marco Gaiarin				        GNUPG 
> Key ID: 240A3D66
>   Associazione ``La Nostra Famiglia''          
> http://www.lanostrafamiglia.it/
>   Polo FVG   -   Via della Bontà, 7 - 33078   -   San Vito al 
> Tagliamento (PN)
>   marco.gaiarin(at)lanostrafamiglia.it   t +39-0434-842711   
> f +39-0434-842797
> 
> 		Dona il 5 PER MILLE a LA NOSTRA FAMIGLIA!
>       http://www.lanostrafamiglia.it/index.php/it/sostienici/5x1000
> 	(cf 00307430132, categoria ONLUS oppure RICERCA SANITARIA)
> 
> -- 
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
> 
>

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

-- 
dott. Marco Gaiarin				        GNUPG Key ID: 240A3D66
  Associazione ``La Nostra Famiglia''         
http://www.lanostrafamiglia.it/
  Polo FVG   -   Via della Bontà, 7 - 33078   -   San Vito al Tagliamento (PN)
  marco.gaiarin(at)lanostrafamiglia.it   t +39-0434-842711   f +39-0434-842797

		Dona il 5 PER MILLE a LA NOSTRA FAMIGLIA!
      http://www.lanostrafamiglia.it/index.php/it/sostienici/5x1000
	(cf 00307430132, categoria ONLUS oppure RICERCA SANITARIA)

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