Windows コンテナーの gMSA のトラブルシューティング

  • [アーティクル]

適用対象: 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 で断続的な障害が発生する

すべてのコンテナーで同じホスト名を使用する必要があるため、2 つ目の問題は、Windows Server 2019 より前のバージョンの Windows および Windows 10 バージョン 1809 に影響します。 複数のコンテナーに同じ ID とホスト名が割り当てられている場合、同時に 2 つのコンテナーが同じドメイン コントローラーと通信すると、競合状態が発生することがあります。 別のコンテナーが同じドメイン コントローラーと通信すると、同じ ID を使用している以前のコンテナーとの通信は取り消されます。 これにより、断続的な認証エラーが発生する可能性があります。また、コンテナー内で nltest /sc_verify:contoso.com を実行すると、信頼エラーとして確認されることがあります。

Windows Server 2019 の動作を変更して、コンテナー ID をマシン名から分離し、複数のコンテナーが同じ gMSA を同時に使用できるようにしました。 したがって、Windows Server 2019 で、同じホスト上でも複数のホスト上でも、同じ ID を使って複数のコンテナーを実行できます。

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 を使用できることを確認する

  1. ホストがドメインに参加していて、ドメイン コントローラーに到達できることを確認します。

  2. RSAT から AD PowerShell Tools をインストールし、Test-ADServiceAccount を実行して、コンピューターに gMSA を取得するためのアクセス権があるかどうかを確認します。 コマンドレットから 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

  3. 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

  4. gMSA のパスワードを取得できるセキュリティ グループにホストが属していても、Test-ADServiceAccount が失敗する場合は、必要に応じて、コンピューターを再起動し、現在のグループ メンバーシップを反映する新しいチケットを取得します。

ドメインに参加していないホスト: gMSA アカウントを取得するようにホストが構成されていることを確認する

ドメインに参加していないコンテナー ホストを持つ gMSA を使用するためのプラグインが、ホストに適切にインストールされていることを確認します。 Windows には組み込みのプラグインが含まれていないため、ICcgDomainAuthCredentials インターフェイスを実装するプラグインを指定する必要があります。 インストールの詳細はプラグインに固有です。

資格情報の指定ファイルを確認する

  1. CredentialSpec PowerShell モジュールから Get-CredentialSpec を実行して、マシン上のすべての資格情報の指定を特定します。 資格情報の指定は、Docker ルート ディレクトリ以下の "CredentialSpecs" ディレクトリに格納する必要があります。 docker info -f "{{.DockerRootDir}}" を実行すると、Docker ルート ディレクトリを見つけることができます。

  2. CredentialSpec ファイルを開き、次のフィールドが正しく入力されていることを確認します。

    1. ドメインに参加しているコンテナー ホストの場合:

      • Sid: ドメインの SID
      • MachineAccountName: gMSA SAM アカウント名 (完全なドメイン名やドル記号は含めないでください)
      • DnsTreeName: Active Directory フォレストの FQDN
      • DnsName: gMSA が属するドメインの FQDN
      • NetBiosName:gMSA が属するドメインの NETBIOS 名
      • GroupManagedServiceAccounts/Name: gMSA SAM アカウント名 (完全なドメイン名やドル記号は含めないでください)
      • GroupManagedServiceAccounts/Scope: ドメイン FQDN の 1 つのエントリと NETBIOS の 1 つのエントリ

      入力は、次の完全な資格情報の指定例のようになります。

      {
    "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"
            }
        ]
    }
}

    2. ドメインに参加していないホストの場合: ドメインに参加していないすべてのコンテナー ホスト フィールドに加え、"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>"
        }
    }
}

  3. 資格情報の指定ファイルのパスがオーケストレーション ソリューションに対して正しいことを確認します。 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

