Morgan Simonsen's Blog

With the release of Windows 2000 products from Microsoft, most prominently Exchange 2000, started running their services under the Local System¹ account instead of using a dedicated Active Directory User account, or what is commonly known as a service account². The reason for this was security. As time passed more and more products adapted this approach and now most products do, at least from Microsoft. A result of this is the widespread use of computer objects in Active Directory to grant permissions. The Local System account act as the host computer account on the network and as such has access to network resources just like any other domain account. On the network, this account appears as DOMAIN<machine name>$. Instead of granting permissions to the service accounts, who were typically Domain Admins, we now grant granular permissions to the computer object where the service is running. When the service on the computer accesses e.g. Active Directory it does so at the host computer account and because that computer now has rights and permissions it can access the necessary data. But why is this configuration more secure? Well, that’s what this post will try to answer.

• Password changes
  A traditional service account (user account) typically had the User cannot change password and Password never expires settings set. This meant that you set the password of the account when you created it and never changed it afterwards. That is not a good security practice. Computer accounts on the other hand are also members of Active Directory and change their password on a regular basis, completely automatic. By using the computer account for your services you get regular password changes for your services.
• Granular permissions
  Traditional user service accounts were usually added to the Domain Admins group. This facilitated easy access to all resources and the services always worked. If the service account, which could be used on several and sometimes all, computers on the network was ever compromised it would give an attacker virtually unlimited access to the network. By using Local System the account can only be used on the host computer and typically never have any rights on other systems. Furthermore, using the principle of least privilege, the host computer’s account can be given only the necessary permissions required to run the service.

¹ Local System, or NT AUTHORITYSYSTEM which is its actual name, is a predefined local account that can start a service and provide the security context for that service. When you run something, a service, a scheduled task or a process as Local System you are running it as the host computer. This has many benefits. For example the system has access to the entire computer, meaning the local SAM, Session 0, and other protected areas which are not immediately accessible to a user, even an administrator. For an administrator to access these protected areas we have to start a process as Local System, which is something only administrators can do. There are also other accounts which represent the system, namely LocalService and NetworkService. LocalService has reduced privileges similar to an authenticated local user account, and operate on the network using a NULL sessions (anonymous). NetworkService also has reduced privileges similar to an authenticated user account, but accesses network resources using the credentials of the computer account in the same manner as a Local System service does. More information about service accounts etc is available in the Services and Service Accounts Security Planning Guide (http://www.microsoft.com/technet/security/guidance/serversecurity/serviceaccount/default.mspx).

² What allowed this was a change in the Local System Account which enabled it to authenticate to network resources just as a regular user account.