委派受控服務帳戶概觀
Windows Server 2025 導入了名為「委派受控服務帳戶」(dMSA) 的新帳戶類型,可從傳統服務帳戶移轉為使用受控且完全隨機化金鑰的電腦帳戶。 dMSA 的驗證會連結至裝置身分識別,這表示,僅限在 Active Directory (AD) 中對應的指定電腦身分識別可存取帳戶。 使用 dMSA 有助於避免以遭到入侵帳戶收集認證 (kerberoasting),而該手法也是傳統服務帳戶的常見問題之一。
比較 dMSA 和 gMSA
dMSA 和 gMSA 是兩種不同類型的受控服務帳戶,兩者皆可用來在 Windows Server 中執行服務和應用程式。 dMSA 會受系統管理員管理,並用來在特定伺服器上執行服務或應用程式。 gMSA 則會由 AD 管理,並用來在多部伺服器上執行服務或應用程式。 兩者皆有助於提高安全性,並簡化密碼管理。 dMSA 的不同之處在於:
- 善加利用 gMSA 概念,可透過 Credential Guard 繫結電腦驗證,藉此限制使用範圍。
- CG 可用來自動輪替密碼並繫結所有服務帳戶票證,藉此強化 dMSA 中的安全性。 隨後則會停用舊版帳戶,以進一步提高安全性。
- 雖然 gMSA 會透過電腦產生和自動輪替密碼等機制來確保安全,密碼仍舊不會與電腦繫結,且可能遭到竊取。
dMSA 的功能
dMSA 可供使用者建立為獨立帳戶,或取代現有的標準服務帳戶。 當 dMSA 取代現有帳戶時,使用現有帳戶密碼對其進行驗證的機制就會遭到封鎖。 該要求會重新導向至本機安全性授權 (LSA),以使用 dMSA 進行驗證,而 dMSA 可存取舊帳戶可在 AD 中存取的所有內容。
在移轉期間,dMSA 會自動了解使用服務帳戶的裝置,隨後則會使用該裝置來移動所有現有服務帳戶。
dMSA 會使用網域控制器 (DC) 持有以加密票證的隨機化密碼 (自電腦帳戶認證衍生而來)。 該密碼可透過啟用 CG 來提供進一步的保護。 雖然在 gMSA 等 Epoch 上,dMSA 使用的密碼會定期更新,主要差異在於:dMSA 的密碼無法在 DC 以外的任何位置擷取或找到。
dMSA 的移轉流程
若快速檢視 dMSA 的移轉流程概念,即可發現當中涉及以下步驟:
- 可設定 CG 原則,以保護電腦身分識別。
- 系統管理員開始並完成服務帳戶的移轉作業。
- 服務帳戶重新整理票證授權票證 (TGT)。
- 服務帳戶新增電腦身分識別,以允許原則。
- 原始服務帳戶遭到停用。
移轉 dMSA 時,請留意下列事項:
- 您無法從受控服務帳戶或 gMSA 移轉至 dMSA。
- 修改安全性描述元 (SD) 後,至少需等候兩個票證存留期 (等同 14 天),才能完成 dMSA 移轉。 建議讓服務保持在「開始」狀態達四個票證存留期 (28 天)。 如果您的 DC 進行分割或複寫在上線期間中斷,請延遲移轉。
- 請留意複寫發生延遲,或超過預設票證更新時間 (10 小時) 的網站。 每一次進行票證更新,以及每當原始服務帳戶於「開始移轉」狀態期間登入時,都會檢查和更新 groupMSAMembership 屬性,而此舉會將電腦帳戶新增至 dMSA 的 groupMSAMembership。
- 舉例來說,有兩個網站使用相同的服務帳戶,而每個網站的複寫週期會超過每個票證存留期所規定的 10 小時。 在這個情況下,群組成員資格就會在初始複寫週期內遺失。
- 移轉需存取讀寫網域控制站 (RWDC),以查詢和修改 SD。
- 如果舊的服務帳號原先會使用該存取讀寫網域控制站,在移轉完成後,不受限制的委派就會停止運作。 如果您使用受 CG 保護的 dMSA,不受限制的委派就會停止運作。 若要深入了解,請參閱使用 Credential Guard 時的考量和已知問題。
警告
如果要移轉至 dMSA,就必須更新使用服務帳戶的所有電腦,以支援 dMSA。 若未這麼做,當帳戶在移轉期間遭到停用時,不支援 dMSA 的電腦將無法使用現有服務帳戶進行驗證。
dMSA 的帳戶屬性
本節將說明 AD 結構描述中的 dMSA 屬性如何變更。 這些屬性可透過使用 [Active Directory 使用者及電腦] 嵌入式管理單元,或在 DC 上執行 [ADSI 編輯器] 等方式檢視。
注意
為帳戶設定的數值屬性代表不同的意思:
- 1 - 帳戶移轉已開始。
- 2 - 帳戶移轉已完成。
執行 Start-ADServiceAccountMigration
會執行下列變更:
- 已將 dMSA 上所有屬性的 Generic Read 權限授與服務帳戶
- 已將 msDS-groupMSAMembership 的 Write 屬性授與服務帳戶
- msDS-DelegatedMSAState 已變更為 1
- msDS-ManagedAccountPrecededByLink 已設為服務帳戶
- msDS-SupersededAccountState 已變更為 1
- msDS-SupersedManagedServiceAccountLink 已設為 dMSA
執行 Complete-ADServiceAccountMigration
會執行下列變更:
- 已移除服務帳戶對 dMSA 上所有屬性的 Generic Read 權限
- 已自 msDS-GroupMSAMembership 上的 Write 屬性移除服務帳戶
- 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\啟用委派受控服務帳號登入