0.4 Before You Change Anything

Introduction

The first change worth making to a tenant is the one that makes every later change safe to get wrong, and it is the change most often skipped because nothing has gone wrong yet.

Identity changes can lock administrators out: a Conditional Access policy written too broadly, an authentication method turned off, an approval nobody can give. Before anything else in this course is configured, the lab needs a way back in that none of those changes can block, and an everyday account that cannot do everything.

This lesson covers why lockout is the first risk, the emergency access accounts that guard against it, how they sign in, how they are kept out of policies, how they are watched and tested, and the named account with limited roles that does the daily work instead of a Global Administrator.

An administrator who cannot sign in cannot fix whatever stopped them signing in. Microsoft lists the situations where an organization finds itself there:

Each case is a dependency failing. Administrators who sign in through federation depend on the federation server. Those who use a phone app for multifactor authentication depend on the phone, the network and the service. Administrators synchronized from Active Directory depend on Active Directory. Eligible role assignments that need approval depend on an approver being available and active.

The last case on the list is the one most likely in a lab. A Conditional Access policy that requires something for all users, such as a compliant device, applies to the administrator writing it as soon as it is enforced. If the administrator's own sign-in cannot satisfy it, the next sign-in fails, and the only account that could turn the policy off is the one that cannot sign in.

Microsoft adds a case that catches organizations which have done privileged access well. When every Global Administrator and Privileged Role Administrator assignment is eligible rather than active, and activation needs approval with no approver set, the default approvers are the active holders of those roles. If there are none, nobody can approve, and the tenant is locked by its own good practice.

An emergency access account is an account with none of those dependencies. It is cloud-only, so Active Directory and federation cannot affect it. It signs in with a method that needs no phone network. It holds Global Administrator permanently, so nothing needs activating or approving. And it is excluded from every policy that could block it.

Microsoft's guidance also covers what the account is not for. It is not a convenient spare administrator, a shared account for routine work, or the account a busy administrator uses when their own is awkward. Every use outside an emergency weakens the case that its use is always an emergency, and that case is what makes an alert on its sign-ins useful.

Microsoft recommends two or more emergency access accounts, so that losing one, or one credential, does not leave none. Each is a cloud-only account on the tenant's initial domain, ending in onmicrosoft.com, because that domain cannot be removed and depends on no other system. Neither is associated with a particular person.

The account then needs Global Administrator, assigned as permanently active. Microsoft is explicit that emergency accounts should not be eligible in Privileged Identity Management, because activating a role is exactly the step that might be impossible in the emergency. The assignment is made once, in Graph or the portal:

PS C:\> Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Directory" -NoWelcome
PS C:\> $u = Get-MgUser -UserId "emergency-access-01@yourlab.onmicrosoft.com"
PS C:\> $a = @{ PrincipalId = $u.Id; DirectoryScopeId = "/"
        RoleDefinitionId = "62e90394-69f5-4237-9190-012177145e10" }
PS C:\> New-MgRoleManagementDirectoryRoleAssignment -BodyParameter $a |
    Format-List PrincipalId, RoleDefinitionId, DirectoryScopeId

PrincipalId      : <the account's object ID>
RoleDefinitionId : 62e90394-69f5-4237-9190-012177145e10
DirectoryScopeId : /

The command reads its target by user principal name and assigns by object ID, which is how Graph refers to every principal. Listing the account's role assignments afterwards, and finding the Global Administrator row with no end date, is the proof the step worked.

The role definition ID is the Global Administrator template, the same in every tenant. Scope / means the whole directory. A Privileged Role Administrator can make this assignment, but in a new lab it is the creating account that does it, since that account is the only administrator.

The accounts hold no license and no mailbox. They do not need one to administer the tenant, and an account with a mailbox has a way for messages to reach it, which an account meant to sit unused does not need.

Northgate shows what happens when this is done halfway. Its tenant has one emergency account, not two, and that account has no authentication method registered at all:

PS C:\> Connect-MgGraph -Scopes "AuditLog.Read.All" -NoWelcome
PS C:\> $f = "userPrincipalName eq 'emergency-access-01@ne.onmicrosoft.com'"
PS C:\> Get-MgReportAuthenticationMethodUserRegistrationDetail -Filter $f |
    Format-List UserPrincipalName, IsAdmin, MethodsRegistered, IsMfaCapable

UserPrincipalName : emergency-access-01@ne.onmicrosoft.com
IsAdmin           : True
MethodsRegistered : {}
IsMfaCapable      : False

An account with no method registered signs in with its password alone.

That works only while no policy demands more, and Northgate's own policies are written to exclude it for that reason. But a password alone is the weakest sign-in an account can have, on the most powerful account in the tenant, and a single account means a single credential to lose. Both are corrected later in the course; in your lab, both are done right from the start.

