一次開機登入，
讓密碼持續一致。

本流程的目標是：新員工以 Google 身分開始使用 Mac；正常冷開機只輸入一次本機密碼，解鎖 FileVault 後接續進桌面；桌面端定期檢查 Google 密碼；不同步時由使用者完成更新，讓下一次開機使用更新後的本機密碼。 J01 J02 J03

「只輸入一次」指帳號已建立、FileVault 已完成啟用、登入設定驗收成功後的正常冷開機。首次 ADE／Setup Assistant、密碼不同步後的修復、復原金鑰救援，不在一次輸入的承諾內。Google 手機提示 MFA 與鍵盤輸入密碼的次數分開計算。

此設計的安全邊界

• FileVault 接續登入會略過這次開機的 Jamf Connect Google 網頁驗證。因此不是每次開機都重新確認 Google 密碼有效，也不會在此階段要求 Google Prompt。J01
• 若雲端已由 A 改成 B，但 Mac 尚未完成更新，本機 A 仍可能解鎖磁碟並進桌面。外部密碼變更不會立刻撤銷離線本機存取。J03
• 同步提示發生在使用者已進桌面後。RequireSignIn 也不能當成「不同步就封鎖桌面」的控制。J05
• 本部署基準不使用 Platform SSO。PSSO 是另一條值得評估的整合路徑，Google 也已有第三方 Xpsso 橋接文件；完整選型與未驗證的 FileVault／MFA 能力見第 03 節。不能只加入通用 PSSO payload 就視為完成切換。J28 X01

先記錄版本與現況，再調整設定。表內「待確認」必須由公司環境的負責人完成；不可把這份手冊的查核日期當成裝置驗收日期。

依據：J02 J06 J12 J13 A01 A02 G01 G02。Google Secure LDAP 授權與支援清單以 Google 官方支援方案及租戶管理後台實際可用功能為準；不能因為有 Workspace 或能使用 Google 登入，就推定有 Secure LDAP。

查核日的 Google 支援清單包括 Frontline Standard／Plus、Business Plus、Enterprise Standard／Plus、Education Fundamentals／Standard／Plus、Enterprise Essentials Plus；Cloud Identity 另須 Premium。需確認實際使用者具有適用授權。Google 管理 LDAP client 需要 Super Administrator；不是一般委派管理角色都有權限。G01 G03 G05 G06

開工前先保留的資料

記錄測試序號代碼、員工帳號短名稱、macOS／Jamf Pro／Connect Login／Self Service+ 版本、原描述檔名稱與 UUID、原 Scope、原值、LDAP client 名稱及憑證到期日。備份原描述檔至公司受控位置。不要在交接表、工單截圖或本頁填寫密碼、私密金鑰、PRK 或 OAuth 機密。

**先依 IdP 選路線：**Google 沿用本篇原方案；O365／Entra 要密碼一致及 FileVault 線上驗證時，優先評估 PSSO Password＋Microsoft 官方擴充。詳見新增的O365／Google 選型與故障速查。這是方案建議，不代表公司已決定更換 IdP 或完成實機驗收。

**新增獨立篇章：PSSO 導入與自主開發評估。**包含已查核 IdP、Google／Twocanoes 部署、架構與生命週期圖、自研工期、Codex Pro 20x 費用與可調整的預算模型。本章保留現行方案的選型摘要。

PSSO 是什麼？為什麼值得納入？

**Platform SSO（PSSO）是 Apple 內建的企業身分整合框架。**它能讓 macOS 配合身分提供者處理登入、帳號與單一登入，但必須有相容的 SSO 擴充 App、IdP 實作及 MDM 設定。Jamf Pro 可負責部署這些元件；Jamf Pro 的 PSSO 設定畫面本身不會把 Google 變成相容的 IdP。J28

**PSSO 可能更符合「登入當下驗證最新密碼」的目標。**本手冊目前的 Connect 路徑，是先用本機憑證進桌面再同步；具完整支援的 PSSO Password 路徑，可在 FileVault 解鎖階段依政策向 IdP 驗證，成功後更新本機密碼。這是值得比較的實質差異，不應省略。A05 A07

三種路徑要分開看

**版本證據：**Xpsso 自己的版本頁列出 1.0，App build 10020／service build 1070，2026-05-13 發行。不能把另一產品 XCreds 6.0 的 PRE-BETA 標籤套到 Xpsso 1.0，也不能把 XCreds 的「FileVault Unlock」功能直接當成 Xpsso 的 pre-boot PSSO 驗證證據。X04

PSSO 能改善什麼，仍有哪些前提？

Apple 要求 FileVault 前能到達 IdP；此時不能依賴尚未可用的 VPN、network relay 或 802.1X。Apple 也明示密碼同步必要時仍會詢問舊密碼。因此 PSSO 不能保證每一種密碼變更／復原情境永遠只輸入一次。macOS 27 網頁驗證另需擴充與 IdP 配合；查核的 Apple 頁面仍帶有部分功能為預發行內容的提示。A05

UserSecureEnclaveKey 的目的，是用 Secure Enclave 保護的金鑰向 IdP 驗證；使用者仍可能用獨立本機密碼登入 Mac。若公司要求「本機密碼＝Google 密碼」，應優先評估支援的 Password 同步流程，而不是把 Secure Enclave Key 當作密碼同步開關。A06

Xpsso 候選架構與導入門檻

**Jamf Pro／ADE → 部署 Xpsso App 與 PSSO 描述檔 → macOS Platform SSO ↔ Xpsso 微服務 ↔ Google OIDC／Secure LDAP。**這是供應商文件所述元件關係的整理，尚非本公司的已驗收架構。X02 X03

採用前需明確分配微服務維運、可用性、憑證輪替與 OAuth／LDAP 機密保管責任。它增加了身分服務元件；不能把評估結果寫成「多勾一個 PSSO 設定即可」。Jamf Pro 仍可保留為 MDM；是否取代 Connect 登入與桌面密碼管理，需依實際功能與遷移結果決定。

以本手冊七種情境為 PSSO 的共同驗收案例，另外確認：

1. Apple silicon、實際 macOS build、Xpsso App／service 的支援矩陣與所選驗證方法。
2. Mac 關機期間 Google A→B；開機可連線時，能否直接用 B 解鎖 FileVault、是否另問 A、是否接續進桌面。
3. 網頁 MFA 是否真的在 FileVault 階段發生，以及 Google Prompt 的同意／拒絕／逾時結果。
4. 離線寬限、帳號停權、微服務或 LDAP 故障時的行為，以及 PRK 復原。
5. 既有 Connect 使用者的遷移、keychain 保留與回復程序；不要在正式 Scope 同時試跑兩套密碼管理設定。

