Active Directory Hardening Is a Sequence, Not a Score

Active Directory hardening in 60 seconds

An Active Directory assessment usually ends with a large number. Sometimes it is a score, sometimes a maturity level, and sometimes a red dashboard that slowly becomes green. The number is useful for tracking work. It is not proof that the directory is hard to compromise.

I have seen the same disconnect repeatedly in hardening reviews: dozens of settings are corrected, stale users are removed, password policy improves, and the shortest path from a support account to domain control still survives. The path may run through an old group nesting, a certificate template, a server where a privileged administrator signs in, or a service account whose password has not changed since the application was installed.

That is why I do not start an AD hardening programme with the scanner’s highest-scoring rule. I start with a simpler question:

What can a normal user, a compromised workstation, or a routine server administrator control today that eventually controls the domain?

Hardening is the work of making every answer to that question shorter, rarer, more visible, and finally impossible.

The offensive starting point: one user, one workstation

I frame the review around a representative, explicitly synthetic casefile. It is not presented as a customer incident. It is a compact model of the paths that repeatedly survive otherwise mature hardening programmes.

The assumed attacker has no exploit and no administrator credential. They have one normal domain user and execution on that user’s workstation. From there, the review asks whether they can convert one form of access into another:

1. the user is nested into an old helpdesk group;
2. that group can read Windows LAPS passwords for a management-server OU;
3. one of those servers receives interactive logons from identity administrators;
4. the same management plane can modify a certificate template or operate on a Tier 0 system;
5. a durable directory permission turns the temporary workstation compromise into repeatable domain control.

No single step has to be labelled “Critical” by a scanner. The danger is the composition. The hardening objective is therefore not to hide the path or delete the user from a screenshot. It is to break the earliest durable edge and prevent the privileged credential from appearing on the lower-tier host in the first place.

Scope and safety contract

The commands in this article are deliberately read-only. Run them only in an authorized domain, preferably with a dedicated standard audit account and from the approved assessment host. They enumerate directory objects, permissions, configuration, and event records. They do not request certificates, relay authentication, modify templates, change group membership, retrieve managed password values, or attempt credential extraction.

Tool output remains a candidate until the path’s effective permission, reachable target, protected consumer, and business impact are confirmed. The offensive lens decides what to investigate; it does not turn every red label into a finding.

What I mean by “hardened”

A hardened directory is not one with every legacy feature disabled. It is one where the following statements have evidence behind them:

• ordinary user and workstation compromise cannot expose control-plane credentials;
• server administrators cannot silently become domain administrators through group nesting, ACLs, delegation, certificates, backup infrastructure, or management tooling;
• service identities have narrow rights, managed credentials, and a known set of hosts that may use them;
• authentication protocols reject the relay and downgrade paths the estate claims to have closed;
• privileged changes produce telemetry that someone reviews;
• the organization can restore a clean forest without depending on the compromised forest itself.

That definition changes the unit of work. “Enable LDAP signing” is a task. “Unsigned LDAP binds are rejected, the incompatible clients have named owners, and relay validation now fails” is a tested control.

First, draw the real control plane

“Tier 0” is often reduced to domain controllers and Domain Admins. That inventory is too small. The practical definition is straightforward: if compromising a system lets an attacker control domain controllers, change authentication, mint identities, or restore a compromised directory, that system belongs in the control plane.

That normally includes:

• domain controllers, forest and domain administration groups, and their delegated operators;
• AD CS certification authorities, certificate templates, PKI administration, and enrollment services capable of producing authentication certificates;
• Entra Connect, federation services, identity lifecycle platforms, password reset systems, and privileged access tooling;
• backup systems holding domain-controller data and the accounts able to restore it;
• hypervisors, management agents, patch platforms, EDR consoles, and monitoring systems that can execute code on domain controllers;
• the workstations and jump hosts from which any of those systems are administered.

