針對適用於 Windows 容器的 gMSA 進行故障排除

發行項
01/27/2025

適用於：Windows Server 2025、Windows Server 2022、Windows Server 2019

已知問題

容器主機名必須符合 Windows Server 2016 和 Windows 10 版本 1709 和 1803 的 gMSA 名稱

如果您執行 Windows Server 2016 版本 1709 或 1803，容器的主機名必須符合您的 gMSA SAM 帳戶名稱。

當主機名與 gMSA 名稱不匹配時，入站 NTLM 驗證請求及名稱/SID 轉譯（由許多函式庫使用，例如 ASP.NET 成員資格角色提供者）將會失敗。即使主機名和 gMSA 名稱不相符，Kerberos 仍會正常運作。

此限制已在 Windows Server 2019 中修正，不論指派的主機名為何，容器現在一律會在網路上使用其 gMSA 名稱。

在 Windows Server 2016 和 Windows 10 版本 1709 和 1803 上同時使用具有多個容器的 gMSA 會導致間歇性失敗

由於所有容器都必須使用相同的主機名，第二個問題會影響 Windows Server 2019 和 Windows 10 版本 1809 之前的 Windows 版本。當多個容器指派相同的身分識別和主機名時，當兩個容器同時與相同的域控制器通訊時，可能會發生競爭狀況。當另一個容器與相同的域控制器交談時，它會取消與任何使用相同身分識別之先前容器的通訊。這可能會導致間歇性驗證失敗，有時當您在容器內執行 nltest /sc_verify:contoso.com 時，可能會被視為信任失敗。

我們已變更 Windows Server 2019 中的行為，將容器身分識別與計算機名稱分開，讓多個容器同時使用相同的 gMSA。因此，在 Windows Server 2019 中，您可以在相同或多部主機上，使用相同的身分識別來執行多個容器。

您無法在 Windows 10 版本 1703、1709 和 1803 上搭配 Hyper-V 隔離容器使用 gMSA

當您嘗試在 Windows 10 和 Windows Server 版本 1703、1709 和 1803 上使用具有 Hyper-V 隔離容器的 gMSA 時，容器初始化將會停止回應或失敗。

Windows Server 2019 和 Windows 10 版本 1809 已修正此錯誤。您也可以在 Windows Server 2016 和 Windows 10 版本 1607 上執行具有 gMSA 的隔離容器 Hyper-V。

一般疑難解答指引

如果您在使用 gMSA 執行容器時遇到錯誤，下列指示可協助您找出根本原因。

已加入網域的主機：請確定主機可以使用 gMSA

確認主機已加入網域，並可連線到域控制器。

從 RSAT 安裝 AD PowerShell 工具，然後執行 Test-ADServiceAccount，以查看計算機是否具有擷取 gMSA 的存取權。如果 Cmdlet 傳回 False，則電腦無法存取 gMSA 密碼。

# To install the AD module on Windows Server, run Install-WindowsFeature RSAT-AD-PowerShell
# To install the AD module on Windows 10 version 1809 or later, run Add-WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0'
# To install the AD module on older versions of Windows 10, see https://aka.ms/rsat

Test-ADServiceAccount WebApp01

如果 Test-ADServiceAccount 傳回 False，請確認主機屬於可存取 gMSA 密碼的安全組。

# Get the current computer's group membership
Get-ADComputer $env:computername | Get-ADPrincipalGroupMembership | Select-Object DistinguishedName

# Get the groups allowed to retrieve the gMSA password
# Change "WebApp01" for your own gMSA name
(Get-ADServiceAccount WebApp01 -Properties PrincipalsAllowedToRetrieveManagedPassword).PrincipalsAllowedToRetrieveManagedPassword

如果您的主機屬於授權擷取 gMSA 密碼的安全組，但仍無法 Test-ADServiceAccount，您可能需要重新啟動計算機，以取得反映其目前群組成員資格的新票證。

未加入網域的主機：請確定主機已設定為擷取 gMSA 帳戶