**選型結論：**若目前只要求正常冷開機一次密碼、接受桌面後同步，現有 Connect 基準可先做驗收。若要求開機當下檢查最新 Google 密碼，PSSO 應列入優先比較；Google＋Xpsso 是可具體評估的候選，但 FileVault／Google Prompt 端到端能力仍待確認，不能宣稱已經解決。

以下為目前 Connect 部署基準的元件分工。

首次建立帳號的路徑

Apple Business Manager／ADE → Jamf Pro 下發套件與設定 → Jamf Connect Login → Google OIDC ＋組織 MFA → 建立員工本機帳號 → 建立 FileVault 解鎖與復原能力。 J07 J08 J09

Google OIDC 登入頁上輸入的密碼可經 Jamf 的 Google passthrough 路徑用於初始本機密碼；Google 專屬參數要成組設定。這不代表每次開機都會從 Google 再拿一次密碼，也不代表既有帳號能在 Login Window 強制完成密碼同步。J08 J09

日常開機的路徑

FileVault → 本機密碼驗證 → 憑證接續登入 → macOS 桌面。 啟用接續登入後，使用者不會再次看到 Jamf Connect 登入要求。J01

桌面密碼同步的路徑

Self Service+ → Google Secure LDAP → 驗證目前保存／使用的網路憑證 → 必要時要求使用者重新驗證與同步 → 更新本機密碼 → 下次冷開機驗收。 LDAP 驗證不是 Google 網頁 MFA 流程。J02 G02

**方案建議：**OIDC 與 LDAP 不是二選一：本手冊首次 Google 登入使用 OIDC；桌面持續密碼同步使用 Secure LDAP。只設定其中一邊，不會自動補齊另一邊。

首次部署

1. IT 完成環境檢查、Google 整合、Jamf 測試 Scope 與復原準備。
2. 全新 Mac 透過 ADE 註冊；Jamf 在登入前部署 Connect 與必要設定。
3. 員工在 Google 畫面輸入密碼 A，依公司政策完成 Google Prompt。
4. Jamf Connect 建立員工本機帳號，透過須經第 12 節 T01 驗收的 passthrough 讓初始本機密碼也是 A。
5. 確認員工 token／解鎖資格與備援路徑；FileVault 若已在 Setup Assistant 開啟，就驗證授權與 PRK；若尚未開啟，再用核准方法啟用並確認 PRK 託管。
6. Self Service+ 在員工桌面完成第一次帳號驗證與密碼一致性檢查；不得預設第一次設定完全不需額外提示。
7. 完全關機後再開機，驗證一次 A 即可到桌面，再交機。

正常使用

1. 冷開機，在 FileVault 輸入本機 A。
2. 成功解鎖後接續登入，直接進桌面。
3. Self Service+ 啟動，依排程／網路變化執行檢查；實際執行時點以測試結果與日誌確認。
4. Google 仍為 A：維持同步，無需使用者改密碼。
5. Google 已改成 B：重新驗證成功後，引導使用者以本機 A 授權更新為 B。
6. 更新成功後，下次冷開機以 B 解鎖並接續登入，進入下一個相同循環。

對照表

這些是此架構的預期行為；公司測試結果請記錄於第 12 節。來源：J01 J02 J03。

七個實際使用情境：這一次開機要輸入哪個密碼？

先確認這台 Mac 的本機密碼是否已完成更新，再決定使用 A 或 B。「Google 已改密碼」與「這台 Mac 已同步」是不同的完成點。以下 A／B 都是狀態代號，不能記錄真實密碼。

情境 01：全新 Mac，透過 ADE 首次交機

**前提：**這裡的 ADE 是 Apple「自動裝置註冊」，不是 Active Directory。公司已完成 PreStage、Google OIDC、Secure LDAP、套件、授權與復原準備，員工本機帳號尚未建立。J07

1. Mac 透過 ADE 進入公司管理流程，由 Jamf Pro 在首次登入前部署 Connect、Self Service+ 與必要設定。
2. 員工在 Google 頁面輸入密碼 A，依公司政策完成 Google Prompt；Connect 透過須經第 12 節 T01 驗收的 Google passthrough 建立對應本機帳號，使初始本機密碼也是 A。J08 J09
3. **先檢查 FileVault 實際狀態。**若 Setup Assistant 已開啟 FileVault，驗證員工解鎖資格與 PRK 託管；若尚未開啟，再使用單一核准方法啟用。macOS 26.4 起 Setup Assistant 預設開啟 FileVault，不能承諾每台新機都會先完成 Google 建帳才啟用加密。A02
4. 進桌面後完成 Self Service+ 帳號初始化及 A／A 一致性檢查；第一次設定可能有額外提示。
5. 完全關機再開機，驗證一次 A 能進桌面；交機前依第 12 節完成 A→B、B 解鎖及復原路徑驗收。

**預期結果：**Google A／本機 A，FileVault 已開啟、員工能解鎖、PRK 已託管。一次密碼的承諾從已完成首次部署與初始化後的正常冷開機開始，不能套用到整段首次設定。

情境 02：員工已改密碼，而且本機已同步完成

**前提：**Google 已由 A 改成 B；員工已在這台 Mac 以 B 完成網路驗證，並成功完成本機 A→B 更新。Google 網頁顯示改密碼成功，本身不足以證明本機已更新。J02 J03

1. 完全關機後開機，在 FileVault 輸入 B。
2. 確認解鎖後接續進桌面，不出現第二個 Google 登入要求。J01
3. 在受控驗收下確認 A 不再通過同一帳號的普通解鎖，並記錄結果；不要反覆猜測密碼。
4. Self Service+ 於桌面運作，返回定期憑證檢查循環。

**預期結果：**Google B／本機 B，正常冷開機一次 B 到桌面。若桌面本機更新顯示成功，但 B 仍無法解鎖 FileVault，停止擴大部署，依第 10 節處理；不要關閉 FileVault 來繞過問題。

情境 03：使用中更改 Google 密碼，隨即重新開機

**前提：**員工已在 Mac 桌面，把 Google A 改成 B 後立即重新啟動。**不能只憑「已改 Google」判定這次開機必須輸入 B。**先分辨本機同步是否完成。J02 J03

• **本機尚未完成更新：**FileVault 仍用 A。進桌面後，確認 LDAP 可達，以 B 重新驗證，再依提示以本機 A 授權更新為 B；成功後再次冷開機驗證 B。
• **本機已完成更新：**FileVault 用 B，接續進桌面；若是更新後第一次冷開機，記錄 B 解鎖及一次登入結果。
• **同步過程遭中斷或結果不明：**先按支援流程確認目前狀態，不要宣稱一定用 A 或 B，也不要連續猜測。