An emergency account still needs strong authentication; being exempt from policies does not make it exempt from attack. Microsoft recommends a passkey (FIDO2), usually on a hardware security key, or certificate-based authentication where an organization already has the public key infrastructure for it. Both satisfy the mandatory multifactor authentication Microsoft enforces on its admin portals.

A passkey is phishing-resistant: it is bound to the site it was registered with, so a fake sign-in page cannot use it. It needs no phone, no network for a text message and no app. The security key sits in a safe, and whoever opens the safe in an emergency can sign in.

Microsoft also recommends that the emergency accounts use a different method from the normal administrator accounts. If everyday administrators use Microsoft Authenticator, the emergency accounts use security keys, so an outage of the Authenticator service, or a flaw in it, does not affect both at once.

The keys and the password are stored where several members of the administration team can reach them, in separate secure locations, and the accounts are not connected to anyone's personal phone. For a lab, a drawer you control is enough. For an organization, Microsoft suggests secure, fireproof safes, with the list of authorized people reviewed during each test.

Certificate-based authentication is the alternative where an organization already runs a public key infrastructure, typically with smart cards. It avoids buying security keys but depends on the certificate authority being reachable and its certificates being valid, which is one more system to keep healthy for an account whose whole purpose is depending on as little as possible.

A passkey on a security key is also protected by the key's own PIN, so a key taken from the safe is not enough on its own; the person needs the PIN too, stored separately. That is two factors held in two places, which is the property that makes the account strong without making it depend on anything outside the room.

For a lab, two inexpensive security keys are the only purchase this module needs. If you cannot buy them, a passkey in Microsoft Authenticator is a weaker substitute, because it depends on a phone, and the lab is a safe place to accept that compromise while knowing it would not do in production.

An emergency account must not be stopped by the policies it exists to recover from. Microsoft's guidance is to exclude the emergency accounts from every Conditional Access policy that blocks or restricts sign-in, and to do it with a dedicated group rather than by naming the accounts in each policy.

The group makes the exclusion one decision instead of many. Adding a second emergency account means adding it to the group, and every policy follows. A new policy is written with the group excluded from the start, and a review of exclusions reads one group's membership.

Report-only policies do not need the exclusion, because they never block anything. Policies aimed at guests do not need it either, since the emergency account is a member. Reading Northgate's policies shows both:

PS C:\> Connect-MgGraph -Scopes "Policy.Read.All","Group.Read.All" -NoWelcome
PS C:\> $g = (Get-MgGroup -Filter "displayName eq 'CA-EmergencyAccess'").Id
PS C:\> Get-MgIdentityConditionalAccessPolicy -All |
    Format-Table DisplayName,
    @{n="ExcludesEA";e={$_.Conditions.Users.ExcludeGroups -contains $g}}

DisplayName                                       ExcludesEA
-----------                                       ----------
Block legacy authentication                       True
Require MFA for all users                         True
Require MFA for guest access                      False
Require compliant device for Exchange             True
Require phishing-resistant MFA for administrators True

Four policies exclude the group, and the one that does not applies only to guests, so the emergency account is outside its scope anyway. Northgate's report-only policy for administrators excludes it too, which is harmless: when that policy is enforced, the exclusion is already in place.

Exclusions are checked from the other side too. A policy that targets a role, such as Global Administrator, would include the emergency accounts through that role even if it never names them, so the group exclusion goes on role-targeted policies as well. Reading every enforced policy for the group after each change to Conditional Access is the quick check that none was written without it.

The group itself is sensitive. Anyone who can add members to it can exempt an account from every policy, so its membership is changed by as few people as possible and every change to it is worth an alert. In a lab, the group is yours alone; in an organization, it is one of the first things an access review should read.

Because an emergency account should almost never sign in, every sign-in is worth knowing about at once. Microsoft recommends an alert on every sign-in and every audit event by the emergency accounts, matched on the accounts' object IDs so that renaming an account does not silence the alert:

SigninLogs
| where UserId in ("946219ee-da2a-4201-9fae-8a87ccadef22")
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName,
    ResultType, ResultDescription

The query reads the exported sign-in logs, which is one more reason the lab's logs go to a workspace from the first day.

Saved as an alert rule that runs every few minutes and fires on any row, it turns each emergency sign-in into a message to the people who should know, whoever made it and for whatever reason. Including failures matters: a failed attempt on an emergency account is someone trying, and is as important to see as a success.

Microsoft also recommends testing the accounts regularly, at least every 90 days, and checking each quarter that they can still sign in under the current Conditional Access configuration.

A test is a real sign-in, with the real security key, followed by reading the sign-in record to confirm which policies applied and that none blocked it. Each test is also a chance to check that the people allowed to use the accounts still know where the credentials are.

A test also proves the alert. The test sign-in should produce the alert within the time the rule runs, and if it does not, the alert is broken and the test has found the second fault before an emergency did. A test that only checks the sign-in and not the alert checks half of what matters.

After any real use, Microsoft recommends a review of whether the use was authorized and whether the actions taken were appropriate. The audit log has every action the account took, so the review reads exactly what was done.

