委派受控服務帳戶概觀

Windows Server 2025 導入了名為「委派受控服務帳戶」(dMSA) 的新帳戶類型，可從傳統服務帳戶移轉為使用受控且完全隨機化金鑰的電腦帳戶。 dMSA 的驗證會連結至裝置身分識別，這表示，僅限在 Active Directory (AD) 中對應的指定電腦身分識別可存取帳戶。 使用 dMSA 有助於避免以遭到入侵帳戶收集認證 (kerberoasting)，而該手法也是傳統服務帳戶的常見問題之一。

比較 dMSA 和 gMSA

dMSA 和 gMSA 是兩種不同類型的受控服務帳戶，兩者皆可用來在 Windows Server 中執行服務和應用程式。 dMSA 會受系統管理員管理，並用來在特定伺服器上執行服務或應用程式。 gMSA 則會由 AD 管理，並用來在多部伺服器上執行服務或應用程式。 兩者皆有助於提高安全性，並簡化密碼管理。 dMSA 的不同之處在於：

• 利用 gMSA 概念來限制使用範圍，使用 Credential Guard （CG） 來系結計算機驗證。
• CG 可用來自動輪替密碼並繫結所有服務帳戶票證，藉此強化 dMSA 中的安全性。 隨後則會停用舊版帳戶，以進一步提高安全性。
• 雖然 gMSA 會受到機器產生的和自動路由密碼保護，但密碼仍然不會受到機器系結，而且可能會遭竊。

dMSA 的功能

dMSA 可供使用者建立為獨立帳戶，或取代現有的標準服務帳戶。 當 dMSA 取代現有帳戶時，使用現有帳戶密碼對其進行驗證的機制就會遭到封鎖。 要求會被重新導向至 本地安全機構（LSA）以使用 dMSA 進行驗證，而 dMSA 可以存取先前帳戶在 AD 中可以存取的所有資源。

在移轉期間，dMSA 會自動了解使用服務帳戶的裝置，隨後則會使用該裝置來移動所有現有服務帳戶。

dMSA 會使用網域控制器 (DC) 持有以加密票證的隨機化密碼 (自電腦帳戶認證衍生而來)。 該密碼可透過啟用 CG 來提供進一步的保護。 雖然在 gMSA 等 Epoch 上，dMSA 使用的密碼會定期更新，主要差異在於：dMSA 的密碼無法在 DC 以外的任何位置擷取或找到。

dMSA 的移轉流程

若快速檢視 dMSA 的移轉流程概念，即可發現當中涉及以下步驟：

1. 可設定 CG 原則，以保護電腦身分識別。
2. 系統管理員開始並完成服務帳戶的移轉作業。
3. 服務帳戶重新整理票證授權票證 (TGT)。
4. 服務帳戶新增電腦身分識別，以允許原則。
5. 原始服務帳戶遭到停用。

移轉 dMSA 時，請留意下列事項：

• 您無法從受控服務帳戶或 gMSA 移轉至 dMSA。
• 修改安全性描述元 (SD) 後，至少需等候兩個票證存留期 (等同 14 天)，才能完成 dMSA 移轉。 建議將服務保持 在啟動 狀態四個票證存留期 （28 天）。 如果您的 DC 進行分割或複寫在上線期間中斷，請延遲移轉。
• 請注意複寫延遲時間長於預設票證續約時間 10 小時的站台。 每次票證更新時，以及每次原始服務帳戶在「開始移轉」狀態期間登入時，都會檢查和更新 groupMSAMembership 屬性，這會將電腦帳戶新增至 dMSA 的 groupMSAMembership 。
  • 舉例來說，有兩個網站使用相同的服務帳戶，而每個網站的複寫週期會超過每個票證存留期所規定的 10 小時。 在這個情況下，群組成員資格就會在初始複寫週期內遺失。
• 移轉需存取讀寫網域控制站 (RWDC)，以查詢和修改 SD。
• 如果舊的服務帳號原先會使用該存取讀寫網域控制站，在移轉完成後，不受限制的委派就會停止運作。 如果您使用受 CG 保護的 dMSA，不受限制的委派就會停止運作。 若要深入瞭解，請參閱 使用 Credential Guard 時的考慮和已知問題。

Warning

如果要移轉至 dMSA，就必須更新使用服務帳戶的所有電腦，以支援 dMSA。 如果這不是真的，不支援 dMSA 的計算機在移轉過程中帳戶被停用時使用現有的服務帳戶進行驗證將失敗。

dMSA 的帳戶屬性

本節將說明 AD 結構描述中的 dMSA 屬性如何變更。 這些屬性可透過使用 [Active Directory 使用者及電腦] 嵌入式管理單元，或在 DC 上執行 [ADSI 編輯器] 等方式檢視。

Note

為帳戶設定的數值屬性表示：

• 1 - 帳戶遷移已開始。
• 2 - 帳戶遷移已完成。

執行 Start-ADServiceAccountMigration 會執行下列變更：

• 服務帳戶會授與 dMSA 上所有屬性的一般讀取
• 服務帳戶會授與 msDS-groupMSAMembership 的 [寫入屬性]
• msDS-DelegatedMSAState 已變更為 1
• msDS-ManagedAccountPrecededByLink 設定為服務帳戶
• msDS-SupersededAccountState 變更為 1
• msDS-SupersededManagedServiceAccountLink 會設定為 dMSA

執行 Complete-ADServiceAccountMigration 會執行下列變更：

• 服務帳戶會從 dMSA 上所有屬性的 一般讀取 中移除
• 服務帳戶會從 msDS-GroupMSAMembership 屬性的 [寫入] 屬性中移除
• msDS-DelegatedMSAState 設定為 2
• 服務主體名稱 (SPNs) 已從服務帳戶複製至 dMSA 帳戶
• 如果適用，則會複製 msDS-AllowedToDelegateTo
• msDS-AllowedToActOnBehalfOfOtherIdentity 如果適用，會複製安全性描述元
• 服務帳戶的指派 AuthN 原則 msDS-AssignedAuthnPolicy 會複製到
• dMSA 已新增至服務帳戶為隸屬成員的任何 AuthN 原則定址接收器
• 受信任的「委派驗證」使用者帳戶控制 (UAC) 位元已複製 (如果已在服務帳戶上設定)
• msDS-SupersededServiceAccountState 設定為 2
• 服務帳戶已透過 UAC 停用位元停用
• SPNs 已從帳戶中移除

dMSA 領域

領域可作為定義驗證邊界的邏輯分組，通常在跨網域或樹系整合不同版本的 AD 時使用。 它們在混合域環境中尤其重要，其中某些網域可能無法完全支援 dMSA 的所有功能。 透過指定領域，dMSA 可以確保網域之間正確進行通訊和驗證流程。

管理員可以使用領域來指定哪些網域或目錄元件可以驗證和存取 dMSA 帳戶。 這可確保即使是較舊的子網域 (可能本身不支援 dMSA 功能) 也可以與帳戶互動，同時維護安全性邊界。 領域有助於在混合環境中順暢轉換和功能共存，確保網域之間的相容性，同時在啟用時維持強式安全性。

例如，如果您有一個在 Windows Server 2025 上執行，名為 corp.contoso.com 的主網域，和一個在 Windows Server 2022 上執行，名為 legacy.corp.contoso.com 的舊子網域，則可以將領域指定為 legacy.corp.contoso.com。

若要為您的環境編輯此群組原則設定，請瀏覽至以下路徑：

計算機設定\系統管理範本\系統\Kerberos\啟用委派的受控服務帳戶登入

另請參閱

設定委派的受控服務帳戶