**預期結果：**兩條成功路徑最終都回到 Google B／本機 B。重新開機本身不會取得雲端新密碼，也不會自動完成本機同步。桌面修復同步所需的額外輸入，與正常冷開機的登入次數分開計算。

情境 04：Mac 關機很久，Google 密碼已在別處更改

**前提：**Mac 關機前最後成功同步的密碼是 A；關機期間，員工在手機或其他電腦把 Google 改成 B。這台 Mac 尚未完成本機更新。J03

1. 冷開機在 FileVault 輸入 本機 A，接續進桌面。這時 B 尚不是這台 Mac 的本機解鎖密碼。
2. 恢復連線，確認 Self Service+ 已啟動且 LDAP 可用，以新 Google 密碼 B 完成網路驗證。
3. 按提示以本機 A 授權更新為 B。
4. 更新成功後完全關機再開機，以 B 驗證 FileVault 解鎖及一次進桌面。

**預期結果：**這次先用 A；完成同步並驗收後，下次正常冷開機改用 B。**遠端更改 Google 密碼不會立即撤銷離線本機 A。**設備遺失、帳號停權或離職時，須另外啟動公司的事件處理與裝置控制流程。

情境 05：開機時沒有網路

**前提：**帳號、FileVault 與接續登入已驗收；Mac 離線，只知道最後完成更新的本機密碼 A。Google 此刻可能仍是 A，也可能已改為 B。J01 J03

1. 依既有 FileVault 解鎖資格使用本機 A；A 仍可能解鎖並接續登入。
2. Self Service+ 無法在線驗證時，把雲端密碼狀態記為未知；舊的「已同步」紀錄不能證明此刻仍一致。
3. 恢復連線後重新檢查：Google 仍為 A 就維持一致；若已改 B，再完成 B 網路驗證、本機 A→B 更新及冷開機驗收。

**預期結果：**離線期間保留本機使用能力；重新成功驗證後，才判定一致或引導同步。離線不等於一定不同步，也不能承諾離線 Mac 在固定分鐘數內完成同步。

情境 06：只記得 Google 新密碼 B，忘記本機 A

**前提：**Google 已改為 B，本機仍為 A，員工忘記 A。員工可能停在 FileVault，也可能仍有尚未登出的桌面工作階段。A03

1. 若仍在桌面，保留工作與可用工作階段，聯絡 IT；若停在 FileVault，停止反覆猜測，先完成公司規定的使用者及裝置身分核對。
2. 授權管理員確認可用的 PRK 或其他核准復原路徑，依 Apple／Jamf 與公司程序處理。不得把 PRK、密碼或私密金鑰抄入本手冊、普通工單或截圖。
3. 復原後重新確認 Google 憑證、本機密碼、員工 FileVault 解鎖資格與 PRK 狀態，再執行冷開機驗收。

**預期結果：**完成受控復原後恢復可登入、可解鎖及可持續同步的狀態。不能承諾直接輸入 B 就能修復，也不承諾此情境只輸入一次。管理員重設與已知舊密碼的正常變更不同，可能需重建 login keychain，須按 Apple 說明處理並告知使用者。A03

情境 07：可以上網，但 Secure LDAP 驗證失敗

**前提：**員工已用目前本機密碼進入桌面，Self Service+ 卻無法完成 Google Secure LDAP 驗證。瀏覽器能上網、Google OIDC 或 Google Prompt 成功，都不能單獨證明 LDAP 可用。J02 G02

1. 把狀態記為未知，記錄錯誤時間、發生階段及不含機密的錯誤訊息，不直接推定 Google 密碼已改變。
2. 依第 10 節檢查 DNS、TCP 636、TLS、LDAP 用戶端憑證與私密金鑰、效期、client 啟用狀態、使用者授權及驗證權限；必要時排查服務錯誤與配額。G02 G06 G08
3. 排除原因後重新驗證正確 Google 憑證：一致就維持；確認需同步才由使用者完成本機更新，再驗收 FileVault。

**預期結果：**以本次成功驗證確認真實狀態；只有本機變更成功並通過 FileVault 冷開機驗收，才記錄完成。不要刪除 state plist、修改 PasswordCurrent 或關閉 FileVault 來製造成功狀態。LDAP 失敗本身不會把本機密碼換成 B。J21 J22

A. OIDC：供首次 Google 登入使用

1. 依 Jamf「Creating an OpenID Connect Application Integration for the Login Window」建立／選定 Google Cloud 專案與 OAuth 應用程式。J10
2. Google Cloud → APIs & Services → Credentials → Create Credentials → OAuth client ID，依 Jamf 文件使用 Web application。公司內部用途使用公司組織下的專案與 Internal audience；新版介面可能位於 Google Auth Platform 的 Branding／Audience／Clients。J10 G07
3. 登記 redirect URI（Jamf 範例為 https://127.0.0.1/jamfconnect）；Connect 的 OIDCRedirectURI 必須完全相同。保存 Client ID 與 Client Secret 到公司核准位置。測試外部個人 Google 帳號確實遭拒，而不是只看登入畫面上的公司網域。J10 G07
4. 在 Jamf Connect Login 設定檔填入 Google provider、Client ID、Client Secret 與回呼值，依第 06 節設定 Google passthrough；Login Window 值須對應同一個 Google OAuth client。J14 J24
5. 以測試 Google 帳號完成網頁登入，驗證公司帳號範圍與 MFA。OIDC 驗證成功只證明登入整合，不代表 LDAP 密碼同步已就緒。
6. 若租戶另有上游聯邦 IdP、無密碼登入、特殊 Google 工作階段政策，先重新驗證 passthrough 能取得用於初始本機帳號的密碼；不要承諾所有登入方式都能自動建立相同密碼。

本手冊不預填租戶 OAuth 參數。交接時必填：專案、Client ID、應用程式類型、redirect URI、允許帳號範圍、設定檔名稱，以及成功登入測試時間。

B. Secure LDAP：供桌面密碼驗證與同步使用

1. 在 Google Admin Console 的 Apps → LDAP 新增或選定公司專用 LDAP client；先確認授權方案及管理權限。G01 G03
2. 設定 Access permissions → Verify user credentials，由預設 No access 改為核准的測試 OU／群組。若需查詢使用者，Read user information 使用相應範圍；Read group information 只在實際流程需要時開啟，不預設是所有 Jamf 密碼同步的必要條件。Google 說明權限變更可能需最長 24 小時生效。G08
3. 啟用 client，取得用戶端憑證及私密金鑰；依 Jamf 官方步驟轉成 .p12。J11
4. Jamf Pro → Computers → Configuration Profiles → New，使用 Computer Level 的 Certificates payload，上傳 .p12、輸入匯出密碼，依 Jamf 官方程序勾選 Allow all apps access，部署至測試 Scope。確認憑證及對應私密金鑰進入 System Keychain。這項允許存取設定應納入公司憑證保護評估，不能部署後假設只有單一 App 能用。J12
5. 在 Self Service+ 的設定中指定 IdPSettings → Provider = GoogleID，啟用帳號管理所需授權與設定。J06 J13
6. 確認 DNS、TCP 636、TLS 信任、憑證效期、client 啟用狀態及使用者權限，再以測試使用者在 Self Service+ 驗證。G02 J02
7. 執行一次外部 Google A→B 變更測試。只有「網路可連、Google 新密碼可驗證、使用者完成本機同步」全數通過，才算整合完成。

