整合 Jamf Pro 與 iOS 15 Account Driven 使用者註冊功能

分享

蘋果在今年推出了 Account Driven 的使用者註冊(User Enrollment)功能。這個功能可以讓使用者的 Apple 裝置,如 iPhone、iPad 登入兩個 Apple ID,一個是個人的、一個是公司的。

個人的 Apple ID 很容易理解,直接到 https://appleid.apple.com 申請就可以了。但是公司的 Apple ID 並不是從上面的網址來產生,而是必須到公司的 Apple Business Manager 幫員工註冊與申請。

再更精準的說,不只是公司可以幫員工申請 Apple ID,學校也可以幫師生申請 Apple ID,只要來到學校的 Apple School Manager 就能完成。無論是公司或是學校所申請出來的 Apple ID,統稱為管理式 Apple ID(Managed Apple ID)。

當員工/師生使用管理式 Apple ID 登入 iPhone、iPad 時,會在設備上額外製作一個區域,專門存放公司或學校提供的資源,而這些資源可以透過 MDM 設定,禁止人員將上面的資源透過個人所下載的 App 傳到外面的世界去,以達成資料保護的功能。而當人員離開公司或學校時,因為這個 Apple ID 是由組織所製作的,所以組織有最大權限能直接註銷這個帳號,並且銷毀原本留在該裝置的公司資源。

另一方面,使用管理式 Apple ID 時,蘋果會提供給企業級管理式 Apple ID 基本 5GB 的 iCloud 空間;教育級管理式 Apple ID 則會有 200GB 的 iCloud 空間。

而在新的 iOS/iPadOS 15 起,使用者更可以從設定 > 一般 > VPN 與裝置管理登入企業或學校所派發的管理式 Apple ID,除了能拿到蘋果提供的 iCloud 空間外,也能自動取得公司資源,像是工作時所需要使用的 App 或電子書等等。

這種透過登入管理式 Apple ID 並且取得組織資源,且在離開組織後可自動銷毀裝置上的相關資源,同時兼顧使用者隱私,不賦予 IT 人員更多額外的管理權利,就稱為使用者註冊(User Enrollment)。而在上段內容所提到的,使用者可以從設定 > 一般登入管理式 Apple ID,並一系列取得相關資源的能力,就稱呼為 Account Driven User Enrollment。

不管是 User Enrollment 或是 Account Driven User Enrollment 都會需要以下工具才能完成:
- Apple Business Manager 或 Apple School Manager 帳號
- MDM 伺服器(以下使用 Jamf Pro 10.33 為例)

除此之外,如果想達成 Account Driven User Enrollment,還會另外需要有以下工具:
- 需註冊並持有網域控制權
- 需擁有該網域相對應的 SSL 憑證,且該憑證不得為自簽憑證
- 需架設一個 HTTPS 伺服器

以下為實現 Account Driven User Enrollment 的做法:

在網域註冊商加入 A Record

為了簡單起見,我在 Linode 上直接開了一個 Ubuntu 18.04 的伺服器,並且用 SSH 遠端連入。此時 Linode 會提供這個伺服器的 IP 出來,接下來就至網域服務註冊商登記一組 A Record 即可。

安裝 NGINX HTTP 伺服器

Nginx 是一種 HTTP 伺服器,輸入以下指令開始進行安裝:

apt update
apt upgrade
apt install nginx
systemctl enable nginx
systemctl start nginx
systemctl status nginx

輸入完最後一列指令後,應該會看到類似文字出現在畫面上,代表 NGINX 已開始服務

● nginx.service - A high performance web server and a reverse proxy server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabl
   Active: active (running) since Tue 2021-11-30 12:36:41 UTC; 24s ago
     Docs: man:nginx(8)
 Main PID: 19324 (nginx)
    Tasks: 2 (limit: 1105)
   CGroup: /system.slice/nginx.service
           ├─19324 nginx: master process /usr/sbin/nginx -g daemon on; master_proce
           └─19327 nginx: worker process

打開瀏覽器輸入已註冊的網址,應該會出現下圖,代表服務正常運作中。

