Another piece in the puzzle. That’s what struck me when I first saw AzureIP being protected by conditional access policies at Ignite last September. And this piece allows you to manage how your users can access AzureIP labelled and protected content.
Start from the top
Let’s say I would try to open a document from an unmanaged device. And this document is labelled and protected by Azure Information Protection. Normally, this will not be a problem. The document is opened and AzureIP will check your credentials and permissions on the document. It will enforce these permissions and the document is presented to me.
But let’s assume that we want to add some more protective measures. For instance, we do not want AzureIP protected content to be opened from an unsafe location or an unmanaged device. Or, more basic, we want to verify the identities of our users by using multi factor authentication. That’s where conditional access steps in.
Conditional access
Azure AD conditional access allows you to set conditions for users trying to connect to specific platforms. Using an authenticator app on your mobile device when accessing your e-mail (multi factor authentication) is one example of this.
Conditional access has two main compontents: the condition and the action. The condition is based on either the sign-in risk, device/platform, location or even the client-app of your users.
Based on this condition, you can enforce your controls.
And AzureIP is now part of the cloud apps you can configure for conditional access. When set-up correctly, you can disallow the use of AzureIP if the device is not domain joined (for example).

In action
When configured and after a couple of minutes, the AzureIP client will start to notice the conditional access policies. In the examples below I tried to login to AzureIP, when (figure 1) multi factor authentication was required and (figure 2) my device was not trusted.


Do be careful! These conditional access policies also work when accessing the admin portal. Which makes sense. But if you encounter these kinds of errors:

Then you know where to look…
Nice stuff!
Much more information then in this blog 🙂 can be found here: https://cloudblogs.microsoft.com/enterprisemobility/2017/10/17/conditional-access-policies-for-azure-information-protection/
This only works in Word and the AIP client when I reset the AIP Client and therefore have to login again.
I have a policy to block access for all users as a test. It works for new users, but not users who have already run the AIP client, even if I reboot their machines. If I reset the AIP client (under help and feedback menu) then I get blocked as I should.
Hi Guy,
That’s weird. I haven’t noticed this. Have you tried a newer (or preview) version of this client? Or have you tried changing the conditional access settings?