On premises Active Directory is limited in terms of the built in Authentication Methods. The authentication methods available to on-premises AD are password and smart card authentication. Although, there are 3^rd party methods available such as RSA Tokens.

However, Azure Active Directory has many authentication methods available. The default option is password. For most organizations those passwords come from on-premises Active Directory. The user is then authenticated natively in Azure AD or the password is validated by on-premises Active Directory. There are two general trends in terms of security. One trend is Passwordless which is a movement away from passwords for authentication. And the second trend is Multi-Factor Authentication (MFA) where a user is initially authenticated with a password and then need to perform a second authentication with another method.

FIDO2 Security Key

FIDO2 Security Key is the next authentication methods we are going to discuss. In terms of Azure Active Directory, a FIDO2 Security Key can be used for Passwordless authentication. A FIDO2 Security Key uses asymmetric cryptography to authenticate a user to an Identity Provider (IdP). A key pair is generated and the private key is secured on the Security Key and the public key is submitted to the IdP during registrations. The user that has access can prove their identity due to the cryptographic relationship between these two keys. The FIDO Security Key usually requires some sort of authentication before it can be used to authenticate the user. This many time is a biometric such as thumbprint, but can take on other methods such as a PIN. If you feel my description is inadequate the FIDO Alliance has an overview on the topic available here: How FIDO Works – Standard Public Key Cryptography & User Privacy (fidoalliance.org)

Microsoft Authenticator

Microsoft Authenticator is an application that installs on your mobile device. Microsoft Authenticator can be used for MFA, as well as for Passwordless sign-in. By default the user will receive a prompt in Microsoft Authenticator when using Passwordless or MFA to click No, it’s not me or Yes. However, there are a number of features that help increase the security of this process. These three security features are: Require number matching for push notifications, and Show geographic location in push and passwordless notifications. Require number matching for push notifications: A user is prompted with a number in their browser, they will then either need to select that number or key in the number to complete the authentication. Show application name in push: This simply displays the application to which they are authenticating. Show geographic location in push and passwordless notifications: This displays the location from which the authentication originated.

SMS

SMS is another authentication method, and it is currently in preview. This allows the user to receive an SMS message. Then the user can login with the code that is sent to their mobile phone. SMS cannot be used for MFA.

Temporary Access Pass

Temporary Access Pass is a self-descriptive feature. TAP allows the administrator to generate a one time pass code that can be used for authenticating to Azure Active Directory. TAP is ideal if you require MFA for a user enrolling their authentication methods. Since a user does not have authentication methods yet registered, they cannot MFA even if this is required. To get through this limitation a user can be given a TAP and use that as their MFA credential. The downside to this feature is there a lot of administrative overhead since sending a TAP must be completed on a user by user bases.

Certificate Based Authentication (Preview)

Certificate Based Authentication (Preview) allows a user to login with a certificate or Smart Card. There are of course some setup steps like importing your Root CA certificate and configuration of the policy. However, this is a nice addition, especially if you would like to leverage your existing smart card infrastructure. I will post a blog entry on setting this up in the near future.

Authentication Strength (Preview)

Authentication Strength (Preview) assigns an authentication strength to different types of authentication. For example, one authentication strength is named Phishing-resistant. In order for an authentication to be considered Phishing-resistant the authentication method must be Windows Hello for Business (WHfB), FIDO2 Security Key, or Certificate based Authentication. You can then use conditional policy to require a certain authentication strength before a user is given access to an application.

Next time

Next time I will probably divert from this intro series to cover Certificate Based Authentication.

Thank You,

-Christopher

So, it’s important to distinguish Azure AD from on-premises AD. There are few similarities between the two. They are both Identity Providers (IdP). However, they used different protocols, structures, and so on. So, let’s look at some of the differences.

Both Azure AD and AD contain identities such as users, groups, and devices. And each identity has attributes that contain information and characteristics about that identity. So, that is a similarity.

Architecture

On-premises Active Directory is hierarchical. In other words, you have a domain then under the domain you have containers, OUs, and sub-containers, and sub-OUs. Azure Active Directory is a flat structure where everything falls directly underneath the Azure AD “Domain”.

