Active Directory Best Practices: A Practical Security Checklist

The best way to secure Active Directory Domain Services (AD DS) is to start with a risk-ranked inventory rather than a broad cleanup. Map the identities, systems, and services that can control the directory; identify exposed privilege paths and legacy authentication; then verify monitoring and recovery before making disruptive changes.

Prioritize these areas:

1. Tier 0 identities, systems, and administrative paths
2. Privileged groups, delegated permissions, and Group Policy Objects (GPOs)
3. Domain controllers and the infrastructure that manages them
4. Service accounts, certificate services, trusts, and identity integrations
5. NTLM, Lightweight Directory Access Protocol (LDAP), and Kerberos dependencies
6. Auditing, alert ownership, and investigation procedures
7. Recoverable backups and rehearsed forest recovery

Where to start with Active Directory best practices

Assess an existing environment or plan a new deployment

For an existing environment, document what is deployed before changing its structure. For a new deployment, use the same inventory to define security boundaries and operational ownership before adding applications.

Start with:

• Forests, domains, trusts, domain and forest functional levels, and domain controllers
• Members of built-in and delegated privileged groups
• Accounts with permissions to modify organizational units (OUs), GPOs, trusts, certificate services, or directory permissions
• Service accounts, scheduled-task identities, application pools, and synchronization accounts
• Active Directory Certificate Services (AD CS), Active Directory Federation Services (AD FS), Microsoft Entra Connect, and other identity infrastructure
• Hypervisors, backup platforms, monitoring systems, patching tools, endpoint security platforms, and administrative workstations that manage domain controllers or identity services
• Applications using LDAP, NTLM, Kerberos, or AD-integrated authentication
• Audit coverage, event forwarding, retention, alert ownership, and recovery documentation

Microsoft’s AD DS tier model treats the identity control plane as more than domain controllers and Domain Admins. AD CS, AD FS, Microsoft Entra Connect, virtualization hosts, backup systems, and management tools may belong in Tier 0 when they can directly or indirectly control identity services.

For each asset or identity, record an owner, purpose, required access, dependencies, and decommissioning process. Unknown ownership is itself a finding because no one is accountable for reviewing or safely removing the access.

Prioritize findings by exposure, impact, and change dependencies

Rank findings using three questions:

• Exposure: Can an attacker reach or use the account, system, or protocol from a lower-trust environment?
• Impact: Could compromise change directory-wide policy, issue trusted certificates, extract privileged credentials, or disrupt authentication?
• Dependencies: What applications, administrators, or recovery processes could fail if the control changes?

An exposed Tier 0 credential deserves attention before cosmetic OU restructuring. However, urgency does not justify an untested production change. Record the current state, expected result, test method, exception owner, and rollback procedure for each significant change. Microsoft also recommends testing and staged deployment for material changes to production Active Directory environments in its Active Directory account security guidance.

Design OUs, security groups, and Group Policy for manageable access

Use OUs to support delegated administration and Group Policy application—not simply to reproduce the organization chart. Microsoft recommends creating an OU structure for defined operational purposes, while recognizing that no single hierarchy fits every environment [OU design concepts].

Keep these control mechanisms distinct:

• OUs define administrative and policy scope.
• Security groups represent roles or access requirements.
• Delegated access control lists (ACLs) authorize specific directory-management actions.
• GPO links and inheritance determine where policies are evaluated.
• GPO security filtering determines which users or computers within that scope can apply a GPO.

Avoid granting permissions directly to individual users when a role-based group can represent the same requirement. Name groups by function and scope, assign an owner, and document where each group is used.

Use a worked example to connect group scope, delegation, and GPO inheritance

Suppose the workstation team must reset passwords for standard employees but must not manage server administrators or Tier 0 accounts.

A manageable design would:

1. Place standard employee accounts in a dedicated account OU.
2. Create a role group for authorized help-desk operators.
3. Delegate only the required password-reset controls on that OU to the role group.
4. Keep privileged accounts in a separate protected OU outside the delegation scope.
5. Link workstation or user policies only where their intended objects reside.
6. Use security filtering only when a subset of objects within the linked scope should apply the GPO.

For resource access, a common pattern is to place user accounts in role groups, nest those groups into resource-specific groups when the domain topology permits, and assign permissions to the resource groups. The exact group scope depends on domain and trust design; the objective is to make the path from identity to permission visible and reviewable.

GPO applicability is not determined by link order alone. Administrators must consider site, domain, and OU links, inheritance, security filtering, and whether the target has both Read and Apply Group Policy permissions. Microsoft documents this evaluation model in Group Policy scope.

Review effective access before changing nested groups or permissions

A group that looks unused may still be referenced by a file ACL, delegated OU permission, GPO security filter, application, script, or another group.

Before changing it:

• Expand nested membership in both directions.
• Locate ACLs and delegated permissions that reference the group.
• Check GPO permissions and security filters.
• Identify application, script, scheduled-task, and trust dependencies.
• Confirm the business and technical owner.
• Capture the current configuration and define a rollback path.
• Test the change with representative users and computers.

Review the combined effect of group membership, delegation, GPO scope, and inheritance. Looking at any one of these controls in isolation can hide the actual access path.

Limit privileged access and secure service accounts

Separate administrative identities and review paths to Tier 0

Administrators should use separate identities for routine work and privileged administration. Restrict sensitive administrative accounts from signing in to lower-trust workstations and servers, and limit high-privilege group membership to people and services with a current operational need. These practices reduce opportunities for privileged credentials to be exposed on compromised systems [Microsoft guidance for Active Directory accounts].

Apply the same separation to administrative tools and workstations. A privileged access workstation should not also be used for email, web browsing, or routine productivity work. Maintain controlled emergency-access procedures, but do not turn emergency accounts into everyday administrator identities.

Review every path into Tier 0, including:

• Direct and nested membership in privileged groups
• Delegated rights to modify privileged accounts, groups, OUs, or GPOs
• Control over AD CS, AD FS, Microsoft Entra Connect, or other identity services
• Administrative access to domain-controller hypervisors, backups, monitoring, patching, or security tools
• Accounts allowed to sign in to domain controllers
• Automation identities able to deploy code or configuration to Tier 0 systems

Do not share an account, group, or service identity across administrative tiers. Microsoft’s tier model warns that a service account used on both Tier 0 and Tier 1 systems can expose Tier 0 credentials through a lower-tier host.

Inventory service accounts, certificates, trusts, and identity-management dependencies

Each service account should have a named owner, defined purpose, approved logon locations, minimum required permissions, credential-management method, and retirement process. Use a separate identity for each service where practical so activity and impact remain attributable.

Where the workload supports it, consider a group Managed Service Account (gMSA). A gMSA provides automatic password management and can support services running across multiple servers. Compatibility must be tested before migration. Microsoft also advises against placing service accounts in privileged groups and recommends documenting their ownership, permissions, risk, and lifecycle [securing on-premises service accounts].

Extend the inventory to:

• AD CS servers, certification authorities, administrative roles, service identities, and certificate templates
• AD FS and Microsoft Entra Connect servers and service accounts
• Forest and external trusts, their owners, and continuing business purpose
• Directory synchronization, provisioning, password-management, and identity-governance systems
• Accounts used by backup, monitoring, patching, endpoint security, and automation platforms

These systems may have more practical control over Active Directory than their names or organizational ownership suggest.

Protect domain controllers and the systems that host them

Domain controllers should have a narrowly defined purpose and a small administrative surface. Restrict interactive and remote logon, software installation, management protocols, and network access to approved operational paths. Do not use domain controllers for unrelated applications or routine administrative work.

Patch domain controllers through a staged process:

