[Samba] Samba-wiki info about profiles and SYSTEM account.

[L.P.H. van Belle]

Hai Marc, 

Great to have that clear now.

Now, ... Sorry about this one but.. Ping;.... ;-) 
https://bugzilla.samba.org/show_bug.cgi?id=12257   Windows 10 unable to update group policy. 
https://bugzilla.samba.org/show_bug.cgi?id=12263   unable to edit / create GPO  

Fixed when you apply system on the sysvol folder.  ;-) 
2 bugs less ;-) 


Greetz, 

Louis

> -----Oorspronkelijk bericht-----
> Van: Marc Muehlfeld [mailto:mmuehlfeld at samba.org] 
> Verzonden: woensdag 3 mei 2017 15:44
> Aan: L.P.H. van Belle; samba
> Onderwerp: Re: [Samba] Samba-wiki info about profiles and 
> SYSTEM account.
> 
> Hi Louis,
> 
> it seems we are both right:
> 
> I talked with Volker about the necessity of SYSTEM in ACLs on a Samba
> server: From Samba side, SYSTEM is not required in ACLs. It's 
> important that the domain user or machine account, that is 
> used to authenticate to the share, is able to access the content.
> 
> SYSTEM is a local security principal on the client and not 
> sent over the network to authenticate. When a local service 
> on a domain member uses SYSTEM to access a domain network 
> share, it authenticates as computername$. To access the 
> content, it is necessary that this machine account is allowed 
> to access the content. For example, because it is listed 
> explicitely, as member of a group, or allowed by a general 
> principal, such as "Authenticated Users". If the local SYSTEM 
> account accesses the server using the computername$ account, 
> the SYSTEM account in the ACLs is not used on the server to 
> validate if computername$ is allowed to access the content - 
> computername$ must somehow have access.
> 
> On the other side, there are be some Windows services that 
> may require that some ACLs are present on the remote server. 
> For example, a service might not work if the ACLs on the 
> remote server do not contain the SYSTEM account - even if it 
> is not used on the server to access the content itself. This 
> is what you discovered.
> 
> I will update the docs accordingly.
> 
> Regards,
> Marc
> 
> 
> 
> 
> Am 03.05.2017 um 12:22 schrieb L.P.H. van Belle via samba:
> > Hai,
> > 
> > I just saw the new site for the profiles :-) didnt notice that.
> > Looks nice.
> > 
> > Now i saw the link to :
> > https://wiki.samba.org/index.php/The_SYSTEM_Account
> > This is very very disturbing....
> > 
> > Especially these lines:
> > "The SYSTEM account is never sent to a remote host to 
> authenticate and for this reason never used to access a 
> remote file system"
> > 
> > "For this reasons, you can omit the SYSTEM account in file 
> system ACLs on Samba shares."
> > Now this is not ok in my believe.
> > 
> > And the funny part, first reference link.
> > 
> https://support.microsoft.com/en-us/help/120929/how-the-system-account
> > -is-used-in-windows
> > Which states :
> > 
> > . On the other hand, the system account does show up on an 
> NTFS volume in File Manager in the Permissions portion of the 
> Security menu.
> > By default, the system account is granted full control to 
> all files on an NTFS volume.
> > And ...
> >>>>     The system account's permissions can be removed from 
> a file but it is not recommended.
> > 
> > The last line on the wiki.
> >>   For this reasons, you can omit the SYSTEM account in 
> file system ACLs on Samba shares.
> > 
> > Now when it goes wrong if you remove SYSTEM from the samba shares...
> > 
> > Example 1:
> > Try to do the following.
> > Add the Administrators security group to roaming user profiles in 
> > Computer Configuration \ Administrative Templates \ System \ User 
> > Profiles
> > 
> > This happens.
> >   When a new roaming profile directory is created, Windows 
> disables permission inheritance and grants SYSTEM and the 
> profile’s user account full control.
> > .... Grants who... Yes SYSTEM!
> > 
> > Example 2
> > If you see something like:
> > The Application Event Viewer indicates errors that the MSI 
> package installation failed with an error ‘Package source not 
> located’.
> > 
> > 1)	On the target computer, log in as an administrator.
> > 2)	Schedule an AT job for 1 minute ahead of the current 
> time to launch a command prompt as NT Authority\System:
> > a.	C:\> at 1:00pm /interactive cmd.exe
> > 3)	After the command prompt window to appear, you will 
> have "NT Authority\System access."
> > 4)	Attempt to list the contents of the share using the UNC path:
> > a.	C:\> dir \\server\share   - You should receive a 
> directory listing of the files on the share
> > 
> > Remove system and this wont work.
> > 
> > Example 3.
> > A program that runs under the NT Authority\System, but the 
> software is on a samba share.
> > For example, software updaters with packages. My zarafa 
> updater runs as user SYSTEM.
> > My packages are on the samba shares.. ...
> > 
> > 
> > Example 4.
> > Last one, lunch time.
> > Install a virusscanner, ( which mostly runs as system ) and 
> set it to scan you network shares.
> > 
> > 
> > Anyone else comments on above. I dont know everything so 
> shoot me if im wrong here.
> > But removing user SYSTEM from the shares is really bad advice, Yes, 
> > its an option, but NOT for sysvol and profiles or shares 
> where you deploy files.
> > 
> > 
> > Greetz,
> > 
> > Louis
> > 
> > 
> 
>