This blog post is original from my own blog, re-posted here

Introduction

What is a Break Glass Account?

Break Glass accounts are emergency access accounts that are used to access critical systems or resources when other authentication mechanisms fail or are unavailable. In Azure AD, Break Glass accounts are used to provide emergency access to the Azure AD tenant when normal authentication mechanisms are unavailable.

Azure AD provides multiple authentication mechanisms, such as user passwords, multifactor authentication (MFA), and conditional access policies. However, there may be scenarios where these authentication mechanisms fail or are unavailable due to technical issues, such as a network outage, hardware failure, or a configuration error.

In such cases, a Break Glass account can be used to gain emergency access to the Azure AD tenant. This account is typically a highly privileged account with extensive permissions and is stored in a secure location. The account is only used in emergency situations and is not used for normal day-to-day operations.

The Break Glass account is activated by authorized personnel, such as IT administrators or security personnel, using a predefined process. The process typically involves multiple levels of approval and verification to ensure that the account is only used in genuine emergency situations.

Once activated, the Break Glass account can be used to perform critical tasks, such as resetting passwords, disabling accounts, or performing other administrative functions that may be required to restore normal operations.

In summary, Break Glass accounts are an important part of the security and resilience of Azure AD. They provide emergency access to critical resources when other authentication mechanisms are unavailable, and they are only used in genuine emergency situations by authorized personnel following a predefined process.

Security in the days

Good cloud environment has strict security policies. Well-known policies there is setup are conditional access policies in Azure AD. Policies that require a compliant device before login for example or forcing MFA. Configuring conditional access is good but there is always a risk of lockout yourself if setup the wrong way. To not lock yourself out, you must create an emergency account! 😲

There are two types of Break Glass Accounts

Yes, in Azure AD, there are two types of Break Glass accounts: the global admin Break Glass account and the privileged role Break Glass account.

1. Global admin Break Glass account: This type of Break Glass account is a highly privileged account that is associated with the Azure AD tenant itself, and not with any specific user or role. It has the highest level of permissions in the Azure AD tenant and can perform any task or operation 🗝️

To activate the global admin Break Glass account, you need to follow a predefined process that typically involves multiple levels of approval and verification. Once activated, the account can be used to perform critical tasks, such as resetting passwords, disabling accounts, or performing other administrative functions.

2. Privileged role Break Glass account: This type of Break Glass account is associated with a privileged role in Azure AD, such as a Security Administrator, Compliance Administrator, or Global Reader. It has the permissions associated with that role and can perform tasks and operations related to that role.

To activate the privileged role Break Glass account, you need to follow a predefined process that is specific to the role. For example, to activate the Security Administrator Break Glass account, you need to follow a process that involves multiple levels of approval and verification by security personnel.

Both types of Break Glass accounts are used in emergency situations when normal authentication mechanisms are unavailable or have failed. It’s important to note that Break Glass accounts should only be used in genuine emergency situations and should be protected by strict security measures to prevent unauthorized access.

Monitoring the use of Break Glass accounts

As discussed above, the break the glass account is a highly privileged user account that must be handled with care. Because of that, it is recommended to monitor all account usage.

This is the reason why you need to create a monitor rule to check for account usage!

The idea is to create an alert rule in Azure Monitor that checks the sign-in logs in the Log Analytics. Every log-in step is logged even when the login is not succesful. If the user account is logged, the IT admin gets an email or a SMS! 🔐👌

For the monitoring we use LogAnalytics and Azure Monitor. This will monitor the sign-in and notify the designated administrator.

Frist we need to create a Log Analytics Workspace if you not have any – you can to it here direct

Browse now to Microsoft Entra > Azure Active Directory > Monitoring & Health > Diagnostic Settings > Add diagnostic setting

Select the AuditLogs and SignInLogs (i know there is more here, but its from my setup 🤪)
Select Send to Log Analytics workspace and select the subscription and your new created Log Analytics workspace.

Browse now to the All Users tab to find your Break Glass account(s) and obtain the ObjectId. We need these to use in the monitor to find if the accounts is used.

Get the ObjectId for your break the glass accounts and write them down to next step

Browse now to Azure Portal and select your new created Log Analytics workspace

Noew we create a noew rule, so we can check the signin logs to check when the accounts is used (or tryed to be so).

Select Custom log Search at the first tab with Signal name – else you can not set this query.
To get the needed information, we need to provide the ObjectId’s from the Emergency accounts you created before.

// Search for multiple Object IDs (UserIds)
SigninLogs
| project UserId
| where UserId == "34bbde15-5585-4333-a9d6-fd1b529ab024" or UserId == "2e5438a8-b3ae-3dd1-b6b8-4bbcb29cae45"

With the Alert Logic part we choose this for now:

• Operator: Greater than
• Theshold value: 0
• Frequency of evaluation: 5 minute

At the next tab Actions, we need to create a new Action Group. Provide it with a name and continue to Notifications – here we can setup where to send the notification to.

