係做MDM嘅過程，自己一即避免嘅係唔好用Office365。
點解咁諗？係因為若無辦法好好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 == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”]) &&
exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”, Value =~ “Microsoft.Exchange.ActiveSync”])
&&
NOT exists([Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value == “S-1-5-21-xxxxxxx”])
&&
NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip”, Value =~ “\bxxx\.xxx\.xxx\.xxx\b”])
=> issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, 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
Background
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 (http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application) is no longer present for any ADAL-enabled client.
Reference URL
https://www.mobileiron.com/en/smartwork-blog/practicing-safe-security-ios-11-and-office-365
https://blog.peterdahl.net/2017/09/12/ios-11-provides-support-for-oauth-2-0-in-the-native-mail-app/
Adjust your AD FS claims rules to account for Modern authentication