Hyper-V の接続に関する問題のトラブルシューティング

用語集

BigFix Inventory と Hyper-V との接続は、Windows Management Instrumentation (WMI) の照会によって確立されます。これらの照会では、DCE-RPC メカニズム経由の PowerShell、SOAP を使用する WinRM、または HTTP プロトコル経由の XML が使用されます。BigFix Inventory クライアントは、VM マネージャー・インターフェースと VM マネージャー・ツールを使用して Hyper-V ホストとの通信を行います。以下のリストで、仮想環境の基本的なコンポーネントについて説明します。

サーバー: WinRM サービスが存在する Hyper-V ホスト。
クライアント: BigFix Inventory のホスト。Windows コンピューターにすることも、Unix コンピューターにすることもできます。

Windows システムと Unix システムの両方のクライアント認証で、同じ認証シーケンス ( NTLM、NTLMV2、または HTTP Basic) が使用されます。通信インターフェースとして PowerShell を使用する場合は、Windows ドメインのメンバーに対して Kerberos ネットワーク認証が実行されます。

複数の Hyper-V VM マネージャー接続のトラブルシューティング

WinRM インターフェースで構成されている Hyper-V VM マネージャー接続が多数ある場合、VM Manager tool は複数のスレッドで同時に接続を正しく確立できない可能性があります。この場合は、vmm_thread_pool_size パラメーターを 1 に設定して、接続スレッドの数を少なくする必要があります。また、VM マネージャー・ツールをさらに追加して、それらに負荷を分散することも検討してください。

手動による Hyper-V のトラブルシューティング

hyperv_precheck.wsf スクリプトを使用して Hyper-V の問題を診断しても満足のいく結果を得られなかった場合は、手動によるトラブルシューティングを続行します。

WinRm サービスが稼働しているかどうかを確認します。コマンド・プロンプトで以下のコマンドを実行します。
```
sc query WinRM
```
この照会コマンドの結果として、以下の情報が表示されます。
```
SERVICE_NAME: WinRM
STATE       : 4  RUNNING
```
注: Windows ユーザー・アカウント制御 (UAC) により、WinRM サービスへのユーザー・アクセスが影響を受ける場合があります。Negotiate 認証スキームを使用する場合は、管理者アカウントのみが WinRM サービスにアクセスできます。すべてのアカウントが WinRM サービスにアクセスできるようにするには、以下のレジストリー値を設定します。
```
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\
LocalAccountTokenFilterPolicy to '1'
```
コマンド・プロンプトを使用して、WinRM 構成プロパティーを検証します。
1. Hyper-V サーバーで以下のコマンドを実行します。
  - winrm get winrm/config/service
  - winrm enumerate winrm/config/listener
2. 以下のコマンドをクライアントで実行します。
  - winrm get winrm/config/client
  注: Hyper-V と BigFix Inventory が同じホストにインストールされている場合、以下のコマンドのみを使用して、必要な情報を得ることができます。winrm get winrm/config.
WinRM 設定の一部を変更して、単純なテスト・ケースを作成します。
1. BigFix Inventory サーバーで、Trustedhosts リストにアスタリスクを追加します。
```
winrm set winrm/config/client @{TrustedHosts="*"}
```
  TrustedHosts="*" と指定すると、クライアントはリモート側での認証を中止します。ただし、リモート側でのクライアント認証は引き続き実行する必要があります。通常は、クライアント上で、Hyper-V サーバー名に対して TrustedHost を設定します。
2. Hyper-V サーバー上で、基本認証と暗号化されていないトラフィックを許可します。
```
winrm set winrm/config/service/auth @{Basic="true"}
winrm set winrm/config/service @{AllowUnencrypted="true"}
```
  Basic="true" と指定すると、平文によるユーザーとパスワードを使用する HTTP Basic 認証が有効になります。AllowUnencrypted= true と指定すると、HTTP 経由で、暗号化されていないデータをサーバーとクライアントとの間で転送できます。
3. WinRM 構成の設定を確認します。
```
'winrm get winrm/config/client':
Client:
        NetworkDelayms = 5000
        URLPrefix = wsman
        AllowUnencrypted = true
        Auth
            Basic = true
            Digest = true
            Kerberos = true
            Negotiate = true
            Certificate = true
            CredSSP = false
        DefaultPorts
            HTTP = 5985
            HTTPS = 5986
        TrustedHosts = *
 
'winrm get winrm/config/service' on the Hyper-V server:
Service:
    RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;S-1-5-21-3273298017-2363932476
    -3643925056-1633)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)
    MaxConcurrentOperations = 4294967295
    MaxConcurrentOperationsPerUser = 15
    EnumerationTimeoutms = 600000
    MaxConnections = 15
    MaxPacketRetrievalTimeSeconds = 120
    AllowUnencrypted = true
    Auth
        Basic = true
        Kerberos = true
        Negotiate = true
        Certificate = true
        CredSSP = false
        CbtHardeningLevel = Relaxed
    DefaultPorts
        HTTP = 5985
        HTTPS = 5986
    IPv4Filter = *
    IPv6Filter = *
    EnableCompatibilityHttpListener = true
    EnableCompatibilityHttpsListener = true
    CertificateThumbprint
```
  以前に Basic = true を変更することによって認証に関する問題が解決した場合は、明らかにクライアントとサーバーとの間で認証プロトコルをネゴシエーションできない状態になっています。HTTPS を使用して WinRM が設定されていない場合は、Basic 認証スキームを使用することはお勧めしません。ユーザー名、パスワード、メッセージ本文を平文で送信すると、セキュリティー情報が漏えいする可能性があります。Microsoft は、以下の 3 つのプロトコルを Negotiate スキームで使用します: Kerberos、NTLMV2、NTLM。クライアントとサーバーは通常、その両方にとって最適な認証メカニズムを選択します。BigFix Inventory で Kerberos プロトコルを使用することはできません。クライアントとサーバーで NTLMV2 プロトコルまたは NTLM プロトコルを使用できるかどうかを確認するには、以下のレジストリー照会を使用します。