Northgate's tenant shows the cost of skipping this. Its sign-ins are exported, but no alert watches the emergency account, and with no method registered it has no strong sign-in to test. Both are the kind of gap that stays invisible until the day the account is needed, which is also the day it turns out not to work.

The account that created the tenant is a Global Administrator. Using it for every build would mean every mistake has unlimited reach, and every record in the audit log would show the most powerful account in the tenant doing routine work. Once the emergency accounts exist, the creating account is treated like one of them: kept, protected, and not used day to day.

Daily work is done with a named, cloud-only account holding the roles each task needs. Microsoft publishes the least privileged role for every task, and the course's first modules need these:

The daily administrator account is also separate from any account you use for email and browsing. An administrator role on the same account that reads mail means a phishing message reaches an account that can change the tenant. Two accounts, one for ordinary work and one for administration, is the pattern Northgate already follows with its a- accounts, and the lab copies it.

The account is cloud-only for the same reason the emergency accounts are. Microsoft's guidance for protecting Microsoft 365 from on-premises attacks is to use cloud-only accounts for privileged roles, so that a compromise of Active Directory does not become a compromise of the cloud. Northgate's two named administrator accounts are both synchronized from Active Directory, one of the findings this course works through.

Each role is assigned the same way, from the role's own page:

With P2 in the lab, each of those roles is assigned as eligible rather than active, and activated for a few hours when a build needs it. That is how the course's privileged access lessons work, and practicing it from the start makes activation a habit rather than an obstacle. Without P2, assign the roles directly and remove each when the module that needed it is finished.

Each role in the list maps to work in the next few modules. User Administrator and Groups Administrator cover creating test users and groups. Reports Reader covers reading what changed. Conditional Access Administrator covers writing policies without being able to assign roles.

Privileged Role Administrator is the most sensitive of them, since it can assign any role, including Global Administrator, so it is the first one to make eligible when P2 is available.

Some steps will still need Global Administrator, such as the first configuration of a feature that only that role can turn on. When that happens, the build card says so, and the creating account is used for that step and nothing else. Recording each such use, even in a lab, builds the habit an organization needs: knowing every time the highest role was used, and why.

The order matters more than any single step. The emergency accounts come first, before any policy exists that could lock anyone out. Their passkeys come before their passwords are put away, so that the strong method is proven to work. The exclusion group comes before the first Conditional Access policy, so no policy ever exists without the exclusion in it.

The log export comes before any of that is relied on, so the test sign-ins are kept. The named daily account comes last, once there is a safe way back in if its role assignments go wrong. Then the creating account and the emergency accounts are put away, and the rest of the course runs as the named account, activating roles when it needs them.

PS C:\> Get-MgUser -Filter "startswith(userPrincipalName,'emergency')" |
    Format-Table UserPrincipalName, OnPremisesSyncEnabled, AccountEnabled

UserPrincipalName                      OnPremisesSyncEnabled AccountEnabled
-----------------                      --------------------- --------------
emergency-access-01@ne.onmicrosoft.com                       True

The check reads the accounts by name prefix, which works in a lab where you chose the names. In an organization, the reliable list is the membership of the exclusion group, compared with the active Global Administrator assignments: every emergency account should appear in both, and nothing else should be in the group.

A blank sync value is what a cloud-only account shows, since the property is set only for accounts that came from Active Directory. Running the same check in your lab after the build should show two emergency accounts, both cloud-only and enabled, where Northgate shows one.

The same order applies to any tenant you are given, not only a new one. Before making a change in a tenant you have just started administering, find out whether emergency accounts exist, whether they can sign in, and whether the policies exclude them. If any answer is no, that is the first change to make, because every other change depends on there being a way back.

None of this takes long, and all of it is easier before anything else exists. Adding an emergency account and an exclusion group to a tenant that already has a dozen policies means editing every policy and hoping none was missed; doing it first means each later policy is written correctly the first time.

The build sets up the emergency accounts, the exclusion group and the daily account, and proves the emergency accounts can sign in.

Store the security keys and the passwords the way you would expect an organization to, even in a lab. The habit is the point, and a lab is where it costs nothing to form.

Lockout is the first risk in any identity change, so emergency access comes first: two cloud-only accounts on the initial domain, Global Administrator permanently active, a passkey each, excluded from every blocking policy through one group, alerted on and tested.

Daily work is done by a named cloud-only account with the least privileged roles for the task, eligible where P2 allows. If you do one thing in your own tenant, sign in with your emergency account today and read the record it leaves.

Resources

Microsoft revises these pages; where a page and this lesson disagree, the page is newer.

• Microsoft Learn: Manage emergency access accounts
• Microsoft Learn: Least privileged roles by task
• Microsoft Learn: Protect Microsoft 365 from on-premises attacks
• Microsoft Learn: Passkeys (FIDO2) in Microsoft Entra ID