Image Generated by Copilot 🙂
I get a lot of questions around best practices for break glass accounts in Microsoft 365 so wanted to document them in this article. To avoid locking yourself out of your Microsoft account, its advised (from Microsoft) to create 2 break glass accounts, one of which is excluded from all Conditional Access policies in your tenant. Let’s break down the ways in which you should create and manage these accounts.
1. Basic Attributes
Here are some of the common properties of the user you want to keep in mind:
- The accounts are not identified with a particular person
- You do not want this associated with an individual or account that is actively logging in each day for work related task (i.e. answering email, chatting on Teams, etc.)
- A naming convention is used that is unique enough that it would not be used in password spray attacks or readily identifiable in AD.
- Do not use: “breakglass@domain.com”, “emergencyaccess@domain.com”
- Here is a convention I like to use: “svr_ea_01@domain.onmicrosoft.com”
- The accounts are cloud-only
- If you are running a hybrid environment, you do not want this user syncing up from local AD. This makes the account more susceptible to lateral movement and multiple areas of compromise.
- The accounts use the default .onmicrosoft.com domain and not the organizations
- (to avoid domain and federation issues)
- The accounts are unlicensed
- These accounts shouldn’t need a license here as their primary function is to regain access in the situation of a lockout
2. Passwords
By default upon creation, you are going to have to set a password for the user. Here are my best practices there:
- Generate a 32 character + password
- Technically you can generate up to a 256 character long password upon user but I like doing at least 32 characters.
- Passwords do not expire
- Make sure the password policy is set to do not expire. This should honestly be your default setting in the tenant already.
- Break the password up and store it in separate locations
- Legacy post will tell you to break parts of the password up in physical envelopes that you store in a fireproof location. While that could still be done, I like to store them in a digital location. Preferrable I will store one part in my documentation tool (i.e. Hudu/IT Glue) and the other in Azure Key Vault. The thought here is that if the documentation tool is compromised, the breach would only include part of the password.
3. MFA
A common misconception is that you are not configuring these accounts for MFA given you are going to be excluding them from MFA policies. That is incorrect. Always set up MFA on these accounts when they are initially configured prior to adding them to exclusions. Here is my reasoning behind that and best practices:
- I am only going to be excluding one of two accounts from all Conditional Access Policies. I want MFA to be enabled to leverage on the account that isn’t going to be excluded.
- Use Phishing-resistant MFA on these accounts like FIDO2.
- YubiKeys are my go-to here for the MFA method used. Even if you exclude a break glass user from Conditional Access, you can still use the Sign in options flow in the sign in process to never enter a username and password for authentication. While unlikely, this could prevent man-in-the middle attacks on these account. Additionally as we will see later, you can uniquely screen for sign ins with this account that don’t use this MFA flow and instead use UN/PW.
- You can set up multiple YubiKeys for one account to be used as a backup in case one is lost.
- Don’t use weaker forms of MFA like SMS/Phone that also could be subject to downtime in the event of things like a natural disaster. (Personally, I don’t use these forms of MFA for anyone as they are more susceptible to common attacks like SIM swapping, social engineering, etc.)
4. Assignment and Configuration
Like I mentioned earlier, I like to exclude one of these users from all Conditional Access Policies. Here are some of the practices I follow:
- This is a direct exclusion to the CAP vs exclusion as part of a group.
- I don’t have a strong opinion here on if you were to do this as part of a group exclusion but I like to do the direct exclusion to limit the number of users that potential get added to exclusions overall.
- The user being excluded across conditional access is PIM enabled, therefore eligible for GA rights.
- This is somewhat contradictory to Microsoft’s documentation but I do have 1 permanent assignment for the Global Admin role which is to the account that is not part of the CAP exclusions and has the phishing-resistant MFA enabled. I don’t want my user being excluded to have perpetual Global Admin rights. Using PIM, you can ensure JIT access and reduce your attack surface overall.
- Reminder here that PIM requires Entra P2 licensing, so this is traditionally harder to implement in our customer environments. I personally would eat the cost of putting in one Entra ID P2 license ($9/m) to have this additional layer of protection but will always try to pass through to the customer.
- PIM is configured so that MFA is required to activate
- Some might argue that this is not best practice given it could lead to more chances of you being locked out of the account if you cannot fulfill the MFA request but I’d rather have the additional layer of protection.
5. Monitoring and Alerting
Microsoft’s documentation includes steps you can configure to set up alerts when activity is seen against these accounts. (Pro-Tip: Sidebar but setting up Azure Monitor is a best pracice no matter what so that you can retain sign-in logs for more than the default 30-day rolling window)
You would create an alerting rule here that could generate a ticket in your PSA tool when activity is detected. This would help you become proactive to ensure that there is no malicious use and/or compromise of these accounts.
Using CloudCapsule to help review these accounts
I built a tool you can leverage to help monitor for break glass accounts across customers. This would allow you to easily see:
- All Global Admins in the account
- Break glass accounts being excluded from Conditional Access
- Last sign in time for break glass accounts
- MFA methods used on breakglass accounts
You can run a free assessment with the tool to see what this looks like in your environment.