Emergency Access in Azure AD

Azure AD has some powerful features such as Conditional Access that can lock you out of your own environment if not configured correctly. It is therefore recommended by Microsoft to create at least two emergency users that can be used to regain access to the tenant in case of an emergency. Sadly I have seen too many organizations that either do not have emergency users at all, or their deployment is inadequate. In this post we will discuss why all organizations need to implement break-glass-accounts (as Microsoft calls them) and how to implement this in Microsoft 365 / Azure environments. It should also be noted that it is technically possible to user a Service Principal (App Registration) instead of a User account, which has its own pros and cons but is beyond the scope of this post.

Use the following guidelines when creating break-glass (emergency) accounts. The list below include both Microsoft’s and my own recommendations.

• At least two break-glass-accounts should be created.
• At least one break-glass-account should be cloud-only (not a synchronized user).
• Excluded from ALL conditional access policies.
• Excluded from Multi-Factor Authentication (MFA) **
• Excluded from Self-Service Password Reset (SSPR).
• Excluded from Identity Protection (for example MFA registration policies).
• Permanent Global Administrator assignment
• Should not be associated with any specific individual.
• Should only be used as a last resort (only when necessary).
• Monitor usage and sign-in attempts closely.
• Reset passwords after each use.
• Passwords should be random generated and at least 16 characters.
• Store passwords securely (make sure the password storage solution is available in an emergency)
• Frequently test break-glass-accounts users and routines associated with them.
• Limit the amount of people who have access to break-glass accounts and passwords.
• Multiple people should be alerted if a break-glass user is used.

** MFA can still be enforced on break-glass accounts, but consider using multiple Multi-Factor Authentication providers so that you are not dependable on a single provider such as Azure MFA. See Microsofts documentation here.

Hopefully it should be fairly obvious to most people as to why these accounts should exist. The top reason was mentioned already, Conditional Access. Having one or more users that are excluded from all Conditional Access policies will allow you to get back into your environment without involving Microsoft support. Another example could be If Microsoft has issues with their MFA service (this has happened multiple times before). In this scenario users might be unable to access corporate data in Microsoft 365, potentially halting production. Having a break-glass user in place that could be used to implement a temporary exclusion/mitigation, and allow critical business activities to continue (possibly preventing losses for the company) is essential for any company.

Monitoring and Alerts

At this point our break-glass users have quite a lot of privileges but very little security, so we need to keep a close eye on them. To do that we will use Log Analytics and Azure Alerts to monitor sign-in events for our break-glass accounts.

Note: Certain steps will require an Azure AD Premium License and an Azure Subscription.

Log Analytics allows you to store, search and query logs, not only from Azure AD but also from other Azure services and on-premise servers. Since Microsoft only provides 30 days of sign-in and audit events in Azure AD, it is considered a best practice to retain these events from a security perspective. Creating a Log Analytics Workspace is also the first step to implement Microsoft’s Security Information and Event Manager (SIEM) Azure Sentinel, though that is beyond the scope of this post.

The high-level tasks we need to do are:

• Create a Log Analytics Workspace
• Forward sign-in/audit information from Azure AD into Log Analytics
• Create Alerts

Log Analytcis Workspace

1. In the Azure Portal search for Log Analytics Workspaces and click Create.
2. On the Basics page, give your workspace a name and specify a resource group and a subscription.
3. On the Pricing Tier, select Pay-as-you-go in order to pay per GB of stored data in the Log Analytics workspace.
4. Click the Review + Create button to create the workspace.

Next we need to tell Azure AD to forward sign-in and audit logs to our Azure Log Analytics Workspace.

1. In Azure AD select the Diagnostic Settings blade in the Monitoring section near the bottom.
2. Give your diagnostic setting a name and select the logs to collect. To monitor our break-glass accounts we only need the SignInLogs, but I recommend collecting all the logs.

If you would like to verify that events are being forwarded, open the Log Analytics Workspace and Select Logs in the General section. If the Queries window appears simply close it (explore this later to explore your data further). Type SigninLogs into the query window and click Run. Note that only new events will be forwarded so if there are no results try to login with a test user then running the query again.

Alerts

Now that we have forwarded events from Azure AD to our Log Analytics Workspace we can setup Azure Alerts to notify us if certain events occur, like sign-in attempts for our break-glass users. There are many other rules/queries that can help in monitoring your Azure AD environment

1. In the Azure Portal search for Alerts and then select New Alert Rule.
2. Start by defining the Scope, which is our Log Analytics Workspace. Select the subscription then filter Log Analytics Workspaces. Select the correct Workspace and click Done
   
3. Under Condition select Add Condition
4. In the Select Signal window that appears search and select Custom Log Search
   
5. In the Configure Signal Logic window locate the Search Query box and enter the query below. Make sure to replace with your break-glass user UPN. This query will alert when a break-glass user successfully signs-in. Should you want to monitor logon attempts that are not be successful then make the following change to the query: ResultType != 0.

SigninLogs | where ResultType == 0 and (UserPrincipalName == "[email protected]" or UserPrincipalName == "[email protected]")

6. Configure the Alert Logic section as follows:
   Based On: Number of Results
   Operator: Greater Than
   Threshold Value: 0
   
7. Finally in the Evaluation Based On section specify 5 for both the Period and Frequency. This will run the query every 5 minutes.

The Configure Signal Logic window should look like the example below.

The logic for our Alert is now complete. Next we need to create an Action Group. Where we define the recipients and how alerts should be sent.

8. Under Actions select Add Action Group, then press Create Action Group.
9. On the Basic page, specify the Subscription, Resource Group and Name for the Action Group.
10. On the Notifications page, select Email/SMS Message/Push/Voice and provide a name.
11. Configure Email/SMS/Push/Voice to suit your needs. I recommend specifying a distribution list to an Operations or Security team. More than 1 person should be the receiver of these alerts.
12. Leave the Actions page blank and complete the wizard.
    
13. If Email alerting was configured as a notification, select Email Subject under Customize Actions and specify a subject to be used with this particular alert such as: Contoso Alert – Break Glass Account Signed In
    
14. Finally under Alert Rule Details Provide an Alert Rule Name, Description and Severity. Then save the Alert.

Verifying

To test the Alerts, sign-in with the break-glass account. An alert should be triggered within a few minutes. Below is an example of an email that is sent when the rule is triggered.

Important: Make sure that your break-glass users are tested frequently. Many organizations make constant changes to their environments, and Microsoft frequently rolls out new changes to Azure AD.