係啱啱啱唔啱個鐘頭前，就係出左上一個Post後，發現MDM Server HD 100% Full而開始Malfunction，當中整晚過程唔講，但係MDM Server reboot 過3 次。係自己成晚無瞓再回魂之後第一樣發現嘅係。 Test iOS Device 嘅 CheckIn Acknowledged，MDM Server 嘅Force CheckIn 亦正常返。。。
究竟係問題咩事，後續分解。。。。。
14：31 更新。
返到Office Check 落左Global Proxy Profile (Type Auto)嘅個部iPAD，超級古怪。
未unlock Screen時，係屋企做MDM Force Checkin return Acknowledged，但係返到Office check Squid log，其實仍然係Access Denied
部iPAD Screen unlock後亦繼續Waiting Checkin pending
More updates coming…….
續上一個Post。
pFSense加Squid Proxy已經Config 好。Proxy Pac亦已經放係Web Server。係PC Browser可以順利用到Proxy，準備工作完成。
係Apple Community入面搵到一個幾好嘅Discussion
AppProxy Provider vs Global Proxy
以自己理解，AppProxyProvider 係 MDM Vendor 嘅App Gateway或者係我哋講MDM嘅PreApp VPN Gateway，等同MobileIron 嘅 Sentry
自己嘅推斷同下面呢段Message差唔多
To start, I want to be clear about one thing: App proxy providers and the global HTTP proxy are very different things. There are lots of architectural differences (app proxy providers are plumbed in at the kernel level whereas HTTP proxies require user-level support) but an obvious behavioural difference is that an app proxy provider will see all TCP connections for a particular app, whereas a global HTTP proxy will only see HTTP[S] connections but for all apps.
AppProxy可以Handle TCP ／ UDP ，但係Global HTTP Proxy真係HTTP／HTTPS
真正問題黎啦，當MDM 推個Global HTTP Proxy Profile落去部iOS device。會唔會導致問題？
答案係。 會有問題，而要Reproduce 嘅方法亦好特別。
係iOS嘅Global HTTP Proxy Profile有兩類 。
1. Auto
2. Manual
Type Auto 係用PAC file
Type Manual 係傳統嘅Server 加Port
而自己發現，Proxy Type用 Manual 係無問題嘅，但係當Proxy Type由原本嘅 Manual轉去Auto。問題就出現。
iOS無辦法正常地去Apply Profile Update，亦影響都Device嘅正常Check-In。而因為咁，部iOS其他嘅Activity 亦會唔正常
現在階段解決方法係有，但係等Vendor reproduce 個Issue，確定係真都未遲
Reference URL
由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
// 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/
經過係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
繼Part1，係2017 年頭附近嘅時間，（確實時間唔確定）。
新方法係由各MDM Vendor嘅Portal去申請，呢個新方法簡單都用一個 個人Gmail都可以做到，亦無每個Corporate Domain只可以reg一次嘅限制。
簡單到難以至信 三 至 五分鐘 就 做完個Registration。
Old Google Managed Domain Procedure
Reference:
AfW Configuration Procedure in Mar/2016
一直係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
You must be logged in to post a comment.