Entra ID

Entra ID is Microsoft’s cloud-based identity and access management (IAM) service. It is used by both Microsoft 365 and Azure to store user accounts and allow access for those accounts to resources. These resources will be Azure resources, but Entra ID can also be used to grant access to non-Azure resources. (The non-Azure part will be discussed in a future post.)

Entra ID was previously known as Azure Active Directory which was usually shortened to Azure AD or AAD.

Identity & Access Management (IAM)

One of the main jobs of Entra ID is an identity service. An identity service is something that contains security principals. These security principals are authenticated (signed-in) with Entra ID, and then authorized by Entra ID to use a resource, such as a storage account.

This is a generic IAM flow. See How IAM works for a deeper dive.

User Accounts

The most common security principal is a user account. A user account represents a single person that will usually have a username and password. They are generally going to log into a thing and then do something to that thing. If you use Exchange Online, you log into the Microsoft 365 service using your username and password and then you send mail.

Service Accounts

But not all security principals are users! What if you have a task that runs nightly, such as a script that runs every night to copy files from one file server to another file server? That script needs to run as some type of account. If you’re lazy, you’ll use your own user account, but there are several problems with that.

• You’re probably going to have to store your account password somewhere in plain text on the server so the script can run as you. Another person who has elevated access to that server can read your password and then pretend to be you to send dirty, filthy videos to your boss and get you fired.
• Your password will likely change at which point the job will stop working.
• Should your account even have permission to the server where the job is running?

Service accounts work differently in different environments but usually allow you to configure a service to securely run without having to specify a password or granting the service full access to the server. Azure has a couple of names for service accounts, but they are officially known as service principals. We’ll talk more about service accounts in the near future.

Authentication & Authorization

These concepts will come up again, so they’re important to define. Authentication is verifying that an account is indeed who they say they are. In the real world this would be done with a physical ID, such as a driver’s license. In the electronic world, this is most commonly done with a password. You’re the only one who is supposed to know the password associated with your account, so that’s how you prove who you are.

Authorization is what an account is allowed to do and is a distinct concept from authentication. In the real world, you may prove who you are, or authenticate, in the lobby of a building, but that doesn’t mean that you are authorized to go into any of the rooms in that building. Similarly, in the electronic world, you may sign into your cloud provider but not be able to do anything after that.

Authentication and authorization are at the heart of the IAM service that Entra ID offers.

Windows Active Directory

If your organization currently has a Windows Active Directory environment, Entra ID can be integrated with Windows Active Directory which we’ll talk more about later. If you don’t have Active Directory, let me suggest that you keep it that way and rely completely on Entra ID for your directory.

Active Directory runs on a Windows Server and is not the same thing as the previous name of Entra ID which was Azure Active Directory. Mercifully, Microsoft changed the name to Entra ID to avoid confusion like this.

Entra ID Security Best Practices

The following recommendations are are pulled from Microsoft’s best practices for Entra roles which you should follow. Below are some particularly important ones.

Entra ID is a security product, and I implore you to take security seriously and don’t stop at just this post. Incremental security improvement is better than no progress at all! See Introduction to Azure security to start your journey.

Global Administrators

Entra ID has a role named Global Administrator, which lets you do whatever you want on the tenant. Since it’s so powerful, there are a few best practices you should follow.

• Limit the number of Global Administrators to less than 5.
• Turn on multi-factor authentication for all administrator accounts (not just Global Administrators).

Multi-factor Authentication

Unless you created your tenant before October 22, 2019, Microsoft has already enabled some default security settings to make it much harder for attackers to gain access to your account. These security defaults do a lot of things you should do anyway, so Microsoft wisely decided to turn them on and make you intentionally disable them if you think you’re so damn special.

One singularly helpful configuration of security defaults is that it enforces multi-factor authentication (MFA) for your Azure users. MFA means that instead of just asking for a password when a user logs on, it asks for another piece of authentication information to prove you are who you claim to be. The secondary authentication information is kind of like second password, but unlike a password, this is generated dynamically so that you don’t know what it will be until you are logging in. Unless this is literally the first time you’ve used a computer (or if you’ve been incarcerated since 2010 - that’s also an acceptable excuse) you’ve seen MFA in action when you’re asked to enter a code that was sent to your mobile device when you log onto your bank. Another MFA method is app-based where you have an app on your mobile device generate a code. The only way someone could get the MFA code is if they steal your phone, which is hard because if you’re like me you have a panic attack if your phone is away for more than three minutes .

You’ll hear some information security folks tell you that SMS (text message) MFA is not secure. I believe this is a gross and irresponsible overstatement (this summarizes the argument nicely). SMS MFA is indeed less secure than app-based MFA, but the hurdles to compromise SMS MFA are high enough that you should definitely use it instead of nothing. You should encourage app-based MFA over SMS, but always use some form of MFA.

In summary, leave security defaults enabled unless you want to take things a step further and use Conditional Access. And if you want to take it even further, consider passwordless authentication.

Emergency Access Accounts

As great as MFA is, you have to depend on MFA working all the time to log in. If there are problems with MFA, then you’ll be locked out of Azure until it’s resolved. For this and other reasons, Microsoft recommends that you create two emergency access (or “break glass”) accounts. For auditing purposes, you want people to access Azure using their assigned accounts, so these emergency access accounts should only be used for - well - an emergency.

As the documentation explains, you’ll want to exclude at least one of these accounts from MFA. But that makes these accounts more vulnerable, so you’ll want to monitor and alert if these accounts are ever used. But hey guess what?! Setting up the infrastructure to do exactly that will be one of our first infrastructure as code projects, so stay tuned!