When you set up an IT environment, one of the first things you need to do is give access to the people who need it. This typically includes system administrators, software developers, and end-users. The solution is to use an identity and access management system.

The one that’s most commonly used for on-premises environments is Microsoft’s Active Directory. It allows you to create and manage user accounts. Then when a user logs in to one of your IT systems, the system will ask for their username and password and then verify these credentials with Active Directory before letting the user in. This process is known as authentication.

When you set up an environment on Azure, instead of using Active Directory, you use Azure Active Directory. It’s quite similar, but it’s used for accessing cloud applications. That includes cloud applications outside of Azure, too, such as Microsoft 365. It can even be used for accessing web-based applications in your on-premises environment. Another big difference is that it’s a managed service, so you don’t have to worry about maintaining the underlying infrastructure that runs it.

Naturally, if you already have an on-premises Active Directory implementation, you don’t have to recreate all of your users and groups in Azure Active Directory. Instead, you can synchronize your accounts between the two systems using Azure AD Connect. This’ll create the accounts on Azure for you and keep them in sync when changes are made to the accounts in Active Directory. It will allow you to use single sign-on (or SSO), which means that users only need to log in once to access both their on-premises environment and their Azure environment. You can also use SSO to access Microsoft 365.

When you sign up for an Azure subscription, an Azure AD tenant is automatically created. This tenant is an instance of Azure AD that’s dedicated to your organization. Since Microsoft has a huge number of Azure customers, it makes sense that it would need to have a separate tenant for each customer. Each tenant has its own dedicated directory of users, groups, and apps.

This all sounds quite straightforward, but things can get much more complicated. First, your organization might want to have multiple subscriptions. One common practice is to have a separate subscription for each department so that each of them can manage their own Azure resources. If you wanted to, you could have a separate tenant in each subscription, but this usually doesn’t work very well. So, many organizations will share the same tenant among all of their subscriptions. That way, users, groups, and apps can be centrally managed while Azure resources can be managed by individual departments. If you want to move an existing subscription to a central tenant, you can do that by changing which tenant is associated with it. You can’t go the either way, though. That is, a subscription can’t have multiple tenants associated with it.

Okay, now let’s go back to the main purpose of Azure AD: authentication. In the past, authentication was mostly handled by getting each person to enter a user ID and password, but these days, you’ll likely want to check more than that to make sure the person isn’t a hacker. One way to get more assurance is to use multifactor authentication (or MFA). In addition to asking the user for something they know, such as their password, you also require something the user has, such as a mobile phone number, or something the user is, such as a human being with a fingerprint.

You’ve probably had to go through multifactor authentication yourself. The most common way to prove you have something unique to you is to get an access code sent to your mobile device and then enter that code during the login process. The most common way to prove you are who you say you are is to put your finger or thumb on a fingerprint reader. Another way is to let a device scan your face.

As you’d expect, Azure AD does support multifactor authentication. In the “what you have” category, it supports:

• Access codes sent by SMS
• Access codes sent by voice call
• The Microsoft Authenticator app
• Hardware keys, including FIDO2 security keys and OATH hardware tokens, and
• OATH software tokens

In the “what you are” category, it currently supports only Windows Hello for Business, which can use facial recognition and fingerprint recognition.

Azure AD also supports an authentication option called “passwordless”. Instead of entering your password plus either what you have or what you are, you can just use both what you have and what you are. In other words, if you need two methods of verification, why not use two different methods that don’t require you to remember a password? That would make things a lot easier for most people while still maintaining security.

There are currently three passwordless options:

• Windows Hello
• Microsoft Authenticator, and
• FIDO2 security keys

In each case, you have a hardware device and biometric authentication. For example, if you’re using the Microsoft Authenticator app, then you have to sign into your mobile device using a fingerprint scan, facial recognition, or your PIN. If you use your PIN, then you’re actually using a password rather than a biometric method, but at least it should be easier to remember than your Azure AD password.

Now after telling you about all of these different authentication methods, I should point out that you have to pay extra to use most of them. If you’re using the free version of Azure AD, then you can require all of your users to register for multi-factor authentication by using the Microsoft Authenticator app. That’s the only authentication method available in the free version.

If you need more flexibility, then you can upgrade to Azure AD Premium. This license includes the conditional access feature, which not only lets you use all of the various authentication methods, but you can also use it to require other conditions before letting users log in.

For example, suppose you want to require that users can only sign in from a device that’s running Windows 10 or higher. You can do that with conditional access. The idea is that conditional access gathers identity signals, such as what device you’re using, then it makes a decision based on rules you’ve configured, and finally, it enforces that decision, such as by blocking access.

Here’s another example. You could configure conditional access so that if a user is logging in from a location that is not on your approved locations list, then they’ll be blocked. Or you could configure it to allow a user to log in from a non-approved location if they go through multifactor authentication. The list of approved locations can be countries (or regions) and IP address ranges.

You can also limit access based on what application a user is trying to access or what client application they’re using to gain access, such as a Microsoft Outlook app.

Yet another possibility is to only allow access if they’re using a managed device that meets your security standards. To make this work, these devices, which can be Android, iOS, macOS, or Windows 10 or higher devices, need to be registered in Azure AD. To enforce security standards on these devices, you can use a mobile device management tool, such as Microsoft Intune.

Before you configure a new conditional access policy, it’s a good idea to test it using the What If tool so you don’t accidentally wreak havoc on your users. The What If tool will tell you what actions it would have taken on recent sign-in attempts if your new policy had been enabled.

There’s also something else you have to do before you can configure a conditional access policy for your users. You need to assign a Premium license to each user account because Azure AD is licensed on a per-account basis. To make this process easier, you can assign a license to a group instead if you’d like. You can also assign other types of licenses, such as Microsoft 365 licenses, to both users and groups.

Generally speaking, it’s a good idea to use groups to organize your users and apply policies in Azure, but how do you keep groups up to date? After all, in a large organization, people come and go all the time, so it can be a challenge to make sure that users are in the right groups. Fortunately, Microsoft provides dynamic membership rules. These rules will automatically add or remove users in relevant groups when something changes. 

A simple example is an "All users" rule. For example, if you wanted to ensure that all of your users were subject to conditional access policies when they signed in, you could create a group called “Everyone”, add every user to it, and create a conditional access policy that targets that group. Then you could apply an “All users” rule to that group, and whenever a new user was created, it would be added to that group automatically.

And that’s it for this introduction to Azure AD.