最近在研究如何把跟電腦使用者相關的設定透過零接觸部署直接下去，原本簡單的事情卻搞了快一整天，後來了解到一個很根本的關鍵：「誰是這台電腦上的 MDM Enabled User？」。

MDM Enabled User 早期叫做 MDM Capable User，從 macOS 10.12 開始，一台電腦上面只可以有一位。從 Jamf Pro MDM-Enabled Local User Acoounts 裡面讀到一句非常重要的話：

The local user account will not be MDM-enabled if at least one of the following is true:

The Skip Account Creation checkbox is selected in the PreStage enrollment and the local user account was created via a policy or JamfConnect Login.

The Make the local administrator account MDM-enabled checkbox is selected in the Account Settings payload of the PreStage enrollment.

換而言之，如果電腦走 Apple 內建的啟用流程，第一位產生出來的使用者就會是 MDM Enabled User，除非在啟用時就設定預埋一個 Managed Admin 帳號，還把這個帳號設定成 MDM Enabled。另一種狀況，就是不完全走 Apple 內建的啟用流程，直接跳過了建立電腦使用者帳號的畫面，這樣子出來的使用者也不會是 MDM Enabled。

為什麼要拿到 MDM Enabled User 呢？原因是為了部署 User Level Profile，像是要幫使用者設定電子郵件，或是根據電腦使用者帳號的資訊來配置 Profile，都會需要拿到 MDM Enabled User。

Jamf Connect Login = 不完全走 Apple 內建的使用者建立流程

Jamf Connect Login 的最大好處是可以協助使用者建立電腦帳密，並且與網域上面的帳密保持一致，也因此不能走 Apple 內建的建立使用者流程，這個結果形成建立出來的帳號就不吻合 MDM Enabled User 的條件。

走回 Apple 內建的使用者建立流程做為解決方案

既然沒辦法在零接觸部署的過程裡使用 Jamf Connect Login 建立帳號，那就只好改回 Apple 的內建流程，但又要如何確保使用者透過 Apple 內建流程所建立出來的使用者帳號，能再透過 Jamf Connect 將其與網域同步帳密，就變成另外一個挑戰。

使用 Pre-fill primary account information

因為透過 Apple 內建流程出來的帳號，是由使用者自己取名的，不一定會是網域上的使用者名稱一致，所以要先啟動 Jamf Pro 的 SSO Integration，並且讓使用者在首次開箱並註冊設備時，啟用 Enrollment Customization，就能把相關的使用者資訊從 SAML 的 NameID 裡面取出來，做為 macOS 原生建立使用者帳號的 macOS Account Name(Short name)。

結合目錄服務，增加查詢其它使用者屬性

事實上，上面的 Name ID 會先填入到 Jamf Pro Inventory Username 的欄位裡，才能做為變數讓 macOS 原生建立的使用者帳號畫面代入 Short Name。而也因為在 Jamf Pro Inventory Username 上已經有值，若再結合 LDAP 或是 Cloud Identity Provider 的 API，就能更進一步的把其餘使用者資訊給查找出來，而最重要的是查找出使用者的 Full Name，才能做為 macOS 原生建立使用者帳號的 Full Name。

如果是使用 Microsoft Azure AD 做為 Cloud IdP 的話，在 Jamf Pro Cloud IdP Mapping 裡面的選項，可以設定 Real Name 真正要對應的欄位是誰。欄位值可以參考 Microsoft Graph Rest API 的資訊。

以 Microsoft Azure AD 為例的話，預設 NameID 會帶的是 UPN，而 Azure AD 的 UPN 預設會是使用者的電子郵件。

Jamf Pro 會拿著這個 Username 回去用 Microsoft Graph API 去問更多資料出來，並回填到上圖的 Jamf Pro 資產訊息裡，而每個欄位要查找的值，都可以到 Jamf Pro Cloud IdP Mapping 裡面去設定。如上圖，Graph API 幫我找到這個 Username 對應的 Full Name 是 Test User。

安裝 Jamf Connect 並啟動 Migrate

當使用者透過原生的帳號建立機制產生後，就能進到桌面開始工作。但這時我們還少了一件事：「讓密碼跟網域保持一樣」。這邊有很多的方式都可以做到這個目的，像是有 Apple Enterprise SSO、NoMAD 等等選項，但如果是為了要跟 Cloud IdP 對齊的話，還是要使用到 Jamf Connect。

由於本地帳號事實上已經建立起來了，不需要再委由 Jamf Connect Login 協助使用者建立本地帳號，反而是希望 Jamf Connect Login 在確認使用者身份後，自動的把這個身份跟剛才所建立的本地帳號連接起來，並且確保本地密碼跟 Cloud IdP 上的密碼維持一致。這時候就需要使用到 Jamf Connect 的 Migrate 屬性。而為了降低使用者的操作複雜度，我想利用 Jamf Connect 裡的預設對照功能，讓使用者只需要簡單的從 Cloud IdP 驗證完自己的身份後，再輸入一次正確的網域密碼，就能自動完成連接。

在 Jamf Connect Admin Guide 提到這段：

Local Account Migration

If a user’s network username and password match a local username and password, the accounts are automatically connected. No additional steps are needed.

問題來了，Local Username 在剛才 Azure AD 的結果，事實上是使用到了 SAML NameID（UPN） -> JSS Inventory -> Username > Pre-fill account information 而來的，換而言之就是該名使用者的電子郵件。

Jamf Connect 在收到使用者登入資訊後，如果這個使用者的 unique_name 是電子郵件的格式，那麼 Jamf Connect 只會取 @ 前面的使用者名稱為做 username，這樣就無法自動完成 migration，因為現在的 local username 是 testuser@appleexpert.com.tw，但 Jamf Connect 看到的 username 是 testuser，就不會自動對應了。

為了要實現自動對應，我一定得想辦法讓其中一個與另外一個相同。既然如此，我就選擇比較簡單的做法，但的確還是得看不同公司的既有環境來決定，而我的方式是使用 Jamf Connect 的 Custom Short Name。

如果是透過定義 Custom Short Name 而代進去的內容，Jamf Connect 不會只拿 @ 前面的名稱。因為 Jamf Connect 走的是 OIDC 驗證，透過後面拿到的 Token 可以看到使用者的相關資訊。

最後只要在 Jamf Connect Login 的 Application&Custom Settings 裡代入 Key 值，就能解決剛才對應不起來的問題。

<key>OIDCShortName</key>
<string>unique_name</string>