My ADFS Claims Rules Journey – Part 1



點解咁諗?係因為若無辦法好好Restrict 街外Unauthorized Access的話。User可以隨便加Email account收Email,咁整套MDM相等明存實亡。

而普遍用Mail多嘅,自己首先會針對點樣封Exchange Online,不論係Android/iOS 嘅Native Client,甚至係Outlook Mobile App,都係要封嘅對象。

首先要提嘅係,真係多得iOS11係17年九月出左,啲花左唔小時間做落嘅Claims Rule 失效。

簡單以條片嚟做Sample,同iOS11之前嘅差別。當用噤Sign-In之後,會redirect 去另一個WebPage去繼續Authentication 。呢種就係Passive Authentication

講咁多做咩?就係Passive Authentication(Modern Authentication)令到以往做落嘅Claim rules 廢武功。

以下係 係iOS 11 前用緊嘅rules

exists([Type == “”]) &&

exists([Type == “”, Value =~ “Microsoft.Exchange.ActiveSync”])

NOT exists([Type == “”, Value == “S-1-5-21-xxxxxxx”])

NOT exists([Type == “”, Value =~ “\bxxx\.xxx\.xxx\.xxx\b”])
=> issue(Type = “”, Value = “true”);


Rule1 當Connection係由街外,

Rule 2 Client Type係ActiveSync,

Rule 3 User唔屬於Permitted Group

Rule 4 唔係由指定ActiveSync Proxy IP Connect過黎

全部符合 就會俾Deny Claim

因為Rule2係Passive Authentication 再無X-MS-Client-Application嘅claim value,無辦法確定Client Application Type,結果會係同其他Browser Based Application 一樣Allow Access


To Be Continue in Part 2


Reference from Link1


Based on the latest beta builds, Apple has added OAuth 2.0 support for Microsoft Exchange accounts in iOS 11, showing an increased commitment to device security. In my opinion, this may be iOS 11’s least talked about, but most impactful feature for enterprises because of the implications for securing iOS with Office 365 and Exchange Online. Let’s dig deeper.

A Brief History on Securing Exchange ActiveSync

Prior to iOS 11’s OAuth 2.0 implementation, ActiveSync email clients such as iOS’s native email handled account authentication to Exchange Online exclusively via something called an Active Profile. The Active Profile defines ActiveSync authentication techniques for non-browser or modern authentication-based clients.

On-premises Microsoft Exchange servers are deployed on secure networks behind layers of firewalls and only accessible to email clients through ActiveSync Proxies. Administrators have significant granular access control via proxies, especially in allowing access to the Exchange servers only from the trusted IP addresses of the proxies. MobileIron’s Sentry is an extra-powerful ActiveSync proxy for mobile devices because the Sentry allows or denies ActiveSync access to the Exchange server based on both device and application posture received from the policy engine on MobileIron Core or Cloud. With Sentry, only trusted mobile devices can access ActiveSync email; users attempting to access email from untrusted mobile devices are denied by the Sentry. Thousands of large enterprises protect their on-premises Exchange servers with Sentry today.

Reference from Link2

In a Passive authentication scenario, the user signs in through a Web form displayed by the identity provider and the user is requested to log in. In Active authentication scenario, the user is authenticated using thick clients. As the thick client does not support redirection, Office 365 gets the credentials and validates the authentication with Access Manager by communicating directly with it.

Reference Video from Link3

Reference from Link4

Another point that you have to account for in redesigning your claims rules is the fact that the Client application clam ( is no longer present for any ADAL-enabled client.

Reference URL

Adjust your AD FS claims rules to account for Modern authentication

Leave a Reply

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