This blog post, I am sharing my thoughts and understanding of identity driven security and Azure Active Directory Conditional Access besides some tricks I learned when working with Azure AD.

Life before Azure Active Directory Conditional Access

I remember couple of years back, when I was working in the identity and data center management, that I had different perception of security and locked down system configuration. We used to apply a defense in depth strategy that begins with security baselines applied to servers, up to network segmentation, top of art firewalls, and log management systems.

All company’s important assets and applications are locked down inside data centers. We heavily invested in intrusion detection and prevention devices, complex firewall rules, physical security measures, and more.

Disaster recovery and high availability measures, were also hard to implement, and requires a lot of planning and financial investments. Things were difficult, but we’ve done it for years, and we become experts in doing that.

I also remember when someone wants to access corporate data located inside the datacenter from outside the corporate network, he had to go through approval cycles, and then open a VPN tunnel just to access internal data and apps. We surely gave him hard time before granting such access.

I was responsible of securing domain controllers and making sure they are well protected. It was a crime to find out that there is a machine that is not joined to our domain.

Now imagine someone comes telling you that we are going to synchronize your Active Directory data to an online service that is exposed to everyone. Not only that, your secure SharePoint and Exchange infrastructure will be now migrated to an online service that can be accessed from anywhere, from any device and anytime. Imagine also that all your data center’s security control measures are no longer in use, because the data is now outside. This sounds like a nightmare becoming a reality and there is no way I am going to accept that.

Well, that was couple of years back. When the perception about cloud was that you will no longer have control over your data, and that cloud is less secure than you on-premises data centers.

Stay in control with a different approach

Microsoft has an interesting point of view for people who are worried like me about having their data in the cloud, and want to have some level of assurance, that they can still be in control. It is called “Identity Driven Security”.

If you are using Azure Active Directory for your authentication when accessing SaaS applications, then you know that when you access one of those SaaS apps, you will be redirected to Azure AD to get a signed token.

This is a strategic place to apply some security checks and access control measures, and that is what Microsoft did. Azure AD can require some conditions to be satisfied before giving you an access token to the SaaS application. Those conditions are branded in Azure AD as (Azure Active Directory Conditional Access), and this is what we will be talking about in this blog post.

It will not work all the time – The ugly truth

First, you must be completely aware of the licensing requirement for using services in Azure AD. Azure AD comes with different licensing models starting from a free tier up to Premium 2 or P2. Azure Active Directory Conditional Access requires P1 and to use the risk condition (Identity Protection), you need P2.

The other fact is that not all requests coming to Azure AD are inspected by Azure Active Directory conditional access. The only authentications attempt that respect your conditional access rules, are those coming from a web browser, or a client app using modern authentication, or Exchange Active Sync apps.

Let me give you an example, suppose you have a great Azure Active Directory conditional access policy that states that to access SharePoint Online, you should do MFA. Now, if you open a browser, and tried to access SharePoint Online, CA will be enforced (CA stands for Conditional Access), and MFA will be required.

Now, what if you are using Office 2007, and we know that this client app does not modern authentication. When Office 2007 client tries to access SharePoint Online, it will contact Azure AD using classic authentication protocols, and thus Azure Active Directory conditional access will not be triggered, and MFA will not be required.

I hope you understand by know that Azure AD CA (Azure Active Directory conditional access) only works with modern authentication client, a web browser session (passive client), or an Active Sync client for mail.

You might be thinking “if I only can disable the use of classic authentication, so that all authentication attempts on Azure AD will trigger my CA rules”

Microsoft till this time of writing this blog post, does not have a way to disable classic (non-modern) authentication attempts. There is news that they will soon.

What can you do in the meanwhile? Since Azure AD does not have a kill switch for legacy classic authentication attempts, and you know that your Azure AD CA will not always be triggered, you have one solution to try.

You can go to your ADFS servers in case you are still using them and not utilizing the awesome Azure Pass-Through Authentication, and you can disable classic authentication by creating some ADFS rules. This way, when a legacy client tries to use legacy authentication protocol, and Azure AD redirects the call to your ADFS, you can deny the use of legacy authentication in the ADFS itself, thus denying the use of legacy authentication and enforcing your CA rules.

As a side note, be aware of POP3 and IMAP, as I believe they are not considered as modern or legacy authentication. Best way is to disable those protocols if possible to make sure you are covered. For example, you can go to Exchange Online or Exchange on-premises, and under the mailbox properties, disable IMAP and POP3.

