Azure AD Conditional Access Policies Base Recommendations

|
Published

Cyber attacks and ransomware have unfortunately become big business, and a more and more frequent occurrence. Ensuring that your organization has the appropriate policies in place goes a long way in preventing these sorts of attacks.

Conditional Access Policies are a feature of Azure AD Premium, and are a feature we recommend every one of our clients has. It can be licensed in a number of ways, but it is not included in the base Microsoft 365 subscriptions.

Conditional Access Policies allow IT to define and enforce policies before users are granted access to different systems. It doesn’t have to be one size fits all, and different policies can be applied based on whom the user is, what they are able to do, and the sensitivity of that system or information.

If you’re not familiar with Azure AD Conditional Access Policies, here are a few Microsoft articles to get you started:

We’ve put together a set of rules that we feel organizations should use as a starting point when defining their policies. Of course, it may make sense to engage an external security firm to assist with this. We are not that firm, but we can provide recommendations if need be. You can jump down to the recommendations here.

Two of the biggest attack surfaces for cyber crime are brute force password attacks, and legacy authentication protocols being allowed. Conditional access policies virtually eliminate both of these.

Passwords are not a good single line of defense for security. Users re-use passwords between systems, and when their password is compromised in one system, those breached credentials can be used on others. Dictionary attacks and other brute force methods also succeed by trying massive numbers of passwords until one succeeds.

Multifactor authentication is part of a strong defense against password attacks. Azure AD Identity Protection can identify risky sign-in behaviour, and conditional access can use this as well as the number of failed sign-in attempts to force a second factor of authentication. This can be a phone call or SMS text code, but the best method is to have the user register the Microsoft Authenticator app on their mobile device. This will prompt them to approve the sign in and prove that they both know something (their password) and have something (their mobile device). It also serves as a notification to the user if someone else is trying to use their credentials.

Another strong recommendation for password protection is to provide a password management service for users to manage their passwords in securely. Check out our How We Use 1Password to Manage Our Internal and Client Credentials article for more details.

We recommend that every user account (whether a real person or a “service” account) require MFA. The only exception is emergency accounts, which we’ll discuss further down. There should not be any other exceptions. This may break some legacy applications, but those should be refactored to eliminate this requirement, and if that is not immediately possible, specific policies should be applied to those accounts to make the scenarios where those accounts can be used be as restricted as possible.

The other big attack surface mentioned above is legacy authentication protocols. This is usually older legacy applications and can even include Microsoft products like older versions of Microsoft Outlook. These authentication protocols are no longer secure and should not be permitted. A single conditional access policy can be used to block all legacy authentication protocols for everyone and is recommended. This may break some user's applications, and the policy can be tested in a report only mode first to determine if there are application upgrades needed to some users before enforcing the policy.


Base Recommendations

Here’s our set of base recommendations. It is not an exhaustive list but should be used to start a conversation with your Managed Services Partner or security consultants.

  • Create an emergency account that is excluded from all policies in case you lock yourself out of your tenant
  • Ensure that any admin has a separate cloud-only admin account they only use for administrative purposes
  • Setup notifications when the emergency account is used
  • Minimize the number of policies to reduce the risk of leaving gaps in your policies
  • Block legacy authentication protocols
  • Apply policies to all apps
  • Define at least three sets of user groups
    1. Admins
    2. General users
    3. External (guest) users
  • You may have additional groups depending on role, system, or sensitivity of data being accessed
  • Require MFA for all users
    1. Define more restrictive policies for admins
  • Block access from countries that you never expect a sign-in from


Emergency Accounts

While it is important to apply conditional access policies to all users, including admins, there is a risk of mis-defining a policy and actually preventing admins getting access to fix the policy. This effectively blocks all access and locks you out of your tenant. This is not a place you want to be as an IT administrator.

Emergency accounts are a back-door way to get back in if you find yourself in this situation. The idea is that they are excluded from all policies, and are a guaranteed way to get back in. Obviously, that raises a security risk, and they need special controls.

One of the best ways to put controls on this is to require multiple people to gain access through the emergency account. This is done by splitting the password into multiple components and having two or more admins have only their portion of the password in their private password vault. This way all admins must agree to use the emergency account.

The other thing to do is to ensure that there are notifications sent to all administrators whenever the emergency account is used. This way if it is improperly used, everyone is aware and can take appropriate action.


Block Legacy Authentication Protocols

Due to the increased risk associated with legacy authentication protocols, Microsoft recommends that organizations block authentication requests using these protocols and require modern authentication. For more information about why blocking legacy authentication is important, see the article How to Block Legacy Authentication to Azure AD with Conditional Access | Microsoft Docs.


Require MFA For All Users

As Alex Weinert, the Directory of Identity Security at Microsoft, mentions in his blog post Your Pa$$word doesn't matter:

Your password doesn't matter, but MFA does! Based on our studies, your account is more than 99.9% less likely to be compromised if you use MFA.

As mentioned above there should be no exceptions to this policy other than the emergency account. This may break some legacy applications using service accounts, but those should be refactored to eliminate this requirement, and if that is not immediately possible, specific policies should be applied to those accounts to make the scenarios where those accounts can be used be as restricted as possible. User credentials should not be used as service accounts, managed identities should be used in those scenarios.

Admin accounts should have the most restrictive policies applied to them, since they have the most rights. We configure our policies to require MFA on every authentication, even if it is a trusted device with a recent session. You may choose to relax this, but we feel it is appropriate.

User accounts can have a variety of factors in their policies.

  • Where the user is signing in from
  • Whether they are on a corporate device or not
  • What systems or information they are accessing
  • If they have recently failed a password authentication
  • How recently they successfully completed an MFA authentication

Certain applications like SharePoint Online in conjunction with Azure Information Protection can also apply additional policies depending on the sensitivity of the data being accessed. For example, a user may not be prompted for MFA because they recently successfully completed it, but then they access a highly sensitive site or document, and an immediate MFA challenge is required before they can proceed, even though they are already signed in.

The last group is the external (guest) users. This can be tricky, because requiring MFA for all your guest users can be problematic. It requires that guests that are external to your organization and not supported by your IT team go through the MFA on-boarding process to choose and setup their MFA method with their mobile device. This can overwhelm many guests and cause them to abandon their attempts to access your resources, which is a poor user experience.

Contrary to earlier statements, it is better to not require MFA for guest users unless the sensitivity of the information and systems being accessed requires it. For example, many of our clients bring guest users in to complete learning in their LMS. The sensitivity of this content is not that high and having guests not able to complete their learning because of MFA complexity outweighs the security concern.

If you do find that some or all of your guests should require MFA, another option to consider is to trust their organization’s MFA if they support it. This would prevent guests having to go through two MFA challenges – one for their organization and another for your tenant. For more details on this see our Azure AD Cross-Tenant Access Settings article.

Latest Articles