Active Directory Security Hardening: Move Beyond Default Settings Before Attackers Do

Most health care organizations deployed Active Directory years ago, configured the basics, and moved on. The domain is running. Users can log in. Group Policy applies. That's good enough, right?

It isn't. And if your organization has survived this long without a serious Active Directory compromise, the honest answer is probably a combination of decent perimeter security, some good fortune, and attackers who haven't decided you're worth the effort yet. All three of those things are finite.

Before you work through the controls in this article, do one thing first: download and run through the HIPAA Endpoint Security Posture Checklist if you haven't already. That checklist is your workstation and server baseline - unique credentials, no local admin rights for standard users, endpoint protection in place. This article assumes that foundation is solid and takes you to the next level: the domain itself. The two pieces work together, and neither replaces the other.

The five controls covered here - administrative tier model, Windows LAPS, Protected Users group, Kerberos delegation controls, and AdminSDHolder hardening - map directly to three HIPAA technical safeguard requirements under 45 CFR Part 164. Specifically:

• 45 CFR 164.312(a)(1) - Access Control (Standard): Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as specified in 164.308(a)(4).
• 45 CFR 164.312(a)(2)(i) - Unique User Identification (Required): Assign a unique name and/or number for identifying and tracking user identity.
• 45 CFR 164.312(a)(2)(ii) - Emergency Access Procedure (Required): Establish and implement as needed procedures for obtaining necessary electronic protected health information during an emergency.

Every section in this article will connect back to at least one of those three. This isn't compliance theater - these are the actual technical mechanisms that the regulation is pointing at. Get the controls right and the compliance documentation writes itself. Each step includes GPO and PowerShell implementation guidance that a solo IT person or a small team can execute without taking down the domain.

Why Default Active Directory Is Still a Liability in Health Care

Walk into almost any health care organization that's been running Active Directory for more than five years and you'll find the same pattern: Domain Admins that include service accounts and help desk staff, a local Administrator account with the same password on every workstation, privileged users who log into clinical workstations with their admin credentials to deploy software, and no audit trail that would tell you whether any of that has been exploited.

That pattern exists not because anyone made a deliberate bad decision, but because the defaults were permissive and there was always something more urgent on the list. In health care specifically, the "something more urgent" list never gets shorter.

The problem is that modern ransomware operators and their affiliates know exactly what that environment looks like because they have hit hundreds of organizations that match the profile. The playbook is well-documented at this point: phish a user, escalate to local admin (easy if the local admin password is the same everywhere), move laterally to a workstation where a Domain Admin has recently logged in, harvest credentials from LSASS, and own the domain in hours. The presence of electronic protected health information (ePHI) makes health care organizations targets for both ransom and data exfiltration.

The HIPAA access control standard at 45 CFR 164.312(a)(1) requires covered entities and business associates to implement technical policies and procedures allowing access only to those persons or software programs that have been granted access rights. Shared local administrator passwords, over-privileged Domain Admin accounts, and accounts that traverse trust boundaries without appropriate controls are not consistent with that requirement, regardless of how the risk analysis frames it.

If your Domain Admins are logging on to workstations - not just domain controllers and management hosts - you are already exposed. That is the starting assumption for everything that follows. The goal of this article is to reduce the blast radius when a credential is compromised, because a credential will be compromised. That is not alarmism. It is the realistic posture for any organization operating in the current threat environment.

Section 1: Implement the Administrative Tier Model

The administrative tier model - sometimes called tiered administration - is the single highest-leverage change most health care AD environments can make. It is not complicated in concept. The execution requires discipline and a few hours of GPO work.

The model divides your environment into three tiers based on the blast radius if that tier is compromised:

Tier 0 includes domain controllers, the Active Directory infrastructure itself, certificate authorities, identity federation servers, and any system that can directly manipulate the AD database. Compromise of Tier 0 is full domain compromise. Full stop.

Tier 1 includes member servers - file servers, application servers, management infrastructure, your EMR/EHR application servers, database servers. Compromise of Tier 1 gives an attacker access to server-tier data and the ability to pivot, but does not by itself hand them the entire domain.

Tier 2 includes workstations, end-user devices, and standard user accounts. This is where most attacks start.

