Using Break Glass Accounts with Microsoft 365 Tenants

Backup In Case Normal Authentication Fails

An obvious difference between cloud and on-premises management is that Microsoft 365 won’t allow you to sign into the console of a physical computer when all else fails and you need to access a server. Not having to go and reboot a server or perform other maintenance to resurrect a failing application is one of the joys of cloud services.

However, sometimes things do go wrong, and normal administrative sign-ins don’t work. It’s possible that an outage might interfere with the ability to sign into Azure AD to access administrator accounts. The most serious kind of outage is when a tenant comes under attack and the attackers change the password for the administrator accounts. A more mundane reason is that someone changes the password of the administrator accounts (perhaps with the best intentions) and promptly forgets. Or that you follow best practice and enable multi-factor authentication (MFA) for all administrator accounts only for the MFA service to go down as happened in November 2018.

To prevent the complete lock out of administrators when bad things happen, it’s a good idea to create one or more break glass accounts (otherwise known as an emergency access accounts). These are highly-permissioned accounts (perhaps holding the global administrator role) intended for use in emergency situations.

Break glass accounts don’t need Microsoft 365 licenses. Their sole role is to perform administrative actions when regular administrator accounts are unavailable. It’s a waste to assign licenses to these accounts as you’ll end up paying monthly fees for zero utility.

Characteristics of Break Glass Accounts

Break glass accounts have the following characteristics:

• Hosted in the cloud: To avoid any dependency on federation with an external or on-premises directory, break glass accounts are cloud objects. The user principal name for the accounts should use the tenant service domain (tenant.onmicrosoft.com). Although it seems logical to use a value like “Break Glass Account” in the user principal names and display names assigned to these accounts, it might be better to obscure their purpose with names that won’t attract attention like “Building Pipeline Maintenance” or something else that won’t attract attention.
• No simple passwords: Multiple layers of authentication such as MFA protect the accounts. However, you should take care to minimize the number of dependencies used by authentication to ensure that the account is available when needed. For instance, you should exclude break glass accounts from conditional access policies to ensure that a policy doesn’t block a signin attempt for the account.
• Varied authentication: To reduce the possibility that a failure blocks access to all break glass accounts, you should vary the authentication methods used for these accounts. Break glass accounts need MFA to access Azure administrative sites and tools. Don’t use SMS-based responses for MFA as the preferred challenge for all accounts. It’s a weak authentication method and a failure of the SMS service will prevent all access. Use a strong authentication method like a FIDO2 key instead and make sure that the keys are stored securely.

In the past, the recommendation was to give break glass accounts passwords that are complex, long, and obscure. Given the need to use MFA to access Azure administrative sites and tools, the need for such a password is reduced. However, multiple layers of security is usually a good idea, so set good passwords for or break glass accounts and store the passwords securely. The details of the storage location and how administrators can access passwords will vary from organization to organization. Some people suggest storing the passwords in fireproof containers in a locked safe. Others recommend dividing passwords up into several parts and storing each part in a separate network location (OneDrive personal, Google Drive, Dropbox, and so on). The important thing is that the process to retrieve break glass account password works, is documented, and audited to prove that it works.

Checking for Break Glass Sign-In Events

After each use of a break glass account, you should change the password. And to make sure that no unauthorized access happens, you should check Azure AD sign-in data periodically to pick up any attempts to log into the accounts. Microsoft documents how to use Azure Monitor for this purpose. The same Kusto queries will work with Microsoft Sentinel.

It’s also possible to run checks against the Office 365 audit log using the Search-UnifiedAuditLog cmdlet. For example, this code runs an audit log search for log in events for two break glass accounts and displays details of any events it finds.

# Identify the accounts to check
$Accounts = "Break.Glass.Account1@office365itpros.onmicrosoft.com", "Break.Glass.Account2@office365itpros.onmicrosoftcom"
$StartDate = (Get-Date).AddDays(-14); $EndDate = (Get-Date).AddDays(1) # Set your own date span here!
[array]$Records = Search-UnifiedAuditLog -StartDate $StartDate -EndDate $EndDate -Formatted -Operations UserLoggedIn -UserIds $Accounts -ResultSize 5000
If (!($Records)) {Write-Host "No audit records found - exiting!"; break}
$Events = [System.Collections.Generic.List[Object]]::new() 	
ForEach ($Rec in $Records) {
   $AuditData = $Rec.AuditData | ConvertFrom-Json
   $DataLine = [PSCustomObject] @{
         ClientIP            = $AuditData.ClientIP
         Date                = $Rec.CreationDate
         User                = $Rec.UserIds
         UserAgent           = $AuditData.ExtendedProperties | ? {$_.Name -eq "UserAgent"} | Select -ExpandProperty Value
         OS                  = $AuditData.DeviceProperties | ? {$_.Name -eq "OS"} | Select -ExpandProperty Value
         Browser             = $AuditData.DeviceProperties | ? {$_.Name -eq "BrowserType"} | Select -ExpandProperty Value
        }
    $Events.Add($DataLine) 

}
If ($Events) {
     CLS
     Write-Host "Log in Events for Break Glass Accounts"
     $Events | Select Date, ClientIP, User, UserAgent
>> }

Log in Events for Break Glass Accounts

Date                ClientIP       User                                                  UserAgent
----                --------       ----                                                  ---------
10/01/2022 17:48:31 51.171.212.129 Break.Glass.Account1@office365itpros.onmicrosoft.com Mozilla/5.0 (Windows NT 10....
10/01/2022 17:48:31 51.171.212.129 Break.Glass.Account1@office365itpros.onmicrosoft.com Mozilla/5.0 (Windows NT 10....
10/01/2022 17:48:29 51.171.212.129 Break.Glass.Account1@office365itpros.onmicrosoft.com Mozilla/5.0 (Windows NT 10....
10/01/2022 17:48:29 51.171.212.129 Break.Glass.Account1@office365itpros.onmicrosoft.com Mozilla/5.0 (Windows NT 10....
10/01/2022 17:48:28 51.171.212.129 Break.Glass.Account1@office365itpros.onmicrosoft.com Mozilla/5.0 (Windows NT 10....

Multiple signin events for an account over a short period of time are not unusual. Teams, for instance, has a habit of generating multiple events when a user connects. The important thing is that evidence exists of sign-in activity for an account which should not be signing in. This deserves immediate investigation.

Not for Everyday Use

Hopefully, you never have to use a break glass account to rescue a tenant. Touching every available piece of wood in the immediate vicinity, I have never had to use my break glass account. But it’s there and waiting. Just in case.

---

Keep up with the changing world of the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. Monthly updates mean that our subscribers learn about new development as they happen.