Service Accounts are a necessary evil in systems administration. They tend to be shared across members of a team, have access to sensitive data and critical infrastructure. Yet, most companies have minimal safeguards in place for these accounts, and even less policy and procedure in place to govern these accounts. Service accounts don’t need to be a security threat, with a few simple Group Policy Objects and a little planning these can be the most secure accounts in your domain.
There are some best practices for security accounts, below is a few of them:
- Use a prefix (‘s-‘ or ‘svc-‘) on the username to note the object as a service account.
- Service Accounts should be for a single purpose, and the name should reflect that purpose (i.e. s-BackupExec).
- Service Account passwords should expire, and be changed on a rotation
- Store service accounts in a single OU
- Use a random password generator for all account passwords and store the passwords in a secure file. KeePass is a great tool for this.
The essence of securing these accounts, is to identify what logon type (Logon as a service, Logon interactively, etc.) that the service account needs, and restrict the account from all others. This can be done through a servies of Active Directory Groups that tie into a few policy elements within a GPO.
To start securing these accounts, let’s create three Active Directory Groups:
- sg-DenyAllLogon
- sg-DenyLocalLogon
- sg-DenyTSLogon
Then lets create a top of domain GPO that will set the following policies under Computer Configuration | Policies | Windows Settings | Security Settings | Local Polices | User Rights Assignments:
- Deny logon as a batch job: sg-DenyAllLogon
- Deny logon as a service: sg-DenyAllLogon
- Deny logon locally: sg-DenyAllLogon, sg-DenyLocalLogon
- Deny logon through Terminal Services: sg-DenyAllLogon, sg-DenyTSLogon
After these items are in place, we can begin adding the service accounts to these groups, and begin restricting their access. For an example, let’s look at a service account (s-adpsscript) that I created to run a PowerShell script that disables computer objects that haven’t been accessed in over 90 days. This account only needs to run a script on a domain controller, and does not need to logon locally or through Terminal Services, so I would assign it to the sg-DenyLocalLogon and sg-DenyTSLogon groups.
This is only the beginning, and it is possible to begin creating even more restricting rights like allowing logon as a service, but denying logon locally. Like anything related to security, you will need to determine how far to go down the rabbit hole.