若 Google 使用第三方 SSO，Secure LDAP 仍需要真正的 Google 使用者帳密，不能直接以第三方 IdP 密碼取代；也不能以 Google Prompt 成功推定 LDAP 已可驗證。G09

憑證匯出密碼與私密金鑰不得寫入腳本、參數清單、原始碼或本網站。輪替時先部署新憑證、測試驗證，再依 Google 管理方式撤下舊憑證，避免同時切斷所有 Mac。G03 J11 J12

憑證轉換範例（先替換安全檔案路徑，匯出密碼由互動提示輸入）：

openssl pkcs12 -export \
  -out /path/to/generated/google-ldap.p12 \
  -inkey /path/to/saved/google-ldap.key \
  -in /path/to/saved/google-ldap.crt

這只是格式轉換，不會啟用 LDAP 或自動派送憑證。Google 的 bind 配額為租戶共用 4 QPS；設定短檢查週期與批次觸發時，需合併考量其他 LDAP client，避免所有 Mac 同時集中重試。G06

Google＋Jamf Connect＋FileVault 設定包

設定包 1.0｜查核：2026-09-22｜公司測試機尚未驗收。

**使用方式：下載設定包 → 填一份參數檔 → 在本機產生設定 → 匯入 Jamf Pro，或複製三份 plist 到對應網域。**本設定包涵蓋首次 Google 登入、桌面密碼同步及 FileVault 接續登入。以既有手冊的 Google 原方案為基準，不使用 PSSO。

下載完整 ZIP · 主手冊 · 26 項公司驗收表

一、先確認你已具備哪些條件

下列項目需要由 Google 或 Jamf 核發／部署，不能以通用 XML 自行捏造。已完成者只需核對，不必重建。

依據：Jamf Google 整合流程、Google 密碼同步、部署 p12、啟用 Self Service+ 帳號管理。Jamf 的整合指南適用 Connect 3.x；上線前記錄公司實際版本／build，不以「最新版」代替驗收。

二、只需填一份參數

解壓縮至公司核准的受控工作位置。複製 settings.example.json 為 settings.local.json，使用純文字編輯器修改；不要在 Git 工作目錄、網站目錄或公開雲端資料夾填真實機密。

Google Client Secret 不填進 JSON。程式執行時在終端以隱藏方式詢問，並只寫入你指定的受控輸出設定。這不是員工 Google 密碼；不要提供任何員工密碼或 PRK。

參數範本如下，內容中的 REPLACE_... 必須替換：

{
  "organization": "REPLACE_COMPANY_NAME",
  "profile_identifier": "REPLACE_PROFILE_IDENTIFIER",
  "google_client_id": "REPLACE_GOOGLE_CLIENT_ID.apps.googleusercontent.com",
  "google_redirect_uri": "https://127.0.0.1/jamfconnect",
  "network_check_minutes": 15,
  "support_contact": "REPLACE_IT_CONTACT",
  "excluded_local_accounts": [],
  "auto_open_app_at_login": true,
  "require_sign_in": true
}

三、產生完整設定檔

在解壓縮後的 google-jamf-filevault 資料夾開啟終端。需要 Python 3.9 以上，僅使用標準函式庫，不需安裝 Python 套件；若管理用 Mac 沒有 Python，可使用下方手動貼上路徑。

cp settings.example.json settings.local.json

填好 settings.local.json 後執行：

python3 render.py --settings settings.local.json --output private-output

輸入 Client Secret 時畫面不顯示字元。程式只產生檔案，不連線、不安裝描述檔、不改員工密碼。再次產生時改用新的輸出目錄，例如 private-output-v2；程式拒絕覆寫原檔。

產出如下：

輸出目錄權限 0700、檔案 0600；Login plist 及 mobileconfig 含有 OAuth Client Secret，不是加密檔。只交給有權的管理員並上傳公司 Jamf；不要寄送一般員工、放進 GitHub 或回傳本手冊網站。產生器處理 XML 特殊字元，避免手動貼入 & 等符號造成格式錯誤。

以系統工具確認格式，不會安裝：

plutil -lint private-output/Google-Jamf-FileVault.mobileconfig
plutil -lint private-output/01-com.jamf.connect.login.plist
plutil -lint private-output/02-com.jamf.connect.plist
plutil -lint private-output/03-com.apple.loginwindow.plist

格式 OK 只表示 XML／plist 可解析，不能證明 Google OAuth、LDAP、Jamf 發送或 FileVault 流程成功。

四、套用到 Jamf：選一種方式

A. 完整描述檔匯入

適用於新建且已清除設定衝突的測試 Scope。

1. 先備份原設定與 Scope，確認 LDAP 憑證、授權、套件及復原前置項目已就緒。
2. Jamf Pro → Computers → Configuration Profiles → Upload，選擇產生的 Google-Jamf-FileVault.mobileconfig。這是整份描述檔匯入，不是貼到 Application & Custom Settings 的文字框。
3. 檢查 Computer Level／System、名稱與 payload。新檔是未簽章 XML；若租戶流程要求簽章，依公司程序用 Jamf Connect Configuration 或公司核准憑證處理，不以改副檔名代替簽章。
4. Scope 只指向指定測試機；保存後確認裝置實際收到。既有三個網域如有其他 profile 管理相同鍵，先完成合併／移出測試 Scope，不能期待後下發就一定覆蓋。
5. 確認有效設定與測試結果。不要再把三份 plist 另外部署一次。

B. 複製 plist 到既有設定

適用於已運作的 Jamf 環境，尤其已有授權、帳號對應、品牌、腳本或管理員政策。先合併必要值，不能用最小基準整份覆蓋現有公司設定。

Jamf Pro → Computers → Configuration Profiles → New／Edit → Computer Level → Application & Custom Settings → Upload。依租戶 UI 選擇 plist 上傳或貼入 XML；對應如下：

將每份 <plist>…</plist> 完整內容貼到自己的網域；不可把三份黏成一個 plist，不可把整份 mobileconfig 貼進偏好設定框。這三份的布林值是 <true/>／<false/>，頻率是 <integer>，不是字串。

