You have a Conditional Access policy that requires users to sign in every 4 hours

• Cloud Access Control
• Getting Started with Conditional Access
• Designing Conditional Access Policies
• Improving MFA Efficiency
• Protecting Data
• Less is More
• Documentation
• Audit
• Break The Glass Accounts
• Use Conditional Access!

Cloud Access Control

Compared to an on-premises environment, cloud access control is quite different. While on-premises access controls are often centered on firewalls hosted in the internal network, this does not translate to the cloud – an important fact often overlooked during migration projects.

Since Microsoft 365 tenants use Azure Active Directory for authentication, by default, any user can connect to Microsoft 365 workloads from any place, at any time. While this is great from a productivity standpoint, it definitely raises some security challenges. For example, attackers can execute a password spray attack to guess the password of an account. And because attackers attempt to compromise account credentials, it’s critical to secure access to Azure Active Directory.

Conditional Access (or CA) policies allow you to create rules (or policies) that dictate how a user authenticates to Microsoft 365 and if they must adhere to certain controls. However, Conditional Access isn’t something to quickly dive into without much thought. Instead, you need to really think about what you want to accomplish to secure user connections, which is what I’ll discuss in this article.

Getting Started with Conditional Access

At first, figuring out how to implement Conditional Access can seem daunting since many configuration options exist, and some with little guidance around. The way I see it, Conditional Access policies are specific to an organization and its requirements, and no perfect set of policies exist that work for every organization.

It’s important to note that Conditional Access is an Azure AD Premium Plan 1 feature, so it’s not available in every tenant but it is included in several Microsoft 365 SKUs:

• Enterprise Mobility & Security E3
• Microsoft 365 E3
• Business Premium

Unfortunately, some organizations will try to circumvent this requirement and attempt to migrate on-premises firewall policies to the cloud to replicate access controls. This approach is wrong – the cloud is an entirely new way of working and access control needs to be managed as such. The days where attackers only use IP ranges from specific countries are long behind us and creating IP-based restrictions (either to block connections from certain countries or only allowing certain IP-ranges) will only give you a false sense of security hinder end-user productivity.

When designing Conditional Access policies there are several actions you need to take and things you need to keep in mind. These are basic concepts and actions, but they are extremely important:

• Confirm the user’s identity during sign-in.
• Validate the security of the device used for the connection.
• Enforce stricter controls for administrator accounts.

Microsoft does provide some templates through the Azure AD portal which are a good way to get started, and I found this Microsoft documentation to be extremely helpful as well.

Additionally, there are a few default policies which I recommend that every organization implement:

• Require MFA for users when using non-corporate devices.
• Require a corporate device when using desktop applications.
• Require MFA for administrator without any exclusions.

Improving MFA Efficiency

While Multifactor Authentication (MFA) contributes to a more secure account, spamming users with MFA challenges isn’t always the best solution. If users become accustomed to approving MFA requests, they can fall into the trap of approving challenges without thinking. In turn, this could mean that someone accidentally accepts a sign-in request generated by an attacker which then enables the attacker to compromise their account. While number matching alleviates this issue, user experience is extremely important when implementing Conditional Access policies.

I recommend implementing Conditional Access policies the smart way. Instead of challenging a user with MFA at each login, try to combine other trusted signals to verify the identity of a user. This could be the state of the device (which uses device compliance from Microsoft Intune) or the user’s location (logging in from a known location). By using multiple signals before issuing an MFA challenge, you will drastically reduce the number of challenges a user receives and how much they’re inconvenienced by it.

Read more: Taking Control of Your Unmanaged PCs with Intune

Protecting Data

Conditional Access supports many features besides MFA you’ll want to consider in your implementation. A big plus is the ability to grant granular access to data through Microsoft Defender for Cloud Apps for example, or block access entirely.

Most organizations aren’t aware that anybody can install Outlook and OneDrive for Business on a personal device, and then copy mailbox and document data to that device. In this scenario, when an employee leaves, you have no control over any data copied to their personal device and they can walk out of the door with that data in their pocket. Ensuring that users can copy company data only to company devices is a wonderful use of Conditional Access.

Less is More