The rule is simple: credentials that administer Tier 0 must never touch Tier 1 or Tier 2 systems. Credentials that administer Tier 1 must never touch Tier 2 systems. A Domain Admin account that logs into workstations violates this rule and eliminates the protection the model provides.

Starting the inventory

Before you can enforce tier separation, you need to know what's in each tier. Run this in PowerShell to get a starting list of accounts with Domain Admin rights:

Get-ADGroupMember -Identity "Domain Admins" -Recursive | 
    Where-Object { $_.objectClass -eq "user" } | 
    Select-Object Name, SamAccountName, DistinguishedName | 
    Export-Csv -Path "C:\Temp\DomainAdmins_$($(Get-Date -Format 'yyyyMMdd')).csv" -NoTypeInformation

Review that list carefully. Service accounts in Domain Admins are a common finding and almost always unnecessary. Each one is a potential path to full domain compromise if the service account's password is weak or exposed.

Enforcing tier separation via GPO

Create two GPOs - one for Tier 0 systems (domain controllers and management hosts) and one for Tier 1 systems (member servers). In each GPO, configure the following under Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment:

For Tier 0 GPO, under "Deny log on locally," "Deny log on through Remote Desktop Services," and "Deny access to this computer from the network," add your Tier 1 and Tier 2 admin groups. Mirror this pattern in your Tier 1 GPO to deny Tier 2 credentials. For more complete separation, also configure "Deny log on as a batch job" and "Deny log on as a service" for the same groups - this closes the path attackers use when they compromise a service account credential and attempt to register it as a scheduled task or service on a higher-tier system.

The intent is that a compromised workstation-tier credential cannot be used to authenticate to a domain controller or server - even if the attacker has the credential. The logon is denied at the domain level before it can succeed.

Privileged Access Workstations

Tier 0 and ideally Tier 1 administration should be performed from dedicated Privileged Access Workstations (PAWs). In a small environment, a PAW can be a hardened VM on a management host that is isolated from the production network - not a physical workstation reserved for one person. The key is that Domain Admin credentials never authenticate to a general-purpose machine that has a browser, email client, and access to user shares.

For a 25-bed Critical Access Hospital with one IT person, a practical minimum is a dedicated management VM that is not used for anything except AD administration, GPO management, and server maintenance. That single step significantly reduces the attack surface.

This control directly supports the unique user identification requirement at 45 CFR 164.312(a)(2)(i) by ensuring privileged actions are performed under purpose-specific accounts that cannot be confused with standard user activity.

Section 2: Deploy Windows LAPS

If every workstation in your domain has the same local Administrator password - or a predictable variation of it - a single compromised credential gives an attacker local admin access to every machine on your network. That is how ransomware moves at speed.

Windows LAPS (Local Administrator Password Solution) solves this by automatically generating, rotating, and storing unique local administrator passwords for each machine in Active Directory. It is built into Windows natively as of April 2023 updates for Windows Server 2019, Windows Server 2022, Windows Server 2025, Windows 11, and Windows 10. The legacy MSI-based LAPS product is deprecated on Windows 11 23H2 and later - if you are still running the old MSI deployment, planning a migration to native Windows LAPS should be on your near-term list. Documentation from Microsoft Learn is at https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview.

Schema extension and GPO deployment

Windows LAPS requires an AD schema update before policies will apply. This is a one-time, forest-wide operation - run it once from the Schema Master and it applies across all domains in the forest. Run this from an account with Schema Admin rights:

# Extend the schema
Update-LapsADSchema -Verbose

