Understanding Conditional Access (Context-Aware) Control

This is a primer for business owners to understand why conditional access is important and how to begin to implement it.

The modern security perimeter now extends beyond an organization's network to include user and device identity. Organizations can utilize these identity signals as part of their access control decisions. Conditional Access is the tool used by Azure Active Directory to bring signals together, to make decisions, and enforce organizational policies. Conditional Access is at the heart of the new identity driven control plane.   Google's Context-Aware Access gives you control over which apps a user can access based on their context, such as whether their device complies with your IT policy. 

Conditional Access (or Context-Aware access) configuration requires that management create policies that make sense, and then those policies are translated to controls implemented at Azure AD, Google, or any identity service of choice.   Because identity can span multiple services, these policies need to consider the core services in question and anything using them for authentication.  

• Enforce MFA.  This sounds counter-intuitive since you can enable MFA without Conditional Access. However enable and enforce are different.  With Enable your only option is to voluntarily comply individuals. While you may think you can manage them, management is only available under Legacy MFA.  In other words, to enforce MFA you must use Conditional Access unless you can turn on Security Defaults which then enforces it across the account.  We generally want it on but find that the blanket approach to be disruptive and still fails to give that assurance you want. We consider this the bare minimum standard for control.

• Guarantee use of modern authentication.  This is a terribly difficult concept to communicate and understand, because Microsoft botched it.  Legacy Auth and Modern Auth run side by side and each runs their own MFA system. They look and feel the same to the end-user for the most part, but they are materially different.  The real life risk is that you can be getting MFA prompts and believe that all is well, only to discover that MFA Prompts are not required in certain conditions and thus someone could easily log into an M365 account.  The scenario is due to a conflict in policies that is extremely difficult to detect unless you have an CA Enforce MFA policy properly configured.

• Retire legacy protocols. Conditional Access can easily turn-off insecure protocols for all users or selectively for some.  This is a huge benefit and we strongly encourage the use of it.  The journey there is not that simple, as you have to understand what's actually in-use and often it it is more pervasive than you expect.  This policy is then the last-piece of a complex change.

• Expedite logins for trusted locations.  While our financial services companies must protect every device at all times, law firms tend to have much more relaxed security.  You may find that no MFA prompts inside your offices is desirable. We caution this use as it exposes a "malicious insider" vulnerability, is not aligned with "zero trust access" but it is convenient and sometimes this is acceptable.  You weigh your risks.

• Enforce trusted location access. We can control what M365 resources are available to your tenant from trusted and non-trusted locations.  This can be done on a per-app, per-protocol. or per user basis.  While the ideal scenario is that you would only access M365 from trusted locations, that's often too complex for small offices.  However, a more surgical approach can be setting it so that only certain apps, like Outlook Web Access, work within the office so that you limit the number of ingress points without completely locking down the tenant.

• Enforce device to service authentication.  This requires extensive device control to be in place using Windows Intune, but it allows your organization to say that "only devices we explicitly trust will be able to connect to M365 services.

• Enforce hardware token authentication.  Hardware tokens, such as FIDO2, are one of our favorite ways to protect services.  They can be used in conjunction with the above items or as a compensating control for some of them (like device to service).  Their implementations, however, are a bit difficult to explain because they are not uniform.   There are, however, two great use-cases that shed light on what to expect:

  • Microsoft uses FIDO2 for password-less authentication.  It helps users spend less time entering passwords and more time using resources.

  • 1Password uses FIDO2 as a multi-factor authentication.  There you are expected to provide your user/pass/key but then you are also asked for your FIDO2 key to validate a connection.

Your organization should choose any, some, or all of these objectives or even create your own. Then use these objectives in controlling access. 

1. Understand what control and protections mean to you.  For that you need to understand what you are trying to protect.  You can take our advice in part or as a whole or do your own.

   1. Consider the core service such as Microsoft 365,  Google Workspace, Windows Active Directory, and any other primary identity service you may use.

   2. Consider the components of your core services such as SharePoint which may benefit differently from controls imposed by such policies.

   3. Consider the other services you use capable of SAML, OAUTH, or other connection protocols and see how they are affected by these rules.

