If organizations provision break-glass access in Azure Active Directory (AD), we recommend using native tools to ensure continued administrative access.
By leveraging password vaulting or multifactor authentication (MFA), the access can be secured against accidental or malicious use. This piece explains the primary options to consider and pitfalls to avoid when creating a break-glass capability in
Azure AD.
What Is Break-Glass Access?
Break-glass access is a resiliency tactic to ensure privileged and administrative access in the event of an outage or availability impact. This could be due to personnel issues, for example, when the individual who normally performs these tasks and has
administrative access in the Azure tenant becomes unreachable or unavailable. More often, it is due to an outage in primary or secondary authentication. The identity provider is down and the primary credentials for normal administrators become unavailable.
Alternatively, the MFA service is down and, therefore, the secondary credentials for normal administrators are unavailable. Because accidents happen, it is important to have a backup set of privileged credentials.
Break-Glass Credential Use Cases
A break-glass credential is unused except in case of emergency. The account must be a shared account and it must not belong to one individual. In fact, the two-person rule – where access requires the presence of two authorized people, and no one
person can achieve access alone – is typically part of the break-glass model.
There are three commonly used patterns for creating emergency administrative credentials:
- Password in a vault. A global administrator account is created and the password is stored in a sealed envelope in a vault. Historically, this was an actual paper envelope in a physical vault. The modern way of doing this is to store the credential in
a password vault, such as Azure Key Vault or BeyondTrust Vault. By breaking the password in two (for example, storing a 32-character password as two 16-character strings), and ensuring no one person has both parts, we can follow the two-person rule.
- Password and MFA token. A global administrator account is created and the password is known to one individual (possibly stored in the individual’s password vault). A second person maintains an MFA token. To use the account, one individual enters
the password and the other completes the MFA request. Organizations can use a hard or soft token to provide the one-time password (OTP) for secondary authentication.
- Account reset. A global administrator account is created and the password is not known or stored. To break glass, the administrator executes a password reset. One way to achieve this is with Microsoft's standard self-service password reset (SSPR) functionality
and a shared email box that designated emergency administrators can access. Another option is to use the Azure Vault’s password reset functionality. This is an easy option to configure, however, it does not adhere to the two-person rule.
Break-Glass Credentials in Azure AD
When you provision the emergency credential in Azure AD as a global administrator account, consider:
- Password/account controls: If there are password rotation controls in place, consider an exception and setting this password to not expire. If there are inactive account controls in place, set an exception because, again, these credentials should rarely
be used. If conditional access polices are in place, set an exception to avoid emergency access being blocked due to device or other policy constraints.
- Monitoring/alerting: You should also monitor and alert on any use of the emergency account. This can be configured in Azure Privileged Identity Management (PIM), if the feature is enabled. This can also be set up within your SIEM, if all authentication
logs are forwarded to the SIEM. Any use of the emergency account must trigger an alert, and any alert must be investigated as a security incident by the security monitoring team.
- Testing: Test the emergency account and break-glass process regularly. Because this access is a resiliency tactic, access should be verified during business continuity and disaster recovery (BC/DR) tests.
Test that the people performing the process know how to obtain and use the administrative credentials. Test that the process (vaulting, MFA, account reset) works technically. Verify that the monitoring and alerting works technically, and that the
security monitoring team acts appropriately. After testing and verification, reset the password and return the emergency account to a ready state.
Mistakes with Break-Glass Accounts
The following are common mistakes to avoid with break-glass accounts:
- Having only one account. Adhering to the two-person rule means both people are needed. Given the DR purpose of these accounts, this may pose a problem if multiple people become unavailable. Organizations can mitigate this by having multiple, redundant
break-glass accounts.
- Using overly complex usernames. Some think it’s best to use hard-to-guess account names, but this account is meant to be used in a crisis scenario. Make the account name something that is easy to remember and easy to enter while in a stressful situation.
- Using overly complex passwords. Long passwords and, depending on the pattern, dividing the password is appropriate and provides security. But because this account is meant to be used in a crisis, consider usability and select characters that are easy
to enter when tense.
- Using the same MFA service as the primary MFA. One disaster scenario is that the MFA service is down and, therefore, normal administrative credentials are not working. A natural disaster may disrupt phones or internet. Use an alternate MFA provider for
the break-glass account.
- Not establishing and testing break-glass procedures. It is not uncommon for an event to occur and either no one is aware of the contingency plans, or the contingencies fail to work altogether. Test the account as part of DR drills.
Creating a Break-Glass Process in Azure AD
Break-glass access is an important resiliency tactic. To ensure success, consider:
- Following the two-person rule and use password vaulting or MFA.
- Avoiding overly complex and unverified processes by focusing on usability and regular testing.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in
connection with such information, opinions, or advice.