若不使用產生器，也可直接複製 templates/ 三份檔案，在受控副本替換所有 __...__，調整頻率及例外帳號，再逐一 plutil -lint。XML 文字中的 &、< 須分別寫成 &、<；優先使用產生器避免手動跳脫錯誤。

五、這份設定實際選了什麼

設定依據：Google passthrough 成組鍵、FileVault 行為、同步政策、登入設定。描述檔封裝依 Apple ManagedPreferences 與 Apple LoginWindow schema。

若既有流程沒有使用 CreateJamfConnectPassword，Jamf 針對 Google 的文件另有 OIDCUsePassthroughAuth=true、CreateJamfConnectPassword=false／未使用、OIDCNewPassword=true 組合。本包固定選用建立 Jamf Connect keychain 的那一組；既有機須確認原流程依賴，不可只從兩組各挑一個值。

六、部署順序：既有 Mac 與全新 ADE

已啟用 FileVault 的既有 Mac

1. 確認員工目前可解鎖、PRK 可由有權 IT 取回；匯出原 profile、Scope 與原設定值到受控位置。
2. 優先使用方式 B 合併。先確認 Self Service+ 的 LDAP 同步能把本機更新到目前 Google 密碼，再測冷開機接續登入。不要把這份新機初始基準當成帳號移轉腳本。
3. 由員工首次開啟 Self Service+ 完成帳號初始化；Jamf 管理通知權限，確認可收到提示。App 啟動、登入狀態及密碼一致性分別確認。
4. 依下表驗收，記錄實際版本與結果後再擴大 Scope。

全新 Mac／全新員工／ADE

1. Jamf PreStage 設定管理員備援與員工建帳方式；Connect 負責員工建帳時，依官方流程略過一般帳號建立。
2. 在首次員工登入前，讓 Login 設定、有效授權、Connect 套件就緒，並部署 Self Service+、LDAP 憑證及同步設定。PreStage 套件已列入不代表實際安裝已完成。
3. 員工以 Google 密碼＋組織 MFA 完成首次登入，確認帳號、預期權限及初始本機密碼一致。首次流程可能有額外提示，不在日常一次密碼承諾內。
4. 核對 FileVault 實際 On／員工解鎖資格、適用的 secure token／volume ownership／bootstrap token 及最新 PRK。macOS 26.4+ Setup Assistant 的加密時序須依主手冊第 07 節驗收，不預設建帳前一定尚未加密。
5. 若尚未啟用 FileVault，使用公司唯一核准的 Jamf 原生啟用與 escrow 流程；不要同時加 EnableFDE。若已 On，保留加密並驗證授權與 escrow。
6. 完成 Self Service+ 初始化與正常冷開機測試後交機。

FileVault 原生管理入口：Computers → Configuration Profiles → Security & Privacy → FileVault；PRK 託管由 Jamf 對應設定及憑證處理，完成後到裝置 Inventory → Disk Encryption 核對。不能隨意複製其他租戶的 escrow PayloadUUID 或憑證。此包刻意分開管理登入偏好與加密復原設定，兩者都要完成。

七、套用後必驗的結果

桌面上可由員工本人工作階段立即觸發檢查（不是將這行直接貼入 Jamf 的 root Policy）：

open "jamfconnect://networkcheck"

確認由預期的 Self Service+ 版本接手且本次檢查有結果。FileVault 狀態可只讀檢查：

fdesetup status

完整操作、PasswordCurrent 狀態限制、復原與 T01～T26 驗收見主手冊第 08～12 節。產生器的本機測試與 plutil 不會將任何公司案例改成通過。

八、回復方式

保留受控的原始 profile、Scope、UUID、設定值與套件版本。出現登入、LDAP 或同步異常時先停止擴大 Scope；恢復原本的有效設定及啟動機制，只處理本次更動的登入／同步偏好。不要刪除仍需使用的授權、LDAP 憑證、FileVault／PRK profile，也不要關閉 FileVault 或清除 keychain。

描述檔回復不會把已更新的本機密碼改回 A；需記錄目前真正有效的密碼狀態。失敗到無法進桌面時，由 IT 依已驗證的復原流程處理，不能期待再次下發設定一定能救回離線裝置。

九、可直接複製的三份 plist 範本

以下是方式 B 使用的完整偏好 plist，仍須填妥佔位值；不是整份 .mobileconfig。若使用產生器，直接複製它產出的已填值檔案即可。

01 — com.jamf.connect.login

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>OIDCProvider</key><string>GoogleID</string>
  <key>OIDCClientID</key><string>__GOOGLE_CLIENT_ID__</string>
  <key>OIDCClientSecret</key><string>__GOOGLE_CLIENT_SECRET__</string>
  <key>OIDCRedirectURI</key><string>__GOOGLE_REDIRECT_URI__</string>
  <key>OIDCUsePassthroughAuth</key><true/>
  <key>CreateJamfConnectPassword</key><true/>
  <key>OIDCNewPassword</key><false/>
  <key>DenyLocal</key><false/>
</dict>
</plist>

02 — com.jamf.connect

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>IdPSettings</key>
  <dict><key>Provider</key><string>GoogleID</string></dict>
  <key>PasswordPolicies</key>
  <dict>
    <key>NetworkCheck</key><integer>15</integer>
    <key>CheckOnNetworkChange</key><true/>
    <key>SyncPasswordsMessage</key>
    <string>Mac 與 Google 密碼不同。請輸入目前的 Mac 本機密碼，更新為已驗證的 Google 密碼；忘記本機密碼時請聯絡 __IT_CONTACT__。</string>
    <key>PasswordSyncBlockList</key><array/>
  </dict>
  <key>SignIn</key>
  <dict>
    <key>AutoAuthenticate</key><true/>
    <key>AutoOpenAppAtLogin</key><true/>
    <key>RequireSignIn</key><true/>
  </dict>
</dict>
</plist>

03 — com.apple.loginwindow

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>DisableFDEAutoLogin</key><false/>
</dict>
</plist>

新機 ADE

先分辨實際啟用路徑。 Apple 現行文件標示 macOS 26.4 起在 Setup Assistant 預設開啟 FileVault。因此不能假設全新機一定尚未加密，或保證所有版本都在 Google 登入之後才啟用。若 FileVault 已 On，保留加密，重點驗證新員工解鎖資格與 PRK；若尚未 On，才走下列延後啟用候選流程。Setup Assistant 強制啟用的 awaiting configuration、帳號建立與 escrow 條件，須與實際 PreStage 一起驗收。A02

