Emergency access accounts: getting in when directory sign-in stops working

A new conditional access policy was meant to require a compliant device for all users. Once it is switched on, nobody, administrators included, can sign in to the portal where it could be switched off. Another scenario: after a storage array failure the domain controllers do not start, and the local administrator password of the virtualisation hosts is in LAPS, that is, in the directory that has just stopped working.

An emergency access account, also called a break-glass account, is the plan for exactly these situations. It works only if it does not depend on the mechanism whose failure it is meant to bypass, and if somebody tested it before the day of the outage.

General rules

An emergency account is not used for daily work. Its password or key is stored so that it can be used in a crisis but cannot be used unnoticed. Every use raises an alert and ends with the credentials being replaced. An account nobody has tested is treated as an account that does not work.

Where emergency accounts are needed

System	Emergency account	Credential	Storage
Entra ID and Microsoft 365	two cloud-only accounts with the Global Administrator role	two FIDO2 keys per account	safe A and safe B
Active Directory	one domain account in Domain Admins	a 32-character password in two parts	parts held by two people, in two safes
Domain controllers	the directory services restore mode password	a password, copy via LAPS	envelope in safe A
Virtualisation hosts	a local account outside LAPS	a password	envelope in safe A
Tools that sign in through the directory	the tool’s local administrator	a random password	envelope, or a password manager with independent access
Network devices	a local account with console access	a password	envelope in safe A

Cloud-only accounts in Entra ID

Emergency accounts in the cloud have to work independently of the on-premises directory, synchronisation and federation. Therefore they:

• are created directly in Entra ID, in the onmicrosoft.com domain, for example bg-admin-01@example.onmicrosoft.com, rather than synchronised from Active Directory,
• hold the Global Administrator role as a permanent assignment, not through activation in Privileged Identity Management, which may itself require approval or a second factor,
• sign in with a FIDO2 key: two keys per account, each in a different safe, with the PIN written in the same envelope as the key,
• have no methods that depend on one person, such as SMS or an app on a private phone,
• are excluded from every conditional access policy, directly or through a group with fixed membership, never through a dynamic group.

Exclusion from conditional access does not mean signing in with a password alone. Microsoft enforces multi-factor authentication for sign-in to its admin portals regardless of those policies, so an account without a strong method would not get in anyway. A FIDO2 key meets that requirement and is phishing-resistant.

The directory account and local accounts

An emergency account in Active Directory helps when the directory works but the administrator accounts do not: they have been locked out, disabled after a suspected compromise, or cannot obtain a Kerberos ticket. It is a direct member of Domain Admins and stays outside the Protected Users group.

The password has 32 characters and is split into two parts of 16 characters. Each part is known to only one person and each sits in a different safe, so using the account requires two people. When the password is changed, both people type their parts in turn into the same field.

# The command prompts for the new password and its confirmation
Set-ADAccountPassword -Identity bg-ad-01 -Reset

Storage

A proven approach: credentials in sealed envelopes, one per system, with a list of people authorised to open them. Two safes in different locations, in case one is unreachable. The seal number is recorded in the register, and a broken seal means the credentials must be replaced.

An alert on every sign-in

In Entra ID, sign-in logs are sent through diagnostic settings to a Log Analytics workspace, and an alert rule checks them every 5 minutes. The alert goes out through an action group to at least two people, by email and SMS. The rule also covers failed attempts, because an attempt to sign in to an emergency account is just as important a signal.

SigninLogs
| where UserPrincipalName in~ ("bg-admin-01@example.onmicrosoft.com", "bg-admin-02@example.onmicrosoft.com")
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultType

In Active Directory, authentication of a domain account leaves event 4768 (Kerberos ticket) or 4776 (NTLM validation) on the domain controllers. A rule in the log collection system fires on either of them with the emergency account’s name, and also on events 4724 (password reset) and 4738 (account changed).

The quarterly test

Once a quarter for each system in the table:

1. Log the test in the ticketing system, with the date and the names of the people involved.
2. The envelopes are opened by people on the authorised list.
3. Sign in and check that the account has the expected permissions.
4. Confirm that the alert arrived, recording the time from sign-in to notification.
5. Change the password or the key’s PIN, prepare new envelopes and new seals.
6. Add an entry to the register: system, account, storage location, test date, who tested, alert delivery time.

The test checks three things at once: whether the account works, whether the alert arrives, and whether the procedure for getting to the safe is workable in practice.

Check your own environment

The state of the emergency account in Active Directory. LastLogonDate should match the date of the last test to within 14 days, because the attribute it comes from replicates with a delay. PasswordLastSet must be later than the last test. A sign-in more recent than the last test with no reported outage needs explaining.

Get-ADUser -Identity bg-ad-01 -Properties LastLogonDate, PasswordLastSet |
    Select-Object SamAccountName, Enabled, LastLogonDate, PasswordLastSet

The exact date of the last logon on each domain controller. The lastLogon attribute is not replicated, so every controller has to be queried separately. The year 1601 in the result means the account has never logged on through that controller.

foreach ($dc in Get-ADDomainController -Filter *) {
    $user = Get-ADUser -Identity bg-ad-01 -Server $dc.HostName -Properties lastLogon
    [pscustomobject]@{ DC = $dc.HostName; LastLogon = [datetime]::FromFileTime($user.lastLogon) }
}

The Entra ID accounts: the date of the last sign-in and the conditional access policies that do not exclude them. A good result for the second query is empty. If the exclusion is done through a group, check the Conditions.Users.ExcludeGroups field.

Connect-MgGraph -Scopes 'User.Read.All', 'AuditLog.Read.All', 'Policy.Read.All'
$user = Get-MgUser -UserId 'bg-admin-01@example.onmicrosoft.com' -Property Id, UserPrincipalName, SignInActivity
# Date of the last sign-in
$user.SignInActivity.LastSignInDateTime
# Enabled policies that do not exclude the account
Get-MgIdentityConditionalAccessPolicy -All |
    Where-Object { $_.State -eq 'enabled' -and $_.Conditions.Users.ExcludeUsers -notcontains $user.Id } |
    Select-Object DisplayName