2. Decide if consolidating authentication should be part of this now, or later. It  is unlikely that your organization will avoid consolidating identity services, so assume that this will happen. Think of this as more of a exercise in controlling scope and velocity of the changes rather than deciding whether or not do them.

3. As far as Legacy Protocols and Legacy Authentication - now it's time to dig into what that means to your organization.  Your organization may realize that there are protocols in use far more than anticipated, especially when it comes to SMTP and EAS.  That may affect people's use of devices.  For example

   1. If you are using SMTP to authenticate websites or applications, you should read our https://bento.frontkb.com/en/articles/2349697 as it is indirectly related to what you are doing and how you should approach it.

   2. If you are using Messages or FaceTime contacts, or the native iOS Mail app -- all of those use EAS.

4. Decide what you are willing to accept, what you are planning to control, and what you think is worth compensating control over direct control.   In other words, a risk assessment, no matter how brief.

5. Implement in stages.  This is a incremental effort that you do one stage at a time.  See our Best Practices below.

Yes.  Today's standards call for enforcing MFA.  In 18-36 months zero-trust-access will be the de-facto standard for access control.  This is based on a series of catastrophic events, like Kaseya's breach, and the executive order of the current administration to move government agencies to ZTA. The bullets on top of this article are all pieces of that ZTA policy.   These are common-sense protection measures. 

Follow these best practices to help ensure a smooth rollout of Conditional Access policies in your company. These best practices are based on customer feedback.

• Don’t block access to services, such as e-mail, that you use to share communications with your users (and that they also need to communicate with you).

• Identify IP ranges that partners, external collaborators, and clients need.

• Keep in mind that some  services, such as Forms and Sites, don’t have a mobile app and will be blocked on phones.

• Discover—Enforce the use of Endpoint verification so you know which devices are accessing (or will be accessing)  data. Find out information about each device, such as if it’s encrypted,  running an up-to-date operating system, and if it’s a company-owned or personal device.
  

  • Note that if you enforce a Conditional/Context-Aware device policy before the user can sign in to Endpoint verification, the user may get access denied even if their device meets the enforced Conditional/Context-Aware policy. This is because syncing the device attributes through Endpoint verification may take a few seconds. To avoid this, be sure to have users sign into Endpoint verification before you enforce a Conditional/Context-Aware device policy.

• Remediate—Get your devices under IT management and in compliance with company standards in preparation for device policy enforcement. This should help reduce help desk tickets and support calls.

• Enforce—Enforce policies to restrict access to apps based on device context. Identify the organizations, sub-organizations, and groups, and then apply device policies in a phased rollout. Base your rollout plan on the device composition of each organization or group, and plan for sufficient help desk support.

• Microsoft Conditional Access: https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/plan-conditional-access

• Google Context-Aware Access Control: https://support.google.com/a/answer/9275380?hl=en#zippy=

• Okta Trust and Access Policies: https://help.okta.com/en/prod/Content/Topics/device-trust/SAML/Desktop/configure-conditional-access-policies-desktop.htm

The following options are considered legacy authentication protocols described by Microsoft; they overlap with Google's “Less Secure Applications”.

• Authenticated SMTP - Used by POP and IMAP clients to send email messages.

• Autodiscover - Used by Outlook and EAS clients to find and connect to mailboxes in Exchange Online.

• Exchange ActiveSync (EAS) - Used to connect to mailboxes in Exchange Online.

• Exchange Online PowerShell - Used to connect to Exchange Online with remote PowerShell. If you block Basic authentication for Exchange Online PowerShell, you need to use the Exchange Online PowerShell Module to connect. For instructions, see Connect to Exchange Online PowerShell using multi-factor authentication.

• Exchange Web Services (EWS) - A programming interface that's used by Outlook, Outlook for Mac, and third-party apps.

• IMAP4 - Used by IMAP email clients.

• MAPI over HTTP (MAPI/HTTP) - Used by Outlook 2010 and later.

• Offline Address Book (OAB) - A copy of address list collections that are downloaded and used by Outlook.

• Outlook Anywhere (RPC over HTTP) - Used by Outlook 2016 and earlier.

• Outlook Service - Used by the Mail and Calendar app for Windows 10.

• POP3 - Used by POP email clients.

• Reporting Web Services - Used to retrieve report data in Exchange Online.

• Other clients - Other protocols identified as utilizing legacy authentication.