Select Email/SMS message/Push/Voice and provide an email and a telephone number to receive the sms after this you can Review + create

The next tab is Details

Provide a name and set Severity to 0-Critical!

Now you are all set to receive notifications when someone tries to login with the Emergency Break Glass accounts to your tenant.

When you test it, you will receive a sms message and an email.

The SMS is received from Microsoft and notify you that there was an alert in the sign-ins with the break glass accounts.

List of Alert Rules you can use

Here is a list of some important alert rules everyone should have in place, as they give some good insigts in your Break-the-glass accounts.

But first, let’s have a look at the recommended alert rules:

Alert Rule Name	Query	Explanation
A break the glass user is account signed in	SigninLogs | where ResultType == 0 | project UserId | where UserId == “34bbde15-5585-4333-a9d6-fd1b529ab024” or UserId == “2e5438a8-b3ae-3dd1-b6b8-4bbcb29cae45”	Checks if any login is happening success
Etc. a break the glass user account or an other sensitive account tried to sign in but failed	SigninLogs | where ResultType != 0 | project UserId | where UserId == “34bbde15-5585-4333-a9d6-fd1b529ab024” or UserId == “2e5438a8-b3ae-3dd1-b6b8-4bbcb29cae45”	Sensitive accounts, not protected by Conditonal Access and MFA, like break glass accounts and service accounts there is requires extra monitoring. This alert rule triggers on successful sign-ins from sensitive accounts.
A sensitive user account was updated	AuditLogs | where Category == “UserManagement” | where OperationName has “Update user” | where TargetResources has “34bbde15-5585-4333-a9d6-fd1b529ab024” or TargetResources has “2e5438a8-b3ae-3dd1-b6b8-4bbcb29cae45”	This alert rule triggers on account changes on sensitive accounts. This includes password changes and attribute changes.
Monitor role changes	AuditLogs | where Category == “RoleManagement” | where OperationName contains “role” | where TargetResources has “34bbde15-5585-4333-a9d6-fd1b529ab024” or TargetResources has “2e5438a8-b3ae-3dd1-b6b8-4bbcb29cae45”	Check if roles is removed, added or changed for the accounts

Edit Conditional Access policies (MFA)

The last step is to make sure the break-glass accounts are excluded from your MFA policies and so on. This is where it all goes about – else in an emergency you cant login! 🤓🤪

You can put in in a group if you have that (can be used to other stuff to, etc. service accounts) and exclude it here:

Self service password reset – reminder when break the glass account is not setup with MFA

If you are using Self service password reset (SSPR), you need to check your settings here too – as if your settings is setup to cover All users – your break the glass accounts will be targeted here.

So when you test your new break the glass account and is excluded from your Conditional Access policyes fine, but still gets promted to setup etc. the Microsoft Authenticator App when login – this is why!

When you look in the login logs for your break the glass account, you can see this:

Under Additional Details you will see this: User authentication was blocked because they need to provide password reset information. Their next interactive sign in will ask them for this, which the app should trigger next.

Set Self service password reset enabled for Selected like here and target a group:

For this group, you can etc. use this Dynamic membership rule to get all users exclude your break the glass accounts:

(user.userPrincipalName -notContains "master1@domain.onmicrosoft.com") and (user.userPrincipalName -notContains "master2@domain.onmicrosoft.com")

But remember – use etc. a hardwaretoken for your break the glass accounts and keep them safe in a safe 👍

Validate accounts regularly to ensure they works as needed

When you train staff members to use emergency access accounts and validate the emergency access accounts, at a minimum do the following steps at regular intervals:

• Ensure that security-monitoring staff are aware that the account-check activity is ongoing and works so the notifications is working, and the right pepole get it!
• Ensure that the emergency break glass process to use these accounts is documented and current.
• Ensure that administrators and security staff who might need to perform these steps during an emergency, are trained on the process.
• Update the account credentials, in particular any passwords, for your emergency access accounts, and then validate that the emergency access accounts can sign-in and perform administrative tasks when needed in an emergency (hope never we need it!) 🤪
• Ensure that users have not registered Multi-Factor Authentication or self-service password reset (SSPR) to any individual user’s device or personal details.
• If the accounts are registered for Multi-Factor Authentication to a device (like FIDO key´s), for use during sign-in or role activation, ensure that the device is accessible to all administrators who might need to use it during an emergency. Also verify that the device can communicate through at least two network paths that do not share a common failure mode. For example, the device can communicate to the internet through both a facility’s wireless network and a cell provider network.

These steps should be performed at regular intervals and for key changes:

• At least every 90 days
• When there has been a recent change in IT staff, such as a job change, a departure, or a new hire
• When the Azure AD subscriptions in the organization have changed

Thank you for taking the time to visit my blog. Kindly share it with others if you find it helpful for them! 😉🔐👍

Stay tuned for the new post about something cool! 🥳