```
reg query HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\LSA\MSV1_0
```
  このレジストリー・キーで使用される以下のパラメーターにより、認証スキーマの動作が制御されます。
  - NtlmMinClientSec
  - NtlmMinServerSec
  これらのパラメーターは、適切なグループ・ポリシー(「コンピューターの構成」 > 「Windows 設定」 > 「ローカルポリシー」 > 「セキュリティオプション: LAN Manager 認証レベル」) で変更することもできます。
リモート・ホスト上の WinRM サービスに対する適切な認証メカニズムを手動で特定するには、以下のコマンドを使用します。
- Windows PowerShell で、以下のコマンドを実行します。
```
Test-WSMan -ComputerName http://<Hyper-V_server_name>:<port> 
-Auth <authentification_scheme> -Cred <user_id>
```
  各部の意味は以下のとおりです。
  
  <Hyper-V_server_name>
  
  Hyper-V サーバーのホスト名。HTTPS を使用している場合、ホスト名は、証明書の CN に一致する必要があります。
  
  <port>
  
  HTTP トランスポートまたは HTTPS トランスポート用の Windows リモート管理クライアントが listen するポート番号。
  
  <authentification_scheme>
  
  認証スキーム(Basic または Negotiate)
  
  <user_id>
  
  Windows PowerShell に対するユーザー ID。
- コマンド・プロンプトで、以下のコマンドを実行します。
```
winrm identify -r:http://<Hyper-V_server_name>:<port> 
-auth <authentification_scheme> -u:<user_id> -p:<password>
```
  各部の意味は以下のとおりです。
- <Hyper-V_server_name>
  
  Hyper-V サーバーのホスト名。HTTPS を使用している場合、ホスト名は、証明書の CN に一致する必要があります。
  
  <port>
  
  HTTP トランスポートまたは HTTPS トランスポート用の Windows リモート管理クライアントが listen するポート番号。
  
  <authentification_scheme>
  
  認証スキーム(Basic または Negotiate)。
  
  <user_id>
  
  WinRM に対するユーザー ID。
  
  <password>
  
  WinRM に対するパスワード。

イベントのトレース

BigFix Inventory が Hyper-V ホストに接続できない場合は、カスタムの Windows Event Tracing を使用します。クライアントとサーバーの設定が矛盾している場合は、セキュリティー・イベント・ログに以下のメッセージが記録されます:Unknown user name or bad password. この場合、サポートされていない認証プロトコルが実際の問題であるかどうかを判断することはできません。Windows Event Tracing は、WMI 照会と WinRM 照会に関する診断データを取得します。

Hyper-V サーバー上で Event Tracing を開始するには、以下のコマンドを使用します。
- logman.exe start winrmtrace -p Microsoft-Windows-Winrm -o winrmtrace.etl -ets
- logman.exe start wmitrace -p Microsoft-Windows-WMI-Activity -o wmitrace.etl -ets
VM マネージャーの接続テストを実行します。
- vmman.bat -testconnection
- vmman.sh -testconnection

フォーマット設定された WinRM イベント・トレース・ログ・ファイルの winrmtrace.etl には、ユーザー認証に関する問題の情報が記録されます。

<Task>User authentication </Task>
<Message>Sending HTTP 401 response to the client and disconnect the connection after
 sending the response</Message>

このファイルには、SOAP、またはクライアントから送信された XML 照会も記録されるため、Hyper-V に関する問題のトラブルシューティングに役立つ重要なデータを確認することができます。

Wireshark を使用した Hyper-V の接続状態のトラブルシューティング

注:

GUI を使用しない環境における Unix 上のネットワーク・トラフィック・ストリームを分析するには、tcpdump コマンドを使用します。すべてのトラフィックを外部のファイルにダンプするには、tcpdump -vvv -XX -w tcpdump.out を使用します。Wireshark を使用すると、tcpdump.out ファイルを表示できます。

PowerShell インターフェースを使用して、BigFix Inventory と Hyper-V との接続テストが成功した場合

パラメーター:

vmman.bat -testconnection
vmman.sh -testconnection

vmm_communication_interface=POWERSHELL

