Five Critical Active Directory Security Configurations your Sysadmins don’t know about
Locking down Active Directory doesn’t always require massive projects—sometimes it’s five overlooked defaults that make the biggest difference. In this post, I break down practical hardening wins like setting machine account quota to 0, enforcing signing/EPA across key services, handling IPv6 safely, using Protected Users for high-value accounts, and enabling Kerberos auditing so you can actually see what attackers do. Quick, actionable, and focused on reducing real-world privilege escalation and lateral movement.
CYBERSECURITY
12/15/20258 min read
1. Machine account quota (ms-DS-MachineAccountQuota) is not set to 0
First, let’s talk about what ms-DS-MachineAccountQuota (often referred to as the machine account quota) actually is. Microsoft defines it as: “The number of computer accounts that a user is allowed to create in a domain.” In simple terms, this setting controls how many computer objects an authenticated user can create by default.
Computer accounts are similar to user accounts in that they have an identity and credentials and can be used for authentication within Active Directory. The important nuance is that this is not only about “joining a machine to the domain” in the helpdesk sense—ms-DS-MachineAccountQuota can allow standard users to create a limited number of computer accounts, and in many environments the default value is 10. Put differently: it’s like giving regular users the ability to create multiple directory principals that may later be leveraged for authentication and access—something most organizations would not explicitly choose if they understood the risk.
Security implications
The security impact ranges from “quietly dangerous” to “very exploitable,” depending on how the domain is configured. On the simple end, permissive permissions or group-based access that applies to computer objects (or to groups computers commonly land in) can unintentionally grant elevated access to any newly created computer account. On the more advanced end, several Active Directory attack paths become more accessible when an attacker can create a computer object—Resource-Based Constrained Delegation (RBCD) is a commonly cited example—because computer objects can have different defaults and capabilities than standard user accounts.
Recommendation
In most environments, setting the machine account quota (ms-DS-MachineAccountQuota) to 0 is a practical hardening step because it removes the default ability for non-privileged users to create computer objects in Active Directory. IT can still create computer accounts as needed through normal administrative workflows or delegated permissions.
To set ms-DS-MachineAccountQuota to 0, follow the implementation guide here:
How to change the default MachineAccountQuota to Zero | Veeam Community Resource Hub
2. No signing enforcement for SMB/LDAP/HTTP/MSSQL (and why that matters)
In many Active Directory environments, common services still allow Windows authentication without strong integrity or “anti-relay” protections. Two concepts matter here:
Signing: protects the session against tampering (integrity).
EPA (Extended Protection for Authentication): hardens Integrated Windows Authentication (IWA)—typically NTLM (NT LAN Manager) or Kerberos—by binding authentication to the intended channel/service (commonly via channel binding tokens, CBT), which helps prevent credential relay and man-in-the-middle style abuse. EPA was introduced in Windows 7 / Windows Server 2008 R2 (initially published by Microsoft in 2009).
Why this matters: relay/reflection style attacks are still one of the fastest ways to turn a low-privilege foothold into a major incident when services accept NTLM and don’t enforce protections.
Here are two high-impact examples of privilege escalation paths that become much harder when you enforce the right controls:
ESC8 (AD CS Web Enrollment NTLM relay → potential domain compromise)
ESC8 targets Active Directory Certificate Services (AD CS) web enrollment endpoints (HTTP/S) that accept NTLM without adequate protections. Attackers relay a victim’s authentication to the web enrollment endpoint to obtain a certificate that can be leveraged for escalation. Microsoft’s guidance for mitigating AD CS NTLM relay attacks explicitly recommends enabling EPA and disabling HTTP on AD CS servers where web enrollment services are used.
CVE-2025-33073 (Windows SMB client elevation of privilege via NTLM reflection/relay behavior)
CVE-2025-33073 is a Windows SMB (Server Message Block) client elevation-of-privilege vulnerability. The primary mitigation is to apply Microsoft’s security update, but analysis of the issue highlights that exploitation is possible on machines that do not enforce SMB signing—which is exactly why SMB signing enforcement is a strong baseline hardening control (in addition to patching).
A quick map of what “signing / EPA” looks like across the services admins see most often:
SMB (Server Message Block): enforce SMB signing.
LDAP (Lightweight Directory Access Protocol): enforce LDAP signing and LDAP channel binding (CBT) using Microsoft’s rollout guidance.
HTTP (Hypertext Transfer Protocol) with IIS Windows Authentication: enable/configure EPA via IIS Windows Authentication extended protection settings.
MSSQL (Microsoft SQL Server): enable SQL Server’s Extended Protection (EPA support) for Windows-authenticated connections where applicable.
Implementation note: don’t flip everything to “enforced” in one step. Start with audit → pilot → phased enforcement, and be most cautious with LDAP signing/channel binding, since that’s where legacy apps are most likely to reveal compatibility issues.
3. IPv6 isn’t disabled (or secured) in the environment
IPv6 has been “the future” for a long time, but the reality is that many internal networks still run almost entirely on IPv4. The problem is that Windows enables IPv6 by default and prefers IPv6 over IPv4 for name resolution when both are available, which can create a quiet attack surface if nobody is actively managing or monitoring IPv6.
Security rule of thumb still applies: if you don’t use it, either disable it properly—or secure it deliberately. Leaving IPv6 enabled “just because it’s the default” is how you end up with an unmonitored pathway attackers can abuse.
Why IPv6 matters to AD security (real attack paths)
A well-known example is mitm6 (“pwning IPv4 via IPv6”), originally documented by Fox-IT. The attack abuses common default behavior in Windows networks to reply to DHCPv6, set the attacker as a victim’s DNS server, and then use tricks like WPAD to capture/relay credentials—often chaining into NTLM relay paths. If your environment isn’t intentionally using IPv6, this kind of abuse is especially dangerous because defenders often aren’t watching IPv6 traffic at all.
Implementation guidance (do this safely)
Before you “just disable IPv6 everywhere,” it’s worth knowing Microsoft’s stance: Microsoft does not recommend disabling IPv6 or unbinding it from interfaces, because some Windows components may not function. Instead, Microsoft recommends using “Prefer IPv4 over IPv6” in prefix policies when the goal is to avoid IPv6 being used by default.
A practical roadmap that keeps you out of trouble:
Step 1: Confirm whether IPv6 is actually required (apps, VPNs, direct-access-style solutions, management tooling, etc.).
Step 2 (common “low drama” hardening): Prefer IPv4 over IPv6 using Microsoft’s documented prefix policy approach.
Step 3 (if you truly do not use IPv6): Disable it in a controlled way, starting with a pilot group. Microsoft documents how to do this via the DisabledComponents registry setting and also notes the operational cautions.
If you must keep IPv6 enabled: treat it as first-class so IPv6 can’t be weaponized as an easy on-ramp.
Bottom line: don’t leave IPv6 in the “default-but-unmanaged” state. Either manage and secure it or reduce exposure deliberately using Microsoft-supported approaches.
4. High-value accounts aren’t members of the Protected Users group
High-value accounts are any Active Directory accounts whose compromise would have an outsized impact—Domain Admins, backup operators/service accounts with broad rights, Tier 0 admins, and “power” service desk accounts with permissions that let them change identities, endpoints, or security controls.
That’s exactly the kind of account the Protected Users group was built for. Microsoft describes Protected Users as “a global security group for Active Directory that's designed to protect against credential theft attacks.” It was introduced with Windows Server 2012 R2 and provides additional protections when members sign in to Windows 8.1 / Windows Server 2012 R2 or later (with the strongest restrictions requiring a Windows Server 2012 R2 domain functional level).
In practical terms, adding an account to Protected Users reduces how “stealable” that account’s credentials and sessions are:
It blocks weaker or higher-risk authentication flows for members (for example, NTLM, Digest, and default credential delegation via CredSSP on supported systems).
It limits Kerberos behavior—members’ TGTs are shorter-lived (4 hours) and cannot be renewed beyond that lifetime, and the accounts can’t be used with constrained/unconstrained delegation at the appropriate domain functional level.
It prevents caching of certain credential material on supported hosts (reducing the chance an attacker can extract reusable secrets from a compromised machine), which directly helps reduce lateral movement involving those accounts.
Implementation notes (where people get burned)
Be cautious with service accounts and any accounts tied to older systems or apps that rely on NTLM or delegation—Protected Users can absolutely break those workflows. Microsoft is explicit about the authentication restrictions and the conditions under which they apply, so plan a pilot and validate dependencies before broad rollout.
A safe approach is to start with interactive admin accounts (Domain Admins, enterprise admins, Tier 0 operators) that should never need NTLM or delegation in the first place, validate, then expand from there.
5. Kerberos auditing isn’t enabled (and you’re missing high-signal evidence)
The final setting to cover is Kerberos auditing on your domain controllers. While Active Directory will log some authentication activity by default, a lot of the most useful Kerberos visibility comes from Advanced Audit Policy subcategories that must be explicitly enabled via Group Policy. Microsoft places these under Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration → System Audit Policies.
Two subcategories to pay attention to are:
Audit Kerberos Authentication Service — logs Ticket Granting Ticket (TGT) activity (for example, Event ID 4768 when a TGT is requested/issued). Microsoft notes that these events generate based on this audit subcategory.
Audit Kerberos Service Ticket Operations — logs service ticket (TGS) activity (commonly used to trace service access patterns and spot suspicious ticket usage).
You might think this isn’t valuable if you don’t have a SIEM—and it’s true that alerting is where you get the biggest payoff. But even without a SIEM, enabling Kerberos auditing is still a win if you can centralize logs. Microsoft’s Windows Event Forwarding (WEF) is a built-in way to forward selected security events to a collector for incident detection and response. When the day comes that you’re doing incident response, these Kerberos events can be the difference between “we think they did X” and “we can prove exactly how they moved and what they touched.”
Implementation note: turning on Kerberos auditing can increase event volume on domain controllers (especially in larger environments), so size your Security log appropriately and forward what you care about. Microsoft explicitly recommends tailoring audit policy to avoid unnecessary log volume while still capturing high-value events.
And one important correction to the common claim: there is a tradeoff. Windows Event Logs do rotate/overwrite based on their configured maximum size—but if you don’t increase the log size or forward events, you can overwrite the evidence you were hoping to keep.
Wrap Up
There you have it—five critical Active Directory security settings that many sysadmins either don’t know about or tend to leave at defaults. If you made it this far, I hope you picked up at least one practical hardening change you can apply right away to reduce risk and improve your organization’s overall AD security posture.
And of course, this is only the start. There are many other configurations and operational practices that can significantly strengthen Active Directory—especially when you look at identity hygiene, tiering, privilege boundaries, and monitoring.
If you’re looking for a professional Active Directory penetration test or a security audit of your environment, reach out to us at: sales@prairielogic.net or fill out the contact form
