The SYSTEM Account: Difference between revisions

From SambaWiki
(New page about the SYSTEM account, explaining what it is in Windows, how it works, and why it is not necessary in file system ACLs on Samba shares.)
 
(Added details when the SYSTEM account may be required by Windows, even if it is not required from Samba perspective)
 
Line 1: Line 1:
= The <code>SYSTEM</code> Account =
= The <code>SYSTEM</code> Account =


The <code>SYSTEM</code> account always uses the <code>S-1-5-18</code> security ID (SID). Because the SID does not contain the domain SID, the account only exists locally in a Windows and Samba installation. The <code>SYSTEM</code> account is often also named <code>LocalSystem</code> or <code>NT AUTHORITY\SYSTEM</code>.
The <code>SYSTEM</code> account uses the <code>S-1-5-18</code> security ID (SID). Because the SID does not contain the domain SID, the account only exists locally in a Windows and Samba installation. The <code>SYSTEM</code> account is also named <code>LocalSystem</code> or <code>NT AUTHORITY\SYSTEM</code>.


In Windows, <code>SYSTEM</code> is used, for example, by local services on the Windows host to access files on the local file system. Because the <code>SYSTEM</code> account exists in every Windows installation, has no password set, and in most cases has <code>Full Control</code> permissions on local NTFS file systems, it would be a security issue, if this account could be used to authenticate to network resources and access files. If local services that use the <code>SYSTEM</code> account access network resources, the local machine's network account (<code>''domain''\''computername$''</code>) is used to authenticate to the network.
In Windows, <code>SYSTEM</code> is used, for example, by local services on the Windows host to access files on the local file system. Because the <code>SYSTEM</code> account exists in every Windows installation, has no password set, and in most cases has <code>Full Control</code> permissions on local NTFS file systems, it would be a security issue, if this account could be used to authenticate to network resources and access files. If local services that use the <code>SYSTEM</code> account access network resources, the local machine's network account (<code>''domain''\''computername$''</code>) is used to authenticate to the network.
Line 24: Line 24:




= Using the <code>SYSTEM</code> Account in File System ACLs =
= Using the <code>SYSTEM</code> Account in File System ACLs on a Samba Server =


On Windows operating systems using the defaults, the <code>SYSTEM</code> account has <code>Full Control</code> permissions granted on the local NTFS system drive. Additionally, documentation often advices to add the account to the file system access control lists (ACL) to enable local services, that are using this account, to access files.
On Windows operating systems using the defaults, the <code>SYSTEM</code> account has <code>Full Control</code> permissions granted on the local NTFS system drive. Additionally, documentation often advices to add the account to the file system access control lists (ACL) to enable local services, that are using this account, to access files.
Line 30: Line 30:
To be consistent with Windows, the internal <code>SYSTEM</code> account also exists in Samba and you can use it when [[Setting_up_a_Share_Using_Windows_ACLs#Setting_ACLs_on_a_Folder|setting file system permissions using Windows ACLs]]. However, on a Unix host that runs Samba, the <code>SYSTEM</code> account is neither used by Samba, nor available to the operating system. Therefore, you cannot run local services on the Samba host using the <code>SYSTEM</code> account.
To be consistent with Windows, the internal <code>SYSTEM</code> account also exists in Samba and you can use it when [[Setting_up_a_Share_Using_Windows_ACLs#Setting_ACLs_on_a_Folder|setting file system permissions using Windows ACLs]]. However, on a Unix host that runs Samba, the <code>SYSTEM</code> account is neither used by Samba, nor available to the operating system. Therefore, you cannot run local services on the Samba host using the <code>SYSTEM</code> account.


From the perspective of a Samba server you can omit the <code>SYSTEM</code> account in file system ACLs. However, certain Windows services validate ACLs on shares and expect defined ACLs, even if they are not explicitely used. If <code>SYSTEM</code> is not listed in the remote server's ACLs, using the share can fail, even if the user is allowed to access the required content. For example, this applies to:
For this reasons, you can omit the <code>SYSTEM</code> account in file system ACLs on Samba shares.

* the <code>Sysvol</code> share
* user roaming profile shares

{{Imbox
| type = important
| text = For compatibility with Windows, add the <code>SYSTEM</code> account to file system ACLs.
}}





Latest revision as of 20:33, 6 May 2017

The SYSTEM Account

The SYSTEM account uses the S-1-5-18 security ID (SID). Because the SID does not contain the domain SID, the account only exists locally in a Windows and Samba installation. The SYSTEM account is also named LocalSystem or NT AUTHORITY\SYSTEM.

In Windows, SYSTEM is used, for example, by local services on the Windows host to access files on the local file system. Because the SYSTEM account exists in every Windows installation, has no password set, and in most cases has Full Control permissions on local NTFS file systems, it would be a security issue, if this account could be used to authenticate to network resources and access files. If local services that use the SYSTEM account access network resources, the local machine's network account (domain\computername$) is used to authenticate to the network.


How the SYSTEM Account Is Used by a Windows Service

The following example describes how a Windows Active Directory (AD) domain member downloads and applies group policy objects (GPO):

  1. The local Group Policy Client service starts. The service is executed locally using the SYSTEM account.
  2. The service authenticates to the domain controller's Sysvol share using local machine's account within the domain. For example, domain\computername$.
  3. If authentication was successful, the services downloads the Computer Configuration part of the GPOs.
  4. On the domain member, the service updates the registry and file system using the SYSTEM account.



Using the SYSTEM Account in File System ACLs on a Samba Server

On Windows operating systems using the defaults, the SYSTEM account has Full Control permissions granted on the local NTFS system drive. Additionally, documentation often advices to add the account to the file system access control lists (ACL) to enable local services, that are using this account, to access files.

To be consistent with Windows, the internal SYSTEM account also exists in Samba and you can use it when setting file system permissions using Windows ACLs. However, on a Unix host that runs Samba, the SYSTEM account is neither used by Samba, nor available to the operating system. Therefore, you cannot run local services on the Samba host using the SYSTEM account.

From the perspective of a Samba server you can omit the SYSTEM account in file system ACLs. However, certain Windows services validate ACLs on shares and expect defined ACLs, even if they are not explicitely used. If SYSTEM is not listed in the remote server's ACLs, using the share can fail, even if the user is allowed to access the required content. For example, this applies to:

  • the Sysvol share
  • user roaming profile shares



Further Resources

For further details about the SYSTEM account and how it is used in Windows, see the following Microsoft documentation: