The curse of the IPV6 and conditional access.

The curse of the IPV6 and conditional access.

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: blocking access from foreign countries.

It’s not the best Conditional Access policy out there, but hey… It creates another barrier.

Beware of the IPV6 curse though. Conditional access and IPV6 don’t go well together.

When you implement this policy without your devices being compliant, there is some possibility users are denied access. When users blame you for having no access, go check out the Azure sign-in logs because they’re probably right!

The picture above is very clear.  Microsoft doesn’t know about the IPV6 locations (for now). You’ll see the error shown above. That’s odd… Why can’t Microsoft detect where the IPV6 location belongs to? All other IP finder tools certainly can!

I guess we have to live with it for now… There are 5 possible solutions to make the user happy again.

  • 1: Exclude the user from the policy (bad idea)
  • 2: Exclude all IPV6 provider address ranges (could be a lot of work to maintain if every user has its own phone and a different provider)
  • 3: Exclude Exchange Online (again a bad idea)
  • 4: Select the unknown locations. (it simply means all ipv6 addresses. Not bad/not good)
  • 5: Go full Office365 when you can, and work with compliant devices. When doing so you can exclude these compliant devices. This is, if possible, your best option.


Microsoft’s conditional access is not without its flaws. But if you slowly move towards a full on Office365 environment with compliant devices, it can be a powerful solution to your customers IT challenges… As long as you keep security top of mind!

Leave a Reply

Your email address will not be published. Required fields are marked *

7  +    =  8