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:
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
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.
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.
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”
One thought on “Conditional Access, the Good, the Bad, and the Ugly”