加入 Apple Management 檔案

回到 Ubuntu 伺服器裡,移動至 /var/www/html 資料夾,先行建立一個 .well-known 資料夾,並在裡面建立一個新的 com.apple.remotemanagement 檔案。

mkdir .well-known
touch com.apple.remotemanagement 

編輯 Apple Management 檔案

利用 vi 文字編輯器,加入以下的文字到 com.apple.remotemanagement 裡。

{
	"Servers":[
		{
			"Version": "mdm-byod",
			"BaseURL": "https://Jamf Pro 網址/servicediscoveryenrollment/v1/userenroll"
		}
	]
}

使用 Certbot 在 Nginx 上安裝 Let's Encrypt SSL 憑證

因為我沒有另外為網域購買 SSL 憑證,所以我使用 Let's Encrypt 的免費憑證服務,搭配 Certbot 自動簽發與安裝在 NGINX 伺服器上。

snap install core; sudo snap refresh core

snap install --classic certbot

ln -s /snap/bin/certbot /usr/bin/certbot

certbot --nginx

跟著上面一行行走完後的最後一步,Certbot 就會把憑證安裝在 Nginx 上,此時就可以打開瀏覽器並輸入網址,看看網址前面是不是有鎖頭了。一定要確認有鎖頭,才代表服務正在使用安全連線的方式進行通訊。

修改 Header 為 application/json

蘋果要求這個 com.apple.remotemanagement 必須要帶上 application/json 的 MIME 格式,所以需要修改一下 Nginx 的設定檔。直接使用 vi 文字編輯 /etc/nginx/sites-available/default 文件,並且找到 server { # SSL Configuration... } 這段內容,在原本的大括弧裡面加上以下內容。

location /.well-known/ {
                default_type application/json;
}

這上面的意思是,將 /.well-known/ 資料夾下面的檔案帶上 application/json 的 MIME 格式。完整的設定檔大概長得像這個樣子:

server {

        # SSL configuration
        #
        # listen 443 ssl default_server;
        # listen [::]:443 ssl default_server;
        #
        # Note: You should disable gzip for SSL traffic.
        # See: https://bugs.debian.org/773332
        #
        # Read up on ssl_ciphers to ensure a secure configuration.
        # See: https://bugs.debian.org/765782
        #
        # Self signed certs generated by the ssl-cert package
        # Don't use them in a production server!
        #
        # include snippets/snakeoil.conf;

        root /var/www/html;

        # Add index.php to the list if you are using PHP
        index index.html index.htm index.nginx-debian.html;
    server_name 你的網域; # managed by Certbot


        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                try_files $uri $uri/ =404;
        }

        location /.well-known/ {
                default_type application/json;
        }

...略
}

接著輸入 systemctl restart nginx 重新啟動 nginx 伺服器。

驗證 Apple Management 文件正常服務

在 macOS 電腦上打開終端機,並且輸入以下指令:

curl -v https://你的網域/.well-known/com.apple.remotemanagement

畫面上應該要出現以下內容:

< HTTP/1.1 200 OK
< Server: nginx/1.14.0 (Ubuntu)
< Date: Tue, 30 Nov 2021 12:59:27 GMT
< Content-Type: application/json   #這邊超重要,一定要出現 application/json
< Content-Length: 108
< Last-Modified: Tue, 30 Nov 2021 12:59:22 GMT
< Connection: keep-alive
< ETag: "61a6202a-6c"
< Accept-Ranges: bytes
<
{
	"Servers":[
		{
			"Version": "mdm-byod",
			"BaseURL": "https://你的 Jamf Pro 網址/servicediscoveryenrollment/v1/userenroll"
		}
	]
}

啟動 Jamf Pro Account Driven User Enrollment 服務

前往 Settings > Global Management > User-Initiated Enrollment > Platforms > iOS > Account-Driven User Enrollment > 啟用 Enable for personally owned devices。

最終測試是否成功

取得管理式 Apple ID 後,打開 iOS / iPadOS 15 的設備,前往設定 > 一般 > VPN 與裝置管理 > 登入公司或學校帳號,試試看是否能正常運作。