1. Confirm current backups and recovery access.
2. Test the update against representative domain controller roles and dependencies.
3. Update a limited set first rather than changing all domain controllers at once.
4. Verify startup, name resolution, authentication, directory replication, SYSVOL availability, event logging, and management connectivity.
5. Continue deployment only after the expected services remain healthy.

Protection must extend beyond the guest operating system. A person who controls the virtualization host, backup console, deployment platform, or security-management tool may also control the domain controller. Treat those administrators, service accounts, credentials, and management interfaces as part of the Tier 0 boundary when they can operate on identity systems, consistent with Microsoft’s AD DS tier model.

For physical and virtual domain controllers, assess:

• Physical access and removable-media controls
• Host and storage encryption appropriate to the environment
• Hypervisor and hardware-management administrator access
• Backup-console access and protection of backup copies
• Deployment, monitoring, patching, antivirus, and endpoint detection and response administration
• Administrative network paths and out-of-band management

Encryption can protect data in specific loss or theft scenarios, but it does not compensate for an overprivileged hypervisor administrator or compromised management platform.

Harden authentication without breaking dependent applications

Inventory NTLM, LDAP, Kerberos, and application dependencies before changing settings

Authentication hardening can disrupt legacy applications even when the security objective is correct. Build an inventory of sign-in paths before enforcing new settings.

For each application or device, identify:

• Protocols and bind methods in use
• Server names and service principal names
• Whether LDAP connections use Transport Layer Security (TLS)
• Service-account and delegation requirements
• Supported authentication alternatives
• Application owner and test environment
• Expected failure signals and rollback procedure

Prioritize unsupported and weak paths, but distinguish an observed dependency from an approved permanent exception. Every exception should have an owner, business reason, compensating controls, and review trigger.

Pilot changes, document exceptions, and test rollback

Requiring LDAP signing can reject unsigned Simple Authentication and Security Layer (SASL) binds and simple binds sent without TLS. Enforcing LDAP channel binding can also reject incompatible clients in applicable LDAP-over-TLS authentication flows. Microsoft therefore recommends auditing and identifying affected clients before enforcement [LDAP signing guidance].

A safe rollout is:

1. Enable the relevant auditing and collect data across normal business cycles.
2. Identify the clients, service accounts, applications, and owners involved.
3. Upgrade or reconfigure compatible clients.
4. Pilot enforcement with representative systems.
5. Monitor authentication failures and domain-controller events.
6. Document time-limited exceptions.
7. Test rollback before broad enforcement.

For LDAP signing, domain-controller event ID 2887 can help identify insecure binds, although additional diagnostic logging may be needed to identify specific clients. Microsoft’s LDAP signing implementation guidance explains the compatibility impact and audit-first approach.

Apply similar discipline to NTLM reduction and Kerberos changes. Do not disable a protocol based only on the absence of support tickets; verify actual usage through logs and representative testing.

Distinguish on-premises AD protection from Microsoft Entra MFA policies

Microsoft Entra multifactor authentication (MFA) does not automatically protect every on-premises AD sign-in. Coverage depends on the authentication path and its integration.

For example, the Microsoft Entra MFA extension for Network Policy Server can add MFA to supported RADIUS-based access flows. That does not mean the same policy is automatically applied to Windows domain logons, Kerberos tickets, LDAP binds, or every AD-backed application.

Inventory cloud and on-premises access paths separately. For each path, document where primary authentication occurs, where additional authentication is enforced, how failures are logged, and what bypass or emergency process exists.

Monitor Active Directory changes and investigate warning signs

Collect events that reveal changes to privilege, policy, authentication behavior, and directory state. High-value monitoring areas include:

• Addition or removal of privileged-group members
• Creation, deletion, or modification of sensitive users, groups, computers, and service accounts
• Changes to GPOs, GPO permissions, links, inheritance, or security filtering
• Changes to delegated directory permissions
• Repeated authentication failures, unusual privileged logons, and insecure LDAP use
• Changes to trusts, authentication policies, certificate services, or identity integrations
• Directory replication failures or unexpected replication-related changes
• Audit-policy changes and attempts to clear or disable logs

