Month: January 2018

續上回～

其實係網上講ADFS 嘅post 大多係接近一年以上嘅舊article。2017 後半嘅新post接近 “0” 。 係無頭絮下只可以用舊sample code 去砌claims rule 去試，

失敗例子如下

Sample1

NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip”, Value =~ “\bXXX\.XXX\.XXX\.XXX\b”])&&

NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”, Value =~ “Microsoft.Exchange.ActiveSync|Microsoft.Exchange.AutoDiscover”])&&

NOT exists([Type == “http://schemas.microsoft.com/claims/authnmethodsreferences”, Value == “http://schemas.microsoft.com/claims/multipleauthn”])

=> issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “DenyUsersWithClaim”);

第一個諗到嘅做法係用有冇行MFA，基如Legacy Client嘅ActiveSync係唔會行MFA（係Part1 AAR 已經界定）。理論上係啱，但係……所有係Internal嘅user一樣唔需要MFA，結果係邊成Internal client亦唔會去login到任何Azure Services….

係試呢段Claims Rule 意外採集獲係，假若Client係用Modern Auth,如果Claim Rules 有用
“exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”])”

係會變成 Always Permit

Sample2

Rule1
c:[Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip”, Value =~ “IP address range”]
=> issue(Type = “http://custom/allow”, Value = “true”);

Rule2
exists([Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value =~ “S-1-5-xx”])
=> issue(Type = “http://custom/allow”, Value = “true”);

Rule3
exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”, Value =~ “Microsoft.Exchange.ActiveSync”])
=> issue(Type = “http://custom/deny”, Value = “true”);

Rule4
exists([Type == “https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, value =~ “Outlook-iOS|Outlook-Android”])
=>issue(Type = “http://custom/deny”, Value = “true”);

Rule5
exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value =~ “/adfs/ls|/adfs/oauth2”])
=>issue(Type = “http://custom/deny”, Value = “true”);

Rule6
c:[Type == “http://custom/allow”, Value == “false”]
=> issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

Rule7
c:[Type == “http://custom/allow”, Value == “true”]
=> issue(Type = “http://schemas.microsoft.com/authorization/claims/permit”, Value = “true”);

呢個係非常極端嘅做法.，再無Default Permit All係最頂，純粹用AD Group去做Control。 Rule 3,Rule5 都係無效果

，再無Default Permit All係最頂，純粹用AD Group去做Control。 Rule3 都係對Modern Auth無效果，Rule5 亦無法試出預期嘅results。最終如果User係Exception Group(AD Group)，就會用得到。

唯一試到係Rule4可以成功Restrict Outlook Mobile for Android/iOS

Characteristic	String for iOS	String for Android
DeviceModel	Outlook for iOS and Android	Outlook for iOS and Android.
DeviceType	Outlook	Outlook
UserAgent	Outlook-iOS/2.0	Outlook-Android/2.0

但係仍然無法簡單地只Restrict iOS Native Mail 去Exchange Online

Part3 Continue – 最後嘅做法

Reference

https://technet.microsoft.com/en-us/library/mt465747(v=exchg.150).aspx

 

 

係做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://www.netiq.com/documentation/netiqaccessmanager4_appliance/identityserverhelp/data/b1afcrj9.html

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