Active Directory (AD) is a primary target for hackers as it provides a way to get access sensitive company data. Here are four considerations for establishing a secure administration model for Active Directory.
1. Remove excess domain administrator privileges
Domain and enterprise administrator accounts hold the keys to your kingdom, and once compromised you can consider your organization owned. Keeping that in mind, it might come as a surprise that one of the biggest security issues companies face is the proliferation of domain administrator accounts and sharing of the domain administrator account password.
Start by ensuring that the domain administrator account password is long and complex, and changed on a regular basis. And at the same time, don’t forget about the Directory Services Restore Mode (DSRM) password. Perform a group membership audit of Schema Admins, Domain Admins, and Enterprise Admins. With the exception of any default accounts, these groups should remain empty most of the time.
Most tasks related to Active Directory don’t require administrator privileges, but when privileged access is required to a domain controller, assign permissions appropriate to the task on a temporary basis. If you decide to delegate ‘administrator’ type privileges on a permanent basis, such as the ability to restart a Windows service or reboot a domain controller, make sure that auditing is configured to record any changes made by the account holders.
2. Delegate
Everyday Active Directory administration tasks, such as creating new user accounts and modifying group membership, don’t require the use of domain administration privileges. The built-in delegation wizard can be used to assign users or groups the necessary rights to perform most common tasks.
To facilitate delegation, I suggest designing an Organizational Unit (OU) structure that allows for the separation of accounts assigned special privileges in the domain, from accounts assigned to non-IT staff. For example, IT helpdesk staff might be given permission to unlock user accounts and modify group objects in one OU, but forbidden to make any changes to objects in an OU reserved for accounts with privileged access to the domain.
3. Use Restricted Groups policy to secure privileged groups
Group Policy contains a feature called Restricted Groups that allows policies to be defined that determines the membership AD or local groups. If you properly restrict the use of privileged AD accounts and delegate access to AD for administration purposes as described above, you can set up a Group Policy Object (GPO) to manage the membership of the Schema Admins, Domain Admins, and Enterprise Admins groups.
While users with membership to any of these groups, or the ability to modify the GPO, would be able to override the policy, using Restricted Groups to define the membership of groups with privileged access to AD can help safeguard domain controllers if a rogue administrator tries to add themselves to a privileged group.
To save time dealing with Group Policy settings use Active Directory tools that make it much easier to manage AD and GPO.
4. Isolate workstations used for managing DCs
If you need to log in or otherwise remotely authorize to AD using an account with privileged access, these operations should always be performed from a device that’s been specially configured to reduce the risks associated with everyday computing tasks.
Workstations designated for use with privileged domain accounts should be isolated from the Internet, be used in accordance with the principle of least privilege, have auditing enabled, and other security defenses provisioned, such as antimalware, endpoint firewall and application control. Additionally, place computer objects for these workstations in their own OU so that policy can be applied separately. Restrict access to local logons only and enforce the limitations mentioned above using Group Policy.
