Azure Active Directory is Microsoft's Identity Management-as-a-Service solution, offering seamless access, easy collaboration, efficiency in IT processes and improved security and compliance. For administrative access at al times and under all circumstances, Microsoft recommends to create at least one emergency access account in Azure Active Directory when an organization has Azure AD Premium P1 and/or Azure AD Premium P2 licenses assigned to their users and admins.

The challenge with emergency access accounts

The challenge with emergency access accounts is that they have the highest privileges in Azure Active Directory (and beyond) through the Global Administrator role, are not assigned to specific people in the organization (they are not ‘named accounts’).

Of course, to meet all emergency situations, these accounts are not governed through any Conditional Access policy; they don’t require multi-factor authentication when signing in and they’re not limited to certain locations or device specifics.

As these accounts only live in Azure Active Directory and typically have a username that ends in *.onmicrosoft.com, sign-ins for these accounts typically don’t end up in on-premises Security Incident and Event Management (SIEM) implementations, either.

As a result, emergency access to Azure AD is a blind spot in many organizations. To avoid misuse of the emergency access account(s), a good solution would be to have people notified when the account is used to sign in.

When is an emergency account used

An organization might need to use an emergency access account in Azure Active Directory, when:

• User accounts for people in the organization and other privileged access are federated, and the federation implementation becomes unavailable.
• The administrators are registered through Azure Multi-Factor Authentication (MFA), and all their individual devices are unavailable or the service is unavailable.
• All synchronized account with privileged access have been deleted and/or disabled on-premises.
• Unforeseen circumstances such as a natural disaster emergency, during which a mobile phone or other networks might be unavailable.

Of course, for the second scenario, an emergency access account with the privileged authentication admin (when multi-factor authentication is set per-admin) or the Conditional Access administrator (when multi-factor authentication is set through Conditional Access) would suffice.

How to get notified

To build the solution to have people notified when an emergency access account is used to sign in, we’ll use Azure Log Analytics and Azure Monitor alerts.

Step 1: Set up a Log Analytics workspace

As the first step, set up a Log Analytics Workspace. As Azure subscriptions, by default, do not get configured with a Log Analytics workspace, the first step is to create a Log Analytics Workspace. Perform these steps:

• Sign into the Azure Portal with an account that has Global administrator privileges and is assigned an Azure AD Premium license.
• In the Azure portal, click All services. In the list of resources, type Log Analytics. As you begin typing, the list filters based on your input. Select Log Analytics workspaces from the list.
• Click + Add.
  The Log Analytics workspace blade appears.
• Fill in the required information to add a Log Analytics workspace.
• Click OK on the bottom of the blade to create the Log Analytics workspace.

The pricing model for Log Analytics is per ingested GB per month. However, the first 5 GB per month is free. Data ingestion beyond 5 GB is priced at $ 2.328 per GB per month. Ingesting Azure AD with Log Analytics will mostly result in free workspace usage, except for large busy Azure AD tenants.

Note:
If you do (expect to) hit the limits of free workspace usage, you can opt not to send audit logs to the Log Analytics workspace in the next step. It’s not necessary for this scenario.

Step 2: Integrate Azure AD logs into Log Analytics

Perform the following steps to route audit activity logs and sign-in activity logs from Azure Active Directory to the Log Analytics Workspace:

• While still logged on in the Azure AD Portal, click on Azure Active Directory in the left navigation menu.
• Select Diagnostic settings in Azure AD’s navigation menu.
• In the main pane, click Add diagnostic setting.
  The Diagnostic settings blade appears.
• On the Diagnostic settings blade, provide a name for the diagnostic settings.
• Select the Send to Log Analytics workspace check box.
• Select the Log Analytics workspace you want to send the logs to, or create a new workspace in the provided dialog box.
• Do either or both of the following:
  • To send audit logs to the Log Analytics workspace, select the AuditLogs check box.
  • To send sign-in logs to the Log Analytics workspace, select the SignInLogs check box.
• Select Save on top of the blade to save the diagnostic settings.

Allow for ample time for the diagnostic settings to apply and the data to be streamed to the Log Analytics workspace.

Step 3: Create the notification

The last step is to act on the logs that are streamed to the Log Analytics workspace:

• While still logged on in the Azure AD Portal, click on Monitor in the left navigation menu.
• click on Alerts in Azure Monitor’s navigation menu.

• Click on the + New alert rule link in the main pane.
• In the Scope area make the following changes:
  • Click the Select resource link.
    The Select a resource blade appears.
  • From the Filter by subscription drop-down list, select the Azure subscription containing the previously created Log Analytics workspace.
  • From the Filter by resource type drop-down list, select Log Analytics workspaces.
  • In the Resource list, select the previously created Log Analytics workspace.
  • Click Done at the bottom of the Select a resource blade to save the settings and close the blade.
• In the Condition area make the following changes:
  • Click the Select condition link.
    The Configure signal logic blade appears.
  • In the Signal name list, select Custom log search. This is the top signal in the list.
  • In the Search query field, type the following query, while replacing user@domain.tld with the actual sign-in name of the emergency access account:SigninLogs
    |where AlternateSignInName contains "user@domain.tld"
    
  • For the Alert logic specify the value 0 for Threshold value.

• • Click Done at the bottom of the Configure signal logic blade to save the settings and close the blade.
• In the Action group area make the following changes:
  • Click the Select action group link
    The Select an action group to attach to this alert rule blade appears.
  • In the list with action groups, select a previously created action group, or click the + Create action group, and specify a meaningful name, and short name, select a subscription and resource group, and click OK at the bottom of the Add action group blade.
• In the Alert rule details area, specify a meaningful name in the Aler rule name field.
• Click the Create alert rule button to create the alert rule and close the Create alert rule pane.

When you set up the alert with the above settings, including the 5-minute interval, the notification will cost your organization $ 1.50 per month. When speed is not of essence in your organization (you may have other problems when the emergency access is required), you can lower the cost to $ 0,50 per month by querying with a frequency of 15 minutes, or more.

Step 4: Test the notification

To make sure the notification works as expected, sign in with the emergency access account into the Azure Portal or any other Azure AD-integrated service. This should trigger the alert within 5 minutes. If it doesn’t, trace back your above steps.

Concluding

To remediate the blind spot your organization may have on the emergency access accounts, create a notification to alert you every time the account is used.