Traitement des incidents de connexion Hyper-V

Si le script hyperv_precheck.wsf n'est pas parvenu à diagnostiquer de manière satisfaisante les problèmes liés à Hyper-V, corrigez le problème manuellement.

1. Vérifiez si le service WinRm est en cours d'exécution. Exécutez la commande suivante à partir de l'invite de commande :

   sc query WinRM

   Les résultats de la requête doivent inclure les informations suivantes :

   SERVICE_NAME: WinRM
   STATE       : 4  RUNNING
   

   Remarque : Le Contrôle de compte d'utilisateur (UAC) Windows peut affecter l'accès utilisateur au service WinRM. Si vous utilisez le schéma d'authentification Negotiate, seul le compte Administrateur peut accéder au service. Pour permettre à tous les comptes d'accéder au service, définissez la valeur de registre suivante :

   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\
   LocalAccountTokenFilterPolicy to '1'

2. Vérifiez les propriétés de configuration WinRM à l'aide de l'invite de commande :
   1. Exécutez les commandes suivantes sur le serveur Hyper-V :
      • winrm get winrm/config/service
      • winrm enumerate winrm/config/listener
   2. Exécutez les commandes suivantes sur le client :
      • winrm get winrm/config/client
      Remarque : Si Hyper-V et BigFix Inventory sont installés sur le même hôte, vous pouvez utiliser une seule commande pour extraire les informations requises : winrm get winrm/config.
3. Configurez un scénario de test simple en modifiant l'un des paramètres WinRM.
   1. Sur le serveur BigFix Inventory, ajoutez un astérisque à la liste Trustedhosts.

      winrm set winrm/config/client @{TrustedHosts="*"}

      TrustedHosts="*" contraint le client à abandonner l'authentification de l'extrémité distante. Toutefois, l'extrémité distante requiert toujours l'authentification de client. En général TrustedHost correspond au nom du serveur Hyper-V sur le client.
   2. Autorisez l'authentification de base et le trafic non chiffré sur un serveur Hyper-V.

      winrm set winrm/config/service/auth @{Basic="true"}
      winrm set winrm/config/service @{AllowUnencrypted="true"}

      Basic="true" active l'authentification de base HTTP à l'aide d'un ID utilisateur et d'un mot de passe en texte clair. AllowUnencrypted= true permet de transférer les données déchiffrées via HTTP entre le serveur et le client.
   3. Vérifiez la configuration 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
      

      Si la modification précédente Basic = true a résolu le problème d'authentification, le client et le serveur ne peuvent pas négocier le protocole d'authentification. Il est déconseillé d'utiliser le schéma d'authentification de base sauf si WinRM est configuré avec HTTPS. Cette procédure pourrait représenter un risque lié à la sécurité en envoyant un nom d'utilisateur, un mot de passe et le corps du message sous la forme d'un texte en clair. Microsoft utilise trois protocoles lors de la procédure du schéma Negotiate : Kerberos, NTLMV2, et NTLM. Le client et le serveur choisissent généralement les mécanismes d'authentification qui leur conviennent le mieux. BigFix Inventory ne permet pas l'utilisation du protocole Kerberos. Pour vérifier si le client et le serveur autorisent le protocole NTLMV2 ou NTLM, utilisez la requête de registre suivante.

      reg query HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\LSA\MSV1_0

      Les paramètres suivants situés sous cette clé de registre contrôlent le comportement du schéma d'authentification :
      • NtlmMinClientSec
      • NtlmMinServerSec
      Les paramètres peuvent être modifiés via la stratégie de groupe appropriée : Configuration ordinateur > Paramètres Windows > Stratégies locales > Sécurité réseau : niveau d'authentification LAN Manager
4. Pour identifier manuellement le mécanisme d'authentification approprié pour le service WinRM sur l'hôte distant, utilisez les commandes suivantes :
   • Exécutez la commande à partir de Windows PowerShell.

     Test-WSMan -ComputerName http://<Hyper-V_server_name>:<port> 
     -Auth <authentification_scheme> -Cred <user_id>

     Où :

     <Hyper-V_server_name>

     ést le nom d'hôte du serveur Hyper-V. Si vous utilisez HTTPS, le nom d'hôte doit correspondre au nom commun (CN) du certificat.

     <port>

     ést le numéro de port sur lequel le client Windows Remote Management pour le protocole HTTP ou HTTPS écoute.

     <authentification_scheme>

     Correspond au schéma d'authentification : Basic ou Negotiate

     <user_id>

     Correspond à l'ID utilisateur de Windows PowerShell.

   • Exécutez la commande à partir de l'invite de commande.

     winrm identify -r:http://<Hyper-V_server_name>:<port> 
     -auth <authentification_scheme> -u:<user_id> -p:<password>

     Où :

   • <Hyper-V_server_name>

     ést le nom d'hôte du serveur Hyper-V. Si vous utilisez HTTPS, le nom d'hôte doit correspondre au nom commun (CN) du certificat.

     <port>

     ést le numéro de port sur lequel le client Windows Remote Management pour le protocole HTTP ou HTTPS écoute.

     <authentification_scheme>

     Correspond au schéma d'authentification : Basic ou Negotiate.

     <user_id>

     Correspond à l'ID utilisateur de WinRM PowerShell.

     <password>

     Correspond au mot de passe de WinRM.

