Active Directory
Note: These are changes to your on-premises directory. SenseOn observes the endpoints and, where configured, the domain controllers, and will detect the techniques described here. It does not configure Active Directory on your behalf. Test every change on this page in a non-production forest first, and take a verified system state backup of your domain controllers before you begin.
Active Directory is rarely the initial access point and almost always the pivot. In the cases SenseOn escalates, the pattern is consistent: a single endpoint is compromised, the attacker enumerates the directory from that endpoint, and the directory hands them a path to Domain Administrator that has usually existed for years. The controls below close the paths that recur.
Order matters here more than on other pages. Administrative tiering is the control that makes the rest meaningful, and it is also the one that takes months rather than an afternoon. Start it early, and do the cheap items alongside it.
Administrative tiering
The most common finding in a post-incident directory review is a Domain Administrator account that has logged on interactively to an ordinary workstation. Once that has happened, the credential is recoverable from that workstation, and the compromise of any single endpoint becomes the compromise of the forest.
The principle is that credentials must never be exposed to a system less trusted than the credential itself.
| Tier | Contains | May sign in to |
|---|---|---|
| Tier 0 | Domain controllers, AD Certificate Services, Entra Connect, backup infrastructure, anything that can grant Tier 0 access | Tier 0 systems only |
| Tier 1 | Servers and applications | Tier 1 and below |
| Tier 2 | User workstations | Tier 2 only |
Practical enforcement:
- Privileged Access Workstations. Tier 0 administration happens from dedicated hardened workstations that do not browse the web or read email. This is the part organisations skip, and it is the part that makes tiering real rather than aspirational.
- Deny logon rights. Use the
Deny log on locally,Deny log on through Remote Desktop Services,Deny log on as a batch jobandDeny log on as a serviceuser rights to prevent higher-tier accounts authenticating to lower-tier systems. This is the mechanism; the tier model is only a diagram without it. - Separate accounts per tier. One person, three accounts. Their day-to-day account never holds privilege.
- Protected Users group. Adding privileged accounts to Protected Users forces Kerberos AES, prevents NTLM authentication, and stops credential caching. Test carefully: it will break anything relying on delegation or on NTLM.
- Account is sensitive and cannot be delegated. Set this on every privileged account so it cannot be impersonated through a delegation path.
Microsoft's current framing is the Enterprise Access Model, which extends tiering to cloud identity. The underlying principle is unchanged.
Delegation
Kerberos delegation is the most reliably exploitable misconfiguration in most directories, and the one administrators are least likely to know they have.
- Unconstrained delegation must be removed. A server with unconstrained delegation caches the ticket-granting ticket of every account that authenticates to it, including Domain Administrators. Compromising that one server compromises the forest. Audit for it and eliminate it. The only object that should legitimately have it is the domain controller itself.
- Use resource-based constrained delegation where delegation is genuinely required. It is configured on the resource rather than the account, so control sits with the owner of the thing being accessed.
- Audit
msDS-AllowedToActOnBehalfOfOtherIdentity. Write access to this attribute on a computer object is a direct path to SYSTEM on that computer. Combined with a non-zero machine account quota, it is a well-worn escalation route.
Machine account quota
ms-DS-MachineAccountQuota defaults to 10, meaning any authenticated user can join ten computers to the domain. Creating a computer account is a prerequisite for several standard escalation techniques.
Set it to 0 on the domain object. Delegate machine join rights explicitly to the accounts and service that actually need them. This is a single attribute change with essentially no legitimate impact once join rights are delegated properly, and it is the cheapest meaningful win on this page.
Service accounts and Kerberos
Kerberoasting requires no privilege at all. Any authenticated user can request a service ticket for any account with a Service Principal Name and crack it offline, at their leisure, with no failed logons and nothing to alert on.
| Control | Detail |
|---|---|
| Use group Managed Service Accounts | gMSAs have 240-character randomly generated passwords rotated automatically by the directory. They are not crackable in any practical sense. This is the actual fix, and every service that supports a gMSA should use one. |
| Where a gMSA is impossible, use a long random password | 25 characters or more, randomly generated, stored in a password manager. Rotate it. The length is what defeats offline cracking. |
| Remove unnecessary SPNs | Audit accounts with an SPN. Many are historic, attached to services long since decommissioned. |
| Never give a service account privileged group membership | A Kerberoastable Domain Administrator is a forest compromise waiting for someone with a wordlist. This combination is common and should be treated as an emergency. |
| Disable RC4 for Kerberos | RC4 tickets crack far faster than AES. Move to AES-only encryption types, having first confirmed nothing in the estate still requires RC4. |
| Audit for accounts without Kerberos pre-authentication | The Do not require Kerberos preauthentication flag enables AS-REP roasting, which does not even need an authenticated session. There is almost never a current reason for it to be set. |
Protocol hardening
These are the protocols that turn a foothold on one workstation into credentials for another.
| Control | Why |
|---|---|
| Disable LLMNR, NBT-NS and mDNS | Name resolution fallback protocols that broadcast to the local subnet and can be answered by anyone on it. Poisoning them harvests NTLM hashes with no interaction. There is no legitimate need for them in a functioning DNS environment. Disable LLMNR by Group Policy and NBT-NS via DHCP option or per adapter. |
| Enforce SMB signing | Blocks NTLM relay over SMB. Required by default on domain controllers, and now enabled by default in more recent Windows releases, but frequently not enforced on member servers and clients. There is a performance consideration on high throughput file servers, so test rather than assume. |
| Enforce LDAP signing and channel binding | The LDAP equivalent, and the relay path to the directory itself. Enable the corresponding auditing first to find clients that will break. |
| Disable SMBv1 | Removed or off by default on supported Windows versions. Audit for it anyway, because it survives in older appliances, scanners and storage devices. |
| Restrict NTLM | Audit NTLM usage first, then progressively restrict it. Full removal is a long project in most estates, but auditing alone tells you where your legacy exposure is. NTLMv1 should be disabled outright. |
| Disable the Print Spooler on domain controllers | Unless the domain controller is genuinely a print server, which it should not be. Removes both the PrintNightmare class of vulnerability and a reliable coercion primitive. |
Active Directory Certificate Services
If you run AD CS, it is Tier 0, and it is frequently the shortest path to Domain Administrator in an otherwise well-run directory. Certificate template misconfigurations allow a low-privileged user to request a certificate that authenticates as somebody else, and the resulting access is durable across password resets for the lifetime of the certificate.
The high-priority checks:
- Templates that allow the requester to supply the subject. A template with
ENROLLEE_SUPPLIES_SUBJECTplus a client authentication EKU plus broad enrolment rights is direct impersonation of any account, including Domain Administrator. - Templates that do not require manager approval where they grant authentication capability.
- Overly broad enrolment permissions, particularly anything granted to Domain Users or Authenticated Users.
- Dangerous access control on the CA object and on template objects themselves.
- Web enrolment endpoints reachable over HTTP with NTLM authentication, which are relay targets. Apply Microsoft's certificate authentication hardening and enable Extended Protection for Authentication.
- Strong certificate mapping. Ensure the certificate-to-account mapping hardening is in enforcement mode rather than compatibility mode.
Audit with a recognised assessment tool, review the findings against Microsoft's guidance, and treat AD CS with the same care as a domain controller, because it is one.
Protect the synchronisation boundary
Where the directory is synchronised to Microsoft Entra ID, the synchronisation infrastructure is Tier 0 in both directions.
- Entra Connect servers are Tier 0. Treat them as domain controllers. The synchronisation account holds directory-wide permissions.
- Do not synchronise on-premises privileged accounts to the cloud. Filter them out. A compromise of Active Directory should not automatically become a compromise of your tenant.
- Keep cloud administrative identities cloud-only, as covered in Identity and Access.
- Password hash synchronisation is worth enabling even where federation is in use, because it allows Entra ID Protection to detect leaked credentials and provides a recovery path if the federation infrastructure is unavailable.
- If you use federation, the token signing infrastructure is Tier 0 and its certificates are the crown jewels. A stolen signing key allows an attacker to mint tokens for any identity in the tenant, and it will not appear in your on-premises logs at all.
Recovery
Assume the directory will need to be rebuilt, because in a ransomware case it usually does. Recovery capability is a security control.
- Offline or immutable backups of domain controller system state. An online backup on a domain-joined server is encrypted alongside everything else.
- A written and tested forest recovery plan. Microsoft publishes a forest recovery guide. The first time you read it should not be during an incident.
- Test the restore, not the backup. An untested backup is a hypothesis.
- Document where the recovery credentials live and confirm they are reachable when the directory is not.
See the Ransomware playbook for how SenseOn responds, and Reflex for automated containment before spread reaches this point.
Auditing and telemetry
Hardening you cannot observe is hardening you cannot verify.
- Enable the advanced audit policy rather than the legacy categories. Focus on account logon, account management, directory service access, and process creation.
- Enable command line auditing with process creation events (4688). Without it, the event tells you a process started but not what it did.
- Forward domain controller events into SenseOn through Log Ingestion. Domain controller security logs are among the highest-value sources you can connect, and the ones most often missing when we need them.
- Deploy the Universal Sensor to domain controllers. They are servers, they are targeted, and their process telemetry is where directory attacks become visible. See Endpoint Requirements.
Once the telemetry is flowing, Hunt Lab is the fastest way to check for the conditions above across the estate.
Go live checklist
- [ ] Verified system state backup of domain controllers taken before any change
- [ ] Tiering model documented, with deny logon rights enforced by Group Policy
- [ ] Privileged accounts separated from day-to-day accounts
- [ ] Privileged accounts added to Protected Users and marked as sensitive and cannot be delegated
- [ ] Unconstrained delegation audited and removed from everything except domain controllers
- [ ]
ms-DS-MachineAccountQuotaset to 0, with join rights explicitly delegated - [ ] Service accounts with SPNs audited, migrated to gMSA where supported
- [ ] No privileged group membership on any Kerberoastable account
- [ ] RC4 disabled for Kerberos, after confirming no dependency
- [ ] Accounts without Kerberos pre-authentication identified and corrected
- [ ] LLMNR, NBT-NS and mDNS disabled
- [ ] SMB signing and LDAP signing with channel binding enforced
- [ ] SMBv1 confirmed absent, NTLMv1 disabled, NTLM usage audited
- [ ] Print Spooler disabled on domain controllers
- [ ] AD CS templates and permissions reviewed, strong certificate mapping enforced
- [ ] Entra Connect treated as Tier 0, privileged accounts excluded from synchronisation
- [ ] Offline or immutable backups in place, forest recovery plan written and tested
- [ ] Advanced audit policy and command line auditing enabled, events reaching SenseOn
- [ ] Universal Sensor deployed to all domain controllers
Related pages
- Identity and Access (Microsoft Entra ID) for the cloud directory and the synchronisation boundary.
- Windows Endpoints for the endpoint controls that stop the initial foothold.
- Log Ingestion for forwarding domain controller events into SenseOn.
- Ransomware playbook and Malware playbook.
Sources
All URLs verified on 19 August 2026.
- Securing privileged access and the Enterprise Access Model
- Best practices for securing Active Directory
- Protected Users security group
- Group Managed Service Accounts overview
- Kerberos delegation
- Overview of Server Message Block signing
- Domain controller LDAP signing requirements
- Active Directory Forest Recovery Guide
- NCSC guidance on preventing lateral movement