This exercise usually changes the programme. A company may have two well-protected domain controllers and an ordinary virtualization team that can mount their disks. It may restrict Domain Admins while a backup operator can restore ntds.dit. It may protect privileged users with dedicated workstations while the same users manage the certificate authority from a daily laptop.

The domain is only as isolated as the least protected system that can control it.

Read-only control-plane baseline

Start by resolving the built-in privileged groups by SID instead of assuming their English names. The following inventory expands nested membership and records the objects; it changes nothing.

Import-Module ActiveDirectory

$domain = Get-ADDomain
$forest = Get-ADForest
$domainAdminSid = "$($domain.DomainSID.Value)-512"
$enterpriseAdminSid = "$((Get-ADDomain -Identity $forest.RootDomain).DomainSID.Value)-519"

$tier0Groups = @(
  Get-ADGroup -Identity $domainAdminSid
  Get-ADGroup -Identity $enterpriseAdminSid
)

$tier0Groups | ForEach-Object {
  $group = $_
  Get-ADGroupMember -Identity $group -Recursive |
    Select-Object @{n='PrivilegedGroup';e={$group.SamAccountName}},
                  objectClass, SamAccountName, DistinguishedName
} | Sort-Object PrivilegedGroup, objectClass, SamAccountName

Then extend that inventory beyond groups. Record systems that can execute on domain controllers, restore their data, mint authentication certificates, synchronize identities, reset privileged credentials, or administer the virtualization layer. Those relationships often live outside AD, so no LDAP query or BloodHound collection can prove the inventory complete.

For protected-object inheritance, inspect AdminSDHolder rather than changing it during discovery:

$adminSdHolder = "AD:CN=AdminSDHolder,CN=System,$($domain.DistinguishedName)"
(Get-Acl $adminSdHolder).Access |
  Select-Object IdentityReference, ActiveDirectoryRights,
                AccessControlType, ObjectType, IsInherited |
  Sort-Object IdentityReference

An unexpected ACE is a lead. Before reporting it, resolve nested membership, confirm the right is effective, identify which protected objects inherit or retain it, and show the privileged action it would authorize.

Separate administration by where the credential may appear

Administrative tiering fails when it is treated as an organizational chart. Creating “Tier 0 Admins” and “Server Admins” groups does not help if the same person signs in to both environments with the same account from the same workstation.

The control I care about is where a credential can be presented, cached, delegated, or stolen.

For Tier 0 work, use a separate privileged identity and a dedicated privileged access workstation. Block that identity from interactive and network logon to lower-tier servers and user devices. Do not browse email, open documents, administer ordinary applications, or use the account as a service identity. Emergency accounts should be few, independently monitored, and tested rather than assumed to work.

The negative control is important. A Tier 0 account should successfully reach its approved management path and fail when used on a Tier 1 server or normal workstation. Without that failed logon, the design exists only in group names and documentation.

Use logon telemetry to challenge the architecture. The query below collects successful logons and special-privilege assignments from an approved event source; it does not attempt authentication.

$start = (Get-Date).AddDays(-14)
Get-WinEvent -ComputerName 'dc01.corp.local' -FilterHashtable @{
  LogName   = 'Security'
  Id        = 4624,4672
  StartTime = $start
} | Select-Object TimeCreated, Id, MachineName, Message

The review question is not merely whether event 4672 exists. Correlate the account, logon type, source host, destination, and approved administration route. A Tier 0 identity appearing from a general server or user workstation is evidence that the tier boundary failed operationally.

Remove stored privilege before rotating passwords

Password rotation is visible and easy to measure. Old permissions are quieter and often more important. A twenty-character password does not protect a group that can add itself to another group, rewrite a GPO linked to domain controllers, read a managed service password, or change a certificate template.

I inventory privilege in four places:

1. membership of built-in and delegated administrative groups, including nesting;
2. ACLs on the domain root, OUs, groups, GPOs, admin accounts, and certificate templates;
3. local administration and remote-management rights on Tier 0 and Tier 1 systems;
4. temporary facts such as privileged sessions, which explain credential exposure but should not be confused with durable permissions.

