Managing Privileged Access to Active Directory
Active Directory has a very flexible delegation model. And while it can be used to improve security, if you don’t plan carefully, you can inadvertently make Active Directory vulnerable. In this Ask the Admin, I’ll look at what you need to take into consideration when planning access to privileged AD groups.
Have you ever wondered why domain controllers (DCs) don’t have a local administrator account? When you promote a server to a domain controller, the local administrator account is removed and administrative access to the server is gained by using an account in the Domain Admins, BUILT-IN\Administrators, or Enterprise Admins groups. These groups also give users access to Active Directory (AD), so there is no separation of admin access to the server and Active Directory. It’s all or nothing.
Restrict Privileged Domain Groups
It is common for IT to get requests to make some users members of the domain Backup Operators or Server Operators group. Although neither gives direct access to Active Directory, both grant admin-like privileges to domain controllers. The list below shows domain groups that have Tier 0 access to Active Directory. For more information on tiered administration, see Why You Should Use Microsoft’s Active Directory Tier Administrative Model on the Petri IT Knowledgebase.
- Enterprise Admins
- Domain Admins
- Schema Admin
- BUILTIN\Administrators
- Account Operators
- Backup Operators
- Print Operators
- Server Operators
- Domain Controllers
- Read-only Domain Controllers
- Group Policy Creators Owners
- Cryptographic Operators
There should be no permanent members of any of the groups listed above. Only the built-in domain administrator account can remain in the Administrators, Domain Admins, and Enterprise Admins groups if it has been appropriately secured. You can find detailed instructions about how to secure the built-in domain administrator account on Microsoft’s website. Other accounts should have a membership of these groups on a temporary basis only.
The Administrators, Domain Admins, and Enterprise Admins groups must be isolated so that if a user account is added, restrictions are in place to prevent the account logging into systems with lower levels of trust than DCs. The BUILT-IN\Administrators group should be added too.
Group Policy can be used to apply Deny access to this computer from the network, Deny log on as a batch job, and Deny log on as a service rights for the BUILT-IN\Administrators group on domain member servers and workstations. Similarly, the Domain Admins and Enterprise Admins groups should be assigned the above three rights on domain member servers and workstations, plus Deny log on locally and Deny log on through Remote Desktop Services.
Delegating Individual NT User Rights
If you decide to grant individual rights to users on domain controllers, you need to be sure that if the right gives admin-like privileges, such as Create global objects, that you carefully monitor users granted the right. Because of the extra caution you should exercise in such situations, it might be better to temporarily grant access to a highly-privileged group than permanent access to a specific user right. PowerShell Just-Enough Administration (JEA) can also be used to restrict the permanent access users have to servers.
For more information on PowerShell JEA, you can read this two-part article on Petri: PowerShell 5.0 Just Enough Administration (JEA) Part 1: Understanding JEA and Configuring the Demo Toolkit and Creating Toolkits and Understanding Logs.
AD DS Management Accounts
If you are going to keep highly-privileged AD groups empty most of the time, you need to implement a mechanism that allows you to populate the groups when required while keeping AD secure. To achieve this goal, create a set of management accounts that are used solely for the purpose populating privileged AD groups. The accounts should be standard domain user accounts, have the passwords reset after each use, and should be disabled when no longer in use. There are four steps to implementing this infrastructure:
- Create an OU structure that separates privileged accounts and systems from standard user systems.
- Create an AD group containing users that are allowed to enable and disable the management accounts.
- Implement strict controls on the accounts.
- Set permissions on the AdminSDHolder object to allow the management accounts to manage privileged groups.
For more information on how to complete the above steps, Microsoft provides detailed information on its website.
Privileged Access Management
Windows Server 2016 contains new features that allow organizations to gain control of compromised AD forests and implement privileged access management (PAM) to better secure AD, including the use of Just-In-Time (JIT) administration. For more information on PAM in Windows Server 2016, see Windows Server 2016: Set Up Privileged Access Management on Petri. You might also want to take a look at Windows Server 2016: Understanding Microsoft’s Enhanced Security Administrative Environment.
Everyday Administrative Tasks
Now that you have removed users access to highly-privileged AD groups, you’ll need to delegate permissions to users to maintain AD. Everyday tasks, such as adding new user accounts, resetting passwords, and modifying group membership can all be achieved without access to any privileged AD groups.
Make sure that you separate standard user accounts by placing them in an Organizational Unit (OU) that doesn’t contain accounts with privileged access to AD. You can then delegate permission to IT helpdesk staff to manage user accounts in the new OU. For information about how to delegate rights in AD, see Delegate Permission to Reset AD User Account Passwords on Petri.
In this Ask the Admin, I discussed how to manage privileged access to Active Directory. In a future article, I’ll look at how to manage privileged access to domain member servers.