Prevent specific devices from accessing Microsoft Intune

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.

  1. Open the AD FS Management console;
  2. Navigate to AD FS > Trust Relationships > Relying Part Trusts;
  3. Right-click the Microsoft Office 365 Identity Platform trust and select
    Edit Claim Rules…;
  4. Navigate to Issuance Authorization Rules and click Add Rule… to open the Add Issuance Authorization Claim Rule Wizard;
  5. On the Choose Rule Type page, select Send Claims Using a Custom Rule and click Next.
  6. 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”);

  7. 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
IMG_0037 wp_ss_20160501_0001

More information

For more information about limiting access to Office 365 and using regex in claim rules, please refer to the following articles:

4 thoughts on “Prevent specific devices from accessing Microsoft Intune”

  1. 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.

    Reply
  2. 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.

    Reply

Leave a Reply to Peter van der Woude Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.