Kerberoasting and the Active Directory Tiered Admin Model

Start with the answer: Kerberoasting is not a software flaw. It abuses how Kerberos is designed. You stop it by making service-account passwords uncrackable and by making sure that a cracked service account is not worth much. The tiered administration model is how you do the second part.

How Kerberoasting works, in plain English

In an Active Directory domain, services such as databases and web applications are tied to an account through a service principal name. When a user wants to use the service, the domain controller hands out a service ticket that is encrypted with a key derived from that service account's password. Any authenticated user may ask for such a ticket. That is normal.

The attacker, with just an ordinary low-privilege account, asks for tickets for many service accounts, saves them and cracks them offline on their own hardware. No failed logins appear, because nothing is being guessed against your servers. If a password is short, reused or old, it falls quickly. MITRE ATT&CK describes this as technique T1558.003, Steal or Forge Kerberos Tickets: Kerberoasting, and lists it as used by many ransomware and intrusion groups.

Why service accounts are the weak spot

• They were created years ago, often by someone who left
• Their passwords are set to never expire, and people avoid changing them for fear of breaking an application
• They are often members of powerful groups because it "made it work"
• Older accounts may still allow RC4 encryption, which is much faster to crack than AES

Fix 1: make the passwords uncrackable

• Use group managed service accounts where the application supports them. Windows generates and rotates a long random password automatically, and nobody knows it
• Where it does not, set passwords of at least 25 random characters and store them in a vault
• Set supported encryption types to AES and remove RC4 where your applications allow it, testing first
• Remove unused service principal names and disable accounts that no longer run anything

Fix 2: limit what a cracked account can do

Microsoft's enterprise access model, which replaced the older three-tier idea, separates administration into planes by how much damage a compromised credential can do. The common shorthand is still tiers:

• Tier 0: domain controllers, identity systems and the accounts that manage them
• Tier 1: servers and applications
• Tier 2: user devices and standard workstations

The rule is simple. Credentials from a higher tier never sign in to a lower tier. A domain administrator does not log on to a file server or a laptop, because anything that touches that machine can steal the credential. Administrators use separate accounts for administration, from privileged access workstations, and a standard account for email and browsing. Service accounts follow the same rule: a service account for an application server has rights on that server and nothing in Tier 0.

With these in place, a cracked service account gives the attacker a foothold on one application, not the keys to the domain. The Protected Users security group adds further protection for sensitive accounts, for example by preventing the use of weaker authentication methods, though it should not be used for service accounts themselves.

Fix 3: detect it

Kerberoasting leaves traces on domain controllers. Windows logs service ticket requests as event ID 4769. Watch for:

• One account requesting tickets for many different service principal names in a short time
• Requests that ask for RC4 encryption in an environment that has moved to AES
• Service ticket requests from accounts or hosts that never made them before

Microsoft Defender for Identity and most security monitoring platforms include detections for this. You can also create honeypot service accounts with attractive names and long passwords, and alert on any request for them.

A starting checklist

• List every account with a service principal name, its group memberships, password age and encryption types
• Replace or rotate the worst ten first: highest privilege, oldest password
• Remove service accounts from Domain Admins and other Tier 0 groups unless there is a documented reason
• Separate admin accounts from daily accounts, and block administrators from signing in to lower-tier systems
• Turn on logging for Kerberos service ticket operations and test the alert

This is a good first deliverable of an Active Directory review. Our Cybersecurity team runs these assessments and helps design the tiering, and the Security category of our shop at the security section of our shop lists related services.

Sources

• Kerberoasting, MITRE ATT&CK T1558.003
• Enterprise access model (Microsoft Learn)
• Group Managed Service Accounts overview (Microsoft Learn)
• Protected Users Security Group (Microsoft Learn)

This article is general information. Test changes to service accounts and encryption types in a lab first, since they can break applications. Last reviewed November 9, 2026.

Keep reading

Next · SecurityAI Agent Bots for Back-Office Work: Where They Help and Where Humans Must ApproveAI agents can draft, sort, match and chase. They should not move money, change access or send anything irreversible without a person approving. Here is how to draw that line, with least privilege, approval tiers and audit logs.8 min read

• What a Code and Endpoint Security Review Finds in the First 24 Hours7 min
• Before Anyone Scans Your Website: Verification and Written Authorization7 min