コンテナーを確認する

  1. Windows Server 2019 または Windows 10 バージョン 1809 より前のバージョンの Windows を実行している場合、コンテナーのホスト名は gMSA 名と一致する必要があります。 --hostname パラメーターが gMSA の短い名前 (ドメイン コンポーネントなし、たとえば、"webapp01.contoso.com" ではなく "webapp01") と一致していることを確認します。

  2. コンテナーのネットワーク構成をチェックして、gMSA のドメインのドメイン コントローラーをコンテナーで解決してアクセスできることを確認します。 コンテナー内の正しく構成されていない DNS サーバーは、ID の問題の一般的な原因です。

  3. コンテナーで次のコマンドレットを実行して (docker exec または同等のものを使用して)、コンテナーにドメインへの有効な接続があるかどうかを確認します。

    nltest /sc_verify:contoso.com

    gMSA が使用可能であり、ネットワーク接続によってコンテナーがドメインと通信できる場合、信頼性の検証によって NERR_SUCCESS が返されます。 失敗した場合は、ホストとコンテナーのネットワーク構成を確認します。 どちらもドメイン コントローラーと通信できる必要があります。

  4. コンテナーが有効な Kerberos チケット保証チケット (TGT) を取得できるかどうかを確認します。

    klist get <myapp>

    このコマンドを実行すると、"A ticket to krbtgt has been retrieved successfully" (krbtgt へのチケットが正常に取得されました) が返され、チケットの取得に使用されたドメイン コントローラーが一覧表示されます。 TGT を取得できても、前の手順の nltest が失敗する場合は、gMSA アカウントが正しく構成されていない可能性があります。 詳細については、「gMSA アカウントを確認する」を参照してください。

    コンテナー内の TGT を取得できない場合は、DNS またはネットワーク接続に問題がある可能性があります。 コンテナーでドメイン DNS 名を使用してドメイン コントローラーを解決できることと、ドメイン コントローラーがコンテナーからルーティング可能であることを確認します。

  5. gMSA を使用するようにアプリが構成されていることを確認します。 gMSA を使用しても、コンテナー内のユーザー アカウントは変更されません。 そうではなく、他のネットワーク リソースと通信するときに、System アカウントに gMSA が使用されます。 つまり、gMSA ID を利用するには、Network Service または Local System としてアプリを実行する必要があります。

    ヒント

    whoami を実行するか、別のツールを使用してコンテナー内の現在のユーザー コンテキストを識別する場合、gMSA の名前自体は表示されません。 これは、ドメイン ID ではなくローカル ユーザーとして常にコンテナーにサインインするためです。 コンピューター アカウントがネットワーク リソースと通信するときは常に gMSA が使用されるため、アプリを Network Service または Local System として実行する必要があります。

gMSA アカウントを確認する

  1. コンテナーが正しく構成されているように見えても、ユーザーまたは他のサービスがコンテナー化されたアプリに対して自動的に認証できない場合は、gMSA アカウントの SPN を確認します。 クライアントでは、アプリケーションに到達したときの名前で gMSA アカウントが検索されます。 つまり、たとえば、ロード バランサーまたは別の DNS 名を介してクライアントからアプリに接続する場合、gMSA に追加の host SPN が必要になる可能性があります。

  2. ドメインに参加しているコンテナー ホストを持つ gMSA を使用する場合、gMSA とコンテナー ホストが同じ Active Directory ドメインに属していることを確認します。 gMSA が別のドメインに属している場合、コンテナー ホストから gMSA のパスワードを取得できません。

  3. ドメインに gMSA と同じ名前のアカウントが 1 つだけ存在することを確認します。 gMSA オブジェクトの SAM アカウント名にはドル記号 ($) が追加されているため、同じドメイン内で gMSA に "myaccount$" という名前を付け、無関係なユーザー アカウントに "myaccount" という名前を付けることができます。 これにより、ドメイン コントローラーまたはアプリケーションが gMSA を名前で検索する必要がある場合に、問題が発生する可能性があります。 次のコマンドを使用して、似た名前のオブジェクトを AD で検索できます。

    # Replace "GMSANAMEHERE" with your gMSA account name (no trailing dollar sign)
