Last Updated on July 7, 2022 by rudyooms

What do I mean by this? 

Conditional Access is an extremely powerful tool within the Microsoft 365 environment. Even when you implement just the basics it provides your tenant with a security baseline but there are some quirks and flaws that I’ll cover in this blog: 

The Good: 

You can control the IF and THEN conditions. For example, IF an end-user tries to connect to portal.office.com from a non-compliant device, THEN it should prompt you for MFA. 

There are a lot of other possible Conditional Access rules you could implement giving you more control about things such as risky sign-in behavior or the persistent browser mode.  Luckily Microsoft has given us wonderful templates we could use to start implementing it

If you are wondering which Conditional Access rules we normally implement you could always take a look at my Github. It will show you a simple PowerShell script that could help you when deploying Conditional Access rules

https://github.com/Call4cloud/Enrollment/blob/main/CA/DU8_Deploy_ConditionalAccessRules.ps1

The Bad:  

Is there anything bad about Conditional Access? It depends… but when using compliant devices we need to beware of the fact that your devices need to be compliant to pass the Conditional Access Rule.

As an example, when you are requiring all devices to be encrypted with Bitlocker before they could access your data.

As shown above, the device isn’t compliant because it requires another reboot. I am describing it all in this blog below

So, you need a compliance policy. Again, not a problem. But for example, a while back there was a problem when you implemented the Bitlocker compliance check as a requirement for your devices to be compliant. Simply because Microsoft 365 couldn’t always determine the state of Bitlocker or on your devices.

Suddenly all your devices were marked non-compliant! Conditional Access cuts off your access to the company’s data at that point. Of course, there are some settings you can change to help mitigate problems like this.

The option to mark the device as not compatible after a few days will ensure your users won’t immediately lose access to their files… Giving you some time to change the compliance requirements. As of right now, this Bitlocker compliance check is working correctly again. But you never know what will break next… 

In my opinion, it makes more sense if Microsoft would add the following option to the access controls in conditional access… Next to Hybrid Azure AD joined devices give us the option to also grant access to Azure AD joined devices!  

But I am not done yet, because when requiring compliant devices before you could access “All Cloud Apps” you could also run into some other issues

I will try to explain it with a couple of examples but both of them share the same service! The Microsoft Store Service

The first example will show you what could happen when you are using the Online Company Portal and require a compliant device before accessing all cloud apps

The second example is about accessing the Microsoft Store to make sure the device gets upgraded to Enterprise. When requiring compliant devices before accessing all cloud apps, you could run into some issues.

The ugly:  

Imagine this scenario:  Your customer wants to migrate to Office365 but without compliant devices. You still want to protect their data. One of the Conditional Access rules you’ll probably implement is: “blocking access from foreign countries“

In my next blog, I will tell you about the “Ugly” (curse) of the IPV6 Conditional access policy. 

Conclusion: 

Using conditional access with compliant devices is the way to go. It’s the only way to put some barriers in front of your Office 365 tenant. Hopefully, this blog showed you some important stuff we need to beware of when implementing some Conditional Access rules like the “Require Compliant Devices”