We’ve been talking a lot about the fire emergency evacuation plan at work recently. Our renter is shaping up the plan and is installing additional fire extinguishers and so on. This inspired me to write a post on how organizations should implement “break glass accounts” in Azure Active Directory.
Please, also have a look at my other post for a complete break glass routine template.
Emergency access accounts, often referred to as “break glass accounts”, is an important part of an organization’s disaster recovery plan. These accounts are highly privileged and should only be used when normal admin accounts can’t sign in. Microsoft recommend at least two break glass accounts in an Azure AD tenant. If you don’t have such accounts in place you should plan to implement at least two as soon as possible. Please use the guidelines in this blog post to implement this right.
As you understand, these accounts are super important to help you sort out disasters like locking yourself out of your tenant with Conditional Access polices, failing federation services, service outages and more. For example, break glass account might be your only way back in when Microsoft MFA services goes down. But break glass accounts are also extremely important to keep safe as many of the important security functions like MFA is disabled. Break glass accounts should be kept secret and no admin should know the entire password without “breaking the glass”.
I have collected some important guidelines around security and configuration of Emergency Access Accounts.
Break Glass Account Security Guidelines
- Should have a complex, hard to guess, username.
- Must have a complex password, preferably split into two parts, stored in envelopes at two different secure locations in fireproof safes.
- There should be a list of allowed admins who can use the break glass accounts. These admins should, of course, also hold the Global Admin role under normal circumstances.
- Be sure to monitor break glass accounts in Azure AD sign-in logs and audit logs and act on any unexpected activity.
Break Glass Account Configuration Guidelines
- Must have the Global Administrator role assigned permanently.
- Must have password set to never expire.
- Must not have MFA configured.
- Must be excluded from ALL Conditional Access policies.
- Must not be assigned to a specific individual.
- Must be a cloud-only account.
- Should use the tenants *.onmicrosoft.com domain (to avoid domain and federation issues).
- Must not be federated.
- Should not be synchronized with on-prem AD.
- Should not be connected with any employee-supplied mobile phones or hardware tokens.
Documentation and Validation
- The emergency routine should be well documented and always kept current.
- Finally, the accounts and emergency routines should be verified and practiced at least every 90 days of all approved admins. Make sure to put this in the calendar!
I hope that these guidelines will help you in your emergency planning. Please follow me here, on LinkedIn and on Twitter for more cloud stuff.
Daniel Chronlund Cloud Security Blog 
Thanks for sharing. Great article and simple to follow.
Glad you found it useful!
Daniel,
How would you recommend the password be created for this account? Since you say the passwords should be splint in two and stored separately, I am just wondering if you’ve come up with a way for the passwords to be created so not a single admin knows the entire password.
Great article btw! I was thinking about making my BGAs require MFA, but have separate iPods with the Microsoft Authenticator App stored in two separate fire proof safes. But thinking about the MFA service going down is making me rethink this.
Thanks,
Brian
Thanks for your comment Brian!
When I do a break glass workshop with a customer I often ask two or three of the participating admins to create a part of the password and then enter their part one by one into the reset password fields. Parts of passwords can be stored in individual envelopes.
For MFA, I have customers looking into using FIDO2 keys for their break glass accounts.
Hope this helps!
optimal
This is really cool, thank you for sharing Daniel. I’d love to see what this looks like in person (or on a youtube demonstration). Have you ever recorded this part of a workshop? I’d like to see the actual process of people (hands covering paper, so to speak) : ) As well as having a 2nd party verifying use of that segment through another process, to ensure all parties are actually recording the real value and it works.
Anyone actually use tamperproof envelopes or other mechanisms to ensure the pieces of a password weren’t somehow compromised? I remember an old movie with nuclear codes kept in a color, plastic sheath – I’ve always thought that would be a good approach for this mechanism too, but not sure if a) it’s really necessary or b) whether people would go to this degree anyway for anything that’s not a nuclear code.
But realizing that the keys to the kingdom in Azure AD with GA / breakglass accounts really is the Nuclear option, we should be so inclined to protect in this manner. Would love to hear others’ thoughts on those notions too. Thanks!