Guide: Limit Microsoft 365 Access to Corporate Devices with Conditional Access
World events since March 2020 have highlighted one of the key benefits of Office 365 and cloud-based SaaS services in general: they are available any time, any place, on any device. As the world was forced to work from home, Office 365 apps such as Teams, Outlook, SharePoint, and OneDrive could easily be accessed outwith the traditional company network, and even on non-company devices. In fact, most Office 365 and Microsoft 365 subscriptions license users to install and use their apps on up to five devices.
One of your primary concerns as a result of this may be data loss prevention. For example, by default, a user can authenticate to their corporate OneDrive or mailbox on a personal device with absolutely no limitations on the ability to synchronize all the files and emails hosted in that service. What happens to local copies of data when that user leaves the organization?
Azure Active Directory Conditional Access can put administrators back in control. Part of the Azure Active Directory Premium P1 license, with Conditional Access you control the conditions under which a user is granted or blocked access to Azure AD resources. Even if you grant access, you can force additional measures, such as responding to a multi-factor authentication (MFA) prompt, or how long before they must log in again.
How Conditional Access identifies corporate devices
In our scenario, we’ll use Conditional Access to allow users to sign in to Office 365 only on corporate devices. We do this based on the device state.
Although there is no device state called “corporate device” in Conditional Access, we can identify two things about a device and infer from them a device is corporately owned:
- Is the device hybrid Azure AD joined?
- Is the device marked as compliant?
Hybrid Azure AD joined refers to a state where a device is joined to your on-premises Active Directory, but also synchronized and joined to the cloud-based Azure AD. We’ve covered how to get your devices into this state here. This is only suitable for Windows devices.
In the screenshot below, you can see how Azure AD reports back the hybrid Azure AD join type.
Marked as compliant means the device is enrolled in a mobile device management solution, such as Intune, and meets that MDM’s compliance requirements, such as having an active firewall. In many ways, this is a better control than only checking the domain membership of the device, as you are also ensuring a level of security posture, which is beneficial for a zero-trust strategy. However, if you are only interested in confirming that the device is enrolled in Intune, you could set a compliance policy with no specific security requirements. This method can be used for the “big 4” modern platforms: Windows 10, macOS, iOS, and Android.
In the screenshot below, you can see how Intune reports back device compliance.
Strictly speaking, the correct term for a device in either of these states is a managed device. This means an IT administrator has some level of control over that device, such as the ability to apply and control settings either from Group Policy or Intune. Devices in neither state are regarded as unmanaged. Assuming we have limited the ability to enroll into Intune to corporate devices only, we can reasonably use the terms managed and corporate interchangeably.
An important point to note is that Azure AD may prompt some platforms and browsers for certificate information if a device state based Conditional Access policy is used. This is typically non-Microsoft based platforms, such as Apple and Google platforms. It does this because the device state information is held within a certificate on that device, and not all software automatically makes this available to Azure AD during the authentication.
Creating the Conditional Access policy
Conditional Access policies are created within Azure AD > Security > Conditional Access. Best practice is to give your policy a name that makes it easy to identify exactly what the policy aims to achieve. This is because if multiple policies match an authentication attempt, they all apply, and a good naming convention simplifies troubleshooting and management.
Policies are broken into assignments and access controls. Assignments are the equivalent of a checklist of everything that must be true about the sign-in for the policy to apply to the sign-in. For most of these settings, you can both include and exclude conditions. For example, include all users but exclude IT staff. If the policy does apply, then the access controls determine if access is denied or allowed and, when allowed, what other steps and measures need to apply or be true.
Before diving into Conditional Access, it’s important to consider how powerful it is: it gives you the ability to completely block authentication to all apps. Therefore, you could misconfigure something and lock important users from important apps, or even all administrators. You should consider creating exceptions for break-glass emergency access accounts whose sign-in activity you monitor. Personally, this is the first step I take when creating any Conditional Access policies.
Users and groups control who the policy will apply to. If you are not in this assignment, you are not subject to its rules. For a policy that blocks Office 365 access on unmanaged devices, you may wish to scope to all users but exclude guests/external users and the emergency access accounts. Alternatively, include only an appropriate Azure AD group.
For Cloud apps or actions, select Office 365. You can select more than one cloud app, so you may want to create a policy that limits all apps you deem sensitive, not just Office 365. The Office 365 app listed in Conditional Access is actually a collection of other apps you can select individually. For example, it includes Exchange Online and SharePoint Online, but you can in theory just choose the component apps. The reason you want to select Office 365 and not any of its component parts is due to the integrated nature of the service. Selecting the unified platform reduces problems associated with dependencies they have on each other.
Conditions are where you specify signals and authentication properties such as IP addresses, operating systems, and apps (which, roughly speaking, means web or client app access). In our example, we’ll be blocking access to all Office 365 access methods so do not specify any conditions. This means that every condition applies. A common use of these conditions, however, is to have different rules for web access and desktop app access.
You will also notice the device state condition in here, but we actually won’t select it for this policy. Read on to see why.
Now we’ve dealt with the “if this…” element of our policy, it’s time for the “then that…”. Access controls are split into grant and session settings.
In the grant pane, select grant access and check the boxes for required device to be marked as compliant and require hybrid Azure AD joined device. You’ll also have an option to choose whether or not the device must be both of these, or either. The recommendation is to select require one of the selected controls so that both on-premises domain joined and Azure AD only joined devices can get access.
What we’ve done here is say “you can get access, but you need a managed device”. Put it another way, this also says “you can’t get access unless you’re a managed device”. Assuming our on-premises domain join process is secure, and our Intune enrollment is limited to corporate devices, this limits all access to Office 365 to corporate devices.
Session settings control what a user is allowed to do once they’re given access. For example, in web browser sessions, you can use app enforced restrictions to block downloads from services such as Exchange Online and SharePoint Online. Hopefully, this has you thinking about the various ways you can shape your policies: potentially one to block access for full apps on unmanaged devices, but another which allows access to only web apps, enforcing no downloads.
Deploying the Conditional Access policy
With the settings all applied, your Conditional Access policy can now be put either report-only or on states. The intent of report-only is to allow Azure AD sign-in logs to audit what would have happened without interrupting the production environment. You can then use this information to understand the consequence of the policy: for example, how much disruption can we expect, and therefore what kind of education should we be providing our users?
There’s a significant warning in place for report-only mode in our case, though. As mentioned earlier, for Azure AD to ascertain the device state, it needs to query a certificate, and some platforms do not allow this automatically. Even though you’re operating in report-only mode, it still needs that certificate to know what it could have done. You will always be warned about this in policies if you include device state based settings.
When you are comfortable that your policy has been configured correctly and will not adversely affect business, simple change the state to on, at which point the policy is immediately enforced on future Azure AD authentication attempts.
If a user now attempts to access any Office 365 resource on a non-corporate (Intune compliant or hybrid Azure AD joined) device, Azure AD will advise them access is blocked. This is true for any means of access, be it using a web app or a full client app. Again, you can use conditions to have different rules for both web apps and client apps.
On corporate devices, the process of authenticating doesn’t change as far as the user is concerned: they will sail straight on in. The one exception to this is when that app can’t check the device state. This shouldn’t be a problem for first-party apps such as the Office 365 suite, but for example may be a problem with third-party browsers, even in Windows. Your users may get an error similar to that in the above screenshot. Chrome for Windows does support device state if using the Windows 10 Accounts extension and as you can imagine, the Chromium-based Edge supports it as standard.