1. 建立測試 PreStage 與 Scope。 確認 ADE 已指派到 Jamf Pro、套件與設定檔有效。先使用測試帳號與測試 Mac。
2. 帳號策略。 依 Jamf Connect PreStage 指引設定受管理的備援管理員，並在 Account Settings 略過一般帳號建立，讓 Connect 負責員工帳號。不要在 Setup Assistant 另建一個不同密碼的員工帳號。J07
3. 確保安裝順序。 在 PreStage 的 Enrollment Packages 加入 Connect PKG，部署 Self Service+ 時一併加入其 PKG；核對套件配送可用性。Connect 安裝套件、Login 設定與授權必須在員工登入前就緒；只勾選套件並不等於已完成安裝，需實際觀察首次開機。Jamf 建議至少保留一個 Setup Assistant 步驟（例如 Privacy），避免全部略過而登入畫面先於套件安裝完成。J07
4. Google 初次登入。 員工用 A 完成 Google OIDC／MFA；確認建立的是正確本機帳號，密碼與 Google 一致。不得假設 ADE 註冊驗證本身等於此步驟。
5. 驗證帳號與復原能力。 確認目標員工的 secure token／適用的 volume ownership，MDM bootstrap token 狀態與備援管理員；各 token 不是同一件事。A01 A02
6. 以單一方法管理 FileVault 啟用。 若尚未啟用，此基準候選採 Jamf Pro 原生延後啟用與 PRK 託管；員工帳號就緒後再套用測試 Scope。若已啟用，保留並驗證即可。既有公司若採 Connect 的 EnableFDE 流程，先保留並驗證，勿同時啟用兩條機制。J17 J18
7. 完成加密與託管。 要確認裝置實際 FileVault 狀態、員工解鎖資格與 Jamf 可授權取回 PRK；尚未完成就不交機。
8. 初始化 Self Service+。 確認 LDAP 憑證、GoogleID、帳號管理與通知設定；由員工完成首次登入與網路檢查。
9. 正常冷開機驗收。 使用測試流程 T02，確認一次 A 進桌面。再跑 A→B 同步與下一次 B 解鎖測試。

停止條件： 出現 Deferred enablement appears to be active for user 'unknown'，表示不能繼續把它視為加密成功。Jamf 已記載 Skip Account Creation 配合過早延後啟用的問題；先檢查帳號與啟用順序。J19

尚未啟用 FileVault 時的候選描述檔

Jamf Pro → Computers → Configuration Profiles → New → Computer Level → Security & Privacy → FileVault。以下適用於已確認可走 deferred enablement 的測試機，不是覆寫 macOS 26.4+ Setup Assistant 預設行為的指令。J25 A02

表內提示略過次數與禁止使用者停用的選項，另參照 Jamf 官方 FileVault 設定指南。

到裝置 Inventory → Disk Encryption 確認復原資料與解鎖使用者；此時尚未回報 PRK 就不能算交機完成。macOS 26 以上在 bootstrap token 可用時，新增或更新 escrow profile 可能自動輪替 PRK，回復設定後也要確認最新託管金鑰。J26

既有 Mac

1. 保留原 profile／Scope 與復原路徑，確認 FileVault On、員工可解鎖、PRK 已託管。
2. 先讓 Self Service+ 完成 Google 密碼同步，確認本機與 Google 同為 A。
3. 對測試 Scope 調整 DenyLocal=false，確保 DisableFDEAutoLogin 沒有有效的 true；不要直接修改受 MDM 管理的本機 defaults 來取代描述檔。
4. 更新同步檢查設定，確認應用程式啟動與通知。
5. 完成冷開機、外部改密碼、離線與同步後冷開機驗收，再分批擴大 Scope。

先確認指令在哪個身分執行

以下 URL 與 defaults read 應在該員工已登入的桌面、以該員工身分執行。不要直接在 Jamf 的 root 腳本中照抄：root 的偏好設定與員工的 GUI 工作階段不同。若要用 Jamf Policy 自動觸發，需另外實作並驗收目前 console user 的工作階段處理。

先確認 Google 登入帳號與本機員工帳號對應。若舊 Jamf Connect menu bar app 與 Self Service+ 共存，需確認 jamfconnect:// 實際由預期版本接手，不能只因指令返回成功就判定執行對象正確。

步驟一：立即啟動檢查

open "jamfconnect://networkcheck"

這只會觸發 Self Service+ 檢查，不保證已完成。確認 App 有運作、網路驗證有結果，再看狀態；不要緊接著讀取舊快取就宣布成功。J20

步驟二：讀取狀態

defaults read com.jamf.connect.state PasswordCurrent
defaults read com.jamf.connect.state LastSignIn
defaults read com.jamf.connect.state UserLoginName

狀態欄位由 App 維護，不要以 defaults write 把 PasswordCurrent 改為 1；這不會改密碼。J21 J22

步驟三：引導完成更新

open "jamfconnect://signin"

1. 請員工輸入目前 Google 密碼 B，完成 Self Service+ 要求的網路帳號驗證。
2. 若提示本機與網路密碼不同，員工輸入目前本機舊密碼 A，授權更新本機密碼。
3. 等待 App 顯示成功；若 macOS 密碼政策拒絕 B，先確認 IdP 與 MDM 政策相容，不得把失敗記錄為完成。
4. 再次連線檢查、讀取狀態，並記錄時間與測試帳號代碼。
5. 在測試 Mac 做正常關機／開機，以 B 驗證 FileVault 與一次登入；受控測試確認 A 不再通過該帳號的普通密碼解鎖。不要反覆猜測密碼造成鎖定。

Google MFA 仍由 Google 網頁政策保護對應流程；此 LDAP 密碼驗證不是每次都會跳 Google 手機提示。不要把「LDAP 成功」寫成「Google Prompt 已完成」。J02 J03 G02

以下指令只讀取狀態。帶有權限需求的查詢由授權 IT 執行；執行失敗必須記為「未知」，不能直接推定功能關閉。輸出可能包含裝置識別碼與帳號名稱，請存入公司受控工單。

# macOS 版本與 build
sw_vers

# ADE / MDM 註冊狀態
profiles status -type enrollment

# FileVault 狀態與有權解鎖的使用者（依需要由授權 IT 使用 sudo）
fdesetup status
sudo fdesetup list

# 對已確認的本機帳號短名稱查 secure token；先替換 LOCAL_SHORTNAME
sysadminctl -secureTokenStatus LOCAL_SHORTNAME

# bootstrap token 的本機與伺服器託管狀態（授權 IT）
sudo profiles status -type bootstraptoken

# Apple silicon：列出 APFS 使用者／volume owner，對照員工 GeneratedUID
sudo diskutil apfs listUsers /
dscl . -read /Users/LOCAL_SHORTNAME GeneratedUID

來源與操作背景：A01 A02 J17。指令輸出是局部證據；secure token 已啟用不等於 PRK 已託管，也不等於員工已通過冷開機解鎖。另在 Jamf Pro 裝置庫存檢查加密狀態、Recovery Key 託管及適用 token 狀態。

