I want to drop some lines about my experience deploying several projects of Azure Conditional Access
- Always exclude your emergency accounts from the conditional access policies (remember if you don’t have an Emergency Account, you’re late), this is something that I always tell to my customers and I will never give up
- Don’t enable new policies without communicate properly to the organization, and also to foresee the impact in the users (you will save a lot of tickets from the customer service)
- Don’t enable policies that requires compliant or hybridAzureAdJoin devices without verifying the state of the devices in the Azure Portal (same as before, you will save tickets and system interruption from the end users)
- Careful with including in the policies the application “all apps”, is it possible to have a disgusting surprise (in my case, it happened to me in Azure, I put some exclusions, but it seems that sometimes the portal calls randomly to other APIs that cannot be controlled (and do not exist in AAD), so the user received a block in the portal even if the policy makes sense for you)
- If you go ahead with the policy with “All Cloud Apps” for the policies bases on devices, be sure to exclude in the policy the app “Intune Enrollment” or you won’t be able to enrol new devices in the portal
- It is very easy to include multiple cases in one policy, but if you want to troubleshoot of what is happening, is it easier to segment the policy in multiple policies. Eat the elephant bite by bite, we have to put in the balance having and managing several policies or be able to troubleshoot correctly.
- Is it recommended to include a naming convention in your policies, in a bird’s eye, you will be able to know what is the use for each policy (user, device, administrator, guest)
So, this is all, probably you’re following most of these recommendations, but if not, don be a fool 😉
Till next time!