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 over 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 can 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 be aware that they must be compliant to pass the Conditional Access Rule.
For example, when you require all devices to be encrypted with Bitlocker before they can access your data.
As shown above, the device isn’t compliant (-2016281112) because it requires another reboot. I am describing it all in this blog below.
So, you need a compliance policy. Again, not a problem. 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 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 would make more sense if Microsoft added the following option to the access controls in conditional access: Next to Hybrid Entra joined devices, give us the option to also grant access to Entra joined devices!
But I am not done yet, because when requiring compliant devices before you can 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 concerns accessing the Microsoft Store to ensure 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”
One thought on “Conditional Access, the Good, the Bad, and the Ugly”