Best Practice: Securing Windows Service Accounts and Privileged Access – Part 2

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 privileged 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. Configure tiered accounts for administrative access. Reference (Updated 1/10/18)

   5. Ensure that priv accounts follow at least the standard password policy

   6. Don’t forget other privileged groups besides DA and EA (Schema Admins, Account Operators, Backup Operators, Administrators, etc.)

   7. 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

   8. 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

      4. Or utilize privileged access workstations

   9. Use LAPS to generate a different password for all local admins

   10. 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)

   11. Disable Macros for end users who do not have a need to run them. Enable Trusted Locations for those that do. https://technet.microsoft.com/en-us/library/cc178948(v=office.12).aspx