Last Updated on June 20, 2022 by Oktay Sari
This post is about blocking access to Microsoft 365 outside the Android for Work Profile with Endpoint Manager. After seeing a question on techcommunity I thought I might as well do a quick post on this topic.
Please note: Normally you would block access to Microsoft 365 resources by using a combination of device compliance and conditional access policies. Simply put, if the device is not compliant (not managed), you are not granted access. When using the personal profile, the device should not be compliant. Using this method, the user will see an error on the device like the one below. The Sign-in logs will also show an error.
Sign-in error code 530003 “Your device is required to be managed to access this resource.”
This method works great, if your configuration is spot on. Because this method might give users the option to enroll their device with Endpoint Manager. And that might leave a user with an out. The Grant control in your Conditional access Policy is set to Grant access if..
But there are many roads to Rome, so let’s see if there are other ways to block access to Microsoft 365 outside the Android for Work Profiles.
Use case
first and foremost, I agree with you that a compliance policy should be good enough, but there are scenario’s where you might need another option to add on top of compliance policies. For example;
- Your compliance policy action to Mark a device noncompliant is scheduled for anything other than Immediately (allowing to sign-in outside the work profile during grace period)
- Your conditional access policy Grant control is set to multiple controls and you Require one of the selected controls (for example, a compliant device or MFA). I know, I know, you should not configure a CA like this, but I’ve seen stranger things.
- Your conditional access policy excludes trusted locations (yeah… not a good idea)
- You don’t have enrollment restrictions for Android device administrator
Note: If you allow both Android device administrator and Android Enterprise, devices that support Android for work profile will enroll with a work profile. Devices that don’t support it will enroll on the Android device administrator platform. Meaning users are allowed to enroll personal devices using the legacy Android device administrator.
Tip: Block Android device administrator with enrollment restrictions 😉
Blocking access to Microsoft 365 with Conditional access and filter for devices
I created a conditional access policy with filter for devices to block access to Office 365, only when the device is an Android and the OS type, is not equal to AndroidForWork or AndroidEnterprise.
Here’s how I configured my Conditional Access policy:
Name | block O365 outside workprofile | |
Assignments | Specific users included | testuser@yourtenant.com |
Cloud apps or actions | Include: Office 365 | |
Conditions – Device platform | Include: Android | |
Conditions – Filter for devices | Exclude: Rule syntax> | device.operatingSystem -eq “AndroidForWork” -or device.operatingSystem -eq “AndroidEnterprise” |
Grant | Block Access |
My Filter for devices is set to Exclude and the rule syntax is device.operatingSystem -eq “AndroidForWork” -or device.operatingSystem -eq “AndroidEnterprise”
This policy works for me and I’ll show you what the user experience is like, later on. First a little deep dive in conditional access filter for devices and my journey to a working filter.
Conditional access Filter for devices and Android for Work Profile
When I was testing this, I had a look at the Policy behavior with filter for devices documents once again. First I wanted to target only unregistered devices (when using the device outside the Android for Work Profile) so I configured my filter different than in the above example. I used Include filtered devices and a negative operator like this:
Time to see if it works. When I start Outlook from within the Android for Work Profile, I can sign-in and open my e-mail. When I sign-in from outside the work profile, I’m blocked and cannot continue. Looking at the sign-in logs, I can see that the attempt from an unknown device matched the device filter and is indeed blocked by the conditional access policy. Great, it seems to work!
The Sign-in logs will show an error;
Sign-in error code 53003 “Access has been blocked by Conditional Access policies.”
When clicking on the Conditional Access tap I can open the CA that fails to see more info. The device matched with the filter and therefore the CA blocked access.
The error codes I’ve showed this far are:
- Sign-in error code 530003 “Your device is required to be managed to access this resource.”
- Sign-in error code 53003 “Access has been blocked by Conditional Access policies.”
Have a look at the Policy behavior with filter for devices doc again and focus on the unregistered device state:
Filter for devices condition | Device registration state | Device filter Applied |
Include/exclude mode with positive operators (Equals, StartsWith, EndsWith, Contains, In) and use of any attributes | Unregistered device | No |
Include/exclude mode with negative operators (NotEquals, NotStartsWith, NotEndsWith, NotContains, NotIn) and use of any attributes | Unregistered device |
You see it? The device filter will only apply if you include or exclude with negative operators.
I got Issues with Conditional Access Filter for devices
Now this filter was working, until I added AndroidEnterprise to my rule syntax like this:
device.operatingSystem -ne “AndroidForWork” -or device.operatingSystem -ne “AndroidEnterprise”
Why you ask? Because I also have fully managed corporate owned devices. According to the documentation this should work too, but it only works partially. Now, the Conditional Access Filter for devices only considered the first expression I’ve set. In this example AndroidForWork.
When I looked at the sign-in logs, I could see that the attempt from an AndroidEnterprise device was blocked. The sign-in from an AndroidForWork device still worked, and I also got a nice block from outside the work profile. I’ve done another post where I had similar issues with Conditional Access Filter for devices.
That’s not good! The device still seems to match with the filter. If you only have personally-owned devices with work profiles then you’re good to go. On the other hand, if you have other enrollment profiles, like Corporate-owned, fully managed or Corporate-owned devices with work profile, then you need to consider another configuration.
Update: It seems I had a logic error in my filter, which is why it only worked partially. You must use “and” to combine multiple “not equal” conditions, or else the expression is always going to be true.
Workaround to blocking access to Microsoft 365 outside the Android for Work Profile
The workaround to blocking access to Microsoft 365 outside the Android for Work Profile is like I showed at the beginning of this post:
My working Filter for devices is set to Exclude and the rule syntax is device.operatingSystem -eq “AndroidForWork” -or device.operatingSystem -eq “AndroidEnterprise”
Now, the filter excludes AndroidForWork and AndroidEnterprise which means that every other OS on a Android device is blocked. In other words, It will still continue to block sign-in from outside the work profile. The Sign-in logs will show the same error as before;
Sign-in error code 53003 “Access has been blocked by Conditional Access policies.”
But when you click on the Conditional Access tab, you’ll see a different error. Now the device did not match with the filter, and therefore the CA blocked access.
Things to consider
In this example, I’ve configured a straight forward conditional access policy, but you might want to check yours and make sure it matched your own requirements. For example:
- Select more specific cloud apps like Exchange Online
- Exclude cloud apps
- Exclude users, groups or break glass accounts
- Configure client apps
User experience
Finally let’s have a look at what the users see on their devices, and what the back-end shows us.
[…] https://allthingscloud.blog/blocking-access-to-microsoft-365-outside-the-android-for-work-profile-wi… […]
You had a logic error in your filter, which is why it only worked partially. You must use “and” to combine multiple “not equal” conditions, or else the expression is always going to be true.
Thx Hans! I’ll update that part of the post. I guess I didn’t see the logic part of it 🙂
Sorry Oktay but i’m not sure about which one is the correct policy to apply…
Hi,
What about iOS?
Great article, is it possible to do the same for iOS devices?
Like the others asked, how can this be done for iOS?
Did you figure it out for IOS?
good morning, how did you arrive at this solution?
device.operatingSystem -eq “AndroidForWork” -or device.operatingSystem -eq “AndroidEnterprise”.
To be more specific I would like to know how and where you obtained the operating system info and the correct value (AndroidForWork-AndroidEnterprise) .
Thank you , regards
Hi, i have a similar case rigth now, the intune says my devices i complian but entraID under devices it says N/A in compliant, it seem like entraID and Intune not syncing, does any one what to do ? Microsoft is not really helping in that case i created, they just refer to some documentation hwo has nothing to do with that.