Depending on the complexity of the conditions an organization tries to cover, implementation can become cumbersome when it results in a large number of policies. Within larger organizations, I have seen fifty or more policies in use. When the organization wants to change a policy, or the help desk needs to troubleshoot a sign-in, a high number of policies involved with processing sign-ins can make this effort extremely challenging. Therefore, it’s important to think about the big picture at the beginning of this process so you combine as many conditions as possible into one policy.

I try to group policies based on a few different signals, such as:

• The type of user. Administrator accounts need stricter policies than regular users.
• The type of data. Access to Teams should be stricter compared to To-Do, which doesn’t contain as much confidential data.
• The ownership of the device used to access the data, as there’s a big difference between the management of personal and corporate devices.
  • A personal device shouldn’t be trusted with as much data as a corporate device, which will have adequate security controls in place which will ensure data is protected.
  • The ability to require different policies according to device ownership is a great use case.        

If you wish to control all three of these signals, it’s not unusual to have ten or more different Conditional Access policies. However, I would recommend grouping them as much as possible to avoid the complexity that comes with managing many policies.

Documentation

As the number of active policies increases, documentation becomes increasingly important. Your documentation should include details of the configuration and a description of what the policy tries to do, which will help you revert the policy to the original state (if required following a change) and remind you why it was implemented in the first place. While it might not be necessary for smaller environments, this is absolutely a necessity for larger enterprises, especially if multiple engineers are responsible for the policies.

I often draw out the policies into a flowchart, as seen in Figure 1. This allows you to visually follow the login process of a user to determine whether they will receive access or not:

Besides documenting policies, be sure to document your exclusions. Not just what exclusions exist, but more importantly: who added the exclusions and why. This tactic helps as you review the exclusions regularly to decide whether they’re still necessary. For whatever reason, many companies don’t document these kinds of exclusions, nor the reasoning, which means no one dares clean them up because they’re afraid that removal will break something.

Aside from documentation, you can use Conditional Access as code. This means your Conditional Access Policies are saved as json files (code) and pushed through a CI/CD tool such as Azure DevOps or GitHub Actions. Changes are made to the source file, and only after approval will the script push the changes – this ensures all changes are peer reviewed which minimizes the margin for error. And as the policies are stored as code, you also ensure your original state is documented.

Read more: Using PowerShell to Manage Conditional Access (CA) Policies

Audit

While documenting your policies helps to revert policies to the original state after an unintentional change, it’s important to know what happens with your policies. Auditing the creation, updates, and removal of policies ensures you are always aware of their current state.

Conditional Access policies can have an extremely significant impact on an environment – just one mistake can affect users very quickly and you don’t want to be the first customer who locks all users out of the tenant. By default, every tenant has access to the Azure Active Directory audit logs, which allows you to search for any modification on your Conditional Access policies. In addition, you can export these logs to a Log Analytics workspace (optionally using Microsoft Sentinel) to setup alert rules to notify you when a change happens.

Besides monitoring policies, monitoring the groups used in the policies is a great idea. Organizations often use groups to scope policies, and an unwanted change to an exclusion group could create a significant hole within your environment.

Break The Glass Accounts

Conditional Access can be extremely powerful, but also dangerous because one small mistake in a policy can lock all users out of your tenant. An outage in the Azure AD MFA service could mean users are unable to access your tenant, therefore every Conditional Access policy should include at least one excluded account, the emergency or ‘Break Glass’ accounts.

These emergency accounts hold the global administrator role and are used to log into the tenant only during emergencies. Once administrators regain access to the tenant, they can make whatever changes are necessary to restore user access. An overview of best practices for emergency accounts is available here.

Use Conditional Access!

In my opinion, a tenant without functioning Conditional Access policies is an insecure tenant. Besides the benefits of implementing Multifactor Authentication in a smart, user-friendly way, Conditional Access policies have controls to limit what data users can access or download in certain scenarios, adding even more value. While getting started with Conditional Access policies can seem daunting at first, creating a solid design and documenting your policies will make things more manageable.

Which service is required to use a sign

What can use Conditional Access policies to control session in real time?

What can you use to ensure that all the users in a specific group must use multi

What can you use to ensure that all the users in a specific group must use multi