09/07/2024 – Update 2

Microsoft enforce since 1st of July 2024 the need for Multifactor Authentication if a account access the Azure Portal. This also affects Break Glass accounts when the will use to access the Azure Portal. To reflect this new requirements classic Breakglass Accounts which only have a password enabled for login will won`t work after the rollout.

Microsoft recommend to use FIDO2 or certificate based authentication for these accounts. I`ve updated the article to enable FIDO2 for Breakglass accounts.

19/01/2022 – Update 1

I´ve updated the article because the actual sign-in query only logs all login attempts of the break glass account (successfully, unsuccessfully, etc.) . I added the different IDs so that you can setup the alert mail based on a indivudal filter. Thank you goes out to Eric Soldierer for this note. I also updated some changed services that had left their preview status.

---

In the past I do a lot of Azure Governance workshop and one interesting topic is how to handle the Break Glass Account. Before we going deeper, first we take a look was is the Break Glass Account. For each Administrator role in Azure or Office365 is it best practice to use MFA to secure the account and get a better security for the Tenant. To realize this, normally we use Conditional Access and create a rule, that every Admin require MFA for login. But what can we do, when:

• the MFA service is down
• we create a Conditinal Access that with a wrong rule set and lost sign-in access
• we do not regulary update our control list and the admin account goes lost

For this cases we need a Break glass account, an additional account with a high security password, to enter the Tenant in an emergeny case. For this account, there are some recommendations:

• only use a generic account
• create a complex password with more than 16 characters
• use a seperate FIDO2 key for every breakglass account
• up to 256 characters possible – the limit of 16 character is removed
• for compliance reason divide the password into two parts
• save each part in a different location
• create a security group that contains the break glass accounts
• create two break glass accounts with no standard username like breakglass@ or emergency
• use the Tenant name for the account
• do not use a custom domain name
• in futher it will be possible to use FIDO2 security key for break glass (right now is in preview and not recommended for such critical scenario)

Now we can discuss in some ways a security gap – a service account with Global admin rights that do not require MFA for login. The use of a generic name can be a risk and the usage of this account most be transparenet for every tenant admin. Now you see, why it is so important to monitor this accounts and get notified when they will be used for login.

General

This article will focus how to monitor a break glass account when a login will be triggered. To get more details about handle emergency accounts, take a look at the really useful article “How to implement and manage emergency accounts access accounts / break glass acounts” from my good friend Thomas Naunheim. If you are interested in this and other information about Cloud Identity Management, please take a look at our Identity Summit, where we will discuss various topics related to securing your identity.

Break Glass Account best practices

My prefered way to handly this account is:

• create a separate Office 365 group mailbox
• grant access to the group mailbox for each Azure Admin Team
• another great idea can be to set up a MS Teams channel for receiving security mails
• Create a Log analytics workspace
• Enable under “Azure AD -> Sign- ins -> Diagnostic settings -> SignInLogs -> Send to log analytics” and choose the created Log analytics workspace

This are my recommendation, but you can use every available Mailbox or Azure App or mobile number to get notified when the account will be used.

Create a break glass account

First check your Azure AD and take a look at available Generic accounts with Global Admin rights. I recommended to have not more than two break glass accounts (depending on the environment).

Create a security Office 365 group and assign the break glass account to this group.

Tip: Use the created break glass account once before continuing so that Azure AD has a result for the next steps.

Enable FIDO2 key for breakglass accounts

When you have Entra ID P1 or P2 in place, it is recommend to setup a Conditional Access rule which will require FIDO2 Keys for the Breakglass accounts and group this accounts in a seperate Entra ID security group.

To set this up, go to Conditional Access blade which you can find via the Azure Portal -> Microsoft Entra ID -> Security.

Go to Policies and take New policy from template where you can find under Protect administrator the template “Require phishing-resistant multifactor authentication for admins”.

After you enroll this policy with a prefered name select the Policy and reconfigure it a little bit and change the User settings to include only a Entra ID group which containts the Breakglass accounts.

Get the break glass account id

Go to the Azure AD User blade and choose the created Break glass account and notice the Object-ID for later.