From an offensive perspective, I rank edges by three properties: privilege gained, how long the edge survives, and whether the target is reachable from the assumed foothold. A permanent WriteDacl right on an OU usually deserves attention before a session observed once on a laptop, even when the session produces a shorter graph path.

Enumerate the permissions attackers chain

The native queries below surface delegation and service-account candidates without exercising them:

# Unconstrained delegation on computers
Get-ADComputer -Filter 'TrustedForDelegation -eq $true' `
  -Properties TrustedForDelegation,PrimaryGroupID |
  Select-Object Name,DistinguishedName,TrustedForDelegation,PrimaryGroupID

# Classic constrained delegation on any directory object
Get-ADObject -LDAPFilter '(msDS-AllowedToDelegateTo=*)' `
  -Properties msDS-AllowedToDelegateTo |
  Select-Object Name,ObjectClass,DistinguishedName,msDS-AllowedToDelegateTo

# Resource-based constrained delegation descriptors
Get-ADObject -LDAPFilter '(msDS-AllowedToActOnBehalfOfOtherIdentity=*)' `
  -Properties msDS-AllowedToActOnBehalfOfOtherIdentity |
  Select-Object Name,ObjectClass,DistinguishedName

For durable graph paths, constrain BloodHound to permission edges instead of allowing transient sessions to dominate the result:

MATCH p = shortestPath(
  (n)-[:MemberOf|Owns|GenericAll|GenericWrite|WriteDacl|WriteOwner|
       AddMember|ForceChangePassword|AllExtendedRights|ReadLAPSPassword|
       ReadGMSAPassword*1..8]->(g:Group)
)
WHERE toUpper(g.name) STARTS WITH 'DOMAIN ADMINS@'
RETURN p

The graph is the hypothesis. For each edge, return to the raw security descriptor, resolve nested groups, verify inheritance and object scope, and confirm the target is reachable from the approved test position. If the path depends on a session, capture its time and recollect before claiming it is repeatable.

This is where a graph is useful, with one warning: the shortest path is not automatically the best finding. A live session may disappear in minutes; WriteDacl on an OU may survive for years. I separate durable permissions from temporary sessions and remediate the durable edge that makes the path repeatable. The detailed reasoning is in the BloodHound edge triage note.

Each delegated permission should have a named owner, business purpose, approved principal, scope, review date, and expiry where possible. “Inherited from an old project group” is not ownership.

Treat service accounts as paths, not password exceptions

Traditional service accounts accumulate three properties attackers value: a stable password, an SPN that allows offline password guessing, and privileges nobody wants to retest because the application is fragile.

Where the application supports it, migrate to a gMSA so Windows manages the password and SPN. Then review the permission that determines which computers can retrieve that managed password. Moving to gMSA eliminates manual password rotation; it does not make an over-broad PrincipalsAllowedToRetrieveManagedPassword harmless.

For every remaining user-based service account, record:

• the service and hosts that use it;
• interactive and remote logon restrictions;
• SPNs and supported Kerberos encryption types;
• direct and nested group memberships;
• local administrator rights and access to network resources;
• the last successful rotation and the tested rollback plan;
• an accountable application owner and a retirement or migration decision.

The priority is not simply “accounts with SPNs.” It is accounts whose offline-crackable credential opens a privileged second hop. That distinction is why Kerberoasting triage starts with privilege and service ownership rather than crack speed.

Inventory the credential readers—not the credentials

The following commands list service identities and the principals allowed to retrieve managed passwords. They intentionally do not call Get-LapsADPassword and do not retrieve a gMSA password.

# User-based service identities with SPNs
Get-ADUser -LDAPFilter '(&(objectCategory=person)(objectClass=user)(servicePrincipalName=*))' `
  -Properties ServicePrincipalName,Enabled,LastLogonDate,
              PasswordLastSet,msDS-SupportedEncryptionTypes |
  Select-Object SamAccountName,Enabled,LastLogonDate,PasswordLastSet,
                msDS-SupportedEncryptionTypes,ServicePrincipalName