# Verify the schema attributes are present
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext `
    -LDAPFilter "(name=ms-LAPS*)" -Properties name, adminDescription | 
    Select-Object name, adminDescription

Once the schema is extended, create a GPO and link it to your workstations OU (and server OUs once you're confident in the rollout). Navigate to Computer Configuration > Administrative Templates > System > LAPS and configure:

• Configure password backup directory: Set to Active Directory
• Password Settings: Enable, set complexity to Large letters + small letters + numbers + specials, minimum 15 characters, age no more than 30 days
• Configure authorized password decryptors: Add the specific security group that should have password retrieval rights - not Domain Admins as a whole

ACL hardening

By default, computer accounts have write access to their own LAPS attributes, which is necessary for the rotation to work. What you do not want is broad read access to the password attributes. Create a dedicated security group - something like "LAPS Password Readers" - and grant that group explicit read access to the msLAPS-Password and msLAPS-EncryptedPassword attributes on your LAPS-managed OUs. Use the Set-LapsADComputerSelfPermission and Set-LapsADReadPasswordPermission cmdlets to manage this cleanly:

# Grant computers permission to update their own LAPS password attributes
$OU = "OU=Workstations,DC=yourdomain,DC=local"
Set-LapsADComputerSelfPermission -Identity $OU

# Grant a specific group read access to LAPS passwords on an OU
$ReaderGroup = "LAPS Password Readers"
Set-LapsADReadPasswordPermission -Identity $OU -AllowedPrincipals $ReaderGroup

Retrieving passwords

Authorized administrators can retrieve LAPS passwords via:

Get-LapsADPassword -Identity "COMPUTERNAME" -AsPlainText

You can also retrieve passwords through Active Directory Users and Computers if the RSAT tools are current, or through the LAPS UI tool.

This control directly supports 45 CFR 164.312(a)(2)(i) (unique user identification) by ensuring every machine has a distinct local credential that can be individually audited, and it supports 45 CFR 164.312(a)(2)(ii) (emergency access procedure) because a local administrator password is often the break-glass path when domain authentication is unavailable. Document that path in your emergency access policy.

Section 3: Lock Down with Protected Users and Kerberos Controls

The Protected Users security group is one of the most underutilized controls in Active Directory. It was introduced with Windows Server 2012 R2 and requires a domain functional level of Windows Server 2012 R2 or higher to enforce the domain controller-side protections. If you are still running an older domain functional level, that is worth addressing on its own.

When a user is a member of Protected Users, Active Directory automatically enforces a set of non-configurable protections. These are not GPO settings that can be misconfigured or overridden. When an account is in the group, the protections apply on every authentication:

• NTLM authentication is blocked for the account. The account must use Kerberos.
• DES and RC4 encryption types are blocked in Kerberos preauthentication. AES is required.
• Kerberos credentials are not cached after the initial TGT is acquired. Long-term keys and plaintext credentials are not stored in memory.
• The Kerberos TGT lifetime is capped at four hours and cannot be renewed. The user must reauthenticate after four hours.
• Unconstrained and constrained Kerberos delegation is blocked for the account.

For a Domain Admin or other Tier 0 account, every one of those protections matters. Blocking NTLM authentication prevents pass-the-hash attacks. Blocking RC4 closes a common Kerberoasting attack path. Preventing credential caching means that even if a workstation is compromised, the Protected User's credentials are not sitting in LSASS memory waiting to be harvested.

Adding privileged accounts to Protected Users

# Add a specific admin account
Add-ADGroupMember -Identity "Protected Users" -Members "adminAccountName"

# Verify membership
Get-ADGroupMember -Identity "Protected Users" | Select-Object Name, SamAccountName

Important caveats before you start adding accounts:

Do not add service accounts. Service accounts that rely on delegation, NTLM authentication, or long-running Kerberos sessions will break when added to Protected Users. This is by design - those are exactly the conditions the group is protecting against - but adding the wrong account will cause immediate service disruption.

Do not add the built-in Administrator account (the default SID -500 account) without testing. That account may be relied on in break-glass procedures. Add your named administrative accounts first.

Test with a single non-critical admin account and verify authentication is working over a full business day before adding additional accounts.

Auditing and removing Kerberos unconstrained delegation

Unconstrained delegation is a configuration that allows a service to impersonate any user who authenticates to it - including Domain Admins. It was a common configuration in older environments and is now considered a significant risk. Run this to find accounts and computers with unconstrained delegation configured:

# Find user accounts with unconstrained delegation
Get-ADUser -Filter { TrustedForDelegation -eq $true } -Properties TrustedForDelegation | 
    Select-Object Name, SamAccountName, DistinguishedName

# Find computer accounts with unconstrained delegation (beyond domain controllers, which require it)
Get-ADComputer -Filter { TrustedForDelegation -eq $true } -Properties TrustedForDelegation | 
    Select-Object Name, DNSHostName, DistinguishedName

Domain controllers will appear in the computer results - that is expected and should not be changed. Any other computer or user account with unconstrained delegation configured should be reviewed. In most cases, the delegation is no longer necessary and can be removed. To remove unconstrained delegation from a computer account:

Set-ADComputer -Identity "SERVERNAME" -TrustedForDelegation $false

These controls are directly connected to 45 CFR 164.312(a)(1) - the access control standard. An account that can be impersonated via unconstrained delegation, or whose credentials can be extracted from a compromised host via NTLM relay or Kerberoasting, does not have meaningful access control in any practical sense.

Section 4: Secure AdminSDHolder and SDProp

This is the control that most health care IT teams have never heard of, and it is one that attackers specifically know about.

AdminSDHolder is a special container object in Active Directory that holds the permissions template for protected privileged groups - Domain Admins, Schema Admins, Enterprise Admins, Account Operators, and several others. Every 60 minutes by default, a process called SDProp (Security Descriptor Propagator) runs on the PDC Emulator domain controller and compares the ACL on each member of those privileged groups against the AdminSDHolder template. If they don't match, SDProp overwrites the member's ACL with the AdminSDHolder template.

Why does this matter for security? Because attackers who achieve Domain Admin access frequently use AdminSDHolder as a persistence mechanism. By adding a backdoor account to the AdminSDHolder ACL with elevated rights, they ensure that SDProp will propagate those rights to every protected group member every 60 minutes - even after the obvious access is removed. An incident response team that cleans up visible access but misses the AdminSDHolder modification will find that access comes back within the hour.

Reviewing current AdminSDHolder permissions

# Get the current ACL on AdminSDHolder
$AdminSDHolder = Get-ADObject -Filter { name -eq "AdminSDHolder" } -SearchBase (Get-ADDomain).SystemsContainer
$ACL = Get-Acl -Path ("AD:\" + $AdminSDHolder.DistinguishedName)
$ACL.Access | 
    Where-Object { $_.AccessControlType -eq "Allow" } | 
    Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType | 
    Sort-Object IdentityReference | 
    Format-Table -AutoSize

Review that output carefully. You should see the well-known built-in security principals (Domain Admins, Enterprise Admins, System, SELF). Any unfamiliar account or group in that ACL is a red flag and should be investigated. Document the expected baseline so that deviations are immediately identifiable.

Monitoring for AdminSDHolder changes

Enable auditing on the AdminSDHolder object itself. An audit entry on AdminSDHolder changes means someone is either doing legitimate security maintenance or attempting to establish persistence. Either way, you want to know.

Configure this via the Security Settings > Advanced Audit Policy Configuration in Group Policy, specifically enabling object access auditing for the AdminSDHolder object. In environments running a SIEM or log aggregation tool, create an alert for Event ID 5136 (A directory service object was modified) where the object name contains "AdminSDHolder."

For environments without a SIEM, a scheduled PowerShell script that exports and compares the AdminSDHolder ACL daily, sending email on changes, provides a reasonable detective control:

$AdminSDHolder = Get-ADObject -Filter { name -eq "AdminSDHolder" } -SearchBase (Get-ADDomain).SystemsContainer
$ACL = Get-Acl -Path ("AD:\" + $AdminSDHolder.DistinguishedName)
$CurrentACL = $ACL.Access | 
    Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType | 
    Sort-Object IdentityReference

$BaselinePath = "C:\AdminSDHolder_Baseline.csv"
$CurrentPath  = "C:\AdminSDHolder_Current_$($(Get-Date -Format 'yyyyMMdd')).csv"

$CurrentACL | Export-Csv -Path $CurrentPath -NoTypeInformation

if (Test-Path $BaselinePath) {
    $Baseline = Import-Csv $BaselinePath
    $Diff = Compare-Object -ReferenceObject $Baseline -DifferenceObject $CurrentACL -Property IdentityReference, ActiveDirectoryRights

    if ($Diff) {
        Write-Host "ALERT: AdminSDHolder ACL changes detected!"
        $Diff | Format-Table -AutoSize
        # Add your email or alerting logic here
    } else {
        Write-Host "AdminSDHolder ACL matches baseline - no changes detected."
    }
} else {
    Write-Host "No baseline found.  Saving current ACL as baseline."
    $CurrentACL | Export-Csv -Path $BaselinePath -NoTypeInformation
}

Run that script on a schedule from your PDC Emulator or a management host. The first run creates the baseline. Every subsequent run compares against it.

AdminSDHolder hardening connects to 45 CFR 164.312(a)(1) - maintaining technical controls that ensure access rights are actually what the organization intends them to be. An AdminSDHolder backdoor is specifically a mechanism for overriding intended access controls, which is precisely what the regulation addresses.

Section 5: Putting It All Together - Phased Implementation Roadmap

Doing all of this at once in a production environment is not realistic for most health care IT teams. Here is a four-week rollout that sequences the work sensibly and gives you time to validate each step before moving to the next.

Week 1: Inventory and Baseline

• Run the Domain Admins audit. Document every account with Domain Admin rights and confirm each one should have it.
• Run the unconstrained delegation audit. Document everything that comes back and flag any non-DC results for review.
• Pull the AdminSDHolder ACL and save it as your baseline. If anything in that ACL looks unexpected, investigate before proceeding.
• Identify a management workstation or VM that will serve as your PAW for AD administration going forward.

Week 2: Windows LAPS

• Extend the schema and deploy LAPS GPO to a pilot OU (a lab machine or a small non-clinical OU).
• Confirm passwords are being generated, stored, and retrievable.
• Set up your LAPS Password Readers security group and confirm ACL restrictions are working.
• Expand LAPS deployment to workstation OUs, then server OUs.
• Document the emergency access procedure for LAPS password retrieval in your HIPAA emergency access policy.

Week 3: Tier Separation GPOs

• Create the Tier 0 denial GPO. Test it against domain controllers in a lab or maintenance window.
• Create the Tier 1 denial GPO. Test against a non-critical member server first.
• Communicate with your team. If someone has been using their Domain Admin account to RDP to workstations, that will break. Coordinate before it breaks in production.
• Remove service accounts from Domain Admins and assign least-privilege service account permissions where needed.

Week 4: Protected Users and Kerberos Cleanup

• Add one or two named admin accounts to Protected Users. Monitor for authentication issues over 24-48 hours before adding more.
• Remove unconstrained delegation from any non-DC systems where it was found in Week 1.
• Set up the AdminSDHolder monitoring script and schedule it via Task Scheduler on your PDC Emulator.

Throughout all four weeks, document what you're doing and why. HIPAA's risk analysis and risk management requirements under 45 CFR 164.308(a)(1) are supported by documented decisions. "We implemented tiered administration to address the risk of privileged credential theft" is a real entry in a risk management log that auditors and OCR investigators recognize as meaningful. "AD is configured" is not.

Conclusion

The five controls in this article - tiered administration, Windows LAPS, Protected Users, Kerberos delegation cleanup, and AdminSDHolder hardening - are where most health care Active Directory environments still have 10-to-15-year-old defaults running. They are not the most visible security controls. They do not show up on a dashboard. But they are exactly the gaps that attackers exploit when they decide a health care organization is worth their time.

Each one maps directly to HIPAA's technical safeguard requirements. 45 CFR 164.312(a)(1) demands meaningful access control - not just a policy that says access is controlled. 45 CFR 164.312(a)(2)(i) requires unique user identification that you can actually trace. 45 CFR 164.312(a)(2)(ii) requires a documented emergency access path. These controls deliver all three in a way that holds up under both an audit and an incident response investigation.

Pair this AD hardening with the full endpoint baseline in the HIPAA Endpoint Security Posture Checklist. Together, the two close the gaps that most attackers use to move from a phishing email to a domain controller.

Start this week. The Tier 0 inventory and the Windows LAPS schema extension are both non-disruptive and can be done in an hour. Everything else builds from there.

This article is for informational purposes only and does not constitute legal or compliance advice. Covered entities and business associates should consult qualified legal counsel or compliance professionals before making decisions pertaining to HIPAA or IT infrastructure.