LAPS, gMSAs, and Tiered Administration: The Three Pillars of AD Defense

After years of penetrating Active Directory environments, I can say with confidence that three controls would have stopped or significantly slowed me in the vast majority of my engagements: LAPS for local admin passwords, Group Managed Service Accounts for services, and a tiered administration model for privileged access. Individually, each one removes a critical attack vector. Together, they transform an AD environment from an easy target into a genuinely difficult one.

Most organizations have heard of these controls. Some have partially implemented one or two. Almost none have deployed all three properly. Here is how to do it right.

LAPS: Ending Password Reuse Across Machines

The Local Administrator Password Solution ensures that every machine in your domain has a unique, randomly generated local administrator password. Without LAPS, organizations typically use a single local admin password across all workstations, sometimes across servers too. When I compromise one machine and extract the local admin hash from the SAM database, I can use that hash to authenticate to every other machine with the same password. This is lateral movement in its simplest form, and it works in the majority of environments I test.

LAPS solves this completely by storing a unique password for each computer in an Active Directory attribute (ms-Mcs-AdmPwd for legacy LAPS, msLAPS-Password for Windows LAPS). The password rotates automatically on a schedule you define. Even if I extract one machine's local admin password, it is useless on every other machine in the domain.

The critical implementation detail most organizations miss is the ACL configuration. By default, Domain Admins can read LAPS passwords. But I frequently find environments where the permissions have been broadened -- sometimes "Domain Users" can read every LAPS password in the domain, completely negating the control. Audit who can read LAPS passwords using the PowerShell module: Find-AdmPwdExtendedRights. Restrict read access to only the specific groups that need it for each OU. Helpdesk staff should only be able to read passwords for workstations in their scope, not for servers or domain controllers.

Deploy LAPS to every domain-joined machine without exception. I regularly find that 20-30% of machines are missing LAPS because they were provisioned outside the standard process or because the GPO was not linked to all OUs. Use PingCastle to identify machines without LAPS deployed and remediate the gaps.

Group Managed Service Accounts: Eliminating Kerberoasting

Traditional service accounts are the weakest link in most AD environments. They have static passwords that are rarely changed, those passwords are often weak enough to crack, and the accounts themselves are typically over-privileged. Kerberoasting exploits all three of these weaknesses simultaneously.

Group Managed Service Accounts eliminate the problem entirely. A gMSA's password is 240 characters of random data, managed automatically by Active Directory. It rotates every 30 days by default. No human ever knows the password, no human ever needs to type it, and no attacker can crack it. The service retrieves its password directly from AD using a secure channel.

The migration process is straightforward for most services. Create the gMSA, grant the computer account permission to retrieve its password, configure the service to run as the gMSA, and remove the old service account. Microsoft SQL Server, IIS application pools, scheduled tasks, and most modern applications support gMSAs natively. For applications that genuinely cannot support gMSAs, use long random passwords stored in a PAM vault and rotate them quarterly at minimum.

After migration, audit your domain for remaining accounts with SPNs. Any account with an SPN that is not a gMSA or a machine account is potentially vulnerable to Kerberoasting. Run Get-ADUser -Filter {ServicePrincipalName -like '*'} regularly and investigate any results. Your goal is zero human-managed accounts with SPNs.

Tiered Administration: Containing the Blast Radius

The tiered administration model, also called the Enterprise Access Model by Microsoft, is the most impactful architectural change you can make to your AD security. The concept is simple: separate your environment into three tiers based on sensitivity, and never allow credentials from a higher tier to be exposed on a lower tier.

Tier 0 is your identity infrastructure: domain controllers, AD management servers, PKI infrastructure, and Azure AD Connect servers. Tier 1 is your servers: application servers, database servers, file servers. Tier 2 is your workstations and user devices. The fundamental rule is that a Tier 0 admin account never logs into a Tier 1 or Tier 2 system, and a Tier 1 admin account never logs into a Tier 2 system.

Without tiering, a single compromised workstation can lead to Domain Admin access within hours. Here is why: an IT administrator logs into a user's workstation to troubleshoot an issue using their Domain Admin account. Their NTLM hash and Kerberos tickets are now cached on that workstation. When I compromise the workstation through phishing or any other vector, I extract those cached credentials and use them to access domain controllers directly. This attack path exists in nearly every untiered environment I test.

Implementing tiering requires separate admin accounts for each tier. Your DA-JSmith account manages Tier 0 resources only and logs in only from Privileged Access Workstations (PAWs). Your SA-JSmith account manages Tier 1 servers and logs in only from Tier 1 jump servers. Your regular JSmith account handles daily work on Tier 2 workstations. Group Policy enforces these boundaries by restricting logon rights at each tier.

Detection and Continuous Validation

Deploying these controls is not enough. You must continuously validate that they remain effective. Run BloodHound for defense regularly to identify new attack paths that may appear as your environment changes. Use PingCastle and Purple Knight quarterly to assess your overall AD security posture and track your score over time.

Monitor for violations of your tiering model. Alert on Tier 0 accounts logging into Tier 1 or Tier 2 systems (Event ID 4624 and 4625 on those machines). Watch for new service accounts with SPNs being created outside the gMSA process. Track LAPS coverage gaps as new machines are provisioned.

These three controls -- LAPS, gMSAs, and tiered administration -- represent the foundation of a defensible Active Directory environment. They are not exotic or expensive. They are built-in features of Windows that most organizations simply have not deployed. Every week you delay implementation is another week where a single compromised workstation can lead to total domain compromise.