Every account in a directory is a promise about who or what may act, with which rights, and for how long. Most quiet failures inside a Windows domain are accounts that broke that promise without anyone noticing: a service account whose password three administrators typed into scripts years ago, an employee who changed departments and kept the old file share, a vendor login that nobody set to expire. Identity management, in the sense this post uses, is the discipline of deciding what kinds of accounts should exist, who or what holds each account’s secret, and who confirms that its rights are still needed.
SY0-801 objective 3.2 adds an “Identity management” group containing Group Managed Service Accounts (gMSAs), least privilege access accounts, and privilege creep, and objective 4.5 adds account types (user, privileged with global and local scope, service, third-party, and emergency access) plus a standalone access review, all of which are new in SY0-801 (CompTIA 2025). The sections below take them in that order: the gMSA and the attack it defeats, least privilege as account design and its slow failure, emergency access accounts built to survive the failure of everything else, and the access control models and recurring reviews that keep the account population honest.
Service accounts and the gMSA
A service account is an account under which a daemon, scheduled task, or application pool runs rather than a person. When a service runs under an ordinary user account, its password is one a human chose, pasted into scripts, and rarely changed, and in a Kerberos domain that password is exposed to a specific offline attack. Kerberoasting (ATT&CK T1558.003) works because any user with domain credentials can request a service ticket for any account with a registered service principal name (SPN), and part of that ticket is encrypted with a key derived from the service account’s password (Weston 2024; MITRE 2025). With the RC4-HMAC encryption type (etype 23), that key is the MD4 hash of the password, i.e., the unsalted NT hash (Jaganathan, Zhu, and Brezak 2006). The attacker holds ciphertext keyed by the password and guesses against it offline, where no lockout policy applies. Credential attacks more broadly are at T-28, and detecting suspicious ticket requests is at T-15.
A Group Managed Service Account (gMSA) is a domain account whose password is generated and rotated by the domain controllers themselves, so that no human ever knows it. A domain controller computes the password from a forest-wide Key Distribution Service (KDS) root key plus the account’s attributes; the result is 240 random bytes, and Windows changes it every 30 days by default (Microsoft 2023; Microsoft 2025b). Only the principals listed in the account’s PrincipalsAllowedToRetrieveManagedPassword attribute, usually a group of computer accounts, can retrieve the current and preceding password, and the service on those hosts logs on as CORP\svcSQL$ with a blank password because the operating system fetches the secret on its behalf. The prerequisites are Windows Server 2012 or later functional levels and a KDS root key, and domain controllers wait up to 10 hours after the root key is created before they allow gMSAs (Microsoft 2025a; Microsoft 2026d). The order of operations is the domain controller first, then each member host:
PS C:\> Add-KdsRootKey -EffectiveImmediately
PS C:\> New-ADServiceAccount -Name svcSQL -DNSHostName svcSQL.corp.example.com -PrincipalsAllowedToRetrieveManagedPassword "SQL-Hosts" -KerberosEncryptionType AES128,AES256 -ServicePrincipalNames "MSSQLSvc/sql01.corp.example.com:1433"
PS C:\> Install-ADServiceAccount -Identity svcSQL
PS C:\> Test-ADServiceAccount -Identity svcSQL
True
The rotation interval can be set only at creation, with -ManagedPasswordIntervalInDays; afterward the msDS-ManagedPasswordInterval attribute is read-only, so a different interval means a new gMSA (Microsoft 2026d). The payoff shows up in the arithmetic of the offline attack. The guess rate in the table is my assumption for illustration rather than a benchmark:
| Secret behind the ticket | Search space | Full sweep at 10^10 guesses per second |
|---|---|---|
| 8 characters, 95 printable ASCII | 95^8 ≈ 6.6 × 10^15 (52.6 bits) | About 7.7 days |
| gMSA, RC4 ticket | 2^128 RC4 key ≈ 3.4 × 10^38 | About 1.1 × 10^21 years |
Human-chosen passwords fall far sooner than a full sweep suggests, because wordlists reach them first, and the gMSA secret changes every 30 days anyway. The precise lesson: a gMSA does not stop the ticket request, which any domain user can still make; it makes offline cracking of the ticket infeasible. Where a manually managed password cannot be avoided, Microsoft’s floor is 14 characters (Weston 2024).
A gMSA is not a complete fix. Microsoft states that gMSA passwords “are still not machine bound and can be stolen” (Microsoft n.d.-a), so a compromised host in the retrieval group yields the account, and placing a gMSA in a privileged group is a listed risk (Microsoft 2023). The managed account family has three generations: the standalone MSA (sMSA) of Windows Server 2008 R2 serves one server, the gMSA of Windows Server 2012 serves many, and the delegated MSA (dMSA) of Windows Server 2025 binds authentication to the device identity instead.
Least privilege account design and privilege creep
Least privilege as a general principle is at T-36; “least privilege access accounts” in objective 3.2 names its application to account design. CompTIA does not define the term, so what follows is interpretation drawn from NIST SP 800-53 Rev. 5 and Microsoft. The pattern has four recurring parts.
- Administrators use a non-privileged account for email and web browsing and a separate privileged account for administration (NIST AC-6(2)).
- Privileged accounts are restricted to defined roles (AC-6(5)), and service accounts receive only what the service needs (ATT&CK M1026).
- Administrative credentials are used only from a privileged access workstation (PAW); Microsoft’s enterprise access model builds on the Active Directory tier model and expands Tier 0 into a control plane (Microsoft 2026e).
- Windows LAPS, built into Windows since the April 11, 2023 updates, gives each device a unique, rotated local administrator password, which blunts pass-the-hash and lateral movement between hosts (Microsoft 2026f).
Privilege creep is that design failing slowly. Rights accumulate as people change roles, cover temporary projects, or inherit membership through nested groups, and the old rights are never removed, so an account’s effective permissions drift upward without anyone deciding that they should. It is not privilege escalation, which is an attack that gains rights never granted; creep is legitimate access that has outlived its justification. NIST AC-2 requires that account managers be notified when users are “terminated or transferred” (NIST 2020), and the second word is the one that matters. When I teach this in ITN 260, I stress transfers; terminations get remembered because the person is gone, while a transfer leaves someone in the building with every group membership from the previous job.
Account types and emergency access
Objective 4.5 sorts accounts into five types, and each type has a control that fits it best. The table pairs them.
| 801 account type | Example | Control that fits |
|---|---|---|
| User | One person, interactive | Joiner, mover, and leaver provisioning |
| Privileged, Global | Domain Admins; Entra Global Administrator | Separate account, PAW, just-in-time |
| Privileged, Local | Administrator on one host | Windows LAPS |
| Service | Service, scheduled task, or app pool | gMSA or dMSA; no privileged groups |
| Third-party | Vendor, contractor, or guest | Expiry date, MFA, narrow scope, review |
| Emergency access | Break-glass when normal admin paths fail | The checklist below |
“Global” in this table means administrative scope across a domain or tenant, not the Active Directory global group scope. For a third-party account, the control that does the most work is an expiry date the directory enforces on its own: Set-ADAccountExpiration -Identity vendor.acme -TimeSpan 30.0:0 expires the account in 30 days whether or not anyone remembers that the contract ended (Microsoft n.d.-b).
Break-glass design
An emergency access account, usually called a break-glass account, exists so that administrators can still sign in when every normal administrative path has failed: the identity provider is down, a Conditional Access policy has locked out the people who wrote it, or nobody is left who can approve a role activation. CompTIA offers no definition; Microsoft’s design for Microsoft Entra ID is the most specific (Microsoft 2026c):
- Two or more accounts, cloud-only on
*.onmicrosoft.com, not federated or synchronized, and tied to no individual. - Global Administrator assigned as permanent active in PIM, not eligible.
- Phishing-resistant passwordless sign-in (a FIDO2 passkey, recommended, or certificate-based authentication) that differs from normal admin methods.
- Excluded from Conditional Access policies that block or restrict sign-in, not from every policy.
- Credentials in fireproof safes in separate, secure locations.
- An alert on every sign-in, a post-mortem after each use, and validation at least every 90 days and after IT staff changes.
Each requirement removes one dependency: cloud-only accounts do not care whether federation is working, a permanent active assignment does not care whether an approver is available, and the Conditional Access exclusion means a policy that accidentally blocks everyone still cannot block these two. Break-glass is therefore deliberately standing access rather than just-in-time, and the reason is concrete: if every Global Administrator assignment is eligible, activation requires approval, and no approvers exist, the administrators are locked out (Microsoft 2026a). T-21 shows the Conditional Access exclusion itself.
Read the word “emergency” carefully, because NIST and Microsoft attach it to different things. A NIST AC-2 emergency account is short-term and automatically disabled under AC-2(2), while a standing one is an “account of last resort” (NIST 2020), which is what Microsoft’s break-glass accounts resemble.
Access control models and policies
Account types answer what kind of account exists; access control models answer how a system decides whether an account may perform an action. Objective 4.5 lists six, and most stems can be classified by asking what the decision is based on.
| Model | Decision basis | Stem cue |
|---|---|---|
| Rule-based | A condition applied to everyone | “Deny unless the source is 203.0.113.0/24” |
| Role-based | Job function | “New AP clerks get the AP role” |
| Time-based | Clock, calendar, or expiry | “Weekdays 07:00 to 19:00 only” |
| Mandatory | Labels and clearances | “Requires a Secret clearance” |
| Discretionary | The owner grants access | “The file owner shared it” |
| Just-in-time | Eligible user activates for a bounded window | “Activate for 2 hours with approval” |
Time-based access covers any clock or calendar condition; NIST AC-2(11) describes such usage conditions as “days of the week, time of day, or specific durations of time” (NIST 2020). Just-in-time (JIT) is different in kind: the user holds an eligible assignment that grants nothing until activated, and the activation expires on its own. Microsoft Entra Privileged Identity Management (PIM) caps a just-in-time activation at a configured 1 to 24 hours and can require MFA, justification, and approval (Microsoft 2026a). Attribute-based access control (ABAC) is not among the listed models, but the list is not exhaustive: if a stem combines subject, object, and environment attributes and ABAC is offered, it still fits NIST SP 800-162 (Hu et al. 2014). If ABAC is not offered, rule-based is the nearest listed model (an inference, since CompTIA does not say).
The policies under access management split by who enforces them. Logical or technical policies are enforced by a system: a Group Policy lockout policy, a Conditional Access policy, an NTFS access control list. Administrative or business policies are enforced by people and process: the written access control policy, approval workflows, separation of duties.
Access review
Access review, also called recertification, is the recurring control that catches privilege creep after the fact. A business owner decides, entitlement by entitlement, whether each person’s access is still needed, and removals follow (NIST AC-6(7)). The owner is the right reviewer because the IAM team can see group membership but cannot see business need. Microsoft Entra access reviews add recurrence, fallback reviewers, a “No sign-in within 30 days” helper, and auto-apply (Microsoft 2026b). An illustrative record, using Entra’s setting names:
Review: FIN-Shares-Modify (corp.example.com), quarterly, 14 days, start 2026-10-01
Reviewers: Group owner (Finance director); fallback: IAM team
On completion: Auto apply results = On; If reviewers don't respond = Remove access
User HR dept Last sign-in Recommend Decision Justification
a.khan Finance 2026-09-30 Approve Approve AP clerk, daily use
m.lopez HR 2026-06-02 Deny Deny Transferred to HR 2026-05-18
r.chen Finance none Deny Deny Contract ended 2026-08-31
Sign-off: Finance director 2026-10-13; 2 removals auto-applied 2026-10-15
Row m.lopez is privilege creep in miniature: a transfer in May, a share still open in October, and no attack anywhere in the story. Row r.chen is a third-party account that should have expired itself when the contract ended and did not. The completion settings deserve a second look: with auto-apply on and “Remove access” on non-response, an ignored review revokes everyone in scope, because an owner’s silence is not evidence of need. Call the sign-off recertification rather than attestation; attestation is a distinct SY0-801 term covered at T-5 and T-4, and account auditing, which reviews the state of accounts rather than their entitlements, is at T-11.
What you need to know for SY0-801
- A static, shared, or script-embedded service password points to gMSA, not to a longer manual password.
- gMSA defeats offline cracking of a Kerberoasted ticket; it does not stop the ticket request.
- sMSA covers one server (Windows Server 2008 R2), gMSA covers many (Windows Server 2012), and dMSA is machine-bound (Windows Server 2025).
- Privilege creep is granted access that was never removed; privilege escalation is an attack. Fix creep with deprovisioning on transfer, role-based access, and access reviews.
- An IdP outage or a locked-out tenant points to emergency access; “no standing admin rights” points to just-in-time.
- Emergency access accounts are standing, cloud-only, tied to no person, excluded from blocking Conditional Access policies, and alerted on every sign-in.
- Time-based is a clock or calendar window; just-in-time is on-request activation that expires; rule-based is a condition applied to everyone.
- A third-party account gets an expiry date, MFA, narrow scope, and a place in every access review.
- Access review recertifies entitlements; account auditing (T-11) reviews account state. The sign-off is recertification, not attestation.
Check yourself
These are original practice questions, not exam items.
1. A SQL Server service account has an SPN and a password unchanged for six years that three administrators have typed into scripts. An assessment shows its service tickets can be cracked offline. Which change best addresses the finding?
- A. Set a 16-character password and rotate it manually every year.
- B. Replace the account with a gMSA that only the SQL hosts can retrieve.
- C. Move the account into Domain Admins so it falls under tiered controls.
- D. Have the administrators share one interactive admin account instead.
Answer: B. A gMSA’s password is random, rotates automatically, and is known to no administrator. A is still human-managed; C and D add privilege or remove accountability.
2. An employee moved from Finance to HR in May. In October she can still open the Finance share, and nobody has attacked anything. Which term and control fit best?
- A. Privilege escalation; patch the file server.
- B. Privilege creep; deprovision on transfer and run recurring access reviews.
- C. Mandatory access control; relabel the Finance share.
- D. Kerberoasting; enforce AES on service accounts.
Answer: B. Legitimately granted access that outlived the role is privilege creep. Escalation is an attack, which the stem rules out.
3. A federated identity provider outage locks every administrator out of a cloud tenant, and all Global Administrator roles are PIM-eligible with approval required. Which design would have preserved administrative access?
- A. One more PIM-eligible Global Administrator with a 24-hour activation window.
- B. Two cloud-only emergency access accounts with FIDO2 passkeys, permanent active assignment, and an alert on every sign-in.
- C. A synchronized Domain Admin account that signs in through the same federation.
- D. A shared Global Administrator password stored in the help desk wiki.
Answer: B. Break-glass accounts must not depend on the failed IdP or on PIM activation, which A still needs; C depends on the broken federation.
This is T-12 of the Security+ 801 Countdown: one change from SY0-701 to SY0-801 every morning until the new exam launches on November 17, 2026. Tomorrow, T-11: Authentication Modernized With Passkeys, Backup Codes, and Breach Checks. New here? Start with T-38: The Blueprint Was Reweighted and Trimmed to 27 Objectives.
References
CompTIA. 2023. CompTIA Security+ SY0-701 Certification Exam Objectives. Version 5.0.
CompTIA. 2025. CompTIA Security+ SY0-801 V8 Certification Exam Objectives. Document Version 2.0.
Hu, Vincent C., David Ferraiolo, Rick Kuhn, Adam Schnitzer, Kenneth Sandlin, Robert Miller, and Karen Scarfone. 2014. Guide to Attribute Based Access Control (ABAC) Definition and Considerations. NIST SP 800-162, updated August 2, 2019.
Jaganathan, K., L. Zhu, and J. Brezak. 2006. The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows. RFC 4757. IETF.
Microsoft. 2023. “Secure Group Managed Service Accounts.” Microsoft Learn.
Microsoft. 2025a. “Create a Key Distribution Service (KDS) Root Key.” Microsoft Learn.
Microsoft. 2025b. “Group Managed Service Accounts Overview.” Microsoft Learn.
Microsoft. 2026a. “Configure Microsoft Entra Role Settings in Privileged Identity Management.” Microsoft Learn.
Microsoft. 2026b. “Create an Access Review of Groups and Applications.” Microsoft Learn.
Microsoft. 2026c. “Manage Emergency Access Admin Accounts.” Microsoft Learn.
Microsoft. 2026d. “Manage Group Managed Service Accounts.” Microsoft Learn.
Microsoft. 2026e. “Securing Privileged Access: Enterprise Access Model.” Microsoft Learn.
Microsoft. 2026f. “Windows LAPS Overview.” Microsoft Learn.
Microsoft. n.d.-a. “Delegated Managed Service Accounts Overview.” Microsoft Learn. Accessed October 12, 2026.
Microsoft. n.d.-b. “Set-ADAccountExpiration.” PowerShell ActiveDirectory module reference. Accessed October 12, 2026.
MITRE. 2025. “Steal or Forge Kerberos Tickets: Kerberoasting.” ATT&CK Enterprise T1558.003, version 1.3.
NIST (National Institute of Standards and Technology). 2020. Security and Privacy Controls for Information Systems and Organizations. NIST SP 800-53 Rev. 5.
Weston, David. 2024. “Microsoft’s Guidance to Help Mitigate Kerberoasting.” Microsoft Security Blog, October 11, 2024.
About the author
Professor Benjamin Lamb, PhD, teaches ITN 260 Network Security Basics at Brightpoint Community College near Richmond, Virginia. Before teaching, he worked as an IT consultant in cybersecurity and risk for a Fortune 500 company. He holds Cisco’s CCNA Automation, and in August 2026 he renewed his CompTIA Network+ with a score of 855 on the 100 to 900 scale, where 720 passes. He first earned Security+ in 2021 and let it lapse in 2024; he is renewing it on SY0-801, so this countdown doubles as his own study plan, written in public.
Credentials: Credly profile. Partnership ideas, workshops, guest lectures, and training collaborations: professor@benlamb.net.

Leave a Reply