It’s obvious that the cloud environment needs to have emergency account(s) (aka break glass) to build a resilient Azure AD environment. These accounts should only be used when normal admin can’t sign-in.

There are many blogs and Microsoft docs about management best practices of the emergency accounts. And yes, you actually should have two of them. Below is a link to an excellent blog deleted this topic:

Monitor Emergence Account Activity

One of the highlighted items for emergency accounts is monitoring. These accounts have high privileged permission to a cloud environment and it’s critical to monitor account activity properly. Referring to the Microsoft RSA presentation, 1.2 million of their cloud accounts were compromised alone in January 2020. I can bet that any organization doesn’t want to have emergency accounts in this list.

Options

Azure Monitor Alerts

Before Azure Sentinel existed, I implemented emergency account monitoring with Azure Alerts feature. It works like a charm but is not as flexible as Sentinel rules. The same KQL query makes a trick in Azure Monitor than in Sentinel.

Azure Sentinel

With Sentinel, a bit more can be achieved. I have created two rules in here.

  • Emergency Account Successful login
  • Emergency Account Failed login

Why two different rules? Because, the successful one is much more critical than the failed one.

You can see that there are a different colors in front of the rule. Red means “High” and Orange means “Medium”. Naturally, playbooks could be integrated for the rules to mitigate possible breach. Extra caution is needed with automation because there might be situation where automatic mitigation should not occur if immediate access with the account is needed.

Emergency Account Successful Usage

The rule logic is following:

  • Raise an alert if there is emergency account successful login (status=0) found in last 15min time domain
  • Run query in every 15min against Azure AD sign-in logs
  • Generate an alert when the threshold is greater than 0
  • Run a playbook and send message to Security Team Teams channel
SigninLogs
| where UserPrincipalName == "ema1@fetads.onmicrosoft.com" 
| where Status.errorCode == 0
| extend AccountCustomEntity = Identity
| extend IPCustomEntity = IPAddress
| extend HostCustomEntity = SourceSystem

Emergency Account Failed Usage

The rule logic is following:

  • Raise an alert if there is emergency account failed login (status !=0) found in last 10min time domain
  • Run query in every 10min against Azure AD sign-in logs
  • Generate an alert when the threshold is greater than 0
SigninLogs
| where UserPrincipalName == "ema1@fetads.onmicrosoft.com"
| where Status.errorCode != '0'
| extend AccountCustomEntity = Identity
| extend IPCustomEntity = IPAddress
| extend HostCustomEntity = SourceSystem

Log Analytics – The Raw Data

Just to verify sign-in status codes from Log Analytics

Conclusion

Simple and effective! Pay extra attention how to manage Azure AD emergency account(s) and especially how to monitor account(s) activities.

Microsoft best practices document – Manage emergency access accounts in Azure AD