Holding one student account in a domain with 400 service principal names, which accounts do you roast and which do you skip?

**The request is free; the crack is the budget.** An attacker holding one ordinary account can request service tickets for all 400 SPNs at negligible cost. So the interesting decision is not *what can I request* but *what is worth cracking*, because every candidate you take on consumes GPU-hours you could spend elsewhere. Good targeting is a selection function: **expected value ≈ probability the password cracks × value if it does**, and a competent operator ranks the 400 by that product rather than roasting blindly. **Discard the machine-keyed accounts immediately.** Two large groups are noise. *Computer accounts* (their names end in `$`) and *group-managed service accounts (gMSAs)* do not have human-chosen passwords — the directory generates ~120 random characters and rotates them. Their keyspace is astronomically large, so the crack probability is effectively zero. Requesting them wastes nothing, but *analyzing* them wastes your attention; a good operator filters them out before spending a single GPU-hour. **Signals that predict a crackable password.** Among the human-owned service accounts, look for the fingerprints of a password a person set and forgot: - **Age.** An account created many years ago and never touched is likely to carry a password set once, to an old standard, and never rotated. - **Naming.** Conventions like `svc_`, `sql_`, `app_`, `backup_`, or a vendor product name mark accounts that run software and were configured by a human at install time. - **No recent password change.** A password-last-set date far in the past is the single strongest 'set once, forgotten' signal. - **Group membership / rights.** Not a crackability signal but a *value* signal — see blast radius below. **Pre-authentication off as an account-age fingerprint.** The flag 'do not require Kerberos pre-authentication' is almost never chosen deliberately in a modern build. It survives from an old application or appliance that could not perform pre-authentication, switched on years ago and never switched back. So its presence does two things at once: it makes the account *AS-REP roastable* (you can pull sealed material without even holding a valid account), and — the part this leaf cares about — it **dates the account**. An account old enough to have needed that tick almost certainly carries a password from the same era: set once, to a weak standard, never rotated. Read the flag as a prediction about the password, not merely as a door. **Weight by blast radius, not just crackability.** The value half of the product is what a cracked password *reaches*. A service account whose password is reused as the local administrator on its app tier turns a single crack into control of those hosts — so it can be worth real compute even if the password is moderately hard. A service account that is a member of a privileged group is worth more still. Conversely, a low-privilege account with a crackable password may not be worth one GPU-hour. Rank by crack-probability times reach, and spend the budget from the top. **Putting it together for the 400.** Filter out the `$` computer accounts and the gMSAs. Sort the human-owned remainder by password-last-set age, pull the pre-auth-off accounts to the front as likely-weak legacy, and re-weight the whole list by privilege and known password reuse. You will find that of 400 SPNs, a dozen or two are worth cracking — and one of those, if its password doubles as a local-admin credential, is the whole game.