PowerShell は、NTLM 認証プロトコルを使用します。この画面は、Hyper-V 接続の詳細情報が表示されている Wireshark コンソールを示しています。

これは、WinRM ポート(5985 および 80) には接続しません。代わりに、DCE-RPC メカニズムを使用して、ポート 135 経由で Endpoint Mapper サービスに接続します。

RemoteCreateInstance response 項目を選択します。
認証処理が正常に完了したかどうかを確認するには、上記のパラメーターを展開して HResult の値を確認します。認証が正常に完了した場合は、以下のように HResult に S_OK というマークが付きます。

PowerShell v2 では、ネゴシエーション用として NTLMv1 がデフォルトで使用されます。NTLM を更新するには、以下のレジストリー設定を使用します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\LMCompatibilityLevel

詳しくは、こちらを参照してください: 「NTLM 2 認証を有効にする方法」。

NTLM インターフェースを使用して、BigFix Inventory と Hyper-V との接続テストが失敗した場合

パラメーター:

```
vmm_communication_interface=NTLM
```
```
vmm_url=http://.../wsman
```
デフォルト・ポート: 80

接続テストが失敗すると、以下のエラー・メッセージが config_file.log ファイルに記録されます。

(...)com.ibm.license.mgmt.vmmanager.hyperv.net.HttpConnector::send::
An error occured while trying to send request to http://.../wsman

(...)com.ibm.license.mgmt.vmmanager.hyperv.net.HttpConnector::send:java.net.
ConnectException: Connection refused: connect

trace.log ファイルと config_file.log ファイルに記録されたエラーで詳細な情報を確認することはできませんが、Wireshark のキャプチャーを表示すると、この問題は TCP に関連していることがわかります。ポート 80 のリスナーを確認するには、以下のコマンドを使用します。

winrm enumerate winrm/config/listener

リスナーが検出されなかった場合は、以下のコマンドを実行してリスナーをセットアップします。

winrm set winrm/config/service @{EnableCompatibilityHttpListener="true"}

注: ポート 80 でリスナーをセットアップすると、このコンピューター上の他の HHTP サービスと競合する場合があります。この問題を回避するには、vmm_url 接続ストリングで専用の WinRM ポート (5985 や 5986 など) を指定します。

NTLM インターフェースを使用して、BigFix Inventory と Hyper-V との接続テストが失敗した場合。HTTP Error 401。

接続テストが失敗すると、以下のエラー・メッセージが config_file.log に記録されます。
```
(...)com.ibm.license.mgmt.vmmanager.hyperv.net.HttpConnector::retrieve::
Response Code is: 401
```
```
(...)com.ibm.license.mgmt.vmmanager.hyperv.net.HttpConnector::retrieve::
The following response code was returned while connecting to VM Manager 
http://.../wsman: responseCode = 401
```
以下の Wireshark キャプチャーは、NTLM ネゴシエーションのリストを示しています。最初の 4 行は、成功した NTLM ネゴシエーションを示しています。4 行目のネゴシエーションで、「4 方向の NTLM ハンドシェーク」と呼ばれるハンドシェークが終了しています。最後の行 (HTTP Error 401: Unauthorized) が検出され、以下の HTTP 応答に展開されます。
WWW-Authenticate: Negotiate 応答は、サーバーが NTLM、NTLMV2、または HTTP 基本認証スキームを使用する準備ができていることを示します。ただし、ネゴシエーション・シーケンスに対して、既にサーバーから正常な応答が返されています。AllowUnencrypted = true になっていることを確認してください。
注: VM マネージャーでは、HTTP 本文を暗号化することはできません。WinRM で許可されるのは、Negotiate で暗号化された HTTP 本文、または Kerberos プロトコルだけです。
以下の Wireshark キャプチャーは、失敗した NTLM ネゴシエーション・ハンドシェークを示しています。4 方向の NTLM ハンドシェークが 401 エラーで終了しています。このエラーの最も一般的な原因は、十分なアクセス権限が設定されていないということです。管理者グループに割り当てられているアカウントを使用して WinRM にアクセスできるかどうかを確認するには、以下の Windows レジストリー・エントリーを構成します。
```
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\
System\LocalAccountTokenFilterPolicy
```

vmm_login というドメイン・プレフィックスの解釈に関するバグが原因で、BigFix Inventory と Hyper-V との接続テストが失敗した場合。

VM マネージャーを BigFix Inventory に追加する場合は、必ず、以下のいずれかの形式で管理者ユーザー名を指定してください。

user_name@domain、例: test@cluster.com
user_name\domain、例: test\cluster.com

アプリケーション更新 9.2.16 以降、管理者ユーザー名を以下のいずれかの形式で指定することもできます。

domain@user_name、例: cluster.com@test
domain\user_name、例: cluster.com\test

注: サーバーだけでなく、VM マネージャー・ツールもバージョン 9.2.16 にアップグレードしてください。

このパターンに従わず、正しくない形式でユーザー名を指定すると、VM マネージャーの認証時にエラーが発生します。この画面は、ドメインの認証エラーを含む Wireshark キャプチャーを示しています。

このエラーが発生した場合は、正しくないフィールドにユーザー名が割り当てられています。