新增Google 登入失敗速查：依 FileVault、Connect 與桌面同步分成 8 種情境，並排比較有／無網路。FileVault 原方案使用最近生效的本機密碼；連上網路不會直接讓尚未同步的新 Google 密碼生效。

RequireSignIn=true 可以讓驗證視窗保留，但不能把它宣稱為全桌面禁止使用、無法強制結束，或同步成功前所有應用程式不可用。若公司將來要求這種存取控制，需另立需求與重新選擇登入架構。J05

以下支線是研究記錄，不是現行故障排除指令。可下載獨立開發支線文件。

開發支線：永久離線裝置的本機使用限制

支線代號：OFFLINE-01｜記錄日期：2026-09-22｜狀態：需求已記錄；開發未啟動；全部實機案例未測。

這是未來可能自主開發的小工具研究方向，不是目前已部署的功能，也不是公司核准上線的防盜保證。它獨立於 Google／Entra 的登入與密碼同步方案。

已確認的需求與 TASTE

使用者提出隱藏資料夾內的 pari.123 檔案作為時間標記，以及一週或兩週未更新後反覆鎖定的構想。**檔名、路徑、7／14 天及執行頻率都只是討論示例，尚未選定為正式參數。**核心需求是永久離線時也能運作，不是依賴檔案隱藏。

威脅情境與成功標準

• FileVault 保持開啟；對方知道仍有效的本機／FileVault 密碼。雲端 Google 密碼可能已變更，但本機尚未同步。
• 交付前可以完成部署與授權；失竊後的判斷、限制及 IT 復原都不能依賴網路、MDM 命令送達、Google 或其他雲端服務。
• 對方可能反覆登入、重開機、嘗試修改時間、刪除檔案或停止服務。一般使用者與管理員／root 權限必須分別測試，不能假設公司已完成降權。
• 使用者接受將反覆鎖定／登出作為研究中的使用阻礙手段；能否達成「到期後只有 IT 可解除」仍須驗證，不能以鎖螢幕畫面代替結果。
• 主要候選目標是作業系統內的持續使用限制。抵抗管理員、復原環境及其他磁碟存取途徑的能力尚未證實；不能直接聲稱提供 FileVault 解鎖前的封鎖或不可繞過的硬體鎖。

永久離線時，本機無法知道公司後來才標示的「已失竊」事件；它能依據的只有預先下發的規則與本機狀態。因此授權逾期不是失竊證明，合法長期離線員工也會受到相同規則影響。期限到達前已有的存取空間、到期前已被複製的資料，不能由後續限制追回。

原廠能力與工具研究結果

以下來源於 2026-09-22 查核，沒有公司裝置測試結果。

現階段沒有任何上述候選被列為「已完整符合」。不因名稱含 offline、freeze 或 lock 就判定可用。

候選設計：交付前部署，之後完全本機執行

這一節是設計建議，不是已選定的實作。

1. 本機背景服務：研究由 Jamf 在交付前安裝系統服務；服務在 OS 可執行時啟動，並處理週期檢查、喚醒及登入狀態變化。不能把它畫在 FileVault 解鎖之前。
2. 有期限的裝置授權：研究使用包含裝置綁定、核發／到期資訊及政策版本的簽章文件。簽發私鑰留在 IT 受控環境，Mac 僅保有驗證公鑰。不把真實私鑰、授權檔或共用解鎖密碼放進專案。
3. 可信的期限判斷：不只依檔案修改日期。簽章可驗證內容來源，但本身不能阻止回撥系統時間、還原舊狀態或替換檢查程式；跨關機的時間與防回復方案是首要可行性缺口。
4. 持續限制狀態：到期後保存限制狀態，不能因重開機、重新登入、員工輸入舊密碼或刪除標記而重新得到完整期限。反覆鎖定／登出是候選執行方式，尚未選定支援 API，也未證明無可操作空檔。
5. IT 離線復原：研究綁定該裝置與本次復原請求的簽章授權，由 IT 工具產生，受管 Mac 在本機驗證。一次性使用、防重放、換機不可使用及復原介面可達性均要測試。

檔案可以存放於一般使用者不可寫入的位置，但隱藏名稱不是安全機制；取得管理員／root 權限後的能力需另外驗證。刪檔或狀態損毀不得被誤認為首次安裝而重設期限，應進入明確的待 IT 修復狀態；這不表示自動清除磁碟。

狀態與流程

流程順序：預先部署 → 永久離線 → 本機檢查 → 授權有效則繼續；到期則限制 → 重啟仍檢查 → IT 收回後離線復原。

關機時程式不能執行；長期關機後只能在下一次可執行時判定期限。整段流程沒有遠端 Lock Computer、等待 APNs／Jamf 指令或雲端解鎖分支。IT 復原授權可由獨立受控工具準備，但失竊 Mac 本身不得需要網路。

不可混淆的防護界線

• 作業系統內鎖畫面／登出，不等於撤銷有效的 FileVault 憑證；也不代表其他磁碟存取途徑均已封鎖。
• launchd 啟動／KeepAlive 不等於防竄改或不可終止；程式簽章也不能單獨保證抵抗已取得管理權限的人。
• 簽章文件、系統權限與時間紀錄都只是候選設計的一部分，不能直接宣稱能防止系統回復或完整快照回復。
• 原本 Google 密碼同步不會因本支線而變成離線即時驗證；PSSO 的網路驗證政策也不能直接視為本支線的離線 IT 復原機制。
• 裝置永不回報時，後台最多記錄「推定期限已到」，不得記成「已確認成功鎖定」。本機證據由 IT 收回後讀取；不保存使用者檔案內容或密碼。
• 不將自動清除、隨機修改員工密碼、移除 FileVault 解鎖資格或破壞復原能力列入本次候選。

未來驗收範例：O01～O12 全部未測

這是將來 SDD 規格及 TDD／實機驗證的輸入，獨立於現有 T／P／E 共 52 項案例。模擬時間、文件簽章及狀態轉移可做自動化測試；FileVault、管理員繞過及復原必須用授權測試 Mac 驗證。

開發啟動與停止關卡

本次只記錄支線，沒有建立正在實作的 Spectra change。未來確定投入時，依 SDD＋TASTE 先建立可行性提案，再決定實作範圍；不要直接從這份研究筆記部署腳本。

若目標要求抵抗已取得管理員及磁碟解鎖憑證的攻擊者，而本機執行機制無法提供所需邊界，應停止該實作方向並重新選型，不能以更多重複腳本或更隱密的路徑取代驗證。工期、人力、授權及預算尚未估算；本支線沒有採購或正式開發承諾。

上線次序

