This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Community Hub.

Happy Halloween!  It's my favorite holiday, because candy is my favorite food.  In my last post, I covered some Business Continuity Disaster Recovery (BCDR) thoughts on exporting critical configurations for some of your Microsoft 365 cloud services.  That got me thinking about a couple more aspects of BCDR, so here are some tricks and treats for your cloud processes. 

Let’s get to it.   

Break-Glass Azure AD Accounts

You should create emergency-use "Break-Glass" (BG) cloud IDs in case (when) there are service issues.

Official Microsoft Guidance - Manage emergency access admin accounts - Azure AD - Microsoft Entra | Microsoft Learn

Hilde’s $0.02

• Generate a long, random, complex password, split it in pieces and store the pieces separately, securely and possibly with the UPN for the ID.
  • In sealed envelopes, in lock boxes?  In safes?  In the data center?  In the DR kit/tubs … somewhere easy/fast to get to, per your BCDR processes.
• Make sure that your BCDR processes account for these cloud elements – creating/cracking open these sealed password stores, using the accounts and cycling the passwords for them.
  • On the sealed envelopes, I’d add the date/time the passwords were generated, names of at least three people involved with this process and their cellphone numbers, even perhaps their signatures.
  • I’d add a blurb about the use-case/procedures and ‘process rigor’ that should accompany opening them.  These aren’t just ordinary envelopes.
  • Storing the UPNs with the password might raise some eyebrows ... but in the heat of an incident, people might not remember what the actual recovery IDs are - and the password is split into chunks, too (right?!).
• FIDO2 is a valid option for the BG accounts
  • In my view, though, it may add confusion and complexity at a time when you need drop-dead simple
    • “Where’s the FIDO2 key?”
    • “What’s the PIN for it?”
    • “Who’s biometric/fingerprint is attached to it?”

Monitoring for Break-Glass Account Sign In

Hopefully, you have monitoring and alerting for sign ins by your elevated/sensitive/admin IDs – likely via a SIEM.  This should include the break-glass IDs, obviously. 

However, you might consider a simple Azure Monitor/Alert for these BG accounts, too.  In my example here, every 5 minutes, a query runs against my Azure AD Sign in log data (that is streaming into a Log Analytics Workspace), trolling for attempted sign in events from the specified IDs.

IMPORTANT NOTE: These sign in attempts do NOT have to be successful to trigger an Alert – but the user account specified DOES have to match.  That means someone who knows the ID is trying (at a minimum) to sign in with it.  Some folks may say ‘We don’t care about sign in failures’ but for these accounts, you totally should care.  If someone knows the ID and is banging away at it, the logs will capture it - and that is cause for at least an Alert.  In my opinion.   

Official Microsoft Guidance - Manage emergency access admin accounts - Azure AD - Microsoft Entra | Microsoft Learn

Hilde’s $0.02

• There is a minimal cost for the Azure Alert processing:

• I setup one Action Group which can be used for multiple Alert Rules.  In the Action Group, I defined an email "action" (sending to a monitored email account) and an SMS "Action" (sending a text to a monitored cellphone)

• Then I setup two “Alert Rules” – one per BreakGlass user ID
  • “BG01@domain.com” is the fictional ID being monitored in this example
  • For the query in the "Condition," I entered the target ID for the corresponding Alert Rule I was creating:

• IMPORTANT:
  • The “Alert rule name” value comes through in the email subject and SMS text
  • Due to this fact, I used the target ID as the first part of the “Alert Rule Name” (see the red box in the screen shot below) 
  • Now, when I get the email and/or text, I can immediately see which ID the alert fired for
  • You can’t - CANNOT - rename Alert Rules today, so name it appropriately when you create it – or you’ll have to recreate it.  Care to guess how I know?  

• When I created the Alert Rules, I specified the "Severity" for these as “Critical” (which is just an arbitrary tag)

• Now, every 5 minutes or so, if the Alert Rule discovers a sign-in attempt for one of the monitored accounts, an email and a text message both get sent (per the Action Group settings).
  • Here’s an example of the Alert's email subject:
    • NOTE: As I said above, the Alert Rule has the monitored ID as part of its name, so I can see right away which ID triggered the Alert (BG01 in this example)  
    • NOTE: the date/time value in the email subject line is UTC

• • Here’s an example of the Alert's SMS text:
    • NOTE: the Alert Rule name here, too, telling me which ID attempted to sign in (again, BG01 in this example)

Ok folks – there you go.  Just a couple more BCDR tips for you.   

If you already have these set up in your environment, KUDOS to you for being proactive!  That’s GREAT! 

A HINDSIGHT NOTE:  I said above that I named the Alert Rule so I could 'see' which ID the Alert was generated for, and in my screenshots, I show the name of the Alert Rule as "BG01 Signed in to AAD".  However, as I also mentioned above, the sign-in doesn't need to actually succeed to trigger the Alert.  As I proof-read this post, I realized I should have perhaps named the Alert Rule "BG01 Attempted to sign in to AAD."  It's a nitpick, I know, but I thought I should point it out here, as I'm too lazy to go re-do all of my Azure settings and screenshots.

Hilde