確認在主機上是否已正確安裝可用於未加入網域的容器主機的 gMSA 外掛程式。 Windows 不包含內建外掛程式，因此您必須提供實作 ICcgDomainAuthCredentials 介面的外掛程式，。安裝詳細數據將會是外掛程式特定的。

檢查認證規格檔案

從 CredentialSpec PowerShell 模組執行 Get-CredentialSpec，以找出電腦上的所有認證規格檔。認證規格必須儲存在 Docker 根目錄下的「CredentialSpecs」目錄中。您可以執行 docker info -f "{{.DockerRootDir}}"來尋找 Docker 根目錄。

開啟 CredentialSpec 檔案，並確定已正確填寫下列欄位：

已加入網域的容器主機：

Sid：網域的 SID
MachineAccountName：gMSA SAM 帳戶名稱（不包含完整網域名稱或貨幣符號）
DnsTreeName：Active Directory 樹系的 FQDN
DnsName：gMSA 所屬網域的 FQDN
NetBiosName：gMSA 所屬網域的 NETBIOS 名稱
GroupManagedServiceAccounts/Name：gMSA SAM 帳戶名稱（不包含完整域名或美元符號）
GroupManagedServiceAccounts/Scope：一個條目用於網域 FQDN，一個用於 NETBIOS

您的輸入看起來應該類似下列完整認證規格範例：

{
    "CmsPlugins": [
        "ActiveDirectory"
    ],
    "DomainJoinConfig": {
        "Sid": "S-1-5-21-702590844-1001920913-2680819671",
        "MachineAccountName": "webapp01",
        "Guid": "56d9b66c-d746-4f87-bd26-26760cfdca2e",
        "DnsTreeName": "contoso.com",
        "DnsName": "contoso.com",
        "NetBiosName": "CONTOSO"
    },
    "ActiveDirectoryConfig": {
        "GroupManagedServiceAccounts": [
            {
                "Name": "webapp01",
                "Scope": "contoso.com"
            },
            {
                "Name": "webapp01",
                "Scope": "CONTOSO"
            }
        ]
    }
}

針對未加入網域的主機： 除了所有未加入網域的容器主機字段外，請確定 “HostAccountConfig” 區段已存在，且已正確定義下列欄位。

PortableCcgVersion：這應該設定為 “1”。
PluginGUID：您 ccg.exe 外掛程式的 COM CLSID。這是該外掛程式所特有的。
PluginInput：用于從秘密存放區擷取使用者帳戶資訊的插件特定輸入。

您的輸入看起來應該類似下列完整認證規格範例：

{
    "CmsPlugins": [
    "ActiveDirectory"
    ],
    "DomainJoinConfig": {
        "Sid": "S-1-5-21-702590844-1001920913-2680819671",
        "MachineAccountName": "webapp01",
        "Guid": "56d9b66c-d746-4f87-bd26-26760cfdca2e",
        "DnsTreeName": "contoso.com",
        "DnsName": "contoso.com",
        "NetBiosName": "CONTOSO"
    },
    "ActiveDirectoryConfig": {
        "GroupManagedServiceAccounts": [
            {
                "Name": "webapp01",
                "Scope": "contoso.com"
            },
            {
                "Name": "webapp01",
                "Scope": "CONTOSO"
            }
        ],
        "HostAccountConfig": {
            "PortableCcgVersion": "1",
            "PluginGUID": "{GDMA0342-266A-4D1P-831J-20990E82944F}",
            "PluginInput": "contoso.com:gmsaccg:<password>"
        }
    }
}

確認憑證規範檔案的路徑正確，確保符合您的編排解決方案。如果您正在使用 Docker，請確保容器執行命令包含 --security-opt="credentialspec=file://NAME.json"，其中“NAME.json”會被 Get-CredentialSpec的名稱輸出取代。名稱是一般檔名，位於 Docker 根目錄下的 CredentialSpecs 資料夾中。

檢查網路設定

檢查防火牆設定

如果您在容器或主機網路上使用嚴格的防火牆原則，它可能會封鎖對 Active Directory 域控制器或 DNS 伺服器的必要連線。