Si BigFix Inventory ne peut pas se connecter à l'hôte Hyper-V, utilisez la fonction de suivi d'événements Windows personnalisée. Lorsque les paramètres du client et du serveur sont en conflit, le journal des événements de sécurité génère le message d'erreur suivant : Unknown user name or bad password. Vous ne pouvez pas déterminer que le problème réel est lié à des protocoles d'authentification non pris en charge. Le suivi d'événements Windows obtient les données de diagnostic des requêtes WMI et WinRM.

1. Pour lancer le suivi des événements sur le serveur Hyper-V, utilisez les commandes suivantes :
   • 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
2. Exécutez le test de connexion du gestionnaire de machine virtuelle.
   • vmman.bat -testconnection
   • vmman.sh -testconnection

Le fichier journal de suivi d'événements formaté WinRM, winrmtrace.etl, contient des informations sur les problèmes d'authentification utilisateur.

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

Le fichier contient également les requêtes SOAP ou XML qui sont envoyées par le client et qui fournissent des données vitales, particulièrement utiles pour traiter les incidents liés à Hyper-V.

Test de connexion réussi entre BigFix Inventory et Hyper-V avec l'interface PowerShell.

Paramètres :

• vmman.bat -testconnection
• vmman.sh -testconnection

vmm_communication_interface=POWERSHELL

PowerShell utilise le protocole d'authentification NTLM.

Il ne se connecte pas aux ports WinRM : à savoir 5985 et 80, mais utilise un mécanisme DCé-RPC pour se connecter au service Endpoint Mapper via le port 135.

1. Sélectionnez l'entrée RemoteCreateInstance response.
2. Pour vérifier si l'authentification a abouti, développez les paramètres et vérifiez la valeur du paramètre HResult. Si l'authentification a réussi, HResult est accompagné de la mention S_OK.

Par défaut, PowerShell v2 utilise NTLMv1 pour la négociation. Pour mettre à jour NTLM, utilisez le paramètre de registre suivant :

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\LMCompatibilityLevel

Pour plus d'informations, voir : Comment activer l'authentification NTLM 2.

échec du test de connexion entre BigFix Inventory et Hyper-V avec l'interface NTLM.

Paramètres :

• vmm_communication_interface=NTLM

• vmm_url=http://.../wsman

• Le port par défaut : 80

Le test de la connexion a échoué et le fichier config_file.log contient les messages d'erreur suivants :

(...)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

Bien que les erreurs des fichiers trace.log et config_file.log ne fournissent pas suffisamment de détails, la capture de Wireshark démontre que le problème est lié à TCP. Utilisez la commande suivante pour rechercher le programme d'écoute sur le port 80.

winrm enumerate winrm/config/listener

Si aucun programme d'écoute n'est détecté, exécutez la commande suivante pour configurer des programmes d'écoute.

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

Remarque : La configuration des programmes d'écoute du port 80 peut être en conflit avec les autres services HTTP sur l'ordinateur. Pour éviter ces problèmes, indiquez un port WinRM dédié, comme 5985 ou 5986, sur la chaîne de connexion vmm_url.

échec du test de connexion entre BigFix Inventory et Hyper-V avec l'interface NTLM. HTTP Error 401.

1. Le test de la connexion a échoué et le fichier config_file.log contient les messages d'erreur suivants.

   (...)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

   La capture Wireshark suivante répertorie la négociation NTLM.
   
   Les quatre premières lignes indiquent une négociation NTLM réussie. La quatrième ligne arrête l'établissement de liaison NTML à quatre voies. La dernière ligne détecte HTTP Error 401: Unauthorized et aboutit à la réponse HTTP suivante.

   La réponse WWW-Authenticate: Negotiate indique que le serveur est prêt à utiliser le schéma d'authentification de base HTTP, NTLM ou NTLMV2. Toutefois, le serveur a déjà correctement répondu à la séquence de négociation. Veillez à indiquer paramètre WinRM AllowUnencrypted = true.

   Remarque : Les gestionnaires de machine virtuelle n'effectuent pas le chiffrement du corps HTTP. WinRM accepte uniquement le corps HTTP chiffré avec le paramètre Negotiate ou le protocole Kerberos.
2. La capture de Wireshark indique l'échec de l'établissement de liaison pour la négociation NTLM.
   
   L'établissement de liaison NTLM se termine en générant une erreur 401. Cette erreur est généralement due à des droits d'accès insuffisants. Pour vérifier si les comptes affectés au groupe Administrateurs sont autorisés à accéder à WinRM, configurez l'entrée de registre Windows suivante :

   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\
   System\LocalAccountTokenFilterPolicy

échec du test de connexion entre BigFix Inventory et Hyper-V en raison du bogue lié à l'interprétation du préfixe de domaine vmm_login.

Lorsque vous ajoutez un gestionnaire de machine virtuelle à BigFix Inventory, veillez à fournir le nom d'administrateur dans l'un des formats suivants :

• user_name@domain, par exemple : test@cluster.com
• user_name\domain, par exemple : test\cluster.com

A partir de la mise à jour de l'application 9.2.16, vous pouvez également indiquer le nom d'administrateur dans l'un des formats suivants :

• domain@user_name, par exemple : cluster.com@test
• domain\user_name, par exemple : cluster.com\test

Remarque : Veillez à mettre à niveau VM Manager Tool vers la version 9.2.16, et pas uniquement le serveur .

Si vous ne respectez pas ce modèle et que le format du nom d'utilisateur indiqué est incorrect, une erreur est générée lors de l'authentification du gestionnaire de machine virtuelle.

Lorsque l'erreur se produit, le nom d'utilisateur est affecté à une zone incorrecte.