While Conditional Access and MFA in Azure and Office 365 are gaining popularity within corporate organizations, I often see people underestimating the importance of having a so-called “emergency access procedure”, often referred as “break glass routine”. In this blog post I will discuss the importance and some best practices I learned in the field.
Basically, there is only one main and obvious reason for having a break glass routine:
Preventing a total (admin) lock-out of your Azure AD or Office 365 tenant.
In addition, there are numerous reasons why you would need a dedicated (cloud-only non-federated) break glass account to mitigate the risk of being locked out of your tenant:
- If accounts are federated (for example by using ADFS as identity provider), an outage of the ADFS or AD farm would block any attempt to sign-in.
- If users with Global Administrator privileges somehow lose their privilege, for example by accident, leaving the organization, or disabled on purpose by using PIM, nobody is having permanent admin access anymore.
- If users with Global Administrator privileges are using MFA or other Conditional Access policies and locked themselves out due to human error (or misconfiguration) or lost their phone(s).
- Everyone knows Azure MFA and CA is not (and will never be) 100% bulletproof if it comes to availability and reliability. Past years there were several occurrences where MFA didn’t work due to a failure at Microsoft datacenters.
- Other unforeseen circumstances like malicious admin activities.
As you probably understand, having such break glass account is a real must-have to prevent admin lockout. You can simply compare the importance of it with those green emergency exit signs at public buildings to guide people to the exit in case of emergency. If there wouldn’t be any procedure, a lot of trouble could happen during a fire. Same goes to your digital access to Azure AD and Office 365.
Okay, now you know the “why” about having an emergency access procedure, let’s talk about the “best practices” behind the scenes.
- Do not solely rely on only 1 break glass account. Aim to create and maintain at least 2 of them.
- If you’re having multiple break glass accounts, avoid to store them on the same geographical location or region.
- Make sure at least 1 break glass account is excluded from any form of MFA or CA policies.
- Avoid using federation services (like ADFS) for break glass accounts. Configure the account to use a non-federated domain (like tenant.onmicrosoft.com).
- Avoid using custom domain names for break glass accounts to reduce dependency of third party DNS providers. Aim to use the default tenant.onmicrosoft.com domain.
- Avoid using a synchronized account. Create the account from the admin portal as a cloud-only account.
- Avoid assigning a break glass account to a employee to prevent access loss during absence or employee leave.
- Configure the credential to not expire by default, however, you should periodically reset the password.
- Adopt the emergency access procedure within regular maintenance windows. For example, try to test the account credential twice a year and additionally reset the password.
- Avoid using obvious or easy to guess usernames and passwords. As a best practice, the username (and of course the password) should be complex as possible.
- Maintain a list (or part of your procedure) which lists admins who are allowed to use the break glass account.
- Monitor and alert on any activity of the break glass account, such as sign-ins.
- Last but not least an obvious one: at least assign the Global Administrator Azure AD role 😉
- Additionally you could also add Owner RBAC permissions to Azure subscriptions you would like to protect.
Twist it, and turn it to your advantage 😉 . If you have any suggestions or additions, please feel free to drop a comment!