My ADFS Claims Rules Journey – Part 3 – Final

 

 

終於有時間心情寫埋最後呢Part。

繼Part 2。 經過不斷Try on Error試Claims Rules之後。
廠嘅以下呢個Article另我放棄Claims Rules去做Restriction嘅諗法。對於ActiveSync嚟講,似乎用Modern Auth係剋死Claim Rule。

以下 幾類型嘅做法可以取替Unauthorize ActiveSync device access

第一            用MDM Vendor嘅Identity Management Software – 相對難度係最高,因為多用SAML, 需要有Deploy SAML嘅經驗。而Infrasture入面嘅配置已經唔係普通Company會投資

第二            Deploy Certificate Authentication。難度同第一種做法不遑多讓。需要Deploy/ Maintain Internal CA / NDES /PKI infrastructure同樣唔容易

第三            係Azure AD,入面嘅Enterprise App disable iOS Accounts,或者係disable 其他嘅Email Client(e.g. Outlook Mobile).從而Restrict Unauthorize End User去Add Exchange Online Account。 呢個方法非常容易,唯一需要擔心嘅就係唔用iOS Native Email之後,俾End User用嘅Email Client

第四           最後 就係configure Default Block/Quarantine
呢種係最容易,最容易Configure。但係代價係需要人肉Device Control

 

Reference Article

https://www.mobileiron.com/en/smartwork-blog/lets-get-technical-ios-11-oauth-20-office-365

My ADFS Claims Rules Journey – Part 2

續上回~

其實係網上講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

My ADFS Claims Rules Journey – Part 1

 

 

係做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

Work Place by Facebook integrate with Azure AD – Part III

 

 

 

 

Part III

做完對上兩邊Config,係時間測試下成果。

首先係去 “https://mydomain.facebook.com”
WorkPlace login page 顯示 “Your company has enabled single sign-on.”
變成冇得係到用”UserName/Password” Auth

“User Name / Password”  vs “SSO”

 

 

 

 

 

 

 

 

 

 

 

當噉”Log In” 就會Redirect 去Azure嘅Login Page (第一步成功)

 

 

 

 

 

之後就變成同Office365 Login 一樣,需要用 AD Credentail / Client Certificate 做 Auth

係已經Join Domain嘅PC。因為有Kerberos Auth,當Page redirect去到Azure Login,只需要打Username (UPN),往後嘅login process就會用Kerberos 完成

Work Place by Facebook integrate with Azure AD – Part II – Azure AD Enterprise App Configuration / Work Place SSO Authentication

 

 

 

 

Part II

續Part I。Work Place Subdomain 準備就絮~開始戲肉。SAML Config。 如SalesForce一樣,大路嘅Idp(ADFS / Azure AD /G Suite / OKTA / One Login / Ping Identity)都有article講點做。基於Domain 已經係 Azure AD 上面Federated,亦即係同Office365 一樣, 會返ADFS Server 做Auth / MFA。 所以係唔需要考慮ADFS 個article 點做。

SAML configuration 唔難。基本都係兩邊資料 Copy n Paste。 但係最鑊,最怕就係兩邊各自各描述。Field名唔知邊個對邊個。

今次都係,先Configure 係Azure AD,First Try照跟Article係唔夠Parameters

大路照跟可以,但係留意以下Step3 >>>>>> 跟Azure咁做係誤以為夠。第一唔清楚咩係Identifier。跟Azure Article 咁做係唔夠,Sequence亦唔啱。 第一唔清楚咩係Identifier。。。。亦要Tick “Show advanced URL settings”嘅CheckBox

係要返WorkPlace, Dashboard,Authentication,係SAML Authentication 呢個Page 下面嘅Info

Azure “Identifier” = WorkPlace “Audience URL”                                             >>> “https://www.facebook.com/company/15digitvalue”

Azure “Reply URL” = WorkPlace “ACS (Assertion Consumer Service) URL” >>> “https://domain.facebook.com/work/saml.php”

Confusing Sample from Azure

3. On the Workplace by Facebook Domain and URLs section, perform the following steps:

Configure Single Sign-On

a. In the Sign-on URL textbox, type a URL using the following pattern: https://<instancename>.facebook.com

b. In the Identifier textbox, type a URL using the following pattern: https://www.facebook.com/company/<instancename>

係Azure做完上半,噉Save。 再Scroll Down落下面噉”Configure Workplace by Facebook”。 接落嚟嘅Information要放返落WorkPlace嘅Authentication Page。
WorkPlace呢邊係兩個URL相對容易啲啲,不係啲名都係唔match

Azure “Azure AD Single Sign-On Service URL” >>> WorkPlace “SAML URL”

Azure “Azure AD SAML Entity ID” >>> WorkPlace “SAML Issuer URI”

最後當然係Paste 返係Azure Download 嘅Signing Cert落去。 先去噉”Test SSO”。先會Pass 個Test Auth。

Cont’d @ Part III

Reference Link

https://docs.microsoft.com/en-us/azure/active-directory/active-directory-saas-facebook-at-work-tutorial

https://developers.facebook.com/docs/workplace/authentication/sso

Work Place by Facebook integrate with Azure AD – Part I – Subscription + Upgrade to Premium Work Place Premium

 

 

 

 

 

絕對唔係新野。 一兩年前記得叫Facbook for Work,但係搵唔到方法申請。機緣下 上星期睇到Azure 嘅article。

WorkPlace by FB要開Account唔難,去https://facebook.com/work 用Corporate Email account就開到。但就咁普通係做唔到任何Customization嘅(包括Authentication Integration)…….. e.g. “https://work-xxxxxxxx.facebook.com”

