When talking to customers about Microsoft 365 security, we often kick off with reviewing the security of Azure Active Directory. However, from time to time, we get reactions such as: “we don’t use Azure AD, only O365”, “we have ADFS, not Azure AD”, “isn’t Azure AD just a cache of our internal AD?”, “are there any security configurations specifically for Azure AD?”, and so on.

Whether you are using O365 (E1 or E3), Intune (or any other product from the EMS Suite) or Azure IaaS and PaaS services, you already have Azure Active Directory!

Did you know the following?

• By default (out-of-the-box Azure AD configuration), any user can invite a guest – a user from another tenant or live-account – to access data in your tenant (OneDrive, SharePoint, O365 groups, Teams, Azure I/PaaS services,…).
• By default, any guest can invite other guests in Azure AD.
• Users can access third party cloud apps with their corporate credentials, using secure SSO-authentication (OAuth, OpenID, SAML,…).
• Users can also ‘consent’ or allow that these third party cloud apps can access their data (for example their mails, all SharePoint and OneDrive documents,…).
• You can integrate Azure AD with over 3000 tested and verified third party cloud apps to manage and control access and even assign identities and groups to these apps.
• You don’t need to install ADFS anymore to allow users to authenticate using their corporate Active Directory credentials.
• You can implement risk-based authentication controls for each of the apps that are integrated.
• Every day, new features are coming.

Whether or not the items in the list above are good or bad, will depend on the specific security needs of your organisation.

Azure Active Directory is a leader in Gartner’s Magic Quadrant for cloud access management and has a wealth of features and functions, not always well understood by many organisations, let alone well used.

In this and upcoming blogposts, we will highlight the most important Azure AD features that you should be aware of.

What is Azure Active Directory?

Azure AD is a cloud-based directory that serves as a store for users, groups, devices and applications. It provides secure authentication mechanisms based on “modern” authentication protocols, such as SAML, OAuth and OpenID-Connect. This directory information allows you to store a lot of relevant info. Beside the basic information such as ID, name, description,… you can store other information as well, about users (work address, telephone numbers, email addresses, manager and department
info,…), groups, devices and applications.

Azure AD differs from Active Directory in the following ways:

• Azure AD has no concept of organisational units. There is a (little-used) feature called ‘administrative units’, but this has been in preview for a very long time and still has no UI-support (only PowerShell). The future of this feature is not clear. All users or groups are hence represented in a flat list, which is sometimes very long.
• Azure AD does not have the same granular access control mechanisms like AD, which allows you to delegate all management aspects in AD. Azure AD has a number of built-in roles and – when looking at recent changes in the documentation on these roles – it looks like there is a good chance that more fine-grained (or even custom?) roles might be possible in future… The fact is that a number of new roles have appeared lately and the actual granular access controls for each role are much better documented than before.
• The management UI for Azure AD is not on par (yet?) with internal AD tools and many automation tasks still require that you open the PowerShell console to get things done…
• Azure AD supports modern authentication methods, like ADFS, since Kerberos or NTLM would not make any sense in a cloud world. However, note that you can have Domain Services connected to resources in your azure subscriptions, to allow classic domain-joined servers in IaaS setup.

And there are a lot more differences, since Azure AD and Active Directory are essentially two different products.

Connecting Azure AD to your organisation

Only a few customers will start from a greenfield situation where there is no existing internal Active Directory in place. Hence, you want to connect Azure AD to your internal Active Directory and ensure all users and groups, but eventually also computers (further referred to as devices) are kept in-sync between the two environments.

Azure AD comes with a sync-tool called “Azure AD Connect” (AADC), which is an altered version of Microsoft’s existing Identity Manger (MIM). Although it has less connectors, called management agents, to sync up with other directory sources (only AD and Azure AD), it comes with several other interesting features.

But what about the user’s passwords and authentication using corporate (AD) credentials?

You have four options that are not mutually exclusive:

• Password Hash Sync (PHS): AADC can sync password hashes from on-premise AD to Azure AD. Note that the well-known and carefully protected password hash is not synced as such, but rather as a hashed version of the password hash, making it cryptographically infeasible to derive the user’s password hash (or password itself) from this new hash. The password hash stored in Azure AD can hence NOT be used for pass-the-hash-attacks (PTH) in your local domain.
• Pass-through Authentication (PTA): In this case, Azure AD will transfer the user ID/password over a cryptographically secured channel through AADC agents to the internal AD for verification.
• Azure AD only passwords: In case you don’t have an internal Active Directory or you are in a greenfield situation.
• Seamless Single Sign-On: In this setup, internal users on AD-joined computers can authenticate against Azure AD using Kerberos and hence get a fully transparent single sign-on experience.

And what about option five: Active Directory Federation Services (AD FS)? AD FS is of course still a valid solution, but – unless you have other well-defined needs to federate with other parties – not the best solution anymore for integrating O365 and other cloud apps with your internal AD.

Why would you choose one or more of the four options over AD FS?

• Less on-premise infrastructure: AD FS requires at least two on-premise servers and an infrastructure to securely publish these services to the internet to accommodate off-premise users without the need for VPN.
• With PHS, you are less dependent on the availability of your on-premise infrastructure and internet connectivity (especially for users working off-premise).
• They offer the same – or even a better – user sign-in experience.
• Smart lockout: attackers use password guessing techniques such as password spraying to find users that have common or weak passwords, or they could lock out specific (critical) accounts by simply trying many invalid password log-ons. Smart lockout will not block the accounts as such, but rather the IP-address(es) of the attacker and provide other methods to significantly slow down the attack. For more info, read this article: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-smart-lockout.

Note that if you use PHS, you should not enable PTA anymore. PHS is also a great backup solution in case the internet connectivity to your on-premise AD infrastructure fails.

In our upcoming blogs, we will dive further into other security aspects of Azure AD, including the integration of your own applications and devices, extending Azure AD to your business partners and cloud apps in a secure way, enhancing security of your connected apps using Conditional Access, the use of enhanced security features to protect your Azure AD such as Privileged Identity Management, identity and password protection, and reviewing governance aspects.

Free webinar about Azure Active Directory

In our webinar of March 2019, we gave a high-level overview of all of the above! You can find more info and rewatch the webinar here.