Exchange 2013 CBA Setup Review

溫故知新 !基於上星期Upgrade Exchange 2013 由 CU13 Upgrade 去 CU21。因為Server 係上年用特別手段Split出嚟。所以Upgrade到臨尾出視。迫於無奈要Delete兩個Exchange Website。呢個星期真正起過一隻新Server去做CAS。
過程無特別要多講因為非常順利,但係如同上年一樣,CBA先係最大難關。係再Review Article嘅途中,就睇到最進口嘅一環。就係Certificate嘅Subject係要有User嘅Email,或者Certificate嘅SAN Name有User UPN。
唔跟呢Part就會出IIS Error 403.7

Prerequisites:

You need access to a CA for client certificates. This can be a public CA solution, individual certificates from a vendor, or an Active Directory Certificate Services solution. Regardless, the following requirements must be met:

  • The user certificate must be issued for client authentication. The default User template from an AD CS server will work in this scenario.
  • The User Principal Name (UPN) for each user account must match the Subject Name field in the user’s certificate.
  • All servers must trust the entire CA trust chain. This chain includes the root CA certificate and any intermediate CA certificates. These certificates should be installed on all servers that may require them, to include (but not limited to) ISA/TMG/UAG server(s) and the Client Access Server (CAS).
  • The root CA certificate must be in the Trusted Root Certification Authorities store, and any intermediate CA certificates in the intermediate store on all of these systems. The root CA certificate, and intermediate CA certificates must also be installed on the EAS device.
  • The user’s certificate must be associated with the user’s account in Active Directory

Reference URL

https://docs.microsoft.com/en-us/exchange/plan-and-deploy/post-installation-tasks/configure-certificate-based-auth?view=exchserver-2019

https://blogs.technet.microsoft.com/exchange/2012/11/28/configure-certificate-based-authentication-for-exchange-activesync/

過程無特別要多講因為非常順利,但係如同上年一樣,CBA先係最大難關。係再Review Article嘅途中,就睇到最進口嘅一環。就係Certificate嘅Subject係要有User嘅Email,或者Certificate嘅SAN Name有User UPN。
唔跟呢Part就會出IIS Error 403.7

Azure AD Seamless SSO

 

 

 

 

Seamless SSO,一個曾經覺得好難好難嘅東東。但係經過呢兩三年前Configure Kerberos,同開始接觸SAML後得到嘅經驗。 Seamless SSO唔再係咁難以觸摸。

第一,都係要多謝我哋偉大嘅Microsoft。Azure AD係上年九月左右嘅Update。 Pass-Through Authentication。Microsoft 解釋Benefit係Authentication會返返OnPremises AD做,可以唔需要開Password Sync。

係另一方面,雖然已經有ADFS WAP,但係係DMZ嘅關係,係無join AD。所以Azure Pre-Authentication係用唔到。係另一方面,雖然已經有ADFS WAP,但係係DMZ嘅關係,係無join AD。所以Azure Pre-Authentication係用唔到。但係用Application Proxy Connector就無呢個限制。Application Proxy Connector可以安裝係任何一部Domain Joined Server。係呢個因素之下,Machine Account 行 Kerberos就絕對無難度。

步驟可以照跟Microsoft。謂獨有一個Step令我特別留意,因為同以往Configure KCD唔同。Common係Delegation – “Trust this computer for delegation to specified services only” 下面嘅Section係揀 “Kerberos only”,但係今次Config Application Proxy Delegation係用”Use Any Authentication Protocol”

  • Reconfirm that the connector host has been granted the rights to delegate to the designated target account’s SPN, and that Use any authentication protocol is selected. For more information about this topic, see SSO configuration article

https://docs.microsoft.com/en-us/azure/active-directory/application-proxy-back-end-kerberos-constrained-delegation-how-to

以下兩條Youtube都介紹得嘅清楚,值得一睇

Reference

https://www.youtube.com/watch?v=PyeAC85Gm7w

https://www.youtube.com/watch?v=vt2R4P4xLQA

https://docs.microsoft.com/en-us/azure/active-directory/active-directory-application-proxy-sso-using-kcd

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

接連神秘Config比改動事件 I & II ……. Kerberos Auth

 

 

 

 

繼二星期前出現Exchange Server CBA vDirectory 被唔正常地disable Apphost settings 由True變False後

係前日再出現神秘事件。今次係兩個 OKTA Connector 同時disconnect,引發完全無法Login之外,就係OKTA IWA(Integrated Windows Authentication) Agent Website 用作Kerberose 嘅SPN突然消失。
所以今次呢個寫嘅IIS Configure Kerberos Auth嘅溫故知新

下面Reference嘅Website值得一睇。但係想特別提出要留意嘅有以下

  • 係開嘅IIS Website會用Service Account以唔用Default 嘅Application Pool Identity,對往後create SPN會容易控制
  • 係IIS嘅Configuration Editor,“system.webServer > security > authentication > windowsAuthentication”,入面嘅 “useAppPoolCredentials” 要Set做True
  • 最後,如果新Configure嘅IIS Website同Server本身機名唔同
    Sample 機名原本係 “ServerA.domain.local” , 但係新IIS WebSite 係 “ServerA.domain.com”, Create 新 SPN照跟Create “HTTP/ServerA.domain.com” 甚至額外加更多SPN “HTTP/Web.domain.com” 係容許嘅。只需要係Network上用resolve到”Web.domain.com”走可以

 

Reference:

http://woshub.com/configuring-kerberos-authentication-on-iis-website/

Client Ceritificate Mapping in IIS Configuration Editor

section:system.webServer/security/authentication/clientCertificateMappingAuthentication /enabled:”True”

 

 

 

 

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