A better Azure AD break glass account?

2 minute read

We all know that we should have some kind of emergency access aka “break glass accounts” to access our Azure AD tenant if things go worse, don’t we? Today I want to show you an alternative to regular user accounts by using a service principal. This also works for Azure AD security defaults.

Microsoft got some great guidance for creating such emergency access accounts based on users Manage emergency access accounts in Azure AD.

Microsoft states the following requirements for an emergency access account:

  • Cloud only account (and not tied to a custom domain)
  • Excluded from Conditional Access policies (-> MFA)
  • Credentials safely stored
  • Monitoring sign-in and audit logs

A service principal (app registration) fulfills all of these. Important to understand is that service principals are not subject to any conditional access policies.


Setup is fairly easy and consists of creating a new app registration, assigning permissions and setting up monitoring.

Azure AD App registration

Create a new AAD App registration:

  • New app registration
  • Name your app
  • Generate a client secret/certificate Add client credentials

Directorly role

  • Assign the Global Administrator role to the app Assign permissions
  • As an alternative you can also assign more fine-grained Microsoft Graph permissions
  • You can also grant permission to the app registration on management groups or specific subscriptions


Create an alert rule for sign-in logs in Azure monitor or sentinel (make sure to replace the AppID):

| where TimeGenerated > ago(48h)
| where AppId in ("2a0d623c-9e26-49f1-af7d-dd3116f7c845")

Using the emergency access app

We can easily interact with the app by using the MSAL PowerShell module (MSAL.PS) and request an access token for the service we want to interact with. For this example, we’ll use the AzureAD PowerShell cmdlets.

$params = @{
    TenantId     = '#replace with your Tenant ID'
    ClientId     = '#replace with your client ID'
    ClientSecret = $('#replace with your client secret' | ConvertTo-SecureString -AsPlainText -Force)
    Scopes       = @("https://graph.windows.net/.default")

$token = Get-MsalToken @params
Connect-AzureAD -TenantId $params.TenantId -AccountId $params.ClientId -AadAccessToken $token.AccessToken

By specifying the .default scope we request an access token for all scopes the app has access to. Because we assigned the Global Administrator role we have the most permissive permissions over the whole Azure AD tenant.

If you still need an account where you can sign-in interactively:

$emergencyAccessAccount = @{
    DisplayName       = "Emergency Access"
    UserPrincipalName = "[email protected]"
    MailNickName      = "ea"
    # Password, ForceChangePasswordNextLogin, EnforceChangePasswordPolicy
    PasswordProfile   = [Microsoft.Open.AzureAD.Model.PasswordProfile]::new('$hithitstheFanTenantisBroken?', $false, $null)
    AccountEnabled    = $true

# create account
$emergencyAccess = New-AzureADUser @emergencyAccessAccount

#assign global admin role to account
$globalAdminRole = Get-AzureADDirectoryRole | Where-Object { $_.DisplayName -in @("Company Administrator", "Global Administrator") }
Add-AzureADDirectoryRoleMember -ObjectId $globalAdminRole.ObjectId -RefObjectId $emergencyAccess.ObjectId

Write-Output $emergencyAccess

#don't forget to remove the account when done
for ($i =300; $i -gt 0; $i--){
    Write-Progress "Deleting Account $($emergencyAccess.userPrincipalName) in $i seconds" -PercentComplete (($i / 60) * 100)
    Start-Sleep -Seconds 1
Remove-AzureADUser -ObjectId $emergencyAccess.ObjectId


So is this option better than a regular break-glass user account?

It depends…


  • If you are not familiar with PowerShell this option won’t be suitable for you
  • If an action or feature cannot be disabled with PowerShell (and an underlying API) you need to create a temporary account with the snippet above
  • App and secrets can be modified from users owning the “Application Administrator” directory role


  • You don’t need to make exclusions from Identity Protection and Conditional Access policies
  • Hurdle to just use the account for whatever sign-in higher
  • Creation of multiple client secrets including rollover is possible
    • Storing one secret in a safe location like a bank deposit which does never expire
    • Storing one secret in KeePass which gets rotated regularly
  • No guessable username like “[email protected]

Hope this provides you an example toward more ideas.