So, remember that Azure Active Directory conditional access works only with modern authentication. To enforce Azure Active Directory conditional access, you must make sure that you only using modern authentication across your enterprise.

Browsers always use modern authentication, as they are operating under the passive mode. For Office applications, you should have the supported version of Office app that supports modern authentication, and to make sure they are configured or enabled to use modern authentication.

Update: Microsoft just released a new feature in Azure Active Directory conditional access that can catch those classic authentication attempts, and you can deny classic authentication to Azure AD so that only modern authentication is allowed. Finally!

SharePoint Online is configured by default to support modern authentication. For Exchange Online and Skype Online, you should enable modern authentication at the service level explicitly. I thought previously that enabling modern authentication in Exchange Online will enforce the use of modern authentication when accessing Exchange Online. It turned out that enabling modern authentication in Exchange Online will not enforce modern authentication but will make Exchange Online accept modern authentication. So, after enabling modern authentication in Exchange Online, you should make sure:

You have a supported version of Office apps that can do modern authentication.
You should make sure the office apps are configured to use modern authentication.

So, if you are running Office 2016, it will do modern authentication by default, but an admin can use a registry setting to disable modern authentication in Office and bypass your conditional access.

Azure Active Directory Conditional Access allows everything by default.

While you might think of CA rules as sort of identity firewall, keep in mind that firewalls usually deny traffic by default unless you create an allow rule.

Azure AD CA does not restrict any access by default, so if you do not have any Azure AD CA rules, then all authentication attempts are allowed without any restrictions. You should explicitly start creating CA rules to govern access.

Do not restrict access to SaaS applications at the CA rules level.

If all what you want is to list users who can access specific SaaS applications and deny access to other users, please do not use Azure AD CA rules for that. This is not the purpose of CA rules.

To list who can access a certain SaaS app, you should do that in the Azure AD Enterprise Application section when you configure the SSO setting for that SaaS app. This is where you can say “those people can utilize Azure AD for SSO to that SaaS app”.

Remember this, Azure Active Directory Conditional Access policies, control how authorized users can access cloud apps under specific conditions. So, the user is already authorized to use the cloud app (this is subject to user assignment when you configure the SSO setting).

What the CA policies will govern is the conditions and access controls to apply for that authorized user when accessing the cloud app.

How to think of Azure Active Directory Conditional Access Policies?

Now, we talked about how by default, everything is allowed in CA unless there is a match for a policy. We have also made it clear that we are talking about users who are already authorized to access that cloud app, but extra controls are to be enforced.

To do that, when that authorized user requests a token from Azure AD to access a cloud app, the request will be directed to Azure AD CA policies. Each policy will be inspected for a match. If a match is found, then the CA policy Access Controls are applied. Again, a policy match will trigger access controls.

So, we are talking about two things in any CA policy:

Conditions
Access Controls

Conditions are used to determine if that authentication attempt will trigger the CA policy to apply its access controls. Let me give you a quick example. Suppose that we have SSO with Dropbox. We want to restrict who can access Dropbox in Contoso, so we created an Azure AD group called “Dropbox Users”, and in Azure AD > Enterprise Applications > Dropbox > Users and Groups, we added that group.

Now, anyone who is added to that group, can get tokens from Azure AD to access Dropbox, and logon using Contoso credentials. This is called “Cloud App User Assignment”, which is the perfect place to restrict who is authorized to access that app and request tokens from Azure AD for that purpose.

Remember also that till now, anyone who is member of this group, can request tokens from Azure AD to access Dropbox without any constrains, as there are no Azure Active Directory conditional access policies yet to enforce access controls.

Now, we will go further and say “for those people who are authorized to use Dropbox, in other words, for those who are members of the Dropbox Users group, we want to enforce some access controls, like require MFA before granting access. This is where Azure Active Directory conditional access policies help in.

CA Policy Conditions

Each Azure Active Directory conditional access policy contains two parts:

Conditions
Access Controls

Conditions are evaluated for each authentication request, and if there is a match, then access controls for that policy will be applied. It is that simple. You can think of it like this “If this happens [Conditions], then do this [Access Controls]”

There are multiple conditions that you can specify, but from those, there are two that are mandatory to specify. Those two mandatory conditions are (Who) and (What). The (Who) part is simply which users or groups that Azure Active Directory conditional access policy will apply to. The (What) part is listing the cloud apps that the authentication request is requesting access to.

So, at a minimum, your Azure Active Directory conditional access policy conditions shall specify which users and what cloud app they are trying to access. Same as a normal firewall policy, where you specify the source IP (who is accessing) and destination IP (what they are accessing). In this case the destination IP represents the cloud app.