Query Sign-Ins about Break-glass

In this example I used a simple query only to monitor one break glass account with the object-id.

Navigate to the Log analytics workspace and select the workspace in which the Azure AD sign in logs will be stored.

Navigate inside the Log analytics workspace to the point “Logs“.

Now you get a window called “New Query 1”. We can place querys based on the KQL language in this field to query all available data into our log analytics workspace. Here we put the following query in:

SigninLogs
| project UserId
| where UserId == “Place-the-break-glass-account-object-id-here”

This query alerts all login attempts as successful login, but you can filter the query with additional IDs to get only notified when a real successful login occurs and faulty logins will not fired.

The following query fired only on successful logins, faulty logins will not been notified:

SigninLogs
| where UserId == “Place-the-break-glass-account-object-id-here”
| where ResultType in (0, 50140, 50055, 50072)

• ResultType ID 0 =
• ResultType ID 50055 = InvalidPasswordExpiredPassword 
• ResultType ID 50072 = UserStrongAuthEnrollmentRequiredInterrupt 
• ResultType ID 50140 = KmsiInterrupt 

With these IDs you can filter which login attempts are fired and receive notification via the configured message option (mail, SMS, etc.).

Click on the blue “Run” button, if you have used the broken glass account in the selected period, you will get some results in the lower part of the window.

Generate a Sign-in alert

With this result we can create a Alert rule for this sign ins. Select the “New alert rule” option.

In the new windows we can configure the alarm rule and the recipients for this alarm.

Click the link under “Condition name” to configure the time interval at which the created KQL query should periodically run.

In the first part you see the configured search query and the results of the query – please leave this unchanged and scroll down to the second part of the window.

Configure time for alert rule

First configure the Alert logic: Number of results = Greater than = 0

This means every login of the break glass account will be monitored, because every login is greater than 0.

Configure the time range how often the search query will be fired. The minimum is 5 minutes and frequency minimum is also 5 minutes.

Now we had configure the condition and see how much the alarm cost for a month.

Create a action group for notifications

The next step is to configure the “Action group”. The Action group contains the recipients for Mail, App or SMS notifications. Click on “Select action group” to get the configuration blade and “Create action group“.

Type a action name and select under Action Type the “Email/SMS message/Push/Voice” option. Now we get an additional window to configure the recipients.

Tip: There are many more options to configure, like a Logic App to configure additional tasks, when a Break glass account login was detected.

Configure the recipients for the fired alarm. Keep in mind to create a separate Azure notify group mailbox and add the Cloud Admin team to this group so that all Admins get a notify about the fired alarm. Additional you can send Azure App Push notifcations or enable SMS or Voice message.

Customize the alarm mail

With the creating of the action group we had finished when the alarm will fired and which people will arrived with the notify. Now we had to configure how the Email looks like for the recipients.

Finally we configure the Email message that we get, when the alarm is fired. so place a meaningful Subject line, Alert rule name and description to the Alarm and set the severity level. Take a look of my examples.

Now we are finished and we can “Create alert rule”.

With this steps we finished the creating of an notification when the Break glass account will be used for login. Keep in mind this is a very important step for every tenant. From my perspective this must be done as a first step, when the tenant is created to increase safety.

The email that the recipients receive looks like this when the break glass account is used for login.

Please note: There is a delay when the login event is registered and when the login event is received by the log analytics workspace, so that the alarm is triggered. Keep this in mind and consider monitoring the changes to the alarm settings as well.

This is one solution to monitor the break glass account. To see additional solutions or more details about handle emergency accounts, take a look at the really useful article “How to implement and manage emergency accounts access accounts / break glass acounts” from my good friend Thomas Naunheim.

If you are interested in this and other information about Cloud Identity Management, please take a look at our virtual Cloud Identity Summit, where we will discuss various topics related to securing your identity. We will also have upcoming Cloud Identity Summits – take a look at the website and stay tuned.

Feedback is very welcome, please use the comment function or reach me via Twitter. 🙂

Links

• MS Docs – Azure AD Authenticatio and authorization error codes
• Update on MFA requirements for Azure sign-in – Microsoft Community Hub