Privileged Access Management

Why privileged accounts are the target

A privileged account can change who has access, read every mailbox, turn off logging and create new accounts. Once attackers hold one, they no longer need to break anything: they simply use the account, and their actions look like normal administration. That is why almost every serious intrusion ends with a privileged account, whatever way in the attacker used first.

The basic ideas — separate accounts, vaulting, just-in-time access, session recording — are introduced under privileged access management in the Security topic. This page goes deeper into how they are built in a Windows and Microsoft Entra environment. Privileged accounts come in several kinds:

• Directory administrators: members of Domain Admins, Enterprise Admins, Schema Admins and the built-in Administrators group in Active Directory (AD); holders of Global Administrator and Privileged Role Administrator in Microsoft Entra ID.
• Server and application administrators: local administrators of servers, database administrators, Exchange or SharePoint administrators.
• Local administrator accounts on every workstation and server.
• Non-human accounts with wide rights: service accounts, synchronization accounts and applications with powerful API permissions (see Identity for Applications and Machines).

Attackers reach these accounts by stealing credentials from memory on a machine where an admin signed in (MITRE ATT&CK T1003.001, LSASS memory), by reusing a password hash (T1550.002, pass-the-hash), or by taking over a cloud account that lacked strong MFA (T1078.004, valid cloud accounts). The defenses on this page all aim at the same three things: fewer privileged accounts, less time with privilege, and fewer places where privileged credentials are ever typed. How the attacks work and how to detect them is on Attacks on Identity.

Separate admin accounts

The first rule costs nothing: an administrator has two accounts. The daily account reads email, browses the web, joins meetings and has no administrative rights. The admin account is used only for administration, and only on machines meant for it.

The point of having no mailbox is not tidiness. Phishing arrives by email; a malicious attachment opened by an admin account runs with admin rights. An account that cannot receive email cannot be phished that way. Microsoft also recommends that accounts holding Entra admin roles are cloud-only: if a synchronized AD account is a Global Administrator, an attacker who takes over on-premises AD can take over the cloud tenant too.

Knowing who holds privilege is the starting point. In AD, the ActiveDirectory PowerShell module lists the effective members of a group, including members of nested groups (there is no domain controller here, so this block is not run):

Get-ADGroupMember -Identity "Domain Admins" -Recursive |
    Select-Object Name, SamAccountName, objectClass

Name               SamAccountName     objectClass
----               --------------     -----------
Administrator      Administrator      user
adm0-identity1     adm0-identity1     user
adm0-identity2     adm0-identity2     user
svc-backup         svc-backup         user

Here the review question is svc-backup: a backup service account in Domain Admins is a common finding, and a dangerous one, because its password is often old, known to several people and stored in a backup console. Enterprise Admins and Schema Admins are usually kept empty until someone needs them for a specific change.

The tiering model

