Gatekeeping the Built-In Administrator: A Break-Glass Blueprint for the RID-500 Account

Articles · September 2026 · Ioannis (John) Konstas

1. Why the RID-500 account is the crown jewel

In most organizations, the built-in Administrator is still there, still enabled, and often still used — for a scheduled task someone set up years ago, a service that “needs admin,” or simply because it was the first account anyone knew. That makes it the single most valuable credential in the directory:

• It is predictable. Its SID is always S-1-5-21-<domain>-500. Renaming it changes the name, not the RID, so attackers and their tools find it instantly.
• It cannot be deleted. You can rename, disable, and restrict it — but it is always part of the domain.
• It holds the keys to everything. By default it is a member of Administrators, Domain Admins, Enterprise Admins, and Schema Admins in the forest root domain.
• Its credentials travel. Every interactive or RDP logon leaves reusable credential material in the memory of that machine. One logon on a compromised laptop can hand an attacker the whole forest.

The goal is not to delete it (you can’t) but to make it unusable in normal life and loud in an emergency.

2. The break-glass principle

Day-to-day administration belongs to named admin accounts, one per person, each with only the rights that person needs. The RID-500 account is reserved for one scenario: every other path into the directory has failed. Everything below follows from that rule.

3. Dual custody: the two-person rule

• Split the secret. Generate a random password of 30+ characters and split it in two. Give one half to the CISO and the other to the Director of Infrastructure. Neither can sign in alone.
• Seal the vault. Alternatively, print the full password, seal it in a tamper-evident envelope, and keep it in a safe that needs two keys or two combinations. Log every time the safe is opened.
• Reset after every use. Once the envelope is opened or the halves are combined, the password is burned. Rotate it, re-split or re-seal it, and document why it was used.

4. Harden the account itself

Find the account by its RID, whatever it has been renamed to, and check its current state:

Import-Module ActiveDirectory

# The domain SID + "-500" always identifies the built-in Administrator
$domainSid = (Get-ADDomain).DomainSID.Value
$admin = Get-ADUser -Identity "$domainSid-500" `
  -Properties Enabled, LastLogonDate, PasswordLastSet, AccountNotDelegated, SmartcardLogonRequired

$admin | Select-Object SamAccountName, Enabled, LastLogonDate, PasswordLastSet,
                  AccountNotDelegated, SmartcardLogonRequired

Set-ADUser -Identity $admin -AccountNotDelegated $true
# Optional: enforce smart-card logon (this randomizes the password)
# Set-ADUser -Identity $admin -SmartcardLogonRequired $true
# Optional, once recovery has been tested:
# Disable-ADAccount -Identity $admin

5. Tier 0 isolation and Privileged Access Workstations

• Keep it in Tier 0. Tier 0 is anything that controls identity: domain controllers, AD itself, PKI, and the systems that manage them. The RID-500 account should only ever authenticate there.
• Use a Privileged Access Workstation (PAW). A dedicated, hardened device — no email, no web browsing, no standard VPN — is the only place Tier 0 credentials are typed. If an attacker dumps the memory of a normal employee laptop, this account’s credentials are simply not there.
• Block everything else. The policies in the next section make every Tier 1 server and Tier 2 workstation refuse the account outright.

6. Deny-by-default Group Policy

Create a dedicated GPO, link it to the OUs that contain member servers and workstations — not the Domain Controllers OU — and add the account to these User Rights Assignments:

Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → User Rights Assignment

7. The kill-switch alert

If the account is vaulted and unused, any activity is either a declared emergency or an intrusion. Configure your SIEM or Microsoft Defender for Identity to raise a high-severity alert on these Security log events (collect them from the domain controllers):

SecurityEvent
| where EventID in (4624, 4625, 4648, 4722, 4724, 4738)
| where TargetSid endswith "-500"
| project TimeGenerated, Computer, EventID, Activity, TargetAccount, IpAddress, SubjectAccount

8. After the glass is broken

1. Record who opened the vault, when, and why.
2. Do only the recovery work required, from a PAW.
3. Rotate the password (or re-issue the smart card), then re-split or re-seal it.
4. Disable the account again if that is your standard state.
5. Review every alert the use generated and close them with the incident record.

9. One-page checklist

Related

• Active Directory Management: Domain Controllers, FSMO Roles, Replication, DNS & Best Practices
• PowerShell Active Directory Reference

References

• Microsoft — Appendix D: Securing Built-In Administrator Accounts in Active Directory
• Microsoft — Enterprise access model
• Microsoft — Securing devices as part of the privileged access story
• Microsoft — Microsoft Defender for Identity

Research and direction by Ioannis (John) Konstas; compiled and finalized with AI assistance.

← All articles