Running the Puppet agent under LocalSystem vs. a service account
Should you run the Puppet agent under a LocalSystem account or a service account?
The first thing to know is that, by default, we run the Puppet agent under LocalSystem. We do this because it has full admin of the local system. Generally, you can do everything you need to locally on the machine. However, there is the occasional use case where you may want to consider using a service account instead, and in particular, a Group Managed Service Account (gMSA).
Below we’ll share some reasons why LocalSystem is the default, why you might want to try a service account instead, and how to do so in a secure way.
Why LocalSystem is our default account
- Simplicity. As long as you don't need to manage any network resources, it does what you need.
- It has no dependencies. Whether the machine is domain joined or standalone, it is a guaranteed account to exist on every Windows box, with maximum permissions.
- In most environments, LocalSystem accounts have fewer domain privileges outside of the machine it's running on. This means it can't do any damage to the wider domain.
Why you might want to consider running under a service account
- In terms of access, it is more controllable than LocalSystem.
The ability to access network resources. Specifically, Windows network shares that require some form of user or system authentication to access them. If the Puppet agent needs to retrieve a file or package from a Windows network share, and that share doesn't allow the "Computer Object" to access it, the Puppet run will generate authentication or permission errors, and fail for one or more resources. Most organizations don't allow a Computer Object to connect to network resources, which are locked down to AD Users and Groups. In those cases, the Puppet service would need to run as one of those users to be able to access the shares.
More specifically, why you might want to consider running under a Group Managed Service Account (gMSA)
- They have automatic password management.
- They can be assigned to multiple nodes. You could have multiple service accounts for different Puppet agents, for example, one for all IIS servers, and one for all SQL servers. This means that you can limit which network resources the Puppet agent can access.
- They act as both a computer account and a user account — a computer account because the password is automatically rotated every 30 days (by AD), and they work as a user because you can assign it to multiple servers. gMSA benefits by using the same access control via familiar AD groups and Group Policy Object (GPO).
- It is good practice, particularly because they have a heightened level of security compared to a normal user account. Users cannot log in as them, so if ever compromised, they have a limited use. This is especially helpful if your service needs to be able to do something outside the box, for example, if you need to reach network resources.
What to consider before using a gMSA
- You need an AD domain with a functional level of Windows Server 2012 or higher.
- You need to create a KDS root key through PowerShell — but you can run the commands against the box, or on the box, however you choose.
- You have to specify the list of machines that are allowed to use that account — either by specifying a list of all the machine names, or by specifying the name of a security group that contains all these servers. For example, a security group for all your web servers and a security group for all your sql servers.
Interested in running the Puppet agent under a gMSA? Here’s how to do it in a secure way
Before you begin: Make sure you satisfy the prereqs for using a gMSA.
- Firstly, install and verify the gMSA on every node you want to switch to a gMSA. Run the following PowerShell commands:
- Now that you have installed the gMSA on the node, you can run the installer:
- Specify the parameters you would normally use to install with a service account.
- Make sure you put the
$at the end of the account name. The account name is not complete without it. You won't see the
$sign in the account name.
- Don't specify a password to the installer — it is not required.
In the services snapin, you will then see the Puppet and PXP services running as the gMSA account, instead of as LocalSystem. Note that if you are provisioning a server for the first time, the install script should be updated to install the gMSA first. After telling AD that the computer is authorized to use that gMSA — and the computer has rebooted, in that order — you can add it to any service. Additionally, once you have a gMSA set up, you can easily switch back to LocalSystem. The following commands will work for both:
Powershell (>=2.0, <6.0):
Note that you can also use a Puppet task to do this.
We hope that this gives you an idea why you may, or may not, want to change from running Puppet under LocalSystem to a service account or gMSA. In short — if you don’t need to access network resources, LocalSystem is capable of doing most of what you need to do. But, gMSAs are a better security posture at the cost of additional overhead.
We would like thank one of our users, Windows sysadmin Andrew Ball from the University of Saskatchewan, for reviewing this blog post.
Claire Cadman is an associate technical writer at Puppet.
- Read more about Microsoft’s gMSA
- Read the white paper Managing Windows with Puppet Enterprise
- Check out our webinar Introduction to Puppet Enterprise for your Windows Environment