針對適用於 Windows 容器的 gMSA 進行疑難排解

發行項
03/18/2023

適用于：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 名稱。

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

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

我們已變更 Windows Server 2019 中的行為，以區分容器身分識別與電腦名稱稱，讓多個容器同時使用相同的 gMSA。因此，在 Windows Server 2019 中，您可以在相同或多個主機上執行多個具有相同身分識別的容器。

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

當您嘗試在 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 Domain Services 連接埠需求。

檢查容器主機 DNS 設定

如果您使用 gMSA 搭配已加入網域的容器主機，則應該在主機上自動設定 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，這可能會造成問題。您可以使用下列命令，在 AD 中搜尋類似名稱的物件：
```
# 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\管理員下的 [事件檢視器中找到。如果您將此記錄檔從容器主機匯出為讀取它，則必須在嘗試讀取記錄檔的裝置上啟用容器功能，而且您必須位於支援搭配未加入網域容器主機使用 gMSA 的 Windows 版本。

事件和描述

事件編號	事件文字	描述
1	容器 Credential Guard 已具現化外掛程式	這個事件表示已安裝認證規格中指定的外掛程式，而且可以載入。不需採取動作。
2	容器認證防護使用外掛程式擷取 %1 的 gmsa 認證： %2	這是一個參考事件，指出 gMSA 認證已成功從 AD 擷取。不需採取動作。
3	容器 Credential Guard 無法剖析認證規格。錯誤： %1	此事件指出認證規格的問題。如果外掛程式的 GUID 不正確，或有其他格式不正確的欄位，就可能會發生這種情況。請檢閱認證規格的疑難排解指引，以確認認證規格的格式和內容。
4	容器 Credential Guard 無法具現化外掛程式： %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 認證。

共用方式為