使用 gMSA 讓 Windows 排程與服務帳號更安全

前幾天研究 AD FS 有意外收獲，學到好東西 - gMSA，Group Managed Service Account。

Windows 服務或排程必須設定執行身分，若不需用 AD 認證存取遠端資源，可考慮使用 Local System、Local Service與Network Service 等特殊本機帳號，排程則有個「不要儲存密碼。工作將只有本機電腦資源的存取權」，這兩種做法都可減少密碼管理困擾。若服務或排程必須使用 AD 認證，一般要為它們建立專屬 AD 帳號，但密碼該如何保管(紙本封存、拆 A B Part... 粉麻煩)？如何定期變更？如何一次修改數百上千個服務或排程的身分設定？都是棘手問題。

為了解決這類困擾，Windows Server 2008 R2 推出了 Managed Service Account (MSA，或稱 sMSA, s = Standalone)，MSA 為單一主機專屬，無法多主機共用，Windows 2012 再加入 Group Managed Service Account (gMSA)，以應付 Cluster/Load Balance 或多主機備援的應用情境。(登楞! 沒錯，十幾年前就有了，我現在才已知用火)

MSA/gMSA 的特色是密碼由作業系統管理，長度高達 240 Byte (30 字元)，加上高複雜度，被暴力破解可能性趨於零。而系統會每 30 天自動更換密碼，更換動作由作業系統處理，完全不需要人員介入設定。除此之外，帳號可授與權限、加入安全群組，使用上與一般帳號無異，應用方便。

要使用 gMSA，有項前置工作是需在 AD 建立 Key Distribution Service (KDS) Root Key 並部署到全 Forest。Root Key 只需建立一次，指令如下(需 Domain Admins 或 Enterprise Admins 權限)。實務上需等 10 小時正式生效，以等待 AD 複寫同步完全，測試環境單一 DC 則可將時間調到 10 小時前省去等待。參考

Add-KdsRootKey –EffectiveImmediately
# 測試環境
Add-KdsRootKey –EffectiveTime ((Get-Date).AddHours(-10))

要建立 MSA，做法為在目標主機使用 New-ADServiceAccount 建立帳號，再使用 Add-ADComputerServiceAccount 將帳號綁定到目標主機上，每個 MSA 專屬特定主機，不能重複使用。

$identity = New-ADServiceAccount -Name <MSA-AcntName> –RestrictToSingleComputer
Add-ADComputerServiceAccount -Identity $identity -ServiceAccount <MSA-AcntName>

gMSA 也是用 New-ADServiceAccount 建立(登入帳號需為 Domain Admins、Account Operators 成員，或具有建立 msDS-GroupManagedServiceAccount 物件權限)，參數範例如下：參考

New-ADServiceAccount <gMSA-AcntName> -DNSHostName "<gMSA-AcntName>.<domain-fqdn>" -PrincipalsAllowedToRetrieveManagedPassword (<成員主機帳號或成員主機帳號所屬安全群組>,...)
# 若無註冊 SPN 需求，DNSHostName 隨意給
# ManagedPasswordIntervalInDays 參數可指定密碼變更間隔天數，預設 30 天

建立 gMSA 時需列舉哪些主機有權存取該帳號密碼，只有此清單上的主機可以使用。實務上可將 PrincipalsAllowedToRetrieveManagedPassword 設給群組，再將主機的電腦帳號(SAMAccountName 為電腦名稱後方有 $ 號)加入群組，管理上較方便。

若要事後增減主機或群組，可使用 PowerSehll 查詢 PrincipalsAllowedToRetrieveManagedPassword 主機或群組陣列，增減陣列元素再重新設定 ：參考

$hostArray = Get-ADServiceAccount <gMSA-AcntName> -Properties PrincipalsAllowedToRetrieveManagedPassword
$hostArray += "NewHost$"
Set-ADServiceAccount <gMSA-AcntName> -PrincipalsAllowedToRetrieveManagedPassword $hostArray

最後來個實地演練。

我先建一個 gMSA 帳號 (gmsaBatch)，設定 PrincipalsAllowedToRetrieveManagedPassword 時只給 ADDC$ (另一台主機的電腦帳號)，故意不包含排程所在主機 ADFS1$ [1]，用 Get-ADServiceAccount 查詢確認 PrincipalsAllowedToRetrieveManagedPassword 欄位的 ADDC$ 已解析成 Distinguished Name [2]；用 schtasks /change 設定執行身分為 gmsaBatch$ (gMSA 的 SamAccountName)，此時出現 "The user name or password is incorrect"，原因是 ADFS1 主機不在 PrincipalsAllowedToRetrieveManagedPassword 清單 [3]。

用 Set-ADServiceAccount 將 AFS1$ 也加入 PrincipalsAllowedToRetrieveManagedPassword (注意：每次要給完整清單) [4]，再試一次，這回設定成功。

另外，若要將主機移出 PrincipalsAllowedToRetrieveManagedPassword，設過 gMSA 的主機要用 Uninstall-ADServiceAccount 將帳號從快取清除。

依實測，我無法用 GUI 查詢查到 gMSA，目前找到的做法是用 schtasks.exe 或 PowerShell 設定，參考語法：schtasks /change /tn "排程名稱" /ru <gMSA帳號$> /rp "" (密碼給空字串)

學會 MSA/gMSA，管理服務或排程執行帳號就多了一個安全方便的新選擇囉。

Introduction to gMSA and how to use it as a secured solution for scheduled tasks and service.