pFSense Squid Proxy Setup + Proxy Pac

 

 

 

 

 

 

由Nokia IntelliSync年代試玩 OpenLDAP LC CentOS 5 試驗機,到變成Squid Proxy 已經用超過十年。基於CentOS 5 已經EOL一段時間。係時候準備新嘅Proxy作為replacment

因為目前需要試iOS Device 經Proxy, 只需要用Proxy Server黎試iOS嘅Global HTTP Proxy。所以唔需要大費周章去再起新Linux。pFSense呢啲Soft Router正正做到自己需要嘅Test

pFSense setup相信唔需要講啲咩,因為真係好簡單。Mount起ISO,Boot機,噤制,等完成安裝。
唯一提係安裝係VirtualMachine,估唔到 係到呢家仍然要選IDE HD。好在係pFSense可以config行RAM Disk。

下面嘅URL有好好嘅Setup Procedure作參考。
唯一唔同係自己唔係要Setup Transparent Proxy。

目標Proxy Set up而係Standard HTTP Proxy 加 Proxy Pac file

以下PAC 係好好嘅Sample

Sample PAC pattern

  • function FindProxyForURL(url, host) {// If the hostname matches, send direct.
    if (dnsDomainIs(host, “intranet.domain.com”) ||
    shExpMatch(host, “(*.abcdomain.com|abcdomain.com)”))
    return “DIRECT”;

    // If the protocol or URL matches, send direct.
    if (url.substring(0, 4)==”ftp:” ||
    shExpMatch(url, “http://abcdomain.com/folder/*”))
    return “DIRECT”;

    // If the requested website is hosted within the internal network, send direct.
    if (isPlainHostName(host) ||
    shExpMatch(host, “*.local”) ||
    isInNet(dnsResolve(host), “10.0.0.0”, “255.0.0.0”) ||
    isInNet(dnsResolve(host), “172.16.0.0”, “255.240.0.0”) ||
    isInNet(dnsResolve(host), “192.168.0.0”, “255.255.0.0”) ||
    isInNet(dnsResolve(host), “127.0.0.0”, “255.255.255.0”))
    return “DIRECT”;

    // If the IP address of the local machine is within a defined
    // subnet, send to a specific proxy.
    if (isInNet(myIpAddress(), “10.10.5.0”, “255.255.255.0”))
    return “PROXY 1.2.3.4:8080”;

    // DEFAULT RULE: All other traffic, use below proxies, in fail-over order.
    return “PROXY 4.5.6.7:8080; PROXY 7.8.9.10:8080”;

    }

而 Proxy PAC 係今次嘅主菜,相對pFSense / Squid 嘅 Setup,花係PAC試嘅時間係更多

今次目的係iOS Device 行Proxy,經MDM Push Global HTTP Proxy Profile。所以PAC 係Set到Mobile Network會用Proxy,反而係Internal Network唔經Proxy

跟住嘅Post會講經MDM Push左Global HTTP Proxy profile發現嘅 古怪問題

To be Continue…

 

Reference URL

https://www.howtoforge.com/pfsense-squid-squidguard-traffic-shaping-tutorial

https://www.netgate.com/docs/pfsense/cache-proxy/setup-squid-as-a-transparent-proxy.html

https://tektab.com/2012/09/26/setting-up-automatic-proxy-configuration-pac-file/

Android Enterprise Chrome Managed Bookmarks

 

 

 

 

 

經過係MobileIron configure Android Enterprise,overall 係成功嘅,不係因為無Web@Work做Secure Browser。只可以用MI Tunnel + Chrome。
係Android Enterprise落App Configure同一般App Config唔同。 Configuration Profile係直接跟App。
但係好衰格嘅係資料好小好難搵。以下係落Managed Bookmarks,係MI Web@Work 落Bookmarks容易好多

由下面Microsoft Link嘅Sample,我只需要Managed Bookmarks個段。 但係另人誤會嘅係 所有嘅slash “\” , 都係唔需要嘅。

{
  "kind": "androidenterprise#managedConfiguration",
  "productId": "app:com.android.chrome",
  "managedProperty": [
    {
      "key": "EditBookmarksEnabled",
      "valueBool": false
    },
    {
      "key":"ManagedBookmarks",
      "valueString": "[{\"toplevel_name\":\"Contoso Bookmarks\"},{\"url\":\"microsoft.com\",\"name\":\"Microsoft\"},{\"url\":\"blogs.technet.microsoft.com\",\"name\":\"Favourite Blogs\"},{\"name\":\"Email services\",\"children\":[{\"url\":\"gmail.com\",\"name\":\"GMail\"},{\"url\":\"outlook.com\",\"name\":\"Outlook\"}]}]"
    }  
     ]
}

再下面由MI Community嘅sample就試到差別

From MI Community

[{“toplevel_name”: “Top Level”}, {“url”: “google.com”, “name”: “Google”}, {“url”: “youtube.com”, “name”: “Youtube”}, {“name”: “Chrome links”, “children”: [{“url”: “chromium.org”, “name”: “Chromium”}, {“url”: “dev.chromium.org”, “name”: “Chromium Developers”}]}]

以上Sample 有space係中間。經過試驗係唔Work嘅

[{“toplevel_name”:”Top Level”},{“url”:”google.com”,”name”:”Google”},{“url”:”youtube.com”,”name”:”Youtube”},{“name”:”Chrome links”,”children”:[{“url”:”chromium.org”,”name”:”Chromium”},{“url”:”dev.chromium.org”,”name”:”Chromium Developers”}]}]

 

Reference

https://blogs.technet.microsoft.com/microscott/configuring-google-chrome-settings-with-intune-and-android-for-work/

 

Android Enterprise – Device Owner Mode Configuration 後感 – Part 2

 

 

 

 

 

繼Part1,係2017 年頭附近嘅時間,(確實時間唔確定)。
新方法係由各MDM Vendor嘅Portal去申請,呢個新方法簡單都用一個 個人Gmail都可以做到,亦無每個Corporate Domain只可以reg一次嘅限制。

簡單到難以至信 三 至 五分鐘 就 做完個Registration。

Old Google Managed Domain Procedure

 

 

 

 

Reference:

AfW Configuration Procedure in Mar/2016

AndroidForWork90_Rev23Mar2016

Android Enterprise – Device Owner Mode Configuration 後感 – Part 1

 

 

 

 

 

一直係MDM Product範疇當中,Android/iOS算係叫雙頭馬。

但呢個講法個人認為係因為包含BYOD。Android品牌多,Model多樣性 嘅百花齊放。 但同樣哋,相對iOS 嘅統一性,Android嘅Device fragmentation確實成為垢病。 係單純roll out business own device 嘅角度,iOS系一面倒佔優。

係以往嘅Android For Work (AfW),唯一嘅做法就係 開Google Managed Account,即係咩?就系用掛Corp Domain去 Google (https://admin. google.com) 類似Microsoft Azure 咁。 Verify 個Corp Domain,Set up Directory Sync, Password Sync 上去Google, bla bla bla, 再掛唯一 一個MDM。冇錯,你無睇錯。係得一個 MDM quota. 呢個系舊做法最大嘅問題,當要第二個MDM 要用 AfW,要remove 原本個 個先。

相對AppleDEP可以 ” 1 to Many” MDM。 呢一part AfW 輸晒 !

 

Reference

https://androidenterprisepartners.withgoogle.com/#!/results/browse-all/0

https://support.google.com/work/android/answer/6174039?hl=en

Kerberos Double Hop Setup 備忘 – Part 2

 

 

 

 

 

今日繼續試落去,就發現自己係有另一部做前Set落已經用緊Double Hop嘅機。
Setup再有小小唔同
DoubleHop Website無enable ASP.Net Impersonation
Application Pool 係用.Net Framework v4.0.30319 . Managed pipeline mode 係”Integrated” (如果有Enable ASP.Net Impersonation,但係Pipeline mode 係Integrated,會出Error 500)

Kerberos Double Hop Setup 備忘

 

 

 

 

Kerberos – 對於自己嚟講叫做常用,但係有時候都會忘記一啲特別嘅Implementation 方法。Double Hop 正正係自己會忘記嘅一種。

先講咩係 Single Hop / Double Hop。

 

顧名思義 Single Hop > 平常 常用嘅度法,好似Share Point咁
Double Hop > 同Single Hop 嘅別就係會再用Kerberos去Connect 另一個Source。 (注意:係兩次Kerberos,我會常常忘記嘅就係第二層無用Kerberos嘅駁法而Fail Error 401)

下面第一條Reference URL 係非常清晰Setup Guide。

而常用Kerberos Hop係 IIS Virtual Directory指係 UNC Path

自己喜歡用嘅方法同Article 講嘅有啲唔同

到法如下 –
IIS WebSite 會用另一個名, 小用本身Server Host Name
Application Pool嘅Identity 會用另一個Service Account,而唔會係Default Built-In Account 嘅 ApplicationPoolIdentity,亦需要用 Setspn register Web Server 嘅 SPN (緊記係Web Server 將會用嘅名)

係會用Kerberos Auth嘅IIS Website>Authentication>Windows Authentication>Advanced Settings > unTick “Enable Kernel-Mode Authentication”。

同埋Website 嘅Configuration Editor > “system.webServer/security/authentication/windowsAuthentication” > “UseAppPoolCrentials” set做”True”

Windows Authentication 入面嘅Provider會揀
Negotiate:Kerberos
Negotiate
Optional: NTLM (如果Website確定只會用Kerberos,可以唔用NTLM)

亦唔好忘記,ASP.NET Impersonation 係必須要Enable,Disable “Basic Authentication” & “Anonymous Authentication”

最後 係加VirtualDirectory,即將要用UNC Path嘅做第二個Hop嘅Target。係用\\host.domain.com 而唔係\\IP Address, 用IP Address 必定會Fail

自己嘅做法就係咁。
之後就可以係Domain Joined PC上面試。係Command Prompt打”Klist” 會見到駁去WebServer 嘅Kerberos Ticket

Reference

https://blogs.msdn.microsoft.com/chiranth/2014/04/17/setting-up-kerberos-authentication-for-a-website-in-iis/

https://blogs.technet.microsoft.com/askds/2008/06/13/understanding-kerberos-double-hop/

 

 

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