You can assign more optional conditions like location (IP ranges), Device Platforms (Android, iOS, Windows Phone, Windows, macOS), or Sign-in risk (requires Azure AD P2 license).

The optional conditions give you extra flexibility when you are designing your CA policies. For example, you can now say “if those users (Who), are trying to access this app (What), and they are coming from outside my corporate network (Location)…”

Use the Exclude part of the CA conditions

Remember that you can exclude things when you are planning your conditions. You can for example exclude specific users or groups from a policy. One common use case are service accounts [AAD Connect Service Account for example) if your policy enforces multi-factor authentication.

Be careful when using the Device Platform Condition

One of the optional Azure Active Directory conditional access policy conditions is the Device Platform condition, where you can say “if the authentication attempt is coming from this device platform [for example Android]”.

This condition is verified using the user-agent http header in the authentication request coming to Azure AD, remember that this can be spoofed easily, allowing the person requesting a token, to bypass your CA policy condition that looks for a specific device platform.

Let me give you a quick example. Suppose you have one of your Azure Active Directory conditional access policies, with a condition > Device Platform > iOS, so that you want this policy to apply for iOS devices. It is easy for someone to build an app and spoof the user-agent http header to make it look like it is coming from a Windows machine, thus bypassing your CA policy, which will only be triggered for iOS devices.

I had a chat with couple of people from Microsoft that encourage me not to use the (Device Platform) optional condition in my CA policies if possible. Nevertheless, there is no harm of using it, just keep in mind that it can be spoofed.

Client apps optional condition

This is an optional condition that you can use to tie the policy to the client app that has initiated an access attempt. Azure AD CA classifies clients apps as either:

Browser > A web site or service if it uses the web SSO protocols, SAML, WS-Fed or OpenID Connect for a confidential client.

Mobile apps and desktop apps > A mobile app or desktop application if it uses the mobile app OpenID Connect for a native client.

So, when we talk about Client Apps, we have the option to say, “if these users (who) are trying to access this Cloud App that is called Dropbox (What), and the Client App is a browser …”.

This is not enough, you need to understand how Azure AD CA recognizes client apps to either a [browser] or [Mobile Apps and desktop apps].

In other words, you should check this reference link, to understand and check Azure AD CA definition of such apps and browsers. By navigating to the previous reference link, you will discover that to satisfy a device policy like a compliant device, not all browsers types and mobile/desktop apps are supported. The devil lies in the details 😊 Just go through the reference link and through the list of supported browsers and apps to make sure you are aware of the limitations.

This condition becomes handy if for example you want to prevent access from web application, but allow access from the mobile and desktop app.

Also, there is a place to choose (ActiveSync) as a client app. You can choose this condition only if you choose (Exchange Online) as the only Cloud App section in your conditional access policy conditions. ActiveSync is treated differently inside Azure AD CA access as explained later in this blog post.

Client apps vs Cloud Apps

Let us recall that there are two conditions that are mandatory when defining conditions for your CA policies. Those two conditions are the Who (users and groups) and What (Cloud Apps). Cloud Apps means that SaaS application that your Azure AD has SSO relationship with. This can be SharePoint Online or Dropbox. Do not confuse this with the optional condition named Client Apps.

One of the optional conditions that you can use beside the two mandatory ones, is called the Client Apps. This is a reference to the client on the device which is requesting a token from Azure AD. This can be a browser client app, or even an app on desktop clients and mobile devices.

What is the story of ActiveSync

Let us start by investigating how ActiveSync clients perform authentication. ActiveSync uses basic authentication or certificate-based authentication to authenticate to Exchange. So now when you have your mailboxes located in Office 365, things become more interesting.

ActiveSync & other non-browser clients like EWS, POP/IMAP use proxy authentication. So, EXO does the authentication with ADFS on behalf of the client. It goes like this.

You open your ActiveSync mail app on your mobile, and you enter your username and password. The mail app sends the Basic authentication credentials to Exchange Online over SSL. Exchange Online will then send the authentication credentials to Azure AD using proxy authentication. Azure AD will then contact your ADFS servers which will contact your local AD to verify the credentials. ADFS will then create a signed token and send it back to Azure AD and then to Exchange Online. The other way is to use certificate authentication which will go to similar flow.

So, by now, we know that ActiveSync mail app will use Basic authentication or certificate-based authentication, and Office 365 will behave like a broker to validate the authentication request.