Separate accounts are not enough if the admin account still signs in everywhere. When an admin signs in to a computer interactively, or over Remote Desktop, credential material for that account is kept in memory on that computer. If the computer is compromised, so is the account. The tiering model (Microsoft's classic AD administrative tier model) groups systems by how much control they give, and keeps the credentials of each tier inside that tier.

Tier 0, tier 1 and tier 2

• Tier 0 holds everything that controls identity for the whole organization: domain controllers, the AD forest itself, Entra Connect or Cloud Sync servers, AD Certificate Services, the accounts and groups that administer them, and anything that can control those machines (such as the virtualization hosts or backup systems that hold domain controllers). Whoever controls any tier 0 asset controls everything.
• Tier 1: servers and applications — database servers, file servers, business applications and their administrators.
• Tier 2: workstations, laptops and user devices, and the service desk accounts that support them.

Two rules follow. Control flows down only: a lower tier never gets rights over a higher tier (a service desk account must not be able to reset a Domain Admin's password). And never log on downward: a tier 0 account never signs in to a tier 1 server or a tier 2 laptop, because those machines are easier to compromise. Each tier has its own admin accounts; one person may hold an account in two tiers.

In AD the logon restrictions are enforced with user rights assignments in Group Policy (for example, "Deny log on locally" and "Deny log on through Remote Desktop Services" for tier 0 groups on every workstation), and more strongly with authentication policies and silos, which limit where an account may obtain Kerberos tickets. The rule is easy to check against sign-in data. This sketch compares each sign-in with the tier of the account and the tier of the host:

# Flag sign-ins where an account from a higher tier logs on to a lower-tier host.
ACCOUNT_TIER = {
    "adm0-identity1": 0,  # tier 0 admin: domain controllers, Entra Connect
    "adm1-dba1": 1,       # tier 1 admin: database servers
    "adm2-desk1": 2,      # tier 2 admin: workstations (service desk)
}
HOST_TIER = {"DC01": 0, "SYNC01": 0, "SQL01": 1, "APP01": 1, "PC-FIN-01": 2, "PC-HR-07": 2}

SIGN_INS = [
    ("adm0-identity1", "DC01"),
    ("adm0-identity1", "PC-HR-07"),
    ("adm1-dba1", "SQL01"),
    ("adm1-dba1", "PC-FIN-01"),
    ("adm2-desk1", "PC-FIN-01"),
    ("adm2-desk1", "SQL01"),
]

for account, host in SIGN_INS:
    a, h = ACCOUNT_TIER[account], HOST_TIER[host]
    if a < h:
        verdict = f"VIOLATION: tier {a} credential exposed on tier {h} host"
    elif a > h:
        verdict = f"DENY: tier {a} account may not manage tier {h}"
    else:
        verdict = "ok"
    print(f"{account:15} -> {host:10} {verdict}")

adm0-identity1  -> DC01       ok
adm0-identity1  -> PC-HR-07   VIOLATION: tier 0 credential exposed on tier 2 host
adm1-dba1       -> SQL01      ok
adm1-dba1       -> PC-FIN-01  VIOLATION: tier 1 credential exposed on tier 2 host
adm2-desk1      -> PC-FIN-01  ok
adm2-desk1      -> SQL01      DENY: tier 2 account may not manage tier 1

Tier numbers go up as privilege goes down, so a < h means "a more powerful account on a less protected machine". The typical real-world violation is the second line: a domain admin who "just quickly" fixes a user's laptop with the admin account.

The Enterprise Access Model

The tier model was designed for an on-premises AD world. Microsoft now describes privileged access with the Enterprise Access Model, which grew out of it and also covers cloud services. As of 2026 Microsoft's documentation maps it like this:

The core idea is unchanged: protect the control plane most strongly and never let a less trusted system hold the keys to a more trusted one. If you read "tier 0" in an older design document, think "control plane".

Just-in-time access

An account that is an administrator all the time is a target all the time, even at night and on holidays. Just-in-time access (JIT) removes such standing privilege: administrators hold no admin rights by default, request them when they have a task, and lose them automatically after a set time. An attacker who steals the account outside that window gets an ordinary account.

Entra Privileged Identity Management

In Microsoft Entra, JIT is provided by Privileged Identity Management (PIM). It works for Entra roles (such as Global Administrator or User Administrator), for Azure resource roles (such as Owner of a subscription) and, through PIM for Groups, for membership of groups that grant access. It requires Microsoft Entra ID P2 or Microsoft Entra ID Governance licensing. PIM distinguishes two kinds of assignment:

• Eligible: the person may activate the role, but does not have it now. This is the normal state for administrators.
• Active: the person has the role now — either after activation, or because an administrator assigned it as active. Active assignments can be permanent or time-bound; permanent active assignments should be rare (break-glass accounts are the classic exception).

Activation is governed by role settings that the identity team configures per role:

• Maximum activation duration: for example 4 hours for Global Administrator; the role disappears when the time runs out.
• Require MFA on activation, or a conditional access authentication context that demands phishing-resistant MFA (see Conditional Access and Zero Trust).
• Require justification, and optionally a ticket number, so the reason ends up in the audit history.
• Require approval: one or more approvers must accept the request before the role becomes active.
• Notifications: email to administrators, approvers and the requester when a role is assigned or activated.

Eligible assignments themselves can expire, and PIM can run access reviews on role assignments, so that "eligible forever" does not quietly become the new standing privilege. Every activation is written to the PIM audit history and the Entra audit log.

Privileged access workstations

A system can be no more secure than the device used to manage it — Microsoft calls this the clean source principle. If a Global Administrator activates the role on a laptop that also browses the web and opens attachments, malware on that laptop can take over the session or steal the token. A privileged access workstation (PAW) is a dedicated, hardened device used only for administration:

• No email client, no general web browsing; only the admin tools and the admin portals it needs.
• Application control (only approved programs run), full-disk encryption, Secure Boot, and patches applied quickly.
• Managed by the tier it serves — a tier 0 PAW is itself a tier 0 asset — and known to conditional access as a compliant device, so that admin portals can require it.

A full separate laptop per admin is the strongest form. Lighter forms exist — a hardened virtual machine on a secured host, or a jump server that admins reach from their PAW — but every step away from a dedicated clean device adds a place where credentials can be exposed.

Local administrators and protected accounts

Windows LAPS

Every Windows machine has a built-in local Administrator account. When all machines are installed from the same image, they often share the same local password. An attacker who captures it on one machine — or its hash — can sign in to all the others. LAPS (Local Administrator Password Solution) gives each computer its own random local administrator password, rotates it on a schedule and stores it in the directory, where only authorized groups can read it.

• Windows LAPS is built into Windows since the 11 April 2023 updates (Windows 10, Windows 11, Windows Server 2019 and 2022) and is native in Windows 11 23H2 and Windows Server 2025.
• It backs up the password to either AD or Microsoft Entra ID (not both); Entra support has been generally available since October 2023. In AD the password can be encrypted so that only a chosen group can decrypt it.
• On domain controllers it can manage the Directory Services Restore Mode (DSRM) password.
• The legacy Microsoft LAPS (the 2016 MSI) is deprecated from Windows 11 23H2, and newer Windows versions block its installer. An emulation mode exists to help migrate.

A service desk analyst with read rights retrieves a password with the LAPS PowerShell module that ships with Windows (not run here):

Get-LapsADPassword -Identity PC-FIN-01

ComputerName        : PC-FIN-01
DistinguishedName   : CN=PC-FIN-01,OU=Workstations,DC=ad,DC=example,DC=com
Account             : Administrator
Password            : System.Security.SecureString
PasswordUpdateTime  : 9/14/2026 3:12:05 AM
ExpirationTimestamp : 10/14/2026 3:12:05 AM
Source              : EncryptedPassword
DecryptionStatus    : Success
AuthorizedDecryptor : AD\LAPS-Readers-Tier2

The password stays a SecureString unless you add -AsPlainText. Every retrieval can be audited, and by default Windows LAPS resets the password and signs the account out 24 hours after it has been used (the delay and action, including reset and reboot, are configurable), so a password read for one repair does not stay valid for weeks. Read rights follow the tiers: the tier 2 service desk group may read workstation passwords, never those of servers or domain controllers.

Protected Users

Privileged AD accounts belong in the Protected Users group (explained on Users, Groups and Computers). At domain functional level 2012 R2 or higher its members cannot use NTLM, cannot use DES or RC4 in Kerberos preauthentication, cannot be delegated, and get ticket-granting tickets limited to 4 hours. That removes several ways of reusing a stolen credential (see Kerberos and NTLM). Test first: service accounts and anything that still needs NTLM break when added.

Break-glass accounts

Strict controls can lock everyone out: a conditional access policy with a mistake, an outage of the MFA service, a federation server that is down, or the only Global Administrator leaving. A break-glass account (Microsoft calls it an emergency access account) is an account with the highest privileges, kept for exactly those situations and used for nothing else. Microsoft's guidance and common practice:

• Two or more, so that one lost key or one broken account does not leave you with none.
• Cloud-only and permanently assigned the Global Administrator role; not synchronized from AD and not federated, so an on-premises outage cannot affect them.
• Excluded from conditional access policies (or at least from the ones that could lock them out), so a broken policy cannot block them. They are still subject to Microsoft's mandatory MFA for the admin portals, so they need a strong method of their own: a passkey on a FIDO2 security key (Microsoft's recommendation) or certificate-based authentication, different from the methods the normal admin accounts use, kept in fireproof safes in separate locations.
• Monitored: an alert fires on every sign-in, because a legitimate use is rare and always planned or an emergency. The alert goes to several people, not only to the mailbox of the person who might be using it.
• Tested at least every 90 days (Microsoft's guidance), with a documented procedure, so the keys and the alert are known to work when they are needed.

Auditing privileged role assignments

The rules above become checks you can run against an export of role assignments (in practice from Microsoft Graph or the PIM blade). This example finds three common violations: a permanent active Global Administrator that is not a break-glass account, an admin account that has a mailbox, and a break-glass account without a sign-in alert.

# Audit a small export of directory role assignments against three rules.
ASSIGNMENTS = [
    # account, role, assignment type, end date (None = permanent), has mailbox
    ("adm-identity1@example.com", "Global Administrator", "eligible", None, False),
    ("adm-identity2@example.com", "Global Administrator", "active", None, False),
    ("adm-helpdesk1@example.com", "Helpdesk Administrator", "eligible", None, True),
    ("adm-exchange1@example.com", "Exchange Administrator", "active", "2026-10-02", False),
    ("breakglass1@example.com", "Global Administrator", "active", None, False),
    ("breakglass2@example.com", "Global Administrator", "active", None, False),
]
BREAK_GLASS = {"breakglass1@example.com", "breakglass2@example.com"}
SIGN_IN_ALERTS = {"breakglass1@example.com"}  # accounts with a sign-in alert rule


def findings(account, role, kind, end, mailbox):
    if account in BREAK_GLASS:
        if account not in SIGN_IN_ALERTS:
            yield "break-glass account without sign-in alert"
        return  # permanent Global Administrator is expected here
    if role == "Global Administrator" and kind == "active" and end is None:
        yield "permanent Global Administrator (make it eligible in PIM)"
    if mailbox:
        yield "admin account has a mailbox (used for email?)"


problems = 0
for row in ASSIGNMENTS:
    for message in findings(*row):
        problems += 1
        print(f"{row[0]:28} {message}")
print(f"{problems} finding(s) in {len(ASSIGNMENTS)} assignments")

adm-identity2@example.com    permanent Global Administrator (make it eligible in PIM)
adm-helpdesk1@example.com    admin account has a mailbox (used for email?)
breakglass2@example.com      break-glass account without sign-in alert
3 finding(s) in 6 assignments

Note what is not flagged: the Exchange Administrator is active but time-bound (it has an end date), which is what an activated PIM role looks like. The break-glass accounts are allowed to be permanent; the check for them is a different one. Good audit rules encode such exceptions explicitly instead of producing a long list that everyone learns to ignore.

Common mistakes

• Permanent Global Administrators by the dozen. Microsoft recommends keeping the number of Global Administrators small; everyone else gets a narrower role, eligible through PIM.
• Synchronizing on-premises admin accounts into Entra roles, which turns an AD compromise into a cloud compromise.
• Logging on downward: Remote Desktop to a user's laptop with a Domain Admin account, or running a scheduled task on a member server under a tier 0 account.
• One local administrator password everywhere, or legacy LAPS that nobody migrated to Windows LAPS.
• Break-glass accounts that nobody tested: the FIDO2 key is lost, nobody knows which safe holds it, or the alert goes to a shared mailbox nobody reads.
• Forgetting non-human privilege: a service account in Domain Admins or an application with tenant-wide write permissions is as powerful as a person in that role, and usually less watched.