Get-ADObject -Filter 'sAMAccountName -like "GMSANAMEHERE*"'

  4. gMSA アカウントで制約のない委任を有効にしている場合は、UserAccountControl 属性の WORKSTATION_TRUST_ACCOUNT フラグが有効であることを確認します。 アプリで名前を SID に、またはその逆に解決する必要がある場合と同様に、このフラグは、コンテナー内の NETLOGON がドメイン コントローラーと通信するために必要です。 次のコマンドを使用して、フラグが正しく構成されているかどうかを確認できます。

    $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 ログ ファイルに記録され、Applications and Services Logs\Microsoft\Windows\Containers-CCG\Admin のイベント ビューアーで表示できます。このログ ファイルをコンテナー ホストからエクスポートして読み込む場合、コンテナー機能が、ログ ファイルを読み込もうとしているデバイスで有効になっている必要があり、お使いの Windows バージョンで、ドメインに参加していないコンテナー ホストを持つ gMSA の使用がサポートされている必要があります。

イベントと説明

イベント番号 イベント テキスト 説明
1 Container Credential Guard instantiated the plug-in (Container Credential Guard によりプラグインがインスタンス化されました) このイベントは、資格情報の仕様で指定されたプラグインがインストールされたが、読み込めなかったことを示します。 対処は必要ありません。
2 Container Credential Guard fetched gmsa credentials for %1 using plug-in: %2 (Container Credential Guard により %1 の gmsa 資格情報がプラグイン %2 を使用してフェッチされました) これは、gMSA 資格情報が AD から正常にフェッチされたことを示す情報イベントです。 対処は必要ありません。
3 Container Credential Guard failed to parse the credential spec. Error: %1 (Container Credential Guard は資格情報の仕様の解析に失敗しました。エラー: %1) このイベントは、資格情報の仕様に問題があることを示します。 これは、プラグインの GUID が正しくないか、形式の正しくない他のフィールドがある場合に発生する可能性があります。 資格情報の仕様の形式や内容を確認するには、資格情報の仕様に関するトラブルシューティング ガイドをご覧ください。
4 Container Credential Guard failed to instantiate the plug-in: %1. Error: %2 (Container Credential Guard によるプラグイン %1 のインスタンス化が失敗しました。エラー: %2) このイベントは、プラグインを読み込めなかったことを示します。 プラグインがホストに正しくインストールされていたかどうかを確認してください。
6 Container Credential Guard failed to fetch credentials from the plug-in: %1. Error: %2 (Container Credential Guard によるプラグイン %1 からの資格情報のフェッチに失敗しました。エラー: %2) このイベントは、プラグインは読み込まれたが、AD から gMSA パスワードをフェッチするのに必要な資格情報を取得できなかったことを示します。 プラグインへの入力が資格情報の仕様で正しく書式設定されていることと、プラグインによって使用されるシークレット ストアにアクセスするのに必要な権限がコンテナー ホストにあることを確認してください。
7 Container Credential Guard is refetching the credentials using the plug-in: %1 (Container Credential Guard は、プラグイン %1 を使用して資格情報を再フェッチしています) これは情報イベントです。 このイベントは、gMSA パスワードの期限が切れているか、プラグインによってフェッチされた資格情報を使用して更新する必要がある場合に生成されます。
8 Container Credential Guard failed to fetch gmsa credentials for %1 using plugin %2. Error reason: %3 (Container Credential Guard によるプラグイン %2 を使用した %1 の gmsa 資格情報のフェッチに失敗しました。エラーの理由: %3) このイベントは、プラグインを使用してフェッチされた資格情報を使用して、AD から gMSA 資格情報をフェッチできなかったことを示します。 プラグインからフェッチされているアカウントに、AD で gMSA 資格情報を取得するためのアクセス許可があることを確認してください。