通訊協定和埠	目的
TCP 和 UDP 53	網域名稱系統 (DNS)
TCP 和 UDP 88	Kerberos
TCP 139	NetLogon（網路登入）
TCP 和 UDP 389	LDAP
TCP 636	LDAP SSL

視容器傳送至域控制器的流量類型而定，您可能需要允許存取其他埠。如需 Active Directory 所使用的埠完整清單，請參閱 Active Directory 和 Active Directory 網域服務埠需求。

檢查容器主機 DNS 設定

如果您在使用 gMSA 搭配已加入網域的容器主機，則應該在主機上自動配置 DNS，以正確進行 DNS 解析並建立與網域的連線。如果您使用 gMSA 搭配未加入網域的主機，將不會自動設定此設定。您應該確認主機網路已設定，使其可以解析網域。您可以使用下列項目，檢查是否可以從主機解析網域：

nltest /sc_verify:contoso.com

檢查容器

如果您在 Windows Server 2019 或 Windows 10 版本 1809 之前執行 Windows 版本，您的容器主機名必須符合 gMSA 名稱。請確定 --hostname 參數符合 gMSA 簡短名稱（沒有網域元件;例如，“webapp01” 而不是 “webapp01.contoso.com”。
檢查容器網路設定，以確認容器可以解析並存取 gMSA 網域的域控制器。容器中設定錯誤的 DNS 伺服器是身分識別問題的常見罪魁禍首。
在容器中執行下列 cmdlet，檢查容器是否具有有效的連線到網域（使用 docker exec 或等效替代方案）：
```
nltest /sc_verify:contoso.com
```
如果 gMSA 可用，且網路連線可讓容器與網域通訊，信任驗證應該會傳回 NERR_SUCCESS。如果失敗，請確認主機和容器的網路設定。兩者都需要能夠與域控制器通訊。
檢查容器是否可以取得有效的 Kerberos 票證授權票證（TGT）：
```
klist get <myapp>
```
此命令應該會傳回「已成功擷取 krbtgt 的票證」，並列出用來擷取票證的域控制器。如果您能夠取得 TGT，但在上一個步驟中 nltest 失敗，這可能表示 gMSA 帳戶設定錯誤。如需詳細資訊，請參閱檢查 gMSA 帳戶。

如果您無法在容器內取得 TGT，這可能表示 DNS 或網路連線問題。請確定容器能夠使用網域 DNS 名稱解析網域控制器，並且網域控制器可以從容器中被路由到。
確定您的應用程式已設定為使用 gMSA。當您使用 gMSA 時，容器內的用戶帳戶不會變更。相反地，系統帳戶會在與其他網路資源互動時使用 gMSA。這表示您的應用程式必須以網路服務或本機系統的形式執行，才能利用 gMSA 身分識別。

提示

如果您執行 whoami 或使用其他工具來識別容器中的目前用戶內容，則不會看到 gMSA 名稱本身。這是因為您一律以本機使用者身分登入容器，而不是網域身分識別。每當電腦帳戶與網路資源交談時，就會使用 gMSA，這就是為什麼您的應用程式需要以網路服務或本機系統的形式執行。

檢查 gMSA 帳戶