Windows Advanced Audit Policy includes categories for group membership, authentication policy changes, Directory Service Access, Directory Service Changes, and replication. Relevant directory-service events are recorded on domain controllers. Enable the categories that support defined detection and investigation requirements rather than collecting every event without a plan [Advanced security audit policy settings].

An alert is useful only if someone is responsible for it. For each high-priority detection, define:

• The team and role that receive the alert
• The expected response time based on risk
• The account, group, object, host, and source-address evidence required
• The approved change records to check
• The criteria for escalating to incident response
• The retention period needed for investigation

Correlate directory changes with endpoint, network, identity-service, and administrative-workstation telemetry where available. A group-membership change is more meaningful when investigators can also determine who initiated it, from which host, and whether the action was approved.

Back up Active Directory and test recovery

A successful backup job does not prove that Active Directory can be recovered. Maintain protected, trusted backups and rehearse the recovery procedures using personnel who would perform them during an incident.

Verify that the recovery plan covers:

• System-state recovery for supported domain controllers
• Access to Directory Services Restore Mode credentials
• Safe access to required privileged credentials and recovery documentation
• DNS and SYSVOL dependencies
• Recovery order for multiple domains
• Backup-console availability if production identity services are unavailable
• Isolation of trusted recovery media and infrastructure from routine administrative compromise
• Post-recovery validation of authentication, replication, policy, and logging

Use the narrowest recovery method appropriate to the incident. A deleted object or incorrect attribute may call for object-level restoration or correction. A failed domain controller may require domain-controller recovery or replacement. Suspected compromise of the directory control plane can require forest recovery under the incident-response process.

Forest recovery is not simply a larger object restore. Microsoft’s AD forest recovery guidance calls for restoring at least one domain controller in every domain from trusted backups. The forest returns to the state represented by the selected backups, so objects and changes created afterward may be lost. Test the procedure and its business consequences before an emergency.

Strengthen identity and access security with Scalefusion OneIdP

Securing Active Directory also requires controlling how users access applications and endpoints. Scalefusion OneIdP complements AD security practices by integrating with existing directory identities and extending access controls beyond the directory.

IT teams can enforce conditional access and MFA for supported applications and provide Just-in-Time (JIT) admin access on managed Windows and macOS devices. These capabilities help restrict unauthorized access and reduce standing endpoint administrator privileges without replacing native AD security controls.

Explore Scalefusion OneIdP

FAQs

1. How often should Active Directory permissions be reviewed?

Use a risk-based schedule. Review Tier 0 access and other high-impact permissions more frequently than low-risk resource access, and perform an immediate review after role changes, incidents, reorganizations, trust changes, or modifications to privileged access. The schedule should reflect regulatory requirements, change volume, and available evidence rather than an unsupported universal interval.

2. Does enabling Microsoft Entra ID MFA protect every on-premises AD sign-in?

No. Microsoft Entra MFA applies only to sign-in paths configured to enforce it, such as supported NPS/RADIUS flows using the Microsoft Entra MFA extension. Assess Windows logons, LDAP, Kerberos, and each on-premises application separately to determine where MFA or another control is actually enforced.

3. Can unused Active Directory groups be deleted immediately?

No. First check direct and nested membership, resource ACLs, delegated directory permissions, GPO security filtering, scripts, applications, trusts, and ownership. Record the current configuration, test removal where possible, and maintain a rollback path before deleting the group.

4. What should be checked after an Active Directory hardening change?

Confirm expected user and administrator authentication, application access, DNS, directory replication, SYSVOL availability, GPO application, event logging, monitoring, and management connectivity. Verify that the intended insecure behavior is blocked and that the documented rollback procedure remains usable.