Re: [Samba] Samba-wiki info about profiles and SYSTEM account.
- Date: Wed, 3 May 2017 15:43:48 +0200
- From: Marc Muehlfeld via samba <samba@xxxxxxxxxxxxxxx>
- Subject: Re: [Samba] Samba-wiki info about profiles and SYSTEM account.
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.
Am 03.05.2017 um 12:22 schrieb L.P.H. van Belle via samba:
I just saw the new site for the profiles :-) didnt notice that.
Now i saw the link to :
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.
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.
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...
Try to do the following.
Add the Administrators security group to roaming user profiles in Computer Configuration \ Administrative Templates \ System \ User Profiles
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!
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.
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.. ...
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.
To unsubscribe from this list go to the following URL and read the