1. 準備：環境、參數、原值、Scope、備援帳號與 PRK 全數記錄。
2. 小組測試：至少覆蓋全新 ADE 與既有 Mac、正常網路與離線、外部改密碼及忘記舊密碼處置。
3. 員工說明：告知開機用「目前 Mac 已同步的密碼」；Google 在其他地方改過後，要在 Self Service+ 完成本機同步。勿向 IT 提供密碼。
4. 分批套用：每批確認描述檔、應用程式與 LDAP 憑證後再觀察登入與同步；只把已通過驗收的組合列為支援基準。
5. 維運接手：指派 Google、Jamf、服務台與資安負責人；設定憑證到期提醒與版本升級重新驗收條件。

必須停止擴大部署的條件

• FileVault 尚未完成、員工無法解鎖、PRK 未託管或備援路徑不可用。
• A→B 更新失敗、更新後 B 無法冷開機解鎖、keychain 持續異常。
• 全新 ADE 錯過 Connect 登入而建立非預期員工帳號。
• 多台 LDAP 驗證失敗、憑證權限／到期問題尚未排除。
• 發現公司其實要求「每次開機即時驗證 Google 或停權即禁止本機登入」，與本方案邊界不符。

回復步驟

1. 保存錯誤階段、時間、版本、有效設定與不含機密的日誌；保留裝置可用的管理工作階段。
2. 將受影響測試 Scope 恢復為部署前的原描述檔與原值，不要假設全部改為 DenyLocal=true 就是正確回復。
3. 不關閉 FileVault、不刪除員工帳號、不移除 secure token、不以刪除 keychain 當成第一線修復。
4. 恢復連線／原應用程式設定後，驗證登入、PRK 可用性與雲端服務。
5. 若已成功把本機密碼由 A 改為 B，恢復 profile 不會把密碼自動改回 A。記錄當前可用密碼狀態，必要時由員工依核准流程再次變更。
6. 若回復涉及 FileVault escrow profile，確認最新 PRK 已託管；macOS 26+ 可能因該 profile 變更而輪替，不能假設舊 PRK 仍有效。J26
7. 找出原因、更新本手冊、重新跑失敗案例及受影響的冷開機流程，再評估恢復部署。

全部初始狀態均為 未測。建議使用測試帳號；測試 B/A 時不可在紀錄中填入真實密碼。預期結果是本方案設計，不代表已在公司環境證實。

測試記錄至少包含：執行人、時間、裝置代碼、OS build、App 版本、profile 版本、前提、實際結果、證據連結與缺陷編號。正式上線需由公司流程指定的人員確認；本網站不代替公司變更管理系統。

每次交機

• 確認 FileVault 已完成、員工可解鎖、PRK 託管、應用程式與同步功能已初始化。
• 完成一次正常冷開機及一次即時網路檢查；告知員工外部 Google 改密碼後要完成本機更新。
• 告知使用者不需把 Google／本機密碼交給 IT，忘記舊密碼時找服務台。

每次重要變更

macOS 大版本、Connect／Self Service+ 版本、Google 密碼／MFA 政策、LDAP 憑證、MDM 密碼政策、ADE PreStage 或登入外掛變動後，重新驗證受影響流程。不要因為「最新版」就跳過測試。

定期追蹤

可使用 Jamf Extension Attributes 收集狀態、版本與最近資料時間，建立服務台追蹤群組。J23 這類庫存會有延遲，且 PasswordCurrent 是使用者層的 App 狀態；不能當成即時 Google 存取控制，也不可只用舊的 true 自動判定合規。

為什麼 Google 已經改密碼，Mac 開機還要舊密碼？

因為此時 FileVault 驗證的是 Mac 已持有的本機憑證。Mac 尚未完成 A→B 更新，A 仍是本機有效密碼。進桌面後完成同步，再以 B 驗收冷開機。J01 J03

「一次密碼」是不是犧牲 FileVault？

FileVault 仍開啟，使用者仍必須先解鎖。改變的是解鎖後直接接續登入，不再增加第二次 Jamf Google 登入要求；也因此這次開機沒有即時 Google／MFA 驗證。J01

能不能不問使用者，直接強制同步？

可以觸發檢查、開啟登入視窗、保留登入提示，但 Google 不會讓 App 直接取回新密碼。正常更新仍需要新網路憑證及本機舊密碼授權；忘記舊密碼則是復原流程。J02 J03 J05 J20

LDAP 有憑證，還需要使用者密碼嗎？

憑證建立 LDAP client 的安全連線與存取資格；使用者驗證仍是另一件事。不能把 client 憑證當成員工 Google MFA 或密碼。G02 J02

開啟 RequireSignIn 就能讓他不同步不能工作嗎？

官方只承諾登入視窗在成功驗證前不顯示關閉／最小化。它沒有承諾整個桌面被封鎖，也不能把驗證視窗的行為擴大成同步必定完成。J05

15 分鐘檢查，是否最多 15 分鐘就改好了？

不是。Mac 必須有網路、App 正常、LDAP 可用；發現問題後仍需使用者完成更新。檢查週期、通知週期與完成同步時間是三件事。J03 J04

Mac 被偷，我改 Google 密碼就可以了嗎？

不能把它當成已封鎖該 Mac。本方案允許本機登入，離線裝置無法立即知道 Google 變更。需要按公司事件流程處理 Google 帳號／工作階段及 MDM 裝置控制，且確認命令是否送達。G04

若假設失竊後永久不再連網，遠端 MDM 命令不能作為這個情境的解法。第 10 節 OFFLINE-01 已記錄預先部署、本機逾時限制及 IT 離線復原的獨立開發方向；尚未實作，不代表目前已有防護。

成功改密碼後，鑰匙圈一定完全沒問題嗎？

正常使用已知舊密碼變更與忘記密碼後的管理員重設是不同流程。本手冊不承諾所有重設都保留舊 login keychain；若需要重建，按 Apple 復原說明處理並事先告知使用者。A03

未來可以切成每次開機都 Google MFA 嗎？

可以另行評估強制 Google 網路登入，但在現有 Jamf 流程通常恢復 FileVault 與 Google 兩個階段，也不等於 Google 遠端變更立即作廢離線磁碟憑證。PSSO 與 Google 第三方橋接的選型見第 03 節；Xpsso 已有產品文件，但不能只改通用 MDM 鍵就宣稱 FileVault／MFA 已完成整合。J01 A04 X01

查核日：2026-09-22。以下連結為可更新的官方文件，日後內容或 UI 可能變動。關鍵設定需依公司實際部署版本再次比對。手冊已將可確認的產品行為、建議設定值及未實測結果分開標示。

文件變更紀錄

維護人／Google 管理員／Jamf 管理員／驗收負責人：由公司填入受控交接記錄。本手冊是操作與驗收基準，不代表已修改或完成測試機設定。