Today I’d like to share my solution for Emergency Account setup for Entra ID.
History point of view
We are living in the ear of multiple cyber threats. Every month I’m able to find new information regarding companies hit by hackers, ransomware, etc. Because of that some time ago well-known practice called ‘Break Glass Acocunt’ setup for On-premises Active Directory was duplicated to Azure AD at that time, and now Entra ID after the name change.
The main idea following this setup is to protect our cloud kingdom by having a dedicated account(s) that can be used in case of emergency (attack, account lockout, disaster recovery, you can call it whatever you want).
Before we start the theory and setup let’s walk through the prerequisites.
- Microsoft Entra ID tenant – Our cloud kingdom – the place that we want to protect
- User Account – our BGA account(S)
- Secure Envelope – to store password
- *FIDO2 compatible key – this is optional. (optional in cases with P2 license)
Having 2 dedicated BGA accounts will allow us to have a direct line into our Entra ID tenant in case of any emergency. The process around BGA should contain the following areas:
- Cloud Only Account – it should not be federated or migrated from on-premises.
This account should have upn with *.onmicrosoft.com domain.
- Store credentials safely
- Monitor account activity
- Validate account regularly
For BGA account names I will use my favourite examples:
- Justin Case
- Casey Worste
So let’s start the fun 🙂 and configure BGA in our tenant
We have to start from scratch meaning we need to create new account(s).
I will focus on the Casey Worste user.
It has to follow the principles below:
- Cloud-only account with *.onmicrosoft.com user principal name
- Complex password
- Permanent assignment for Global Administrator role
- No MFA*
- Excluded* from all policies under conditional access policies same as in indentity protection**.
* I know that most of security teams will dislike this approach but it is recommended by Microsoft as well, and we will monitor it properly.
** Nowadays it’s recommended to move to Conditional Access policies for managing Sign-In and Risky user policies.
You can do this either manually or using this script from my repository. I have described 2nd option below
Actually, we have 2 options here:
- Create a complex password and divide it into 2 secure envelopes. Store it in 2 places (safe boxes)
- Enable authentication strengths for the BGA account assign a Fido2 key and give the key to one place when the pin is stored in a secure envelope.
All mentioned two solutions require 2 people to use BGA – either the password is shared only partially or someone has a key and somebody else has a pin.
In order to set BGA monitoring we have to have an Entra ID P1 license (it is required by the Diagnostic settings of Entra ID)
So if you already have configured Diagnostic Settings for Entra ID that means you can go to Log Analytics Workspace and create alerts for your BGA.
A couple of hints regarding this monitoring:
- Focus on BGA Object ID instead of names
- Create Action Groups that will include more than one user email – preferably it should be a distribution group.
- Monitor activities such as:
- Account successful login
- Account failed login
- Account Lockout
- Account properties change
- The account added to a role in Entra ID
- The account removed from the role in Entra ID
- The account added to the group
- The account was removed from the group.
On paper /or design everything works fine so I highly recommend checking if our design is working according to the assumptions.
I recommend performing quarterly reviews of the BGA configuration and then resetting the password to a new one.
As you noticed (I hope) BGA setup is not so complicated.
Within a few clicks, you can at least sleep well without any pressure in case of any emergency situation.
I hope also that all of that is well known for you and your tenant is secured the right way :).
Stay tuned for the next article…