Best Practices for Emergency Accounts

Break The Glass or emergency accounts are a necessity in the cloud world we live today. Every year Azure AD goes down for a few hours because of some Multifactor Authentication issue. This means none of your users are able to log in. As this is problematic, you need to take action to prevent these kind of scenarios.

Microsoft themselves acknowledge this scenario and advises you to create two emergency accounts to protect yourself from outages like this. In this blogpost I will go over some best practices I like to use when I am creating/managing emergency accounts.

Amount

The first question you should ask yourself: “How many emergency accounts will I create?” Well in theory you only need one. But in that case, that account should be working absolutely fine without any hiccups.

The chance that somebody:

• Miswrote the password
• Accidently included it in one policy
• Let the account expire

Are all real issues. That’s why it is always recommended to create two emergency accounts.

Cloud Accounts

Most organizations are currently using Azure AD in hybrid mode where the accounts are created in the local active directory and sync’ed to the cloud using Azure AD Connect. But, please, do not create your accounts in your local AD. Instead, create them as cloud only accounts in Azure Active Directory. This way, a misconfiguration in AAD connect will not mess anything up and it will also prevent lateral movement.

Domain

When creating the accounts, always use the .onmicrosoft.com domain that is connected to your tenant. I recommend using this suffix over your standard domain so that you avoid any issues with your own domain.

This makes sure there are no issues on Microsofts side (routing your domain) or on your side that might prevent you from logging in.

Naming convention

Naming convention is something that I like to implement while setting up emergency accounts. One thing I always avoid is naming the account ‘Emergency’ or ‘Break the glass’ admin. Because if an attacker ever gets ahold of your AzureAD users overview, he could use it to target your emergency accounts as they are most likely not protected by MFA.

Besides that, you can choose whatever name you want. I have customers using regular names (John Doe, John Johnson) or doing stuff like using the names of Greek gods. Pick whatever fits you :).

Password

This might be one of the most important rules for you emergency accounts: “Make the password 128 characters”. 128 characters is the maximum size for an Azure AD password, I would advise you to utilize it. The harder the password, the harder it will be for an adversary to hack it.

But where does one store the password? Some store it in an password manager, others on a physical piece of paper. Writing it down on a piece of paper and locking it away in a vault might be the most secure, but it does bring some challenges. You need to make sure you can secure the physical location and in the event of an outage, you will need to have physical access to the vault (which might not be that easy for remote teams).

Conditional Access

Because this account needs to protect you from potential outages, you need to exclude this account from having multifactor authentication. I also recommend to exclude it from every conditional access policy you have. Create a group, add your two emergency admins and exclude them from every policy. That way, you can be sure you won’t be affected in any CA/MFA outage.

Because of this, emergency accounts are compatible with security defaults.

Monitoring

Because these accounts aren’t protected by any form of Conditional Access or Multifactor Authentication, you need to be notified in the unlikely event an attacker has breached the account. That’s why monitoring the sign-in logs for this account is key.

Monitoring the account can be done manually, but I prefer to do this automatically ofcourse.

It’s possible to do this through Log Analytics (I have blogged about it in the past). But Cloud App Security can also be used for this. As it is really easy to setup a custom rule for this, I prefer to do it this way. Keep an eye out for my tutorial on that!

Validation

Validation is the last step and is often forgotten. But it is of the upmost importance to test your setup regularly! Make sure you try logging in with the account and verify you are not prompted for any security feature (MFA, Conditional Access policy) and check if your logging is functioning as expected.