如果您的容器似乎已正確設定，但使用者或其他服務無法自動向容器化應用程式進行驗證，請檢查 gMSA 帳戶上的SPN。用戶端會依其觸達應用程式的名稱找出 gMSA 帳戶。這可能表示，如果用戶端透過負載平衡器或不同的 DNS 名稱連線到您的應用程式，則 gMSA 將需要額外的 host SPN。
若要搭配已加入網域的容器主機使用 gMSA，請確定 gMSA 和容器主機屬於相同的 Active Directory 網域。如果 gMSA 屬於不同的網域，容器主機將無法擷取 gMSA 密碼。
請確定網域中只有一個帳戶與您的 gMSA 同名。 gMSA 物件會將美元符號（$）附加至其 SAM 帳戶名稱，因此在相同的網域中，gMSA 有可能被命名為 "myaccount$"，而同時存在名為 "myaccount" 的不相關用戶帳戶。如果域控制器或應用程式必須依名稱查閱 gMSA，這可能會導致問題。您可以使用下列命令搜尋 Active Directory 中類名相似的物件：
```
# Replace "GMSANAMEHERE" with your gMSA account name (no trailing dollar sign)
Get-ADObject -Filter 'sAMAccountName -like "GMSANAMEHERE*"'
```
如果您已在 gMSA 帳戶上啟用不受限制的委派，請確定 UserAccountControl 屬性仍然已啟用 WORKSTATION_TRUST_ACCOUNT 旗標。容器中的 NETLOGON 需要此旗標才能與域控制器通訊，就像應用程式必須解析名稱為 SID 的情況一樣，反之亦然。您可以使用下列命令來檢查旗標是否已正確設定：
```
$gMSA = Get-ADServiceAccount -Identity 'yourGmsaName' -Properties UserAccountControl
($gMSA.UserAccountControl -band 0x1000) -eq 0x1000
```
如果上述命令傳回 False，請使用下列命令，將 WORKSTATION_TRUST_ACCOUNT 旗標新增至 gMSA 帳戶的 UserAccountControl 屬性。此命令也會從 UserAccountControl 屬性清除 NORMAL_ACCOUNT、INTERDOMAIN_TRUST_ACCOUNT和 SERVER_TRUST_ACCOUNT 旗標。
```
Set-ADObject -Identity $gMSA -Replace @{ userAccountControl = ($gmsa.userAccountControl -band 0x7FFFC5FF) -bor 0x1000 }
```

未加入網域的容器主機：使用事件記錄檔來識別設定問題

搭配未加入網域的容器主機使用 gMSA 的事件記錄可用來識別設定問題。事件會記錄在 Microsoft-Windows-Containers-CCG 記錄檔中，而且可以在 [應用程式和服務記錄檔] 底下的 [事件查看器] 中找到，Microsoft\Windows\Containers-CCG\Admin。如果您將此記錄檔從容器主機匯出至讀取它，您必須在嘗試讀取記錄檔的裝置上啟用容器功能，而且您必須位於支援搭配未加入網域的容器主機使用 gMSA 的 Windows 版本。

事件和描述

事件編號	事件文字	描述
1	容器憑證保護器初始化了外掛程式	此事件表示已安裝認證規格中指定的外掛程式，而且可以載入。不需要採取任何動作。
2	容器憑證保護使用外掛程式擷取適用於 %1 的 gmsa 憑證：%2	這是一個資訊事件，指出 gMSA 凭證已成功從 AD 擷取。不需要採取任何動作。
3	容器 Credential Guard 無法剖析認證規格。錯誤：%1	此事件表示認證規格的問題。如果外掛程式的 GUID 不正確，或有其他格式不正確的欄位，就可能會發生這種情況。請檢閱認證規格的疑難解答指引，以確認認證規格的格式和內容。
4	容器憑證防護無法啟用外掛程式：%1。錯誤：%2	此事件表示無法載入外掛程式。您應該檢查外掛程式是否已正確安裝在主機上
6	容器 Credential Guard 無法從外掛程式擷取認證：%1。錯誤：%2	此事件表示載入外掛程式，但無法擷取從AD擷取 gMSA 密碼所需的認證。您應該在認證規格中確認外掛程式的輸入已正確格式化，而且容器主機具有存取外掛程式所用秘密存放區的必要許可權。
7	容器 Credential Guard 會使用外掛重新取得認證：%1	這是資訊活動。當 gMSA 密碼已過期且需要使用外掛程式所擷取的認證重新整理時，就會產生此事件。
8	容器 Credential Guard 無法使用外掛程式 %2擷取 %1 的 gmsa 認證。錯誤原因：%3	這個事件表示，使用外掛程式擷取的認證無法用來從AD擷取 gMSA 認證。您應該確認從外掛程式擷取的帳戶具有AD中擷取 gMSA 認證的許可權。

共用方式為