A lot of organizations run Active Directory Domain Services as their Identity and Access Management (IAM) solutions. Their Domain Controllers unlock access to the simplified view on the organization’s processes, structure and systems, so people can perform the jobs they were hired to do.
Just when you thought your Active Directory environment couldn’t get any more optimized after the first four blogpost in this series, I’m back again today to help Active Directory admins out with fighting their worst nightmare: Inadvertently and/or accidental misconfiguring Active Directory, grinding the entire business to a halt.
It’s not like it didn’t happen in the past. You might not have heard of any organizations going out of business due to disastrous Identity and Access Management, but I’ve seen a couple in my heyday… To be honest, most organizations had trouble throughout, including a lack of proper processes, policies and auditing. The ‘pile-on effect’, due to not being able to find the root cause of issue, inadequate documentation and the inability to restore backups, eventually got the best of them.
(Parts of) The Solution
So, how do we avoid misconfiguring Active Directory?
– Anonymous customer
As many Active Directory admins have asked me how to avoid misconfiguring Active Directory. Either stemming from true loyalty towards their employer or from a Cover Your *ss (CYA) attitude, this question is a good one. The answer is pretty simple though:
Apply the Principle of Least Administrative Privilege
The amount of administrators, able to make changes to the database, and their administrative reach, as in the changes they’re allowed to make, should be as limited as possible. In real-world environments, membership to the groups Enterprise Admins and Enterprise Admins but also domain admins in a multi-forest environment, should only be given to the most trustworthy and capable persons in your organization. The Schema Admins group, on the other hand, should be empty by default as a best practice, since as an Active Directory admin, you would only need access to its permissions when you perform a (planned and tested) Active Directory schema update, defunct and/or extension.
Use the Best Practices Analyzer (regularly)
Since Windows Server 2008 R2, Microsoft ships Best Practices Analyzers (BPAs) with Windows Server. Best Practices Analyzers help you to avoid 80% – 90% of the common misconfigurations that lead to data loss. You do not need to purchase BPAs as extras; you gain access to them from the Server Manager and through the many Best Practice Analyzer PowerShell Cmdlets. The ability to run the BPAs from a remote (management) workstation with the Remote Server Administration Tools (RSAT) installed and through PowerShell make them useful in environments with Server Core installations too.
The Active Directory Domain Services Best Practices Analyzer (AD DS BPA) checks for many misconfigurations at the server level (PDCe time synchronization is a big one, that pops up in many environments I see), at the organization-level (Regular Backups), but also inside the Active Directory. One important AD DS BPA check within the database, that I particularly like, is whether all Organizational Units (OUs) are protected against accidental deletion.
Protect important objects against accidental deletion
Even in organizations with well-skilled Active Directory admins, people slip up.(Administration is still a job done by humans, and humans tend to make mistakes)
Many processes in Active Directory already exist to prevent changes you might not want to see occur. AdminSDHolder is a prime example of such processes; Hourly, it mulls through the ACLs on user objects that are part of typical administration groups (Domain Admins, Print Operators, etc.) and resets them to default. Other objects are marked as system objects and these cannot be deleted with the default tools, like Active Directory Users and Computers (dsa.msc) and the Active Directory Administrative Center (dsac.exe).
The most pervasive human error in Active Directory administration is the accidental deletion of an important object. A feature in Active Directory Domain Services for Windows Server 2008, called Protect against accidental deletion, when enabled, can save your behind.
While presented as a simple check mark on objects in the common management tools, under the hood, this feature changes the ACLs on the object to prevent it from being deleted. The only way to be able to delete it is by either changing the ACLs or remove the check mark.
Since Organizational Units (OUs) hold other objects, these are the kind of object you’d want to protect, regardlessly. Protection against accidental deletion for Organizational Units is enabled by default when an Active Directory domain is first setup using a Domain Controller with at least Windows Server 2008. Also, be weary of Protection against accidental deletion for Organizational Units when you’re using tools like csvde.exe and ldifde.exe to create Organizational Units.
Deploy Read-only (Server Core) Domain Controllers
In organizations where teams of administrators are divided by geographic boundaries, often problems seem to magically appear due to ineffective communication between the teams. Language barriers may apply, but also the loss of nonverbal communication during digital meetings can hamper conveying sarcasm and cynicism.
In these cases, a team of administrators located at the HQ of the organization (or located at any hub in a typical hub-and-spoke networking environment) might decide to prevent changes in the Active Directory database (and surrounding services) while still maintaining an Active Directory foothold at (spoke) locations and allowing the administrators at the (spoke) location to manage the Windows Server(s), hosting Active Directory Domain Services.
In this scenario, Read-only Domain Controllers can be placed in (spoke) locations, installed with Server Core installations of Windows Server. Read-only Domain Controllers, in this scenario, act a more secure method for deploying Domain controllers and Domain Admins can grant non-administrative domain users the right to log on to them while minimizing the security risk to the Active Directory forest. Server Core installations of Windows Server lack most of the Graphical User Interface (GUI) and administrators using these systems are less prone to click-and-miss errors.
As a Domain Admin, you can configure (Server Core) installations of Windows Server for this type of role separation in the following way:
- Log on to the Read-Only Domain Controller as a Domain Admin
- Click Start, (click Run,) type cmd, and then press ENTER.
- At the command prompt, type dsmgmt.exe, and then press ENTER.
- At the DSMGMT prompt, type local roles, and then press ENTER.
- For a list of valid parameters, type ?, and then press ENTER. Note:
By default, no local administrator role is defined on the RODC after AD DS
installation. To add the local administrator role, use the Add parameter.
- Type add <DOMAIN>\<user> <administrative role>For example, type add CONTOSO\testuser administrators
Block changes to Active Directory Domain Services
A more rigorous, but viable solution is to block changes to Active Directory. While you can make administration more process-driven by incorporating Role-based Access Control (RBAC) with a super account and making this account perform actions based on workflows, (System Center Orchestrator and SharePoint Server are Microsoft tools you can use to that purpose) or use a 3rd party management solution like Quest’s ActiveRoles Server and its proprietary management tools , blocking changes to Active Directory is also possible with the native tools, like Active Directory Users and Computers (dsa.msc) and the Active Directory Administrative Center (dsac.exe).
One of the solutions that can limit Active Directory administrators from making changes to specific objects, specific attributes and at specific hours is STEALTHbits StealthINTERCEPT. As part of this solution, a StealthINTERCEPT agent is installed on each of the (R/W) Domain Controllers, that monitors changes to the database on the database level (not the protocol level). When the changes do not adhere to the policies laid out by the Chief Security Officer (CSO), the changes do not get applied, get logged and (optionally) the CSO and his/her auditing department get notified.
Set up Adequate Auditing
Speaking of auditing… Every organization, multi-national or not, should have some sort of mechanism for (external) Active Directory auditing. Whether you’d simply want to track changes to Active Directory (a granular auditing feature found in Domain Controllers running Windows Server 2008 and up), set up a 3rd party auditing infrastructure for the CSO and his/her department, or employ the services of an audit, assurance or governance firm, like PwC and KPMG, depends on the needs and requirements of your organization.
In my opinion, though, no auditing is inadequate auditing. To set up auditing of Active Directory changes, including the ability to see old and new values when changes are made to objects and their attributes, perform the following steps:
- First enable the global audit policy. With the Group Policy Management Console (gpmc.msc), right-click Default Domain Controllers Policy, and then click Edit.Under Computer Configuration, double-click Policies, double-click Windows Settings, double-click Security Settings, double-click Local Policies, and then click Audit Policy.
In the details pane, right-click Audit directory service access, and then click Properties. Select the Define these policy settings check box. Under Audit these attempts, select the Success, check box, and then click OK.
- As the second step, enable the change auditing policy. On each of your Domain Controllers running (Server Core installations of) Windows Server 2008 or up, click Start, right-click Command Prompt, and then click Run as administrator. Type the following command, and then press ENTER:auditpol /set /subcategory:"directory service changes" /success:enable
- Now you’re able to determine the objects and attribute modifications you want to have audited. For instance, when you want changes to the Builtin container audited, right-click it in either Active Directory Users and Computers (dsa.msc) and the Active Directory Administrative Center (dsac.exe), and then click Properties.Click the Security tab, click Advanced, and then click the Auditing tab. Click Add, and under Enter the object name to select, type Authenticated Users (or any other security principal), and then click OK. In Apply onto, click Descendant User objects (or any other objects). Under Access, select the Successful check box for Write all properties. Click OK until you exit the property sheet for the OU or other object.
Now, when an accidental change occurs on a object or its attributes, the old value and new value are logged as event-IDs 5136 (object modification), 5137 (object creation), 5139 (object move) and 5141 (object deletion) in the Security event log.
To have control over an Active Directory environment is to take control over it. By adhering to best practices like the ones above, you can take control and be in charge of the contents within Active Directory. When less of your time is spent like a fireman in your networking environment, you have time to become the dentist and pull out some rotting teeth and fill gaps.
Well-known security identifiers in Windows operating systems
Schema vs. Enterprise vs. Domain Admins
Description and Update of the Active Directory AdminSDHolder Object
Best Practices Analyzer for Active Directory Domain Services
AdminSDHolder – or where did my permissions go?
Modify the AdminSDHolder container
AdminSDHolder, Protected Groups and SDPROP
Understanding AdminSDHolder and Protected Groups
AD DS: Read-Only Domain Controllers
Administrator Role Separation Configuration
AD DS Auditing Step-by-Step Guide