你的下一步?

這個過程比較複雜,但是很適合公司裡面已有大量的 iPhone / iPad,絕大多數都是員工自己購買的,而且希望能用自己的設備工作,同時也能確保公司所提供的資源不會受到濫用,其實很值得準備一套 Jamf Pro ,並且開啟這項功能試一試。

Read more

Managed Preferences 到底贏不贏得過本機設定?自己寫工具測給自己看

Managed Preferences 到底贏不贏得過本機設定?自己寫工具測給自己看

在管理一批用 MDM 集中控管的 Mac 時,常常會遇到一個問題:某個 preference key,使用者自己用 defaults write 改過一次,管理員可能又用 sudo defaults write 在系統層級動過一次,最後 MDM 又把同一個 key 標成 Managed(強制)。這時候系統實際生效的到底是哪一個值? Apple 官方文件對 CFPreferencesAppValueIsForced 這支 API 的說明相當簡略,只告訴你這個 API 可以拿來判斷某個 key 是不是被強制,卻沒有把整個 preference 搜尋順序裡各層級的先後關係講清楚。網路上能找到的資訊也大多是憑印象轉述,沒有人真的擺出證據。 與其對著文件猜,不如自己寫一支工具,實際測給自己看。以下這篇的測試環境是 macOS Tahoe 26.6.

By Glee Tsai
Apple 生態系的真實威脅—我們都可能是目標

Apple 生態系的真實威脅—我們都可能是目標

從一場分享開始的警醒 前陣子在 Jamf Nation Live Taipei 分享了 2024-2025 年 Apple 裝置威脅報告,深入探討了全球 Apple 生態系正面臨的資訊安全威脅。 許多人對 Apple 產品有一種根深蒂固的信心—拿著 Mac 或 iPhone,就像拿到了數位世界的「免死金牌」。說實話,Apple 在軟硬體整合上的安全設計確實領先業界,這不是誇大其詞。但也正因為這份信心,我開始想更深入地了解真實情況。 從 Jamf Security 360 報告開始,我觀察了全球情報機構(如 Citizen Lab、Google TAG、Kaspersky)揭露的真實案例。那時我才意識到一個有點殘酷的事實,也正好對應了同事最常對我說的那句話:Apple 設備並非堅不可摧,使用者自身往往才是最大的弱點。 為什麼 Apple

By Glee Tsai

從 Jamf Pro 自定義註冊畫面帶使用者資訊至 Jamf Connect 失敗的處理方式

Jamf Pro 在設定裡面的 Enrollment Customization,本來可以設定在使用者完成設備註冊的當下,同步把 SAML 裡的資訊帶給後面的 Jamf Connect Login,這樣就可以減少一步使用者還需要登入的步驟。但在撰文的當下,Jamf Pro 11.1 仍在這個功能上有問題,在跟 Jamf Support Team 了解後,大概能用一種 Workaround 來解決,只是要特別留意以下事情: 1. 在 Jamf Pro 裡的 Enrollment Customization 不要再打勾 Enable Jamf Pro to pass user information to Jamf Connect 了(因為勾了也沒有用) 2. 確保

By Glee Tsai

在 Apple 零接觸部署下僅允許某個群組啟動設備

在 Jamf Pro 有整合 Single Sign On 的情況下,可以前往 Settings > Enrollment Customization 設定僅允許一個群組中的成員啟用設備。如果這個成員沒有在這個群組裡面的話,就不能夠開箱設備。如果以 Entra ID 為例,需要把 Object ID 填在下方的欄位即可。 對照到我在 Entra ID 上的群組設置: 至於如果不是 Entra ID,而是其它的 SSO Provider 的話,最好可以用 SAML Tracer 這一套 Google Chrome 外掛去看一下自己的 SAML 文件是如何表達群組的,例如下圖能看到這個使用者屬於以下五個群組。 接著有另外一個很重要的事情要提醒,如果你要阻擋註冊的成員,可以登入到 Jamf Pro

By Glee Tsai