所以。。 第一件事係upgrade去Work Place Premium。 Procedure都係基本verify domain ownership。 一係Domain RootLevel 嘅Web Server Webpage放token,另一選擇就係DNS 落 TXT Record (後者絕對易做得多,但係估唔到FB Support話睇唔到我隻Domain host 係邊,唔講 TXT Record 個做法我知……玩野)

時間關係。。 兩日等左 DNS Record Creation 同往後FB嘅vertificaton,之後再需要等FB Subdoamin 由https://work-xxxxxxxx.facebook.com 變成我哋嘅 “https://mymdomain.facebook.com”

當Domain完全轉好(係會慢慢逐小逐小變出嚟,所以收左FB Email話Verification OK,最後都等左兩個鐘(封Mail講十分鐘OK….呃人)

Cont’d – Part II

Reference Link

https://docs.microsoft.com/en-us/azure/active-directory/active-directory-saas-facebook-at-work-tutorial

https://developers.facebook.com/docs/workplace/authentication/sso

初試SAML大集會 ….. 1.OKTA 2.Sales Force 3.ADFS

saml  salesforceoktaadfs-logo

絕對係新挑戰 !!!!!

SAML      一直係以往唔多敢去掂嘅野。相比Kerberos,SAML有自己覺得好難睇嘅XML (Recursive xml)。諗起都怕怕。怕怕。

基如嚟緊好高機會要用同自己嘅未雨綢繆,決定放手睇睇佢……

第一係搵用嘅IdP(Identity Provider) 同SP(Service Provider)
雖然已經有ADFS係到可用, 但係ADFS唔係呢個今次Buildup最初會用嘅。

SalesForce已知嘅係大路嘅Service Provider。。 Production 要錢無可能。但係Developer Edition係兩個User免費 ,未搵到有無Support。 超孤寒。。。。
已IdP係搵嘅當中睇到OKTA。。 佢對比好啲。 三個App,一百個User係永久免費,亦有Support。 好啲

好。。。 準備完成。。 開工

大至上嘅Concept

rtaimage

AD 係Identity  Source, 最初令自己亂嘅係點開OKTA嘅UserID.
因為係未安OKTA Agent同AD link埋之前。 OKTA 自己嘅user account都係用同一個domain suffix. Password 一樣會難去確定。
但係發現當安完OKTA Agent match 好user之後。 係得返AD password. 即係唔需要搵account 做local account。

之後係Salesforce拖OKTA。
兩者integration當個中有個伏位係OKTA。 Support SAML 嘅 App 當中,Salesforce App有三個。而”Salesfforce.com(Federate ID)”係有問題,唔work。。。 因此咁而報case support。。

開始時候做法幾乎一樣,都係要諗用另一個account作為Full Rights Admin。亦因為呢個原因。係Salesforce create自己嘅account用唔同Password。
係OKTA加Salesforce app, 同Salesforce 裡面config Single Sign-On幾乎係照跟就可以。所以假若唔係 “Salesforce(Federate ID)”出事。。
係可以兩日整好。。。

Set好後不論係 SP Initiated(Salesforce 會有多個Auth Option)還是IdP Initiated(OKTA App list,SSO 直接list)都會 開到。。

最後,係Salesforce 駁ADFS。

步驟唔多,仍然要係Salesforce portal加Single Sign-On setting
但係伏位係ADFS Server入面嘅Issuer
當開 FederationMetadata 睇嘅時候
“https://adfsserver.domain.com/federationMetadata/2007-06/FederationMetadata.xml”

adfssalesforceconfig

ADFS 入面嘅Metadata.xml , 佢嘅Element名叫”entityID”, 而個名同ADFS server Web URL睇落一樣,但係佢唔係https,係http 。
呢一樣錯,就會fail。
SAML Assertion會check 到mismatch。。。。

Done ! That’s it

Reference:

Salesforce integration with OKTA

http://saml-doc.okta.com/SAML_Docs/How-to-Configure-SAML-2.0-in-Salesforce.html

Salesforce integrate with ADFS 3.0

https://developer.salesforce.com/page/Single_Sign-On_with_Force.com_and_Microsoft_Active_Directory_Federation_Services

Troubleshooting Tools

https://www.samltool.com/base64.php

SharePoint 2013 – SAML Auth

index

 

 

 

對比Kerberos, SAML絕對係未明但係照跟照做嘅。 係本身行緊嘅SharePoint2013 幾乎無變動,只需要Extend 其中一個 Web Application作為Target.  其餘只係跟Sample Syntax照改。 Sample 有 minor typo mistake但係唔會死人

Reference

http://summit7systems.com/beginners-guide-to-claims-based-authentication-ad-fs-3-0-and-sharepoint-2013-part-iii-configuring-sharepoint-2013-for-ad-fs/

https://technet.microsoft.com/en-us/library/hh305235.aspx

MFA Server upgrade 6.3.1 > 7.0.2 . 後知後覺~中伏了~

mfa_thumb

 

 

 

 

 

 

咩都唔使講~.Net2.0轉去.Net4.0 ADFS Adapter 改名,要用舊source先uninstall,再用新source再安個,再Register Adapter…
M$記:你玩得透。。。。~!@#$%?&*()

 

Reference site:

http://c7solutions.com/2016/04/upgrading-azure-multi-factor-authentication-server

http://c7solutions.com/2016/04/upgrading-mfa-6-3-1-to-version-7