# gMSAs and the hosts/groups allowed to retrieve each managed password
Get-ADServiceAccount -Filter * `
  -Properties PrincipalsAllowedToRetrieveManagedPassword,
              ServicePrincipalNames,msDS-SupportedEncryptionTypes |
  Select-Object Name,Enabled,PrincipalsAllowedToRetrieveManagedPassword,
                msDS-SupportedEncryptionTypes,ServicePrincipalNames

# Extended rights over a Windows LAPS-managed OU
Find-LapsADExtendedRights -Identity 'OU=Workstations,DC=corp,DC=local'

For every reader, ask what compromise of that principal gives an attacker next. A workstation group allowed to retrieve a gMSA used only on web servers may be a serious but bounded error. The same reader over an identity-management service or backup platform can be a direct control-plane path. The secret type is not the severity; the consumer is.

Migrate authentication protocols with evidence, not hope

The protocol layer is where hardening programmes most often choose between two bad approaches: enforce everything in one maintenance window and break legacy applications, or audit indefinitely and never enforce anything.

Use a measured migration instead:

1. enable the relevant LDAP, NTLM, and authentication auditing;
2. identify the client, service, account, destination, and owner behind each legacy event;
3. fix or isolate the dependency;
4. enforce the control on a pilot scope;
5. verify both a successful modern authentication and a rejected legacy attempt;
6. expand enforcement and keep an exception register with an expiry date.

Build the relay map before changing policy

An attacker does not ask whether “signing is enabled in the domain.” They ask which source can be coerced to authenticate over which transport, which destination will accept that authentication, and what the captured identity may change there. The defensive inventory must use the same three columns.

Collect the full event record, not only a count. Microsoft documents LDAP signing events in the 2886–2889 range and channel-binding events in the 3039–3041 range. Their exact message and availability depend on the Windows Server generation and configured diagnostics, so preserve the event text with the ID.

$start = (Get-Date).AddDays(-14)
Get-WinEvent -ComputerName 'dc01.corp.local' -FilterHashtable @{
  LogName   = 'Directory Service'
  Id        = 2886,2887,2888,2889,3039,3040,3041
  StartTime = $start
} | Select-Object TimeCreated,Id,MachineName,LevelDisplayName,Message

Event 2887 is useful as a summary that unsigned binds still occur; detailed logging is needed to attribute incompatible clients. Event 3039 and related channel-binding records help identify clients that cannot supply a valid token. Do not move to enforcement until each recurring client IP, identity, application, and owner is known—or deliberately isolated as an expiring exception.

LDAP signing and LDAP channel binding solve different problems. Signing protects LDAP message integrity; channel binding ties authentication to the TLS channel. An LDAPS listener is not automatically safe from relay merely because traffic is encrypted. Likewise, SMB signing closes an SMB relay destination but says nothing about HTTP-to-LDAP relay. The complete protocol model is in the NTLM relay note.

The result I want is not a registry value. It is a rejected unsigned bind tied to the policy change, plus evidence that the approved client still works.

Put AD CS inside the same review

AD CS is not an optional appendix to directory hardening. A certification authority that can mint authentication certificates is an identity control system. Its servers, administrators, certificate templates, enrollment endpoints, private keys, backup process, and management hosts belong in the control-plane inventory.

Review more than published template flags. Check who can change each template, who can publish it, who can administer the CA, who can enroll, which identities a requester may place into a certificate, whether manager approval or authorized signatures are meaningful, and whether web enrollment endpoints have current authentication protections.

This is the difference between finding one unsafe template and finding the permission that lets a routine group make any template unsafe. The AD CS ownership analysis shows why template ACLs are often the durable root cause.

Enumerate AD CS without issuing a certificate

Certipy v5 separates find from active commands such as req, auth, relay, ca, and template. For a read-only hardening baseline, use only find, preserve the JSON evidence, and review the complete enabled-template set rather than filtering immediately to -vulnerable:

certipy find \
  -u '[email protected]' -k -no-pass \
  -dc-host 'dc01.corp.local' \
  -enabled -json -output 'adcs-baseline'

The -vulnerable classification understands nested group membership and is useful for triage, but it remains a tool interpretation. Confirm the template DACL, enrollment principals, issuance requirements, EKUs, subject construction, CA publication state, CA administration, enrollment endpoint, and domain-controller certificate mapping independently. This article intentionally stops before certificate enrollment or authentication testing; those require a separate approved lab plan and evidence scope.

Recovery is a security control, not a backup report

A successful backup job proves that bytes were copied. It does not prove the organization can recover a forest after identity systems, administrators, and management tooling are all considered untrusted.

A defensible recovery programme answers operational questions:

• Which backup represents the last known-safe directory state?
• Are there at least two regularly backed-up writable domain controllers per domain?
• Are built-in Administrator and DSRM credentials available outside the forest being recovered?
• Can the team rebuild on clean infrastructure without authenticating to compromised management systems?
• In what order are the forest root, domains, DNS, SYSVOL, trusts, PKI, and synchronized identity services restored?
• When was the procedure last rehearsed, how long did it take, and what failed?

Microsoft’s forest recovery guidance is explicit that the operation restores each domain to the time of the selected trusted backup and loses later directory changes. The difficult decision is therefore not “do we have a backup?” but “which backup is recent enough to be useful and old enough to be clean?” That decision requires daily health history and an exercise, not a green backup console.

Retest like the attacker, report like an engineer

A remediation is not verified because the responsible team changed a GPO, removed a group member, or produced a new scanner report. Repeat the original path from the original source context and require the earliest dangerous action to fail.

I use five states:

1. candidate — a tool, ACL, event, or configuration suggests a path;
2. validated edge — effective permission and reachability are independently confirmed;
3. validated path — the edge reaches a protected consumer or control-plane capability;
4. remediated — the root permission, credential exposure, or protocol behavior changed;
5. retested — normal behavior succeeds and the original offensive action is denied.

Use a compact evidence record for every retest:

CLAIM            Tier 0 identities cannot authenticate to Tier 1 servers
SOURCE           approved Tier 1 test host
PRINCIPAL        dedicated Tier 0 test identity
POSITIVE CONTROL Tier 0 PAW → approved DC management succeeds
NEGATIVE CONTROL Tier 1 host → Tier 0 logon is denied
EVIDENCE         policy export + event record + timestamp + tester
RESULT           VERIFIED / FAILED / BLOCKED

If I could do only five things on Monday

1. Build the real control-plane inventory, including AD CS, backup, identity sync, hypervisors, and management agents—not only domain controllers.
2. Find every lower-tier host where a Tier 0 identity authenticated during the last fourteen days, then block and retest those logon routes.
3. Recalculate durable ACL-only paths to Domain Admins and remove the earliest unnecessary edge.
4. Review who can read Windows LAPS and gMSA passwords and which privileged systems consume those credentials.
5. Enumerate all enabled AD CS templates and their write/enrollment principals, then assign a date for the next clean-room forest recovery exercise.

The order I would use for the first 90 days

Trying to remediate every scanner item in parallel creates change without risk reduction. I use a sequence that closes the highest-value paths first and creates evidence for the next stage.

Days 0–15: establish control. Inventory the real control plane, name owners, reduce emergency access, secure recovery credentials, and collect a baseline with a normal domain account. Tools may include PingCastle, BloodHound, native exports, and Certipy, but their output remains a list of candidates.

Days 15–35: isolate privileged administration. Separate accounts, define PAWs or hardened jump paths, restrict privileged logons to approved systems, remove daily-use activity from admin identities, and test the deny paths.

Days 35–60: remove durable escalation. Review nested groups, ACLs, GPO control, delegation, LAPS and gMSA password readers, service identities, and AD CS administration. Fix the permission that creates the path, then recollect the graph.

Days 60–80: enforce authentication controls. Use audit data to migrate LDAP, NTLM, SMB, and web-authentication dependencies. Pilot, enforce, and preserve rejection evidence.

Days 80–90: recover and retest. Run a bounded forest recovery exercise, rebuild the attack-path graph, repeat negative controls, and close only the findings whose original path no longer works.

What can break—and what to measure first

Offensive hardening is not reckless enforcement. A control that breaks identity-dependent business services will be rolled back under pressure, often without a second attempt. Measure the dependency, pilot the change, preserve a rollback path, and define the negative security test before the window.

Change	Likely dependency	Measure before enforcement	Security pass condition
Require LDAP signing	Legacy Java appliances, scripts, simple binds	Client IP, identity, bind type, owner, and frequency from Directory Service events	Approved signed clients work; unsigned bind receives a documented rejection
Enforce LDAP channel binding	Older LDAPS clients and TLS intermediaries	3039–3041 event messages, TLS termination path, client support	Valid CBT succeeds; missing or mismatched CBT is rejected according to policy
Restrict NTLM	Appliances, old applications, local-account workflows	Source, target, account, protocol, and business owner for each NTLM use	Kerberos/modern path succeeds; expired exception path fails
Introduce tiered logon restrictions	Shared administration habits and legacy jump servers	Fourteen to thirty days of privileged logon source/destination evidence	Approved PAW route succeeds; higher-tier identity is denied below its tier
Migrate a service to gMSA	Application startup, cluster, SPN, and encryption support	Test instance, service dependencies, allowed retrieval hosts, AES support	Service starts and authenticates; unauthorized host cannot use the gMSA
Narrow LAPS readers	Helpdesk and break-fix procedures	Current readers, actual retrieval events, device ownership, emergency route	Approved support retrieval works; unrelated principal cannot read the secret
Harden AD CS enrollment	Auto-enrollment, NDES/SCEP, web enrollment, certificate mapping	Published templates, enrollment volume, endpoint protocols, mapping exceptions	Approved enrollment succeeds; unauthorized identity shape is denied without issuance

Evidence matrix

Hardening claim	Evidence I require	Negative control	What is not enough
Tier 0 is isolated	Complete control-plane inventory, approved admin paths, logon restrictions, and observed Tier 0 sessions only on approved hosts	Attempt the same Tier 0 logon from a lower-tier test system and require failure	A diagram showing three tiers
Standing privilege is reduced	Effective membership and ACL evidence before and after the change, plus a recollected attack graph	Re-run the original path from the same low-privilege principal	Removing one user from one screenshot
LAPS is effective	Unique rotating local passwords, encrypted storage where applicable, narrow read rights, and retrieval audit events	Use one managed credential against a second host and require failure	Installing the LAPS client or creating a GPO
Service identities are hardened	gMSA migration or tested rotation, narrow password-retrieval rights, AES support, denied interactive logon, and application-owner acceptance	Remove an unauthorized retrieval host and confirm it can no longer use the account	A long password with no owner
LDAP and relay paths are closed	Audit-to-enforcement record, signed binds, channel-binding policy, compatible client success, and rejected relay/unsigned bind evidence	Send a controlled unsigned or unbound authentication and require rejection	Registry or GPO screenshots alone
AD CS cannot mint unintended identities	CA and template ACL review, enrollment constraints, authentication mapping state, endpoint protection, and independent path analysis	Attempt an unauthorized enrollment shape and require denial without issuing a usable certificate	“Certipy found no ESC1” without ACL review
Forest recovery is viable	Trusted backup selection, offline credentials, clean-room runbook, timed exercise evidence, and documented failures	Rehearse without relying on the production forest or its management plane	A successful backup job

What the final hardening record should contain

Do not hand defenders a score and a hundred screenshots. For every accepted issue, record:

• the exact principal, permission, system, protocol, or configuration that creates the risk;
• the complete path to a protected identity or business asset;
• effective permission and reachability evidence, not only a scanner label;
• a named remediation owner and target state;
• dependencies and approved temporary exceptions;
• the positive test showing normal operation still works;
• the negative test showing the dangerous path now fails;
• the date and evidence for retest.

I added a reusable offensive AD hardening review register with those fields. It is intentionally a decision record rather than a vulnerability checklist: each row starts from an attacker hypothesis and ends with positive and negative retest evidence.

This prevents two common failures. The first is declaring every tool signal a finding. A BloodHound edge, Certipy label, or health-check score is a candidate until effective rights, reachability, and impact are confirmed. The second is closing a finding because a setting changed even though the original path was never repeated.

My conclusion

The best Active Directory hardening programmes are not the ones that change the most settings. They are the ones that can show, in order, which path existed, which durable edge created it, what changed, what legitimate behavior survived, and why the same path now fails.

Start with the systems that can control identity. Isolate the credentials that administer them. Remove old permissions before polishing policy. Treat service accounts and certificates as authentication paths. Enforce protocols with audit evidence. Then prove that the directory can be recovered without trusting the environment that just failed.

A score can summarize that work. It cannot replace it.

MITRE ATT&CK mapping

Tactic	Technique ID	Technique name	Defender verification signal
Reconnaissance	T1087.002	Account Discovery: Domain Account	Audit LDAP search spikes via Event ID 1644 / Directory Service log
Credential Access	T1558.003	Steal or Forge Kerberos Tickets: Kerberoasting	Event ID 4769 with Ticket Options 0x40810000 and Encryption Type 0x17
Privilege Escalation	T1484.001	Group Policy Modification	Audit ACL modifications on CN=Policies,CN=System in Directory Service
Lateral Movement	T1550.002	Use Alternate Authentication Material: Pass the Hash	Event ID 4624 (Logon Type 3) using NTLM instead of Kerberos

Defender action checklist

Use this actionable checklist during Active Directory hardening rollouts:

1. Tier 0 isolation: Configure User Rights Assignment in GPO to deny Domain Admins from logging on locally or via RDP to Tier 1/2 systems.
2. Enforce AES-256 for Kerberos: Disable DES and RC4-HMAC encryption types for Kerberos via Group Policy (Network security: Configure encryption types allowed for Kerberos).
3. Protect high-privilege principals: Add Tier 0 administrative accounts to the Protected Users security group to prevent credential caching.
4. Require LDAP signing & channel binding: Set LDAPServerIntegrity = 2 on Domain Controllers and enforce Channel Binding Tokens (CBT).
5. Deploy Windows LAPS: Enforce rotating random local administrator passwords managed directly through Active Directory.

Sources reviewed

• Microsoft: AD DS tier model
• Microsoft: privileged access overview
• Microsoft: Windows LAPS overview
• Microsoft: Windows LAPS with Windows Server Active Directory
• Microsoft: group Managed Service Accounts overview
• Microsoft: LDAP signing and channel binding
• Microsoft: Active Directory forest recovery
• Microsoft: certificate template concepts
• Microsoft: Get-ADGroupMember
• Certipy v5 command reference
• BloodHound Cypher search documentation

Sources & freshness

How current is this note?

Sources checkedAugust 24, 2026

The latest source-review, content-update, or publication date is shown.

ReviewAuthor review complete

The author completed a technical review. This does not, by itself, claim lab reproduction.

Primary references

• learn.microsoft.com · tier-model ↗
• learn.microsoft.com · security-con…vileged-access ↗
• learn.microsoft.com · laps-overview ↗
• learn.microsoft.com · laps-scenari…tive-directory ↗
• learn.microsoft.com · group-manage…ounts-overview ↗
• learn.microsoft.com · ldap-signing ↗
• learn.microsoft.com · ad-forest-re…how-to-recover ↗
• learn.microsoft.com · certificate-…plate-concepts ↗
• learn.microsoft.com · get-adgroupmember ↗
• github.com · 08-‐-Command-Reference ↗
• bloodhound.specterops.io · cypher-search ↗