Category: Information Security>Asset Management|Compliance|Computer & Network Security>Microsoft

In the first post I covered best practices for securing service accounts.  In this post, I am going to discuss some key elements in securing priveleged access.  Keep in mind, Microsoft has published a comprehensive guide to securing an Active Directory.

Keep in mind that many of these things will require additional work on the front end, but that is usually due to poor existing practices.  Once processes are in place, these key components should not add significant overhead to administrative tasks.

1. No users should regularly reside in Domain Admins (DA) or Enterprise Admins (EA) groups
   1. Straight from the horse’s mouth: As is the case with the Enterprise Admins (EA) group, membership in the Domain Admins (DA) group should be required only in build or disaster recovery scenarios. There should be no day-to-day user accounts in the DA group with the exception of the built-in Administrator account for the domain, if it has been secured as described in Appendix D: Securing Built-In Administrator Accounts in Active Directory.
   2. Follow MS’ recommendations for securing DA and EA accounts.
   3. If you are a single forest, single domain then no one needs to be in the enterprise admins period
   4. Don’t allow domain admins to logon to workstations
2. Ensure that priv accounts follow at least the standard password policy
3. Don’t forget other privileged groups besides DA and EA (Schema Admins, Account Operators, Backup Operators, Administrators, etc.)
4. Maintain separate admin credentials and standard user accounts
   1. Do not use the same account for admin access and for regular access
   2. This includes things like browsing the web on member servers or workstations with priv accounts
      1. Block internet access from all servers
   3. No remote access with privileged accounts
5. Use a jump off server for admin tasks.
   1. Remote to it with a standard account and then remote from there to perform admin tasks
   2. You should allow interactive logons by authorized users and should remove or even block other logon types that are not needed for server access. (https://technet.microsoft.com/en-us/library/dn487449.aspx)
   3. Admin functions should require more than one factor of authentication
6. Use LAPS to generate a different password for all local admins
7. Either use read only domain controllers in a DMZ or create a separate domain with a one way trust (trade off of complexity and security)

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.

What is the minimum privilege needed?

1. If the account will only use local resources on a single device, use a local account on that device.
2. If the account needs permission to see users, computers, groups etc use a domain service acct.
3. 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

1. 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
2. Explicitly deny network and remote desktop logon rights
3. Ensure IUSR accounts and any anonymous accounts do not have access outside of quarantined folders

Any other type of domain account

1. Create an OU for service accounts to manage separately
2. Create usernames with a random component such as <creation date>_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.
3. Do not use the description field in AD to keep track of their purpose since all users can read that information.
   1. 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.
4. 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.
   1. Passwords should be changed regularly at least 90-180days depending on other mitigating controls
5. Disable interactive logon for the service accounts
6. 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).
7. 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