This week again something completely different. This week I’m going into the world of AD FS. More specifically, I’m going to use AD FS to prevent specific devices from accessing Microsoft Intune (and Office 365). I’ve received that question a few times lately, of which a couple of times on the Microsoft Intune forums, and I thought it would be worth a small blog post.
Using AD FS to deny specific claims is not the prettiest method to prevent users and/or devices from accessing Microsoft Intune (or Office 365). However, it can be very efficient for specific use cases. This blog post will provide an easy method to find the required information to construct the claim rules and a step-by-step direction for configuring the relying party trust. However, keep in mind that it’s only meant to provide a configuration suggestion and to show the many configuration capabilities of AD FS. This suggestion can be easily expanded to create a more specific scenario.
Construct claim rule
Let’s start with finding the required information to create and configure the claim rule. I always like to use an environment in which I can simply deny all the access to the specific relying party. That will make it fairly easy to find the required information for the claim rule. By not permitting access to the relying party, the Event Viewer will generate messages about every request for a token for the relying party. Especially the Event ID 501 messages are interesting. Those messages provide information about the caller identity, which includes the information about the device that’s being used.
The information that I’m looking for is available in the claim http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent. That claim contains the information that I’m looking for. However, keep in mind that it differs per application and per device, which information is provided as part of that claim. I used the Company Portal app, during my search for the required information, and that provided me with the following information about the devices that I used.
Device | Value |
iPad Mini 2 | Mozilla/5.0 (iPad; CPU OS 9_3_1 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Mobile/13E238 |
Nokia Lumia 930 | Mozilla/5.0 (Windows Phone 8.1; ARM; Trident/8.0; Touch; rv:11.0; IEMobile/11.0; NOKIA; Lumia 930) like Gecko |
That information can be used during the construction of the required claim rules. In the claim rules I can check for the existence of a specific value that’s provided in the claim. Based on the information, that was provided, I created the following existence rules, in which “(?i)” means that it’s not case sensitive.
Device | Value |
iPad Mini 2 | exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “(?i)ipad”]) |
Nokia Lumia 930 | exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “(?i)lumia\ 930”]) |
Configure relying party trust
The existence rule can be used to deny the access to the relying party. The following step-by-step example will create a claim rule that checks if the device enters through the proxy (x-ms-proxy) and that checks for the device type (x-ms-client-user-agent). When both are evaluated as true, the access will be denied.
- Open the AD FS Management console;
- Navigate to AD FS > Trust Relationships > Relying Part Trusts;
- Right-click the Microsoft Office 365 Identity Platform trust and select
Edit Claim Rules…; - Navigate to Issuance Authorization Rules and click Add Rule… to open the Add Issuance Authorization Claim Rule Wizard;
- On the Choose Rule Type page, select Send Claims Using a Custom Rule and click Next.
- On the Choose Claim Rule page, specify a Claim rule name, provide the following Claim rule and click Finish.
exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”]) &&
exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “(?i)lumia\ 930”])
=> issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”); - Verify that this new claim rule is created below the default Permit Access to All Users claim rule.
This example will prevent the end-user from using a Nokia Lumia 930 for accessing the relying party. Simply perform the same steps and adjust the existence rule to prevent an iPad from accessing the relying party.
End-user experience
Now it’s time to have a look at the end-user experience. This time it’s extra important to realize the impact on the end-user experience, as the end-user will not get a very clear error message. Based on the examples used in this blog post the end-user will have the following experience on an iPad Mini 2 and a Nokia Lumia 930.
iPad Mini 2 | Nokia Lumia 930 |
![]() |
![]() |
More information
For more information about limiting access to Office 365 and using regex in claim rules, please refer to the following articles:
- Limiting Access to Office 365 Services Based on the Location of the Client: https://technet.microsoft.com/en-us/library/hh526961(v=ws.10).aspx
- AD FS 2.0: Using RegEx in the Claims Rule Language: http://social.technet.microsoft.com/wiki/contents/articles/16161.ad-fs-2-0-using-regex-in-the-claims-rule-language.aspx
Discover more from All about Microsoft Intune
Subscribe to get the latest posts sent to your email.
Thanks for sharing, is this still valid?
Thanks publishing, is this still valid? When performing a simple copy and paste into a new custom rule I receive the following error when I select OK:
“POLICY0002:Could not parse policy data Line number1 Column number: 16, Error token: “. Line exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “(?i)ipad”])
=> issue(Type = “http://schemas.microsoft.com/authorization/claims/permit”, Value = “true”);
“Parser error: POLICY0029: Unexpected input’.
I’m running Windows 2012 ADFS 3.0 with existing ADFS Office 365 claims rules. Any help is appreciated.
It should still work. It could be a matter of wrong quotes that are shown when copied.
Hi Peter,
Nice article. Is there a way to block devices based on Serial Number?
We have to block personal iOS devices from enrolling in SCCM 1702 Hybrid.
Thanks.
Hi Reddy,
1706 introduces the ability to block personal devices from enrolling.
Peter