Best Practice: Securing Windows Service Accounts and Privileged Access – Part 1
I recently had a client ask me about our recommendations for securing service accounts within Active Directory. We talked for a bit, and then I decided to write them down. This post will have two parts, the first part is for Service Accounts and then the second post will be about privileged accounts Best Practice for Securing Privileged Windows Accounts.
What is the minimum privilege needed?
- If the account will only use local resources on a single device, use a local account on that device.
- If the account needs permission to see users, computers, groups etc use a domain service acct.
- When only read access to or minor file manipulation is required a standard domain user is usually sufficient.
For local accounts – typically IIS type service accounts or simple applications, a normal local user account is sufficient
- Create a strong password, 25+ characters, and forget the password. If needed, just change the password. If the password is needed regularly, store in an enterprise password manager
- Explicitly deny network and remote desktop logon rights
- Ensure IUSR accounts and any anonymous accounts do not have access outside of quarantined folders
Any other type of domain account
- Create an OU for service accounts to manage separately
- Create usernames with a random component such as _servicename (to prevent guessing). A compromise of a domain user could allow an attacker to read all users, so even this could go further to just create a random username and use a password manager to keep track of them.
- Better yet use Microsoft’s managed service accounts to handle the passwords for you.
- Do not use the description field in AD to keep track of their purpose since all users can read that information.
- You can use a custom field within the AD schema to store this information set the confidentiality bit (http://windowsitpro.com/active-directory/using-confidentiality-bit-hide-data-active-directory by Guido Grillenmeier) in order to allow only domain admins to see this information.
- Ensure your domain functional level is 2008 or greater and set a fine grained password policy for all service accounts. Require strong passwords. Either forget the passwords or use a password manager, preferably just forget them.
- Passwords should be changed regularly at least 90-180days depending on other mitigating controls
- Disable interactive logon for the service accounts
- Do not give service accounts domain admin rights. This is rarely necessary and is usually only done out of laziness (I can speak from past experiences).
- Create a special group (by Jessica Payne (MSFT))called NoWorkstationAccess or NoLateralMovement and add all service accounts to it. Use the linked blog to assign this group as part of SpecialGroups. Then be sure to add this to any computer that those users should not be logging on it (you may need more than one group), an alert will be generated regarding the login and a logging system can alert on it. This can capture malicious lateral movement.
In addition to the blogs mentioned, Microsoft has some good whitepapers for preventing pass-the-hash which apply in part to this: https://www.microsoft.com/en-us/download/confirmation.aspx?id=36036
Update 12/20/2017: Added a reference to managed service accounts