Accessing attributes and data

However, how that information is accessed is very different between the two. For both, you can of course use PowerShell to pull information. Also, both have GUIs that can be utilized. Azure AD has the Azure Portal and AD has the Microsoft Management Consoles.  In Azure AD you also have the option to use the Azure Command Line Interface (CLI), as well. The protocols that are used to access that information are of course different. The most common protocol for on-premises AD is LDAP. Most applications and tools leverage LDAP to some degree to pull information. Azure AD the primary way to access as well as change information is Graph API.

Authentication Protocols

Active Directory leverages Kerberos and NTLM to for authentication.

Whereas Azure Active Directory uses Oauth 2.0 and Open ID Connect. However, you will see SAML used quite a bit, especially for Single Sign On (SSO)

Configuration of Devices

In Active Directory, Group policy is used to configure computers. Many of the settings in Group Policy center around configuring security settings

In Azure Active Directory, Intune is used to manage the configuration of computers and devices.

Users, Groups, and Devices

Users

Synced Users

On-premises Active Directory contains user accounts. However, Azure AD has many types of user accounts. For most organizations the majority of the users are sourced from Active Directory. In other words, users are synced from Active Directory. These are called synced accounts. Keep in mind that on-premise Active Directory is authoritative for these accounts including for the password

Cloud Users

Additionally, users can be created natively in the cloud. These are named cloud users. These users do not exist in the on-premises Active Directory.

Guest Users

Finally, there are also guest users. Azure AD has a feature named B2B. B2B allows users from other Azure AD tenants to be given access to applications in your tenant. So, for example lets imagine a user is from the Contoso organization and his UPN is john@contoso.com. Continusing this example there is another organization named Fabrikam and hosts the Fabrikam.com domain. Fabrikam can invite john to the Fabrikam tenant as a guest account. Then when accessing an application hosted by Fabrikam, John would log in to the Contoso tenant and that authentication would be trusted by Fabrikam, and John could access the application. I will go into much more detail in an upcoming posting.

Groups

Below are the group types available in Azure AD. One nice feature that Azure AD possess is dynamic groups. With dynamic groups the group is built dynamically based on one or multiple attributes of the user or device.

• Synced Groups: Groups synced from on-premises Active Directory
• Assigned Group: A cloud group whose membership is assigned.
• Dynamic Group: A cloud group whose membership is determined by an attribute query.
• M365 Group: A group used in M365 for collaboration, especially with Office 365 applications
• M365 Dynamic Group: An M365 group whose membership is dynamically assigned by an attribute query.

Devices

Devices can be added to Azure Active Directory. There are 3 device states that Azure AD supports: Hybrid Azure AD Joined, Azure AD Joined, and Azure AD registered. I will just cover the basic here and save the details for an upcoming posting.

Hybrid Azure AD Joined: This is Windows computer that is joined to both on-premises Active Directory and Azure Active Directory. An Active Directory user or Azure AD user can login to these types of machines.

Azure AD Joined: This is a Windows computer that is joined to Azure Active Directory. Azure AD Users can sign into these devices. Keep in mind an Azure AD User can be a user synced from on-premises Active Directory.

Azure AD Registered: Is a device, usually a phone or tablet that is joined to Azure Active Directory. A local user account is able to login to this device. For example, with an iPhone you effectively login to the phone with your iCloud account and not an Azure AD account.

Administrative Units

In on-premises Active Directory you delegate access to users, groups, and devices by OU. Azure AD is a flat structure, so there are no OUs to delegate access. In Azure AD you delegate access through Administrative Units. In order to accomplish this, you must first create the Administrative Unit. Then you add Users, Devices, or Groups to that AU. Finally, there is a set of roles that have certain rights and permissions over the objects contained in that AU. So, you add the users you would like to delegate access to, to one of those roles.

Conclusion

This concludes Part 1. In Part 2, I will discuss Authentication methods. Keep in mind that this posting was an overview, and I will go into a more detailed explanation once I cover the most common aspects of Azure AD at a high level.

-Chris