But there is more. ActiveSync in iOS 11 and above does not use ActiveSync for authentication, instead it uses modern authentication (reference article). This is because iOS 11 provides support for OAuth 2.0 in the native mail app. This means that if you are using the native email client in iOS device running iOS 11 or later, the native mail app will be using modern authentication when talking to Office 365.

The key thing to remember here is that when you plan your Azure Active Directory conditional access policies to control access to Exchange Online from mobile devices, you should create two policies:

First conditional access policy that deals with ActiveSync mail clients that use legacy authentications.
Second conditional access policy that deals with ActiveSync mail clients that can do modern authentication. In this conditional access policy, the grants (Access Controls) that you can use is only to require device compliant or/and to require an approve client app.

Conditional Access Policy Access Controls

Till now, we have listed the conditions in which the policy will apply for an authentication request from an authorized user. We did not specify what controls we want to apply once a policy match exists.

For example, Bob wants to access Dropbox, and he is authorized to use this app. Azure AD will try to find a match in one or more conditional access policy, by evaluating the conditions in each policy. Once a match is found, then Azure AD will enforce the Access Controls that the CA policy is configured with.

So, what are those access controls? The list is growing with time, but for now, Azure AD contains two types of access controls:

Grants
Session

Session controls enable limited experiences within a cloud app, that is once you access the cloud and get an authentication token, the session can be monitored, and some controls might be put in place to enforce some policies like file download restrictions. SharePoint Online is one of the key cloud apps that can utilize this feature.

Let us move to the access control grants. Those can be:

Require multi-factor authentication.
Require the device to be marked as compliant. [Categories as Device Based Conditional Access Control]
Require domain joined (Hybrid Azure AD). [[Categories as Device Based Conditional Access Control]
Require approved client app.

You can select multiple grants, and decide whether you want them all to apply, or one them to apply. So, you can say, I want the device to require MFA, or to require domain joined (Hybrid Azure AD). In this case, if the device is domain joined (Hybrid Azure AD), then MFA will not be triggered, because Azure AD CA will always try to provide seamless experience and minimal interruption to the user. That is why to ask the user for MFA when his device is domain joined (Hybrid Azure AD).

Required Approved Client App

This grant is simple to explain. Microsoft lists all client apps that are marked as approved in this list. This is saying that in order to give away an authentication token for the specified cloud app, you should be using one of those approved apps.

One of the most requested features from Office 365 administrators is to restrict access to Office 365 by allowing only specific client applications. To elaborate more, Microsoft Intune has a brilliant feature called App Protection Policies (Reference article). Using App Protection Policies, you can protect company data on mobile devices, without fully enrolling the mobile device in MDM. Sometimes you are not allowed to enroll mobile devices with an MDM agent like Intune MDM solution, but you still want to protect corporate data like Office 365 data. To do that, Microsoft mobile applications for Office 365 like Outlook mobile app, can be configured to request a PIN and restrict copy and print operations [Reference Article]

Saying that, you want to prevent your users from accessing Office 365 data from their mobile devices using any mobile app, and only allow access to Office 365 using those Microsoft approved apps that can enforce App Protection Policies (also called managed apps).

Now, Azure AD conditional access policies have an access control grant that can enforce the use of those approved client applications that are fully capable of enforcing Intune App Protection Policies.

This is a long-waited feature, that I believe will help many organizations to start using Azure AD conditional access policies with Intune App Protection Policies to protect Office 365 data on mobile devices without enrolling them in an MDM solution. Microsoft did a great job documenting how to use this grant to protect access to Office 365 here.

Require the device to be marked as compliant.

Compliant in Azure Active Directory conditional access policies means one thing, Intune. The authorized platform to decide if the device is compliant is Microsoft Intune. When Azure AD CA policy is seeking compliant, it will ask Intune if it knows that device, and whether that device is marked as compliant or not.

This means that the device should be enrolled in Intune, and this includes Windows devices and mobile devices. This does not include Intune MAM policy approach, where you manage the app itself.

For Azure AD domain joined devices, you should consider enrolling those devices in Intune during the join process, and to define a compliance policy, so that you can use Azure AD CA grant (Require the device to be marked as compliant). In other words, it is not enough for the Windows machine to be Azure domain joined, it should be enrolled in Intune and marked as compliant.

Saying that, a device can be registered in Azure AD and enrolled in Intune without being Azure AD domain joined.

Require domain joined (Hybrid Azure AD)

This requirement refers to Windows desktops, laptops, and enterprise tablets that are joined to an on-premises Active Directory and joined to Azure AD at the same time. So, if your machine is only joined to on-premises Active Directory, then this grant will not be satisfied, because Azure AD will have no knowledge about them.

This also does not apply to Windows machines that are joined to Azure AD alone without being also joined to on-premises Active Directory.

Remember also, that a device should be joined to the on-premises Active Directory first, before joining it to Azure AD. In other words, you cannot have a Windows machine that is joined to Azure AD and then you decided to join it to the on-premise Active Directory. It should start from having the device first joining your on-premises Active Directory, and then you can hybrid join it to Azure AD.

So again, the Windows machine should be joined to on-premises Active Directory. You should then join it also to Azure AD. There is an option to register devices to Azure AD, which is not enough. The device should be Azure AD joined, and not only registered.

Azure AD domain joined devices are shown in Azure AD as registered devices with a (Domain Joined, AAD Registered) flag. Azure AD registered devices are shown in Azure AD as registered devices without the (AAD Registered) flag. Here is a link to learn more how to do hybrid Azure AD join.

Device compliant vs domain joined (Hybrid Azure AD)

It took me sometime to understand how to plan my grants especially when it comes to device compliant and domain joined grants.

What can be better than a real example on how both work? When you plan your conditional access policies, remember that the end goal is to enhance your security score and security measures when accessing cloud apps. Usually, you want to have some assurance that that devices connecting to your cloud apps are:

Known to you.
Some assurance that they are well configured.

Contoso is a big enterprise with offices all around the world. They are using Azure AD and Office 365, and they are interested in applying conditional access policies.

Contoso has a big on-premise Active Directory with a lot of group policies to configure their domain joined devices. They are using System Center Configuration Manager to apply patches and deploy applications to domain joined machines. They can make a statement that if the device is domain joined, then most likely it is configured with their GPOs and patched using their SCCM. We will call those devices [Category 1 devices]

Contoso has also remote offices that is not connected to the corporate network. Machines in theses offices are not joined to the on-premises Active Directory and not managed by their SCCM implementation. They decided to join those machines directly to Azure AD to gain SSO to Office 365, and to enroll them in Intune. Intune helps managing the updates, configure some device restrictions, and deploy applications. We will call those devices [Category 2 devices]

The security team in Contoso wants to create an Azure Active Directory conditional access policy to restrict access to SharePoint Online so that only devices they know about, and devices that they think are well configured, can access SharePoint Online.

The first thing to do is to configure Category 1 devices so that they will automatically join Azure AD. Doing that will make Azure AD aware of their existence, and thus will make them fall under the Azure Active Directory conditional access grant [Require domain joined (Hybrid Azure AD)].

Now, the security team can create one Azure Active Directory conditional access policy with the following conditions

Users and Groups > ALL.
Cloud App > SharePoint Online.

And with the following access controls grants [Require one of the selected grants]:

Require the device to be compliant > Will apply to devices in category 2
Require domain joined (Hybrid Azure AD) > Will apply to devices in category 1

This will give Contoso the perfect solution. Require the device to be compliant (Category 2 devices) means that the device is:

The Windows machine is enrolled in Intune, and
Intune marks the Windows machine as compliant.

Or:

This is a mobile device that is managed by Intune, and
Intune marks the mobile device as compliant.

Require domain joined (Hybrid Azure AD) will apply to (Category 1 devices), which means the local GPO are in place, and the device most likely is managed by the local SCCM.

Keep in mind that (Require the device to be compliant) will also apply to mobile devices managed by Intune, which is fine by Contoso security team, as they can define the compliance state for those devices inside Intune.

Terms of use

A new addition to the Azure Active Directory conditional access policies access control grants is the Terms of use. Say for example that you want anyone accessing Dropbox to agree to your company’s policies before accessing that third-party SaaS app. You can define a term of use document for example, saying that you are not allowed to store sensitive corporate data in Drobox, and you want people accessing Dropbox to read this policy before moving forward.

Terms of Use grant does not appear by default in the list of grants. You should go first to the Term of Use section inside the Azure Active Directory conditional access section and create one. After that, you will see a new grant to enforce that term of use document when accessing your SaaS application.

MICROSOFT 365 ADVANCED THREAT PROTECTION VIDEO

Here is a video I published on my YouTube channel. It is about “How to secure your modern workplace with Microsoft Advanced Threat Protection”. Please subscribe to the channel to get updates on my new videos.

“I will introduce you to Microsoft 365’s threat protection services and demonstrate how Microsoft 365’s threat protection leverages strength of signal, integration, machine learning and AI to help secure the modern workplace from a advanced persistent threats or APT.”