Isolation de serveurs et de domaines à l'aide d'IPSec et de stratégies de groupe

Chapitre 7 : Dépannage d'IPSec

Dernière mise à jour le 16-02-2005

Ce chapitre fournit des informations relatives au dépannage d'IPSec (Internet Protocol security), dans le cadre d'une isolation de serveurs et de domaines, par exemple. Il est basé sur l'expérience et les processus de l'équipe Service informatique (IT) de Microsoft. Lorsque cela est possible, ce chapitre fait référence aux procédures de dépannage Microsoft existantes ainsi qu'aux informations associées.

Le support informatique de Microsoft repose sur un modèle de prise en charge multi-niveaux, et le support technique est communément appelé support de niveau 1. Les procédures de remontée des incidents permettent aux techniciens du support technique de transférer les incidents nécessitant l'intervention de spécialistes.

Les procédures de ce chapitre font référence à trois niveaux de support : niveau 1, niveau 2 et niveau 3. Pour garantir des conseils aussi pratiques et précis que possible, la majeure partie du contenu se situe au niveau 2. Les conseils de niveau 1 permettent d'aider les entreprises à déterminer aussi rapidement que possible si un problème est lié à IPSec et, si tel est le cas, à générer les informations requises pour aider les ingénieurs du support de niveau 2 à résoudre le problème.

Les informations extrêmement détaillées et complexes qui sont nécessaires à la résolution des problèmes de niveau 3 ne sont pas traitées dans ce chapitre. Si les informations proposées dans ce chapitre ne permettent pas de résoudre un problème lié à IPSec, Microsoft vous recommande de contacter Microsoft® Product Support Services (services de support technique) pour obtenir une assistance supplémentaire.

La plupart des procédures de support, des outils et des scripts utilisés par Microsoft sont fournis dans ce chapitre à titre de référence. Ces recommandations et outils sont généralement adaptés et répondent aux besoins spécifiques de votre entreprise.

Lorsque IPSec est utilisé pour sécuriser le trafic sur le réseau via les protocoles TCP (Transmission Control Protocol) et UDP (User Datagram Protocol), les procédures et outils de dépannage réseau TCP/IP traditionnels peuvent se révéler inefficaces. C'est pourquoi il est important de planifier et d'élaborer des techniques de dépannage spécifiques à IPSec qui pourront être utilisées si un problème se présente sur les ordinateurs qui utilisent ou (tentent d'utiliser) IPSec pour leurs communications.

Sur cette page

Niveaux de support et transfert des incidents
Dépannage de niveau 1
Préparation du dépannage de niveau 2
Processus de dépannage d'IPSec
Dépannage de niveau 3
Résumé

Niveaux de support et transfert des incidents

Le support de l'isolation de serveurs et de domaines est un service standard proposé par Microsoft, qui est défini par les accords sur les niveaux de service (service level agreement, SLA). Le support de l'isolation est fourni par les niveaux suivants :

• Niveau 1 : support technique. Le support technique constitue le point d'entrée à la fois pour les problèmes client associés et non associés à un domaine. Le support technique prend également en charge les serveurs gérés par les services informatiques centraux. (Les autres serveurs peuvent être gérés par des équipes de gestion des applications d'entreprise ou des groupes de produits). Les membres du support technique sont formés pour utiliser une taxinomie et divers organigrammes de classification des problèmes liés à l'isolation de serveurs et de domaines.

  Au cours de la phase pilote de la solution d'isolation de Microsoft, les problèmes rencontrés par les clients ont été transférés au service de sécurité informatique d'entreprise. Cependant, après le déploiement de la solution dans l'étape de production, les problèmes client ont été traités par les équipes de support de niveau 2.

• Niveau 2 : exploitation du centre de données, centre d'exploitation du réseau global, support des applications d'entreprise et support de messagerie/collaboration. Ces groupes sont des équipes d'exploitation quotidienne qui surveillent et gèrent les services informatiques et leurs ressources associées. Lors des phases pilote d'isolation de serveurs et de domaines, ces équipes ont été le point de départ de transfert des problèmes de serveur et du dépannage pour le support technique et le service de sécurité informatique d'entreprise. Chaque groupe possède un expert en isolation de serveurs et de domaines, ainsi que des procédures de dépannage détaillées.

• Niveau 3 : services d'infrastructure et de réseau Windows. Lors des phases pilote d'isolation de serveurs et de domaines, ce groupe a défini une équipe d'experts en dépannage des composants architecturaux et des technologies inhérentes à la solution, comme IPSec, le traitement des paquets TCP/IP, les comptes d'ordinateurs et les droits de connexion au réseau. Si un autre niveau de transfert est nécessaire au sein de Microsoft, le niveau 3 fonctionne directement avec les équipes de développement Windows jusqu'à ce que le problème soit clos. Hors du cadre de Microsoft, ce niveau fonctionne avec les services de support technique Microsoft en cas de nécessité.

La section suivante résume les techniques de dépannage pouvant être utilisées par le personnel du support technique dans l'organisation du support de niveau 1.

Dépannage de niveau 1

Cette section présente le processus général de dépannage des problèmes liés à IPSec qui est utilisé par le personnel du support technique chargé du support de niveau 1. En général, le personnel du support de niveau 1 est composé d'opérateurs téléphoniques qui tentent de diagnostiquer les problèmes à distance.

Le problème est-il lié à IPSec ?

Le support technique est susceptible de recevoir des appels du type « J'ai réussi à me connecter au serveur x jusqu'à l'activation d'IPSec » ou « Tout fonctionnait parfaitement hier, mais je n'arrive pas à me connecter aujourd'hui ». D'après l'expérience des équipes informatiques de Microsoft, le déploiement d'IPSec a entraîné l'augmentation des volumes d'appels pour tous les types de problèmes de connectivité réseau et les incidents « d'accès refusé » car les utilisateurs étaient plus attentifs aux comportements des applications et du réseau. Si un utilisateur pensait que le problème était lié à IPSec, il appelait le support technique. Un plan d'implémentation de l'isolation de serveurs et de domaines doit inclure un système de classification des appels afin que le personnel du support technique puisse fournir des rapports précis sur le volume et la nature des problèmes liés à IPSec.

Une fois que l'appelant a fourni toutes les informations d'administration utiles, le personnel du support technique doit suivre un processus de dépannage défini. Étant donné que les répercutions des stratégies IPSec sur les communications peuvent varier et que le processus de déploiement peut prendre plusieurs jours (voire plusieurs semaines), il est vivement recommandé de définir un organigramme et de le mettre à jour pour chaque ensemble de modifications d'isolation mis en place. Le personnel de gestion du support technique doit être impliqué dans ce processus de planification.

L'objectif du support technique est de classer le problème dans une catégorie afin de pouvoir lui appliquer des solutions adaptées. Si ces tentatives ne permettent pas de résoudre le problème, le support technique doit s'assurer qu'il a bien reçu les informations requises, puis il doit transférer le problème au support de niveau 2. Par exemple, le support technique doit être en mesure d'identifier divers types de problèmes de la manière suivante :

• Connectivité réseau. Utilisez les messages ping et tracert du protocole ICMP (Internet Control Message Protocol) pour tester les chemins du réseau.

• Résolution de noms. Utilisez les commandes ping <nom destination> et nslookup.

• Applications. Certaines applications fonctionnent (par exemple, net view), alors que d'autres ne fonctionnent pas lorsqu'elles communiquent avec la même destination.

• Services. Par exemple, déterminez si le serveur exécute le service de routage et d'accès distant (Routing and Remote Access, RRAS), lequel crée une stratégie IPSec automatique conflictuelle avec le protocole L2TP.

• Ordinateur de l'appelant. Déterminez s'il peut accéder à n'importe quel ordinateur hôte ou à un ordinateur de destination approuvé spécifique qui est utilisé par le support technique pour les tests et les diagnostics.

• Ordinateur cible. Déterminez si l'ordinateur de l'appelant peut accéder à tous les ordinateurs du support technique utilisés pour les tests et s'il ne peut pas accéder à certains ordinateurs de destination.

En fonction de l'entreprise, le support technique peut utiliser l'Assistance à distance ou le Bureau à distance pour se connecter à l'ordinateur de l'appelant. Les instructions fournies dans ce chapitre ne nécessitent pas un accès à distance, mais elles peuvent s'avérer utiles pour le personnel du support technique qui peut s'en servir plutôt que de guider l'appelant dans le composant logiciel enfichable MMC (Microsoft Management Console) Moniteur IPSec ou la visionneuse du journal des événements.

Dans des scénarios où l'isolation de serveurs est utilisée sans isolation de domaines, le personnel du support technique doit savoir quels serveurs font partie du groupe d'isolation.

Détermination de l'étendue et de la gravité

L'une des premières questions auxquelles le support de niveau 1 doit répondre est la suivante : « qui est concerné par le problème ? » En effet, le personnel technique doit savoir si d'autres utilisateurs rencontrent le même problème et, le cas échéant, le nombre d'utilisateurs concernés et leur emplacement. Le personnel technique doit ensuite s'intéresser à l'étendue du problème. Par exemple, cela affecte-t-il la connectivité d'un seul serveur ou existe-t-il d'autres problèmes de type échec de connexion ou d'authentification sur des zones importantes du réseau ?

Les problèmes de connectivité peuvent impliquer de nombreuses couches et technologies utilisées dans les communications réseau. Les ingénieurs du support technique doivent connaître le fonctionnement général des communications réseau TCP/IP Windows, ainsi que les problèmes spécifiques liés à la solution. Cette section détaille les différents types de problèmes courants que chaque support de niveau 1 doit traiter.

• Problèmes spécifiques à l'ordinateur. Les communications protégées par IPSec requièrent une authentification IKE (Internet Key Exchange) mutuelle des ordinateurs. Les ordinateurs qui débutent des communications et ceux qui y répondent doivent posséder des comptes de domaine valides et avoir accès aux contrôleurs de leur domaine. En outre, pour que les attributions de stratégie IPSec et que les contrôles d'accès au réseau fonctionnent, il est nécessaire que les comptes d'ordinateur soient dans les groupes de domaine appropriés. D'autres problèmes spécifiques peuvent affecter le comportement d'IPSec :

  • Le système d'exploitation ne dispose pas du Service Pack ou du correctif approprié, ou la configuration de la clé du registre est incorrecte.

  • Un logiciel ou des services particuliers sont installés et en cours d'exécution sur l'ordinateur.

  • La connexion réseau utilise une adresse IP spécifique ou communique à l'aide d'un chemin réseau particulier.

  En raison de ces types de problèmes, certains ordinateurs peuvent rencontrer des problèmes de connectivité et d'autres non.

  Remarque : tous les outils de dépannage d'IPSec mentionnés dans ce chapitre nécessitent des privilèges du groupe des administrateurs locaux.

• Problèmes d'emplacement réseau et problèmes spécifiques au chemin. Dans une solution d'isolation de serveurs et de domaines ou de déploiement à grande échelle d'IPSec, il est probable que la totalité du trafic TCP et UDP sera encapsulée. Par conséquent, les périphériques réseau du chemin ne voient que les protocoles IKE, IPSec et ICMP. S'il existe des problèmes réseau au niveau de la transmission de ces trois protocoles entre la source et la destination, il est possible que la communication soit bloquée entre les deux ordinateurs.

• Problèmes spécifiques à l'utilisateur. Le déploiement d'IPSec, dans le cas d'une isolation de serveurs et de domaines, par exemple, peut avoir des répercutions sur les droits de connexion au réseau des utilisateurs d'un domaine. Par exemple, le problème peut concerner uniquement les utilisateurs qui ne font pas partie d'un groupe autorisé à accéder au réseau, ou il peut concerner un utilisateur autorisé qui ne parvient pas à obtenir les informations d'authentification Kerberos contenant les appartenances de groupe correctes. Il peut exister des différences de comportement entre les comptes de domaine et d'utilisateur local ou les comptes de service.

Deux autres caractéristiques de l'isolation de serveurs et de domaines sont fréquentes lors des déploiements d'IPSec en entreprise : il s'agit de l'utilisation de filtres de sous-réseau pour définir les intervalles d'adresses utilisés sur le réseau interne et l'application de stratégies IPSec basées sur l'appartenance au domaine et au groupe qui ne tiennent pas compte de l'emplacement d'un ordinateur sur le réseau interne. C'est pourquoi, en cas de problème avec la conception des filtres de sous-réseau ou le chemin réseau utilisé par cet ordinateur pour communiquer avec les autres, des problèmes de connectivité peuvent survenir uniquement dans certaines zones du réseau lors de l'utilisation d'une adresse IP particulière (une adresse sans fil au lieu d'une adresse LAN), ou sur certains ordinateurs uniquement.

Organigrammes de dépannage

Les organigrammes de gestion des appels de cette section ont été élaborés par les équipes informatiques de Microsoft pour faciliter le classement des problèmes de support d'IPSec de niveau 1. Outre les outils standards, deux des organigrammes font référence à un script d'actualisation de la stratégie IPSec, dont une description est fournie dans la section « Exemples de scripts de prise en charge » plus loin dans ce chapitre.

La figure 7.1 est utilisée pour réaliser un diagnostic initial et pour déterminer le type de problème :

• S'agit-il d'un problème de connectivité réseau ? Si oui, procédez à une action de dépannage réseau de base. Si la tentative de résolution échoue, transférez le problème au support de niveau 2.

• S'agit-il d'un problème de résolution de noms ? Si oui, procédez à une action de dépannage de résolution de noms de base. Si la tentative de résolution échoue, transférez le problème au support de niveau 2.

• S'agit-il d'un problème lié à l'application ? Si oui, transférez le problème au support de niveau 2.

• S'agit-il d'un problème IPSec lié à l'ordinateur de l'appelant ? Si oui, reportez-vous à la figure 7.2.

• S'agit-il d'un problème IPSec lié à l'ordinateur cible que l'appelant tente de contacter ? Si oui, reportez-vous à la figure 7.3.  

  

  Figure 7.1 Processus de dépannage en cas d'échec de communication avec l'ordinateur cible

Remarque : cet organigramme part du principe que l'ordinateur de l'appelant exécute IPSec et que les zones DNS de recherche inversée sont configurées pour permettre le bon fonctionnement de la commande ping –a.

La figure 7.2 permet d'identifier les problèmes liés à l'ordinateur de l'appelant. Outre les diagnostics, cet organigramme référence l'utilisation d'un script d'actualisation de stratégie IPSec (reportez-vous à la section « Exemples de scripts de prise en charge » plus loin dans ce chapitre), qui peut résoudre le problème sans nécessairement l'identifier. Les étapes illustrées dans la figure 7.2 vous aident à déterminer les éventuels problèmes suivants liés à l'ordinateur de l'appelant :

• S'agit-il d'un problème de routage et d'accès distant ? Si oui, arrêtez le service RRAS (s'il n'est pas requis) ou transférez le problème au support de niveau 2.

• S'agit-il d'un problème de stratégie ? Si oui, essayez d'actualiser la stratégie de groupe et la stratégie IPSec.

• S'agit-il d'un problème lié au compte de domaine ? Si oui, créez un compte de domaine pour l'ordinateur de l'appelant.

• S'agit-il d'un problème autre que ceux énoncés ci-dessus ? Si l'actualisation de la stratégie IPSec et/ou la création d'un compte de domaine n'ont pas permis de résoudre le problème, transférez le problème au support de niveau 2.

  

  Figure 7.2 Dépannage d'IPSec sur l'ordinateur de l'appelant –  problèmes connexes

La figure 7.3 permet d'identifier les problèmes liés à un ordinateur cible spécifique. Notez que cet organigramme référence également l'utilisation d'un script d'actualisation de stratégie IPSec qui peut résoudre le problème sans nécessairement l'identifier. La figure 7.3 vous aide à déterminer les éventuels problèmes suivants liés à l'ordinateur cible (ou vous indique le chemin d'accès à cet ordinateur) :

• S'agit-il d'un problème RRAS ? Si oui, transférez le problème au support de niveau 2.

• S'agit-il d'un problème de stratégie IPSec ? Si oui, essayez d'actualiser la stratégie de groupe et la stratégie IPSec. Vérifiez ensuite la connectivité réseau.

• S'agit-il d'un problème de connectivité réseau ? Si oui, transférez le problème au support de niveau 2.

• S'agit-il d'un problème de droits de connexion ? Si oui, transférez le problème au support de niveau 2.

  

  Figure 7.3 Dépannage d'IPSec sur l'ordinateur cible –  problèmes connexes

Une fois que le personnel du support de niveau 1 a étudié le problème par rapport aux organigrammes, l'un des états suivants est attribué au problème :

• Résolution complète. Cet état indique que le problème a été résolu et que sa cause a peut-être été déterminée.

• Résolution partielle. Cet état signifie que le problème a été résolu mais que sa cause n'a pas été totalement comprise. Par exemple, l'actualisation d'une stratégie IPSec peut résoudre le problème mais n'explique pas forcément pourquoi une mauvaise stratégie ou aucune stratégie n'a été appliquée.

• Non résolu. Cet état indique que le problème est toujours en attente d'une résolution mais que sa cause a probablement été identifiée. Le problème est transféré au support de niveau 2.  

Prévention des attaques de manipulation

Dans une solution d'isolation, le personnel du support technique peut avoir connaissance de certaines zones spécifiques de l'environnement informatique non protégées par IPSec, comme les ordinateurs appartenant à la liste d'exemption. Ces zones ne doivent pas être utilisées pour protéger des informations confidentielles, car en général, les autres solutions de sécurité ne donnent accès à ces informations qu'aux équipes de support de niveau supérieur. C'est pour cette raison que le personnel du support technique doit être formé à la détection et à la prévention des manipulations.

Une attaque de manipulation se manifeste lorsqu'une personne peu fiable tente d'obtenir des informations sur le fonctionnement de la sécurité et sur les points faibles du système de sécurité, en profitant simplement de la tendance des gens à faire confiance aux autres. Le personnel du support technique doit contrôler attentivement les informations suivantes :

• Membres de la liste d'exemption. La liste des adresses IP dans les filtres de la liste d'exemption est à la disposition des administrateurs locaux sur tous les hôtes approuvés lors de l'utilisation du composant logiciel enfichable MMC Moniteur IPSec ou lors de l'affichage du cache de la stratégie IPSec dans le registre local. De plus, les paramètres de sécurité utilisés dans l'entreprise sont susceptibles de donner aux utilisateurs non administratifs un accès en lecture au cache. Une fois que l'isolation du domaine est entièrement implémentée, les pirates analysent le réseau pour détecter les ordinateurs exemptés qui seront capables de répondre aux requêtes de connexion TCP et UDP. Notez que les serveurs DNS, DHCP et WINS sont facilement identifiables à partir de la configuration DHCP et que les contrôleurs de domaine sont faciles à localiser par l'utilisation d'une requête DNS ou UDP LDAP (Light Directory Access Protocol).

• Ordinateurs de l'entreprise ne faisant pas partie de la solution d'isolation. Par exemple, certains types de serveurs ou domaines peuvent ne pas être inclus dans la solution.

• Ordinateurs qui utilisent l'isolation de serveurs ou qui requièrent un contrôle d'accès basé sur les machines. Les serveurs contenant les informations les plus sensibles sont généralement dotés des protections de sécurité les plus efficaces.

• Utilisateurs qui sont des administrateurs ou qui jouent un rôle spécial dans le service informatique. Les noms de connexion ou les adresses électroniques sont divulgués lorsqu'ils sont utilisés dans les noms complets ou partiels des ordinateurs.

• Sous-réseaux utilisés à des fins spécifiques ou par certaines entreprises. Si ces informations sont connues, un pirate peut alors concentrer son attaque sur les points les plus importants du réseau.

• Autres mesures de sécurité basées sur le réseau qui sont utilisées. Par exemple, il est extrêmement utile pour un pirate de savoir s'il existe des pare-feu, si les filtres de routeur autorisent certains trafics ou si la détection d'intrus sur le réseau est utilisée.

Les agents du support technique doivent également être vigilents si des appelants leur demandent de se connecter à l'adresse IP de leur ordinateur pour détecter un problème ; par exemple, un pirate demande à une personne du support technique de se connecter à son ordinateur en utilisant le partage de fichiers, le Bureau à distance, Telnet ou un autre protocole réseau. Si l'agent du support technique effectue la connexion sans IPSec, l'ordinateur pirate peut obtenir des informations sur le mot de passe ou (dans certains cas, comme avec Telnet) « dérober » le mot de passe. Cette situation peut se produire car certains protocoles réseau des clients ne procèdent pas à l'authentification de l'ordinateur de destination, ni n'établissent de relation d'approbation, ou encore, ils ne requièrent pas de protection par mot de passe fiable avant de révéler des informations sur l'identité de l'utilisateur ou des données sur le mot de passe.

Exemples de scripts de prise en charge

Dans la plupart des scénarios de dépannage, il est possible de trouver rapidement une solution lorsque les informations appropriées ont été identifiées. Pour ce faire, vous pouvez utiliser divers outils Windows, comme ceux déisngés dans les organigrammes. Dans la solution Woodgrove Bank, plusieurs scripts ont été développés pour fournir des informations clés, sans que le personnel du support de niveau 1 ne connaisse en détail le fonctionnement des outils et la syntaxe. Ces scripts sont disponibles dans le dossier de téléchargement Tools and Templates de ce guide.

Scripts disponibles pour le support de niveau 1

Si l'utilisateur est également l'administrateur local de son ordinateur, le personnel du support technique peut lui demander d'exécuter l'un des trois scripts fournis dans le cadre de cette solution. Ces scripts sont des exemples des scripts personnalisés utilisés dans l'environnement Woodgrove Bank détaillé dans ce guide. Ils sont décrits dans ce chapitre pour illustrer la manière dont les scripts peuvent être utilisés dans le processus de dépannage.

Remarque : ces scripts sont des exemples testés, mais ils ne sont pas pris en charge par Microsoft. Ils doivent être utilisés par une entreprise comme base pour l’élaboration d'une solution personnalisée.

IPSec_Debug.vbs

Ce script fournit des informations de débogage et peut résoudre certains problèmes. Il arrête et redémarre le service IPSec (qui supprime toutes les associations de sécurité IKE et IPSec actuelles), force une actualisation de stratégie de groupe à recharger la stratégie IPSec actuellement affectée au domaine à partir du service d'annuaire Active Directory® et met à jour le cache de la stratégie. Pour éviter la perte de connectivité des sessions de bureau à distance, le script doit être téléchargé sur l'ordinateur de l'appelant et exécuté localement par un compte disposant de privilèges administratifs. Utilisez la syntaxe suivante pour exécuter le script à l'invite de commande :

cscript IPSec_Debug.vbs

Le script effectue les fonctions suivantes :

• détection de la version du système d'exploitation ;

• appel du script Detect_IPSec_Policy.vbs ;

• augmentation de la journalisation de la stratégie de groupe ;

• augmentation de la journalisation du protocole d'authentification Kerberos version 5 ;

• purge des tickets actuels du protocole Kerberos ;

• actualisation de la stratégie de groupe ;

• activation de la journalisation IPSec ;

• exécution de tests PING et SMB (Net View) ;

• détection des versions de fichier IPSec ;

• exécution de tests de diagnostic de la stratégie et du réseau ;

• copie des événements IPSec 547 dans un fichier texte ;

• désactivation de la journalisation IPSec ;

• restauration de la journalisation du protocole Kerberos ;

• restauration de la journalisation de la stratégie de groupe.

Ce script active également tous les journaux liés à IPSec en vue du dépannage par le support de niveau 2.

Detect_IPSec_Policy.vbs

Ce script détermine si l'ordinateur exécute la stratégie IPSec appropriée en vérifiant les informations sur la version de la stratégie IPSec de domaine dans le cache du registre local actuel. Utilisez la syntaxe suivante pour exécuter le script à l'invite de commande :

cscript Detect_IPSec_Policy.vbs

Remarque : ce script est également appelé à partir du script IPSec_Debug.vbs ; il n'est donc pas nécessaire de l'exécuter en complément de ce dernier.

Refresh_IPSec_Policy.vbs

Il s'agit du script d'actualisation de la stratégie IPSec référencé dans les organigrammes de dépannage. Il actualise les tickets du protocole d'authentification Kerberos sur l'ordinateur ainsi que la stratégie de groupe et peut résoudre le problème si ce dernier est provoqué par une attribution de stratégie IPSec incorrecte ou par un échec lors du téléchargement de la stratégie de groupe. Utilisez la syntaxe suivante pour exécuter le script à l'invite de commande :

cscript Refresh_IPSec_Policy.vbs

Transfert des problèmes

Lorsque le personnel du support technique doit transférer un problème IPSec, le personnel du niveau 1 doit collecter les informations suivantes et les transmettre avec la requête de service :

• les fichiers journaux générés avec le script IPSec_Debug.vbs ;

• le nom de l'ordinateur de l'appelant afin que le niveau de support technique suivant puisse identifier le fichier journal généré par le script ;

• l'ordinateur de destination auquel l'accès est refusé, afin que le problème soit transféré au groupe de support compétent.

Les scénarios d'isolation de serveurs disposent souvent de leur propre équipe technique pour identifier l'appartenance des groupes d'accès au réseau.  

Préparation du dépannage de niveau 2

Le support de niveau 2 a deux rôles principaux. Tout d'abord, en tant que destinataire des transferts de niveau 1, le niveau 2 valide les problèmes et passe en revue les étapes effectuées par le niveau 1 pour s'assurer qu'aucune étape de dépannage n'a été omise. Dans cette optique, le niveau 2 doit confirmer que les problèmes transférés sont véritablement liés à IPSec et qu'il ne s'agit pas d'une erreur de diagnostic. Ensuite, en tant qu'ingénieurs de support réseau qualifiés, les membres du support de niveau 2 doivent utiliser leurs compétences et leur expérience (voir la section suivante) pour résoudre le problème grâce à l'analyse du journal et sans obtenir le contrôle administratif de l'ordinateur. Toutefois, les fichiers journaux ne font que capturer les informations, et les actions correctives nécessitent un accès administratif. En principe, un membre du support technique de niveau 2 n'est pas administrateur de domaine et n'est pas chargé d'apporter des modifications à une stratégie IPSec basée sur un domaine ni aux appartenances de groupe.

Compétences du support de niveau 2

Le personnel technique chargé du support IPSec de niveau 2 doit posséder des compétences et de l'expérience dans les domaines suivants :

• Stratégie de groupe. Il doit connaître les stratégies à attribuer, savoir comment elles sont attribuées et être en mesure d'effectuer les tâches suivantes :

  • vérifier les listes de contrôle d’accès (Access control lists, ACL) sur les objets de la stratégie de groupe (Group policy objects, GPO) ;

  • vérifier les paramètres GPO ;

  • vérifier les appartenances des ordinateurs et des utilisateurs aux divers groupes.

• Expérience des logiciels tiers utilisés par l'entreprise.

• Identification des échecs d'authentification.

  • Le personnel technique doit être capable de vérifier que le compte d'un ordinateur appartenant à un domaine est correct en utilisant les utilitaires netdiag et nltest.

• Configuration IPSec. Le personnel technique doit être capable d'effectuer les tâches suivantes :

  • vérifier les configurations du filtre IPSec ;

  • recharger la stratégie de domaine IPSec ;

  • désactiver entièrement IPSec ou uniquement la stratégie de domaine afin d'utiliser la stratégie locale pour des tests ;

  • dépanner le processus de négociation IKE d'IPSec et les protocoles de sécurité.

• Réseau. Le personnel technique doit être capable d'effectuer les tâches suivantes :

  • dépanner la pile de protocole réseau sur un ordinateur hôte ;

  • comprendre et résoudre les informations collectées dans un fichier de suivi réseau ;

  • dépanner des problèmes de chemin d'accès au réseau, y compris les solutions de recherche de l'unité maximale de transfert (Maximum Transmission Unit, MTU) du chemin TCP et les solutions d'accès distant au réseau privé virtuel (virtual private network, VPN).

Problèmes inhérents à l'utilisation d'IPSec

Comme nous l'avons mentionné dans la section précédente, dans le cas d'une solution d'isolation de serveurs et de domaines, le personnel du support de niveau 2 a besoin de connaître les détails relatifs aux communications protégées par IPSec, mais il doit aussi être capable d'isoler les problèmes associés à d'autres composants.

Pour établir une communication IPSec entre deux ordinateurs, ceux-ci nécessitent généralement une stratégie IPSec compatible. Par exemple, une stratégie IPSec peut bloquer la communication si l'ordinateur distant ne dispose pas d'une stratégie IPSec adéquate. Bien que ce comportement soit intentionnel ou acceptable lors du déploiement d'un changement de stratégie, le fait qu'il bloque la connectivité réseau entre un ou plusieurs ordinateurs et provoque l'apparition d'avertissements ou d'erreurs dans une application n'est pas forcément visible immédiatement. Dans le pire des cas, un administrateur peut accidentellement attribuer une stratégie IPSec à tous les membres d'un domaine qui bloque la totalité du trafic. Il est difficile d'interrompre la réplication de la stratégie préjudiciable, sauf si l'erreur est immédiatement réparée avec une attribution qui réplique rapidement l'attribution d'origine. Ce type d'erreur entraîne une situation dans laquelle les communications entre un client et un contrôleur de domaine sont nécessaires à l'utilisation d'IPSec. Étant donné que l'authentification utilisée dans cette solution repose sur le protocole Kerberos, les clients qui héritent de cette stratégie ne sont pas en mesure d'effectuer le processus de connexion, car ils ne sont pas capables d'obtenir le ticket Kerberos requis pour sécuriser les communications. Les administrateurs doivent planifier avec minutie toute modification de la stratégie et s'assurer que des mesures de protection existent pour minimiser les risques de ce type de situation.

Des informations générales sur le dépannage du protocole TCP/IP sont fournies dans les guides de dépannage répertoriés à la section « Informations complémentaires » à la fin de ce chapitre. Cependant, plusieurs procédures mentionnées dans ces guides fonctionnent uniquement si IPSec assure la connectivité. Si IKE ou IPSec sont défaillants, alors la plupart de ces procédures et outils deviennent inopérants. Dans un scénario d'isolation de serveurs et de domaines, il est possible que certaines procédures indiquées dans ces guides ne fonctionnent pas du tout, même si IPSec assure la connectivité. Un service de support technique doit mettre à jour et personnaliser ses outils et procédures de dépannage afin qu'ils soient efficaces dans un environnement d'isolation de serveurs et de domaines. Comme il existe différentes manières de déployer des stratégies IPSec pour contrôler et sécuriser le trafic réseau, il est peu vraisemblable que les entreprises puissent uniquement utiliser les procédures existantes et un jeu d'outils générique.

Il est important que le personnel du support dispose d'exemples documentés sur les résultats escomptés des outils de dépannage réseau qui sont obtenus à partir d'un laboratoire où l'isolation de serveurs et de domaines ou le déploiement d'IPSec fonctionnent correctement. Dans la plupart des cas, les outils de diagnostic réseau n'attendent pas le délai de trois secondes pour passer en communication en texte clair ou les brefs délais requis pour la négociation IKE initiale des associations de sécurité (security associations, SA) d'IPSec. Par conséquent, les outils peuvent afficher un résultat lors de leur exécution initiale et afficher un autre résultat s'ils sont exécutés quelques secondes plus tard. En outre, lorsque l'accès au réseau est délibérément refusé par IPSec, les outils signalent des échecs. Le type d'échec dépend de l'outil utilisé et de l'environnement IPSec.

Remarque : dans la section consacrée au support de niveau 1, les termes appelant et cible ont été utilisés pour aider le personnel du support technique à résoudre les problèmes courants. Dans la section relative au support de niveau 2, il est préférable d'utiliser les termes IPSec initiateur et répondeur pour que les processus de dépannage avancé soient plus clairs. Le reste de ce chapitre utilise ces termes IPSec.

Stratégie de groupe et appartenance aux groupes

La stratégie IPSec basée sur le domaine dépend de la stratégie de groupe et du téléchargement des GPO. Si le système de stratégie de groupe du client rencontre des erreurs lors de la détection de changements GPO ou lors de leur téléchargement, la connectivité IPSec peut s'en trouver affectée. Si l'attribution de la stratégie de groupe est contrôlée par l'appartenance à une unité d'organisation (UO) et que les comptes d'ordinateurs sont par inadvertance déplacés vers une autre UO, supprimés ou recréés dans une UO inappropriée, il est possible qu'une stratégie IPSec inadéquate soit attribuée.

Cette solution utilise les groupes de sécurité des domaines pour contrôler les attributions de stratégies et l'accès au réseau. L'appartenance aux groupes est contenue dans les tickets (tickets TGT et de service) du protocole d'authentification Kerberos version 5. La durée de vie de ces tickets est assez longue. Ainsi, les administrateurs doivent prévoir le temps nécessaire aux ordinateurs pour recevoir les informations d'identification des nouveaux tickets TGT et de service Kerberos contenant les mises à jour des appartenances aux groupes. Le protocole Kerberos permet très difficilement de déterminer si les tickets Kerberos d'un ordinateur contiennent les appartenances aux groupes appropriées. Il s'agit d'une difficulté liée à la conception des tickets, car toutes les informations sur l'appartenance à un groupe sont stockées sous forme chiffrée dans le ticket. L'appartenance à un groupe doit être déterminée par l'utilisation des informations du service d'annuaire, et non par l'utilisation des tickets.

Authentification Kerberos

La conception de l'isolation de serveurs et de domaines utilise le protocole Kerberos version 5 pour l'authentification IKE. Étant donné que le protocole Kerberos requiert une connectivité réseau et un service disponible à partir du DNS et des contrôleurs de domaine, le manque de connectivité entraîne l'échec de l'authentification Kerberos et d'IKE. (IKE échoue également si Kerberos échoue.) Ainsi, des problèmes de connectivité entre un ordinateur A et un ordinateur B peuvent être provoqués par une connectivité réseau bloquée entre l'ordinateur A et l'ordinateur C. Ces problèmes sont causés par l'incapacité du protocole Kerberos de s'authentifier auprès d'un contrôleur de domaine. Dans ce type de situation, les informations fournies dans les événements 547 des journaux d'audit et de sécurité de Windows offrent généralement des conseils très précieux sur la source du problème.

Trafic entrant protégé par IPSec requis

Cette solution d'isolation de serveurs et de domaines spécifie que des communications protégées par IPSec sont requises pour l'accès entrant. Cette condition a pour conséquence d'obliger les outils de surveillance à distance exécutés sur des ordinateurs non approuvés ou sur des périphériques de surveillance réseau dédiés à signaler qu'il est impossible de contacter un ordinateur distant. Si ces ordinateurs ou périphériques ne peuvent pas intégrer l'environnement « approuvé », ils ne seront pas capables de jouer un rôle de surveillance sauf si des exemptions spécifiques sont ajoutées à la conception. Le dépannage est compliqué par le fait qu'IPSec peut être requis pour établir la connectivité vers un hôte approuvé, ce qui signifie qu'un administrateur risque de ne pas pouvoir se connecter à un hôte approuvé, ni de pouvoir interrompre le service IPSec sans perdre la connectivité. Si la stratégie IPSec de l'administrateur autorise la communication en texte clair, alors la connexion à distance subit un délais de trois à quatre secondes après l'interruption du service sur l'ordinateur distant. Toutefois, l'arrêt du service IPSec sur un ordinateur distant supprime les associations de sécurité IPSec utilisées par tous les autres ordinateurs actuellement connectés. Si les autres ordinateurs ne sont pas en mesure d'établir la communication en texte clair, alors les communications sont interrompues et les connexions TCP sont hors délais. Comme les ruptures soudaines des communications TCP peuvent entraîner la corruption des données de certaines applications, l'arrêt du service IPSec doit uniquement être utilisé comme dernier recours du processus de dépannage. Avant l'arrêt du service IPSec, il est préférable de préparer la mise hors tension de l'ordinateur afin que tous les utilisateurs connectés puissent mettre fin correctement aux communications.

Problèmes de direction des communications

L'un des scénarios de dépannage courants présente une communication réussie dans une direction mais qui échoue dans la direction opposée. L'authentification IKE requiert généralement l'authentification mutuelle des ordinateurs. Si un ordinateur ne peut pas obtenir de ticket Kerberos lorsqu'il initie le mode IKE principal pour un ordinateur distant, alors IKE échoue. Cette situation peut se produire si le client Kerberos de l'initiateur ne peut pas accéder à un contrôleur du domaine de l'ordinateur de destination. Si les ordinateurs font partie de domaines qui ne sont pas mutuellement approuvés (approbation bidirectionnelle), alors les négociations IKE en mode principal réussissent lorsqu'un seul ordinateur démarre et échoue si l'autre ordinateur démarre. De la même manière, les droits de connexion au réseau peuvent être différents sur deux ordinateurs. Il est possible que les négociations IKE en mode principal et en mode rapide échouent dans une direction pour ces raisons, mais également si les conceptions des stratégies IPSec ne sont pas compatibles.

Les pare-feu pour hôte qui interceptent le trafic au-dessus de la couche IPSec peuvent imposer la direction des connexions. Certains pare-feu pour hôte interceptent le trafic sous la couche IPSec. Une fois que la communication IPSec est établie, le trafic protégé par IPSec sera vraisemblablement autorisé dans les deux directions pendant une certaine durée.

Le filtrage avec état par un routeur réseau ou un pare-feu peut également bloquer les actions IKE de recomposition ou le flux du trafic IPSec sans influencer les autres protocoles de diagnostic comme le protocole ICMP. Il est possible que les ports TCP et UDP ne soient pas accessibles sur un ordinateur parce qu'un service n'est pas exécuté ou parce qu'un périphérique qui fonctionne au-dessus de la couche IPSec (un pare-feu Windows ou un routeur réseau, par exemple) bloque l'accès.

Suivis des réseaux et dépannage avancé du chemin d'accès au réseau

Les échecs de la négociation IKE entraînent souvent l'interruption de réponse à la négociation IKE de la part de l'ordinateur qui subit l'échec ou, dans certains cas, entraînent le renvoi du dernier message de bon fonctionnement jusqu'à ce que la limite de nouvelles tentatives expire. IKE doit être capable d'envoyer des datagrammes UDP fragmentés contenant les tickets Kerberos, car ces paquets dépassent souvent l'unité maximale de transfert d'un chemin (path maximum transmission unit, PMTU) pour l'adresse IP de destination. Si la fragmentation n'est pas correctement prise en charge, de tels fragments peuvent être abandonnés par les périphériques réseau dans un chemin donné. En outre, il est possible que le réseau ne transmette pas les paquets du protocole IPSec ou les fragments des paquets IPSec correctement. L'intégration d'IPSec à TCP permet à TCP de réduire la taille des paquets afin de recevoir la surcharge des en-têtes IPSec. Cependant, la négociation TCP de la taille maximale du segment (maximum segment size, MSS) lors de la liaison TCP ne prend pas en compte la surcharge IPSec. D'où le besoin croissant de recherche de l'unité PMTU ICMP sur le réseau afin de garantir que les communications TCP réussies sont protégées par IPSec. Ainsi, le dépannage des échecs de connectivité peut nécessiter les suivis des réseaux des deux côtés de la communication ou d'un seul, ainsi que les fichiers journaux des deux côtés de la communication.

Les ingénieurs du support technique doivent savoir lire les fichiers du suivi réseau et comprendre la négociation IKE. Les serveurs doivent être équipés du logiciel Moniteur réseau de Windows. Le Moniteur réseau de Windows 2000 permet l'analyse d'IPSec AH et d'IKE. Windows Server 2003 ajoute la prise en charge de l'analyse IPSec ESP null, l'analyse d'ESP lorsque le chiffrement est déchargé et l'analyse de l'encapsulation UDP-ESP utilisée pour NAT traversal.

Jeu d'outils de dépannage

Avant de commencer les opérations de dépannage, il est important d'identifier les utilitaires capables de fournir des informations en vue de faciliter le processus de dépannage. Cette section ne vise pas à dupliquer les informations disponibles dans l'aide de Windows 2000, Windows XP ou Windows Server 2003 accessible via la page Troubleshooting tools (Outils de dépannage)  du site Web de Microsoft Windows Server™ 2003 à l'adresse www.microsoft.com/resources/documentation/
WindowsServ/2003/standard/proddocs/en-us/
sag_IPSec_tools.asp.

Les informations détaillées sur les outils sont uniquement fournies dans cette section pour le cas où elles ne seraient pas facilement accessibles dans la page Troubleshooting tools ou lorsqu'il est utile de disposer de résumés sur les différentes versions des systèmes d'exploitation.

Composant logiciel enfichable MMC Gestion de stratégie de sécurité IP

Le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP permet de créer et de gérer les stratégies IPSec locales ou les stratégies IPSec stockées dans le service d'annuaire Active Directory. Il sert également à modifier la stratégie IPSec sur les ordinateurs distants. Le composant MMC Gestion de stratégie de sécurité IP est inclus dans les systèmes d'exploitation Windows Server 2003, Windows XP, Windows 2000 Server et Windows 2000 Édition Professionnel, et il peut être utilisé pour afficher et modifier les détails de la stratégie IPSec, les filtres, les listes de filtres et les actions de filtrage IPSec, ainsi que pour attribuer ou supprimer l'attribution de stratégies IPSec.

Composant logiciel enfichable MMC Moniteur de sécurité IP

Le composant MMC Moniteur de sécurité IP affiche les statistiques IPSec et les associations de sécurité actives. Il permet également d'afficher des informations sur les composants IPSec suivants :

• le mode principal et le mode rapide IKE ;

• les stratégies IPSec locales ou de domaine ;

• les filtres IPSec qui s'appliquent à l'ordinateur.  

Bien que ce composant logiciel enfichable fasse partie des systèmes d'exploitation Windows XP et Windows Server 2003, il existe des différences dans les fonctionnalités et les interfaces de ces deux versions. En outre, la version Windows Server 2003 possède les fonctions supplémentaires suivantes :

• Windows Server 2003 propose des détails sur la stratégie IPSec active : nom, description, date de dernière modification, emplacement, chemin, UO et nom d'objet de stratégie de groupe. Pour obtenir ces informations sous Windows XP, vous devez utiliser l'utilitaire de ligne de commande IPSeccmd (décrit ultérieurement).

• Des statistiques sont fournies séparément pour le mode principal et le mode rapide dans des dossiers situés sous chaque mode, et non dans un seul affichage.

  Remarque : sous Windows 2000, l'outil Moniteur de sécurité IP est un programme exécutable indépendant (IPSecmon.exe) disposant de sa propre interface graphique utilisateur. Vous trouverez des informations sur cet outil et son utilisation dans l'article 257225 Basic IPSec troubleshooting in Microsoft Windows 2000 Server (Résolution élémentaire des problèmes liés à IPSec sous Windows 2000)  de la Base de connaissances Microsoft à l'adresse https://support.microsoft.com/kb/257225.

Une mise à jour de ce composant logiciel enfichable est disponible pour Windows XP en tant que partie de la mise à jour décrite dans l'article 818043 L2TP/IPSec NAT-T update for Windows XP and Windows 2000 (Mise à jour NAT-T pour le protocole L2TP et la sécurité IP dans Windows XP et Windows 2000)  de la Base de connaissances Microsoft à l'adresse https://support.microsoft.com/?kbid=818043. Grâce à cette mise à jour, il est possible d'afficher les ordinateurs Windows Server 2003 à partir de Windows XP. Le composant logiciel enfichable MMC Moniteur de sécurité IP mis à jour peut également lire les fonctions avancées créées sous Windows Server 2003 (par exemple, les informations sur le groupe 2048 Diffie-Hellman, les mappages de certificats et les filtres dynamiques), mais il ne peut pas les modifier. Pour plus d’informations, reportez-vous à l’article de la Base de connaissances référencé.

Netsh

Netsh est un utilitaire de script de ligne de commande qui vous permet d'afficher ou de modifier la configuration réseau. Vous pouvez l'utiliser localement ou à distance. Netsh est disponible sous Windows 2000, Windows XP et Windows Server 2003. De plus, la version Windows Server 2003 a été améliorée afin de fournir des fonctions de gestion et de diagnostic IPSec. Les commandes Netsh pour IPSec sont uniquement disponibles pour Windows Server 2003 ; elles remplacent les commandes Ipseccmd de Windows XP et Netdiag de Windows 2000.

Ipseccmd

Vous pouvez utiliser l'utilitaire de ligne de commande Ipseccmd à la place du composant logiciel enfichable MMC Stratégie de sécurité IP. Il est uniquement disponible pour Windows XP. Windows XP Service Pack 2 fournit des fonctionnalités supplémentaires pour cet outil.

Ipseccmd doit être installé à partir du dossier Outils de support du CD d'installation de Windows XP. Une version mise à jour est disponible avec Windows XP SP2 et doit être installée à partir du dossier Outils de support du CD d'installation de Windows XP SP2. La version précédant la version SP2 ne fonctionne pas sur les ordinateurs mis à jour, et la version mise à jour ne fonctionne pas sur les ordinateurs antérieurs à SP2.

L'utilitaire Ipseccmd mis à jour est doté des fonctionnalités suivantes :

• il active et désactive la journalisation d'IKE de façon dynamique ;

• il affiche des informations sur une stratégie actuellement attribuée ;

• il vous permet de créer une stratégie IPSec de longue durée ;

• il peut afficher la stratégie IPSec actuellement attribuée et active.

Pour plus d'informations sur l'utilitaire Ipseccmd mis à jour, reportez-vous à l'article 818043 (cité plus haut) de la Base de connaissances Microsoft.

Pour afficher tous les paramètres de la stratégie IPSec et les statistiques de diagnostic, utilisez la syntaxe suivante :

ipseccmd show all

Pour afficher les stratégies IPSec actuellement attribuées et actives (locales ou placées dans Active Directory), utilisez la syntaxe suivante :

ipseccmd show gpo

Remarque : cette commande fonctionne uniquement avec la version SP2.

Pour activer la journalisation du débogage sur Windows XP SP2, utilisez la syntaxe suivante :

    ipseccmd set logike  (le redémarrage du service IPSec n'est pas requis)

Pour désactiver la journalisation du débogage, utilisez la syntaxe suivante :

    ipseccmd set dontlogike  (le redémarrage du service IPSec n'est pas requis)

Remarque : seul Ipseccmd vous permet d'activer la journalisation Oakley sous Windows XP SP2 ; les commandes ci-dessus ne fonctionnent pas sur des ordinateurs antérieurs à la version SP2.

Netdiag

Netdiag est un utilitaire de ligne de commande d'exécution de diagnostics utilisé pour tester la connectivité et la configuration réseau, y compris les informations IPSec. Netdiag est disponible avec Windows 2000, Windows XP et Windows Server 2003, mais sa fonctionnalité change en fonction de la version du système d'exploitation. Sous Windows Server 2003, Netdiag n'inclut plus la fonctionnalité IPSec, mais vous pouvez utiliser le contexte netsh ipsec à la place et utiliser Netsh pour les tests réseau de base. Vous devez vous assurer que vous utilisez la version la plus récente de votre système d'exploitation en procédant à une vérification via le Centre de téléchargement Microsoft. Netdiag doit être installé à partir du dossier Outils de support du CD du système d'exploitation utilisé.

Remarque : Netdiag n'est pas mis à jour lors de l'installation de Windows XP SP2.

La pertinence du dépannage d'IPSec par Netdiag dépend de la version du système d'exploitation. Les différences en termes de fonctionnalités sont décrites dans le tableau suivant.

Tableau 7.1: Fonctionnalité Netdiag IPSec sous différents systèmes d'exploitation

Commande	Description	Windows 2000 ?	Windows XP ?	Windows 2003 ?
netdiag /test:ipsec	Affiche la stratégie IPSec attribuée	Oui	Oui	Non**
netdiag /test:ipsec /debug	Affiche la stratégie IPSec active, les filtres et les statistiques du mode rapide	Oui	Oui*	Non**
netdiag /test:ipsec /v	Affiche la stratégie IPSec active, les filtres et les statistiques du mode principal	Oui	Oui*	Non**

* Fournit des diagnostics réseau, mais affiche le nom de la stratégie IPSec uniquement. L'utilisation d'Ipseccmd permet d'obtenir des informations IPSec supplémentaires.

** Fournit des diagnostics réseau, mais n'affiche aucune information IPSec. Vous devez utiliser la syntaxe suivante : netsh ipsec dynamic show all.

Autres outils utiles à la prise en charge d'IPSec

En plus des outils spécifiques à IPSec cités précédemment, le tableau ci-dessous répertorie d'autres outils qui peuvent se révéler utiles et qui doivent être inclus à votre jeu d'outils de dépannage de niveau 2.

Tableau 7.2 : Outils divers permettant le dépannage d'IPSec

Outil	Systèmes d'exploitation pris en charge	Obtention	Rôle	Informations complémentaires
Ipsecpol.exe	Windows 2000 uniquement	Kit de ressources de Windows 2000	Configure les stratégies IPSec dans l'annuaire ou un registre	Aide contenue dans les outils du kit de ressources de Windows 2000
Gpresult	Windows 2000, Windows Server  2003, Windows XP	Kit de ressources Windows 2000 ; pour Windows XP et Windows Server  2003, Gpresult fait partie du système d'exploitation	Indique quand la stratégie de groupe a été appliquée pour la dernière fois	Aide contenue dans les outils du kit de ressources de Windows 2000, Aide de Windows XP et de Windows Server  2003
Composant logiciel enfichable MMC Jeu de stratégie résultant (Resultant Set of Policy, RSoP)	Windows Server  2003, Windows XP	Inclus dans le système d'exploitation	Affiche la stratégie IPSec d'un ordinateur ou des membres d'un conteneur de stratégie de groupe	Windows Server  2003
Srvinfo	Kits de ressources Windows 2000, Windows Server  2003, Windows XP	Windows 2000 et Windows Server  2003	Fournit des informations sur les services, pilotes de périphériques et protocoles	Aide contenue dans les outils du kit de ressources de Windows Server  2003
PortQry	Kits de ressources Windows 2000, Windows Server  2003, Windows XP	Windows Server  2003	Génère des rapports sur l'état des ports réseau	http://support. microsoft.com/ kb/310099
NLTest	Kits de ressources Windows 2000, Windows Server  2003, Windows XP	Outils de support	Teste les relations d'approbation et les canaux Netlogon sécurisés	Aide contenue dans les outils du kit de ressources de Windows Server  2003
Klist	Kits de ressources Windows 2000, Windows Server  2003, Windows XP	Windows 2000 et Windows Server  2003	Génère des rapports sur les tickets Kerberos	Aide contenue dans les outils du kit de ressources de Windows Server  2003
Pathping	Kits de ressources Windows 2000, Windows Server  2003, Windows XP	Inclus dans le système d'exploitation	Teste les chemins d'accès et la connectivité réseau	Aide de Windows
LDP	Kits de ressources Windows 2000, Windows Server  2003, Windows XP	Outils de support	Teste le client LDAP pour Active Directory	Aide contenue dans les outils du kit de ressources de Windows Server  2003

Utilisation d'outils ICMP avec IPSec

Les outils Ping, Pathping et Tracert de Windows XP et de Windows Server 2003 reconnaissent IPSec, mais ils peuvent ne pas fonctionner correctement tant que des associations de sécurité n'ont pas été établies (si la communication en texte clair est autorisée). Si des associations de sécurité IPSec étaient négociées avec succès pour encapsuler le trafic ICMP utilisé par ces utilitaires, elles ne seraient pas en mesure de détecter des sauts (routeur) intermédiaires entre le client et la destination. Les calculs relatifs à la perte de paquets concernant l'outil Ping peuvent indiquer les paquets perdus pendant la durée requise par IKE pour négocier avec succès une association de sécurité IPSec avec la cible. Les calculs sur la perte de paquets pour chaque saut intermédiaire ne sont pas disponibles lorsque le trafic ICMP est encapsulé par IPSec.

Ces utilitaires ICMP sont conçus pour détecter si le pilote IPSec correspondait à un filtre IPSec pour le paquet de demande d'écho ICMP sortant et nécessitait ainsi une négociation de sécurité IKE. Lorsque cela se produit, le message « Négociation de la sécurité IP » est affiché par l'utilitaire. Un bogue connu de Windows 2000 empêche l'utilitaire Ping d'attendre autant que nécessaire avant de tenter une nouvelle demande d'écho, ce qui signifie que la commande peut s'achever immédiatement au lieu d'attendre trois secondes pour que la SA logicielle soit établie. L'utilitaire Ping de Windows XP et de Windows Server 2003 attend le temps nécessaire avant d'envoyer la demande d'écho suivante.

Le message « Négociation de la sécurité IP » ne s'affiche pas lorsque :

• le pilote IPSec abandonne le paquet ICMP sortant en raison d'un filtre bloquant ;

• le pilote IPSec autorise le transfert du paquet ICMP non sécurisé en raison d'un filtre d'autorisation ou d'une SA logicielle ;

• le pilote IPSec ne détecte pas le paquet sortant (par exemple, s'il a été abandonné par les couches situées au-dessus du pilote).

  Remarque : certains outils utilisant ICMP ne sont pas capables de détecter qu'IPSec négocie la sécurité et peuvent produire des résultats incohérents ou erronés.

Processus de dépannage d'IPSec

Si le support de niveau 1 a clairement identifié un problème, le support de niveau 2 sera en mesure de trouver rapidement la procédure de dépannage appropriée dans les sections suivantes. Dans ce modèle, le support de niveau 1 traite principalement les problèmes d'accès du client. En général, les propriétaires administratifs de serveurs sont capables d'effectuer des diagnostics de connectivité réseau de base et peuvent ignorer le niveau 1. Cependant, chaque entreprise doit ajuster le modèle en fonction de son environnement de support. Le support de niveau 2 doit se concentrer sur l'identification du point d'échec de la communication, puis rechercher des causes associées dans l'architecture du système.

Si votre entreprise utilise les scripts fournis dans le cadre du processus de dépannage, vous aurez accès à un certain nombre de fichiers journaux au format texte qui vous aideront à diagnostiquer le problème. Le tableau suivant présente la description des fichiers générés par le script.

Tableau 7.3 : Fichiers générés par le script IPSec_Debug.vbs

Nom de fichier	Description
<NomOrdin>_FileVer.txt	Liste des versions de fichier de plusieurs DLL associées à IPSec.
<NomOrdin>_gpresult.txt	Résultat de la commande gpresult.
<NomOrdin>_ipsec_547_events.txt	Affiche le résultat de n'importe quelle erreur IPSEC 547 dans le journal des événements de sécurité.
<NomOrdin>_ipsec_policy_version.txt	Résultat du script Detect_IPSec_Policy.vbs. Affiche la version de la stratégie actuelle et indique si elle correspond à la stratégie Active Directory.
<NomOrdin>_ipseccmd_show_all.txt	Uniquement pour Windows XP. Ce fichier capture le résultat de la commande ipseccmd.
<NomOrdin>_kerberos_events.txt	Affiche le résultat de n'importe quel événement Kerberos dans le journal des événements système.
<NomOrdin>_klist_purge_mt.txt	Résultat de KList lors de la purge des tickets d'ordinateur.
<NomOrdin>_lsass.log	Copie du fichier lsass.log, s'il est présent.
<NomOrdin>_netdiag.txt	Résultat de l'exécution de netdiag.
<NomOrdin>_netsh_show_all.txt	Uniquement sur les plates-formes serveur. Résultat de l'exécution de la commande show all dans netsh.
<NomOrdin>_netsh_show_gpo.txt	Uniquement sur les plates-formes serveur. Résultat de l'exécution de la commande show gpo dans netsh.
<NomOrdin>_oakley.log	Copie du fichier Oakley.log, s'il est présent.
<NomOrdin>_OSInfo.txt	Sortie des informations du système d'exploitation actuel.
<NomOrdin>_RegDefault.txt	Résultat des valeurs de la clé de registre d'origine avant leur modification. Peut être utilisé pour rétablir manuellement les valeurs précédentes du registre si le script échoue.
<NomOrdin>_userenv.log	Copie du fichier userenv.log, s'il est présent.
<NomOrdin>_<SrvName>_netview.txt	Résultat de l'exécution de la commande net view sur <NomSrv>.
<NomOrdin>_<SrvName>_ping.txt	Résultat de l'exécution de la commande ping sur <NomSrv>.
<NomOrdin>_winlogon.log	Copie du fichier winlogon.log, s'il est présent.

Étant donné qu'il existe plusieurs points d'échec potentiels, cette section traite chaque composant architectural dans l'ordre, à commencer par la connectivité réseau. Les procédures définies vous aideront à effectuer les tâches suivantes :

• vérifier la configuration du réseau IP, la connectivité réseau et le service avec les contrôleurs de domaine ainsi que la connectivité du chemin client/serveur pour les protocoles liés à IPSec ;

• vérifier que les stratégies de groupe et IPSec sont correctement appliquées sur le client et le serveur ;

• identifier les problèmes liés à la négociation IKE et à la communication protégée par IPSec ;

• identifier la cause d'un problème en vue du transfert vers le support de niveau 3, si nécessaire.  

Prenons l'exemple suivant : un client indique qu'il est capable d'exécuter une commande ping sur un serveur mais qu'il ne peut pas se connecter à un partage de fichiers sur ce serveur. Il s'agit du seul serveur auquel le client ne peut pas accéder. Une recherche rapide dans le journal de sécurité de l'événement 547 (échec de la négociation IKE) contenant l'adresse IP du serveur indique que le client a une stratégie IPSec et qu'IKE est en cours d'initialisation. Si l'événement 547 indique que le délai de négociation IKE du client a expiré, cela signifie que la négociation IKE du serveur a certainement échoué. Le support de niveau 2 doit alors effectuer des recherches dans la base de données d'événements MOM relatives aux événements 547 collectés à partir du serveur spécifié, lesquels contiennent l'adresse IP du client actuel.

Avertissement - Démarrage et arrêt du service IPSec

Le document Windows Server 2003 TCP/IP Troubleshooting (Dépannage de TCP/IP sous Windows Server 2003) ainsi que les autres références expliquent comment savoir si IPSec est responsable d'un problème de connectivité en arrêtant le service IPSec. Cet arrêt interrompt le filtrage IPSec sur l'ordinateur, désactive la protection fournie par IPSec, expose l'ordinateur à un accès réseau non approuvé et désactive la protection des paquets. En outre, dans un environnement d'isolation de domaines, le trafic TCP et UDP non protégé par IPSec sera abandonné par les autres membres du domaine. Si IPSec est désactivé sur un ordinateur, cela entraînera des interruptions de connectivité avec les ordinateurs distants disposant actuellement d'associations de sécurité IPSec. Lorsque le service IPSec est interrompu, IKE envoie des notifications de suppression pour toutes les associations de sécurité IPSec et pour l'association de sécurité IKE à tous les ordinateurs connectés. Les ordinateurs distants disposant d'une stratégie IPSec autorisant les communications en texte clair rétablissent la connectivité après un délai de trois secondes. Les ordinateurs distants disposant d'une stratégie IPSec n'autorisant pas les communications en texte clair ne seront pas en mesure de communiquer.

C'est pourquoi il est important d'utiliser les techniques citées dans les sections suivantes pour résoudre les problèmes d'isolation sans interrompre le service IPSec. Le service IPSec doit être désactivé uniquement en dernier recours pour éliminer les problèmes liés à IPSec dans les situations suivantes :

• environnements de trafic de diffusion et de multidiffusion ;

• connexions à des ordinateurs distants ne nécessitant pas IPSec pour un accès entrant (par exemple, les ordinateurs membres de la liste d'exemption).  

Sous Windows 2000, l'arrêt du service IPSec dissocie le pilote IPSec de TCP/IP et décharge le pilote IPSec de la mémoire.

Sous Windows XP et Windows Server 2003, l'arrêt du service IPSec supprime tous les filtres du pilote IPSec et définit le mode du pilote sur AUTORISER. Le pilote IPSec n'est pas déchargé de la mémoire. Pour éviter le chargement du pilote IPSec, il faut que le service IPSec soit désactivé et que l'ordinateur ait redémarré.

Sous Windows 2000 et Windows XP SP1, la journalisation d'IKE dans le fichier Oakley.log requiert le redémarrage du service IPSec. L'arrêt du service n'est pas nécessaire pour activer et désactiver la journalisation d'IKE dans le fichier Oakley.log sous Windows XP SP2 et Windows Server 2003. La toute dernière mise à jour d'Ipseccmd pour Windows XP SP2 propose la syntaxe
ipseccmd set logike et ipseccmd set dontlogike qui permettent d'activer/désactiver la journalisation d'IKE dans le fichier Oakley.log. La journalisation d'IKE sous Windows Server 2003 peut être activée dynamiquement par l'utilisation des commandes Netsh décrites dans l'aide en ligne.

Vérification de la connectivité réseau

Si le support de niveau 1 identifie d'éventuels problèmes de connectivité réseau, alors la première étape consiste à déterminer si une connectivité réseau de base existe. Pour ce faire, vous devez vérifier que la configuration IP appropriée est utilisée, que le chemin réseau entre l'ordinateur initiateur et l'ordinateur répondant est valide et que les services de résolution de noms fonctionnent.

Problèmes de configuration de l'adresse IP du réseau

Si la configuration IP dynamique n'a pas réussi ou si les communications sont bloquées après le redémarrage de l'ordinateur (ou dans des conditions normales d'utilisation), le problème peut être dû à IPSec. Sous Windows Server 2003, ce type de problème peut être lié au comportement à tolérance de pannes d'IPSec (par exemple, si l'ordinateur est démarré en mode sans échec ou en mode de récupération Active Directory).

Remarque : pour obtenir des détails sur le comportement à tolérance de pannes de Windows Server 2003, reportez-vous à la section Understanding IPSec Protection During Computer Startup (Comprendre la protection IPSec au démarrage de l'ordinateur)  du module Deploying IPSec (Déploiement d'IPSec) du kit de déploiement de Windows Server 2003 à l'adresse www.microsoft.com/resources/
documentation/WindowsServ/2003/all/deployguide/
en-us/dnsbj_ips.asp.

Windows Server 2003 a recours au comportement à tolérance de pannes si le service IPSec ne peut pas démarrer correctement ou s'il ne peut pas appliquer la stratégie attribuée. Le comportement à tolérance de pannes s'applique uniquement lorsqu'une stratégie IPSec est attribuée à l'ordinateur et que le service IPSec n'est pas désactivé. Cela signifie que la connectivité vers ou à partir d'un ordinateur pourrait échouer dans des conditions normales car le pilote IPSec n'applique pas la stratégie IPSec basée sur domaine. Une fois que vous avez déterminé quel trafic est autorisé et bloqué par le mode d'amorçage et les configurations persistantes, un échec de communication peut être facile à expliquer. Pour obtenir d'autres informations ou des informations complémentaires, vous pouvez interroger l'état actuel à partir de la ligne de commande à l'aide de la syntaxe suivante :

netsh ipsec dynamic show config

Sous Windows Server 2003, le pilote IPSec est chargé au démarrage de l'ordinateur avec le pilote TCP/IP. Par conséquent, pour supprimer le comportement à tolérance de pannes du pilote IPSec, vous devez désactiver le service IPSec et redémarrer l'ordinateur. Le chapitre cité plus haut qui est consacré au déploiement d'IPSec présente la configuration recommandée des exemptions d'amorçage afin d'exempter les connexions RDP (Remote Desktop Protocol, protocole bureau distant) entrantes, ce qui permet de garantir que l'accès distant au serveur est disponible lorsque tout autre trafic est bloqué.

Dans une solution d'isolation de serveurs et de domaines, le trafic de diffusion et le trafic vers les serveurs DHCP est exempt pour garantir que la configuration IP dynamique fonctionne correctement. Cependant, la liste d'exemption doit être mise à jour manuellement et peut devenir obsolète. Si un ordinateur ne peut pas obtenir de configuration DHCP correcte (par exemple, s'il utilise une adresse IP de configuration automatique 169.254.x.x) ou s'il rencontre des problèmes de renouvellement de bail, vous devez alors étudier la stratégie IPSec pour déterminer les exemptions appropriées. Lorsque le service IPSec est en cours d'exécution, utilisez la commande Ipconfig pour confirmer qu'il n'y a aucun problème d'obtention d'adresse :

• Pour les clients DHCP, ouvrez une fenêtre de commande et tapez ipconfig /release suivi de ipconfig /renew.

Si les problèmes de configuration d'adresses se produisent uniquement au démarrage de l'ordinateur sous Windows XP SP2 et Windows Server 2003, la configuration des exemptions (exemptions par défaut et exemptions d'amorçage par défaut) doit être examinée.

Problèmes de résolution de noms

La conception de stratégie IPSec utilisée dans les scénarios d'isolation de serveurs et de domaines ne doit pas interférer avec les procédures types utilisées pour déterminer si la résolution de noms fonctionne. Par exemple, dans le scénario Woodgrove Bank, la conception de stratégie IPSec exempt tout le trafic vers les serveurs DNS et WINS. Toutefois, il est possible que les serveurs DNS et WINS soient configurés pour ne pas répondre aux requêtes Ping. Répondez aux questions suivantes pour confirmer que la résolution de noms fonctionne correctement lorsque le service IPSec est en cours d'exécution :

• Le client peut-il envoyer une requête ping à l'adresse IP du serveur DNS indiquée dans sa configuration IP ?

• La commande nslookup permet-elle de trouver un serveur DNS ?

• Le client peut-il envoyer une requête ping au nom DNS complet de l'ordinateur cible ?

• Le client peut-il envoyer une requête ping au nom DNS ou NetBIOS abrégé de l'ordinateur cible ?

À l'origine des problèmes potentiels de résolution de noms figurent la configuration incorrecte et l'activation du fichier HOSTS, la configuration incorrecte de l'entrée du serveur DNS dans les propriétés IP, des enregistrements DNS incorrects, des problèmes de mise à jour des fichiers de zone, des problèmes de réplication Active Directory, la communication en texte clair utilisée pour les serveurs DNS et des problèmes de mise à jour automatique de DHCP.

Les raisons possibles des échecs de la résolution de noms NetBIOS sont la configuration incorrecte et l'activation du fichier LMHOSTS, la configuration incorrecte de l'entrée du serveur WINS dans les propriétés IP, l'indisponibilité du serveur WINS, l'enregistrement WINS incorrect, des problèmes de réplication WINS, des échecs du proxy WINS et des délais d'expiration réseau pour le serveur WINS.

Pour consulter des procédures d'aide au dépannage du DNS intégré à Active Directory, reportez-vous à la page Troubleshooting Active Directory - Related DNS Problems (Dépannage d'Active Directory - Problèmes DNS connexes)  sur le site de Microsoft.com à l'adresse www.microsoft.com/technet/prodtechnol/
windows2000serv/technologies/activedirectory/
maintain/opsguide/part1/adogd10.mspx.

Certains environnements exigeant une sécurité élevée peuvent nécessiter la protection des serveurs DNS et WINS par IPSec, ce qui peut entraîner des problèmes de résolution de noms. Par exemple, si le DNS est intégré à Active Directory et s'il existe des filtres dupliqués pour la même adresse IP dans la stratégie IPSec, un filtre peut négocier la sécurité pour le serveur DNS et l'autre exempter les contrôleurs de domaine. Pour plus d'informations, reportez-vous à la section Dépannage de la stratégie IPSec plus loin dans ce chapitre.

Si le problème de résolution de noms persiste, vous pouvez obtenir la liste des filtres de l'initiateur et vérifier s'il existe des filtres dupliqués. Vous pouvez utiliser les options de ligne de commande suivantes pour afficher les listes de filtres pour cette tâche :

Ipseccmd show filters
Netsh ipsec static show all 

Si le problème de résolution de noms persiste, arrêtez brièvement le service IPSec (si possible) lorsque les tests sur la résolution de noms sont répétés. Si les tests de résolution de noms échouent uniquement lorsque le service IPSec est en cours d'exécution, vous devez continuer vos recherches pour savoir quelle stratégie IPSec est appliquée (voir les explications plus loin dans cette section).

Vérification de la connectivité et de l'authentification avec les contrôleurs de domaine

Étant donné que la transmission de la stratégie IPSec, l'authentification IKE et les protocoles de niveau supérieur dépendent de l'accès aux contrôleurs de domaine, des tests de connectivité réseau et de bon fonctionnement des services d'authentification doivent être réalisés avant les étapes de dépannage d'IPSec spécifiques (voir la section suivante). Dans le scénario Woodgrove Bank, la conception de la stratégie IPSec exempt tout le trafic vers tous les contrôleurs de domaine ; les tests de connectivité réseau pour les contrôleurs de domaine ne devraient donc pas être affectés par IPSec. Toutefois, la liste des adresses IP du contrôleur de domaine de la liste d'exemption doit être mise à jour manuellement. Si la négociation IKE est visible pour une adresse IP de contrôleur de domaine, alors la stratégie IPSec peut ne pas être correctement attribuée ou ne pas être mise à jour.

Pour dépanner l'accès aux services réseau dans Active Directory

• Assurez-vous que le client peut envoyer une requête ping à chaque adresse IP du contrôleur de domaine. Si ce n'est pas le cas, reportez-vous aux étapes de connectivité réseau ci-dessus.

• Identifiez les adresses IP utilisées pour les contrôleurs du membre du domaine. Utilisez la commande nslookup <nom domaine> pour obtenir la liste complète des adresses IP. Un scénario d'isolation de serveurs et de domaines doit prévoir un filtre spécifique au mode rapide avec une stratégie de négociation (action de filtrage) autoriser pour chacune de ces adresses.

• Utilisez l'outil portqry.exe version 2.0 ou ultérieure ou l'outil PortQueryUI pour tester l'accès aux ports UDP, LDAP et RPC du contrôleur de domaine. Les messages du protocole UDP utilisés par l'outil portqry ne requièrent généralement pas l'authentification du protocole de niveau supérieur ; ils peuvent donc vérifier la disponibilité du service même si l'authentification n'est pas disponible. Ces étapes sont expliquées à la page HOW TO: Use Portqry to Troubleshoot Active Directory Connectivity Issues (COMMENT FAIRE : Utilisation du Portqry pour la résolution des problèmes de connectivité de Active Directory) , disponible à l'adresse https://support.microsoft.com/?kbid=816103.

• Lorsque vous êtes connecté au réseau interne, utilisez la commande netdiag /v >outputfile.txt pour effectuer divers tests de connectivité liés à DNS et au contrôleur de domaine. L'utilitaire Netdiag utilise plusieurs connexions réseau et protocoles pour réaliser les tests ; si l'une de ces connexions déclenche des négociations IKE et que l'authentification échoue parce que IKE ne réussit pas à localiser un contrôleur de domaine pour l'authentification IKE, l'erreur de l'événement 547 peut être consignée dans le journal de sécurité.

L'outil de support klist.exe de Windows peut être utilisé pour vérifier que la connexion et l'authentification Kerberos ont réussi. L'outil Klist doit être exécuté dans le contexte du système local pour que vous puissiez afficher les tickets Kerberos de l'ordinateur.

Pour afficher les tickets de service Kerberos pour l'utilisateur de domaine connecté

• Ouvrez une invite de commande et tapez ce qui suit :

  klist tickets
  

Pour afficher les tickets de l'ordinateur du domaine

1. Vérifiez que le service Planificateur de tâches est en cours d'exécution et que l'utilisateur connecté fait partie du groupe Administrateurs local.

2. À une invite de ligne de commande, choisissez une heure en avance d'une minute par rapport au temps système actuel (16:38, par exemple) et tapez ce qui suit :

   at 4:38pm /interactive cmd /k klist tickets
   

   Notez que la barre de titre de la fenêtre de commande contient C:\Windows\System32\svchost.exe.

Bien que les tickets Kerberos contiennent des informations sur le groupe de l'utilisateur ou de l'ordinateur, ces informations sont chiffrées afin qu'il soit impossible d'afficher les groupes. Par conséquent, les appartenances aux groupes doivent être confirmées manuellement par l'inspection des appartenances de groupe dans le service Active Directory. Pour vous assurer que les ordinateurs possèdent les informations d'appartenance aux groupes les plus récentes sur leurs tickets Kerberos, utilisez klist afin de purger les tickets Kerberos actuels. Lors de la nouvelle tentative de négociation IKE, les nouveaux tickets Kerberos seront obtenus automatiquement.

Pour purger les tickets Kerberos d'un ordinateur

(Les étapes 1 à 4 doivent être réalisées dans le contexte d'un système local.)

1. Vérifiez que le service Planificateur de tâches est en cours d'exécution et que l'utilisateur connecté fait partie du groupe Administrateurs local.

2. À une invite de ligne de commande, choisissez une heure en avance d'une minute par rapport au temps système actuel (16:38, par exemple) et tapez ce qui suit :

   at 4:38pm /interactive cmd
   

3. Tapez klist purge et appuyez sur O pour chaque type de ticket afin de supprimer tous les tickets Kerberos.

4. Tapez klist tickets pour confirmer qu'il n'existe aucun ticket.

5. Si cette procédure fait partie du dépannage de l'échec des négociations IKE, attendez une minute pour que le délai de négociation IKE soit écoulé puis reéssayez d'accéder au serveur cible avec l'application. Les nouvelles négociations IKE en mode principal nécessitent de nouveaux tickets d'attribution de tickets (ticket-granting ticket, TGT) Kerberos et des tickets de service pour l'ordinateur de destination, lequel disposera des informations les plus récentes sur les groupes. Veillez à ne pas exécuter l'application à partir de la fenêtre de commande exécutée dans le contexte du système local.  

Vous trouverez des procédures détaillées supplémentaires sur le dépannage de Kerberos dans les Livres blancs suivants :

• Troubleshooting Kerberos Errors  (Dépannage des erreurs Kerberos) à l'adresse www.microsoft.com/downloads/details.aspx?
  FamilyID=7dfeb015-6043-47db-8238-dc7af89c93f1&displaylang=en

• Troubleshooting Kerberos Delegation (Dépannage de la délégation Kerberos) à l'adresse  www.microsoft.com/downloads/details.aspx?
  FamilyID=99b0f94f-e28a-4726-bffe-2f64ae2f59a2&displaylang=en

Vérification des autorisations et de l'intégrité de la stratégie IPSec dans Active Directory

Il peut s'avérer nécessaire de vérifier les informations relatives au conteneur de la stratégie IPSec dans le service Active Directory. La procédure suivante utilise l'outil de support ldp.exe.

Pour vérifier les informations sur le conteneur de la stratégie IPSec

1. Cliquez sur Démarrer, Exécuter, tapez ldp.exe et appuyez sur ENTRÉE.

2. Sélectionnez Connexion, puis Connecter. Indiquez le nom du domaine cible.

3. Sélectionnez Connexion, puis Liaison. Indiquez les informations de connexion pour le domaine cible.

4. Sélectionnez Afficher, puis Arborescence. Vous pouvez soit n'indiquer aucun nom de domaine de base et rechercher le conteneur de la stratégie IPSec, soit spécifier le nom du domaine LDAP pour le conteneur de la stratégie IPSec comme emplacement de base.

5. Cliquez sur le symbole + en regard du nœud du conteneur dans l'arborescence. Si vous possédez des autorisations en lecture sur le conteneur, tous les objets de la stratégie IPSec qu'il contient s'affichent.

Remarque : selon la configuration des autorisations, il est possible que certains utilisateurs de domaine ne disposent pas des autorisations en lecture. Pour plus d'informations, reportez-vous à l'article 329194 IPSec Policy Permissions in Windows 2000 and Windows Server 2003 (Autorisations de stratégie IPSec dans Windows 2000 et Windows Server 2003)  de la Base de connaissances Microsoft à l'adresse https://support.microsoft.com/?kbid=329194.

Pour effectuer un dépannage avancé des problèmes d'extraction et de corruption de la stratégie, vous pouvez utiliser ldp.exe pour inspecter manuellement le contenu du conteneur IPSec et les relations existant entre les objets de la stratégie IPSec. Windows 2000, Windows XP et Windows Server 2003 utilisent le même schéma d'annuaire de base pour la stratégie IPSec, affiché dans le diagramme de la structure de la stratégie IPSec de la référence technique How IPSec Works  (Fonctionnement d'IPSec) de Windows Server 2003 disponible à l'adresse
WindowsServ/2003/all/techref/en-us/w2k3tr_ipsec_how.asp.

Le tableau suivant décrit les relations existant entre le nom de l'objet Active Directory et le nom du composant de la stratégie IPSec configuré dans le composant logiciel enfichable MMC Gestion de stratégie IPSec :

Tableau 7.4 : Association entre le nom du composant de la stratégie IPSec et le nom de l'objet Active Directory

Nom du composant de la stratégie IPSec	Nom de l'objet Active Directory
Stratégie de sécurité IP	ipsecPolicy{GUID}
Méthodes de sécurité Échange de clés IKE	ipsecISAKMPPolicy{GUID}
Règle IPSec	ipsecNFA{GUID}
Liste de filtres IPSec	ipsecFilter{GUID}
Action de filtrage IPSec	ipsecNegotiationPolicy{GUID}

L'utilitaire Ldp.exe permet de savoir à quel moment les objets de la stratégie IPSec ont été modifiés pour la dernière fois, ce qui peut aider à résoudre les problèmes de version d'objet et de réplication. Vous pouvez le lancer depuis une fenêtre de commande dans le contexte du système local afin de résoudre les problèmes d'autorisation en lecture du service IPSec.

Attention : il est fortement recommandé d'attribuer les mêmes permissions à tous les objets du conteneur de sécurité IP. Microsoft vous déconseille d'attribuer des autorisations aux objets de la stratégie IPSec sur une base individuelle. Pour contrôler l'accès en lecture et en modification de la stratégie IPSec, il est nécessaire de gérer les autorisations dans le conteneur IPSec, comme l'explique l'article 329194 IPSec Policy Permissions in Windows 2000 and Windows Server 2003  de la Base de connaissances à l'adresse https://support.microsoft.com/?kbid=329194.

La corruption de la stratégie de sécurité IP est la cause la plus courante à l'origine de situations dans lesquelles un objet IPSec contient une référence DN (Domain Name, nom de domaine) à un objet qui n'existe plus. Cependant, la corruption peut également se produire si des caractères de contrôle deviennent partie intégrante du nom d'un objet, si des objets individuels ne peuvent pas être lus en raison de problèmes d'autorisation ou si des noms identiques d'objets entraînent une conception inadéquate de la stratégie IPSec (par exemple, deux versions de la même liste de filtres). Reportez-vous à la section suivante sur le dépannage du service IPSec pour plus d'informations sur le dépannage de la corruption de la stratégie IPSec.

Remarque : les détails de conception de ces objets sont considérés comme une structure de données interne privée et ne sont pas publiés par Microsoft. Des différences existent au niveau du format de ces objets dans les diverses versions de Windows ; Microsoft est susceptible d'apporter des modifications à ces formats à tout moment. C'est pourquoi ces objets doivent uniquement être gérés à l'aide du composant logiciel enfichable MMC Gestion de stratégie IPSec et des outils de ligne de commande disponibles sur chaque plate-forme. Vous ne devez supprimer des objets au moyen de LDP qu'en dernier recours, lorsque la corruption empêche l'utilisation du composant MMC Gestion de stratégie IPSec ou des outils de ligne de commande.

Connectivité du chemin réseau

Microsoft vous recommande d'exempter le protocole ICMP dans le cadre de solutions d'isolation de serveurs et de domaines. Il existe plusieurs raisons à cette recommandation, notamment la nécessité d'utiliser ICMP pour tester le chemin réseau à l'aide des utilitaires Ping, Pathping et Tracert, par exemple. Ces utilitaires doivent par conséquent fonctionner correctement et ne pas afficher le message « Négociation de la sécurité IP ». Si ce message s'affiche, cela signifie qu'une stratégie IPSec inappropriée a peut-être été attribuée.

Pour déterminer si le problème est lié à une configuration réseau de base ou à la connectivité du chemin

• Le client peut-il envoyer une requête ping à sa propre adresse IP ou à l'adresse de boucle locale 127.0.0.1 ? Si la réponse est non, cela peut signifier qu'il existe un problème de configuration TCP/IP, qu'un pare-feu tiers a été installé, que l'utilitaire Ping est manquant ou que la configuration IP n'est pas valide. Utilisez d'autres procédures de dépannage de la configuration TCP/IP pour résoudre le problème.

• Le client peut-il envoyer une requête ping à la passerelle par défaut affichée dans sa configuration IP ? Si la réponse est non, cela peut signifier que la configuration IP du client est inopérante, que l'interface locale n'est pas connectée ou que sa connectivité est limitée, que des filtres réseau ou locaux bloquent le trafic ou que le chemin réseau vers la passerelle par défaut est interrompu. Utilisez d'autres procédures de dépannage du protocole TCP/IP pour résoudre le problème.

• Le client peut-il envoyer une requête ping aux serveurs DNS affichés dans sa configuration IP ? Si la réponse est non, cela peut signifier que les serveurs DNS ne s'autorisent pas à recevoir des messages de demande d'écho ICMP, que la stratégie IPSec n'exempt pas les adresses IP du serveur DNS appropriées ou que vous êtes en présence de l'un des problèmes mentionnés précédemment. Utilisez d'autres procédures de dépannage du protocole TCP/IP pour résoudre le problème.

• Le client peut-il envoyer une requête ping à une adresse IP de la liste d'exemption, un contrôleur de domaine, par exemple ? Si la réponse est non, cela signifie que le problème n'est pas lié à IPSec ou que IPSec ne possède pas de filtre pour cette adresse IP exemptée. Cette dernière hypothèse peut être confirmée par l'examen de la configuration des filtres. Reportez-vous à la section sur la stratégie IPSec plus loin dans ce chapitre.

• Le client peut-il envoyer une requête ping à l'adresse IP de la destination cible ? Si la réponse est oui, alors une connectivité réseau de base existe entre le client et la cible sans IPSec. Si la réponse est non, exécutez l'outil tracert sur l'adresse IP de la cible et d'autres adresses IP de destination pour déterminer le degré de validité du réseau. Utilisez d'autres procédures de dépannage du réseau et du protocole TCP/IP pour résoudre le problème.

Les tests de connectivité du chemin réussissent peut-être pour ICMP, sauf lors de l'utilisation des protocoles IKE ou IPSec. En particulier, la charge d'IPSec pour les paquets d'authentification en mode principal IKE contenant le ticket Kerberos est souvent plus importante que l'unité PMTU pour l'adresse IP de destination, qui requiert une fragmentation. Ainsi, les pare-feu pour hôte, le filtrage des routeurs, les pare-feu pour réseau et les filtres de l'hôte cible doivent être ouverts aux protocoles et ports suivants et prendre en charge la fragmentation :

• IKE. Port source UDP 500, port de destination 500 et fragments

• IKE/IPSec NAT-T. Port source UDP 4500, port de destination 4500

• IPSec ESP. Protocole IP 50 et fragments

• IPSec AH. Protocole IP 51 et fragments

Le filtrage avec état du chemin n'est pas recommandé

Le filtrage avec état peut entraîner des problèmes de connectivité pour IKE, AH et ESP car l'état est généralement basé sur des délais d'expiration d'activité. Les périphériques ne peuvent pas inspecter le trafic IKE pour savoir quand les associations de sécurité IPSec sont supprimées car ces messages sont chiffrés par IKE. Par définition, IKE est requis pour permettre la recomposition dans l'une ou l'autre direction, ce qui signifie que les messages de suppression peuvent être envoyés dans l'une ou l'autre direction. Si un message de suppression n'est pas reçu par l'une des extrémités, cette dernière risque de penser qu'une association de sécurité IPSec existe toujours alors que son homologue ne la reconnaît plus et rejette les paquets qui l'utilisent. La direction de la recomposition IKE est basée sur la direction du trafic qui utilise la durée de vie basée sur les octets plus rapidement, sur les petits décalages de recomposition lors de l'expiration des durées de vie basées sur le temps et sur la direction du flux des paquets après la suppression des SA IPSec inactives. Le filtrage avec état basé sur l'hôte du trafic IKE sur les clients qui initient les connexions (et donc les négociations IKE) via le pare-feu Windows ne provoque généralement pas de problème. Le pare-feu Windows ne filtre pas les paquets IPSec, car le pilote IPSec traite les paquets sur une couche inférieure à celle sur laquelle le filtrage du pare-feu est réalisé. Cependant, les ports IKE doivent être configurés « ouverts » dans le pare-feu hôte afin de recevoir les négociations IKE entrantes pour les connexions de protocole de niveau supérieur autorisées via le pare-feu (par exemple, pour le partage de fichiers utilisant le protocole SMB sur le port TCP  445).

Prise en charge de l'unité PMTU ICMP requise par le protocole TCP

Le paramètre par défaut sous Windows 2000 et les versions ultérieures pour chaque paquet TCP est le bit Ne pas fragmenter défini dans l'en-tête IP. Ce paramètre est conservé lorsque le mode de transport AH ou ESP IPSec est utilisé pour sécuriser le paquet. Par conséquent, un paquet trop important sera abandonné au niveau du routeur qui renverra un message ICMP destination inaccessible indiquant la taille maximale autorisée. Ce comportement est appelé recherche de l'unité maximale de transfert (MTU) du chemin TCP. L'ordinateur client et l'ordinateur cible doivent être capables de recevoir des messages PMTU ICMP pour les paquets IPSec trop volumineux. Il est important que le trafic protégé par IPSec évite la fragmentation, car l'accélération matérielle ne traite généralement pas les paquets fragmentés. Les paquets IPSec fragmentés doivent être traités par le pilote IPSec du logiciel.

Windows 2000 et Windows XP ne prennent pas en charge la recherche PMTU ICMP pour les paquets du mode de transport IPSec qui utilisent l'encapsulation NAT traversal (port UDP 4500). Windows Server 2003 prend en charge ce processus de recherche. Reportez-vous à la page Troubleshooting Translational Bridging (Dépannage du pont de conversion) dans la section TCP/IP Troubleshooting (Dépannage TCP/IP) de la documentation en ligne de Windows Server 2003 à l'adresse www.microsoft.com/resources/documentation/Windows/
2000/server/reskit/en-us/cnet/cnbd_trb_gdhe.asp pour connaître les options et outils qui fonctionnent sans la recherche PMTU.

Remarque : il existe un problème connu qui nécessite l'activation de la détection PMTU TCP pour que IPSec sécurise le trafic dans un scénario NAT traversal où les connexions UDP-ESP d'IPSec sont initiées par un hôte situé à l'extérieur du NAT vers un hôte situé derrière un NAT. Si ce scénario est requis, confirmez que la détection PMTU TCP est activée en vous assurant que la clé de registre suivante n'est pas définie ou qu'elle est définie sur 1 aux deux extrémités :
**    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\**
**    Parameters\EnablePMTUDiscovery=1**
    (Il est possible que cette clé s'affiche sur plusieurs lignes, mais il s'agit d'une seule ligne dans le registre.)
Le modèle de stratégie de sécurité de base du serveur membre sous Microsoft Windows Server 2003 ainsi que les configurations tierces peuvent configurer cette clé de registre pour désactiver PMTU TCP.

Prise en charge requise de la fragmentation

Les chemins réseau et les filtres doivent prendre en charge la transmission de fragments pour les protocoles IKE, IPSec, AH et ESP. IKE utilise les paquets UDP et leur permet d'être fragmentés selon les besoins. L'implémentation NAT traversal d'IPSec ajoute la prise en charge de l'évitement de la fragmentation IKE uniquement lorsque IKE s'authentifie au moyen de certificats (par exemple, dans des scénarios de réseau privé virtuel L2TP/IPSec). L'authentification IKE qui utilise Kerberos ne prend pas en charge l'évitement de la fragmentation et doit être capable d'envoyer et de recevoir des paquets UDP fragmentés contenant le ticket Kerberos.

Le chemin réseau doit prendre en charge la transmission des fragments pour les protocoles AH et ESP car IPSec sécurise le paquet IP d'origine complet avant la fragmentation sortante au niveau de la couche IP. IPSec est intégré à TCP afin que, dans le cas où les paquets TCP sont définis sur Ne pas fragmenter (paramètre par défaut), TCP réduise la taille de ses paquets pour recevoir les octets supplémentaires ajoutés par l'encapsulation d'IPSec.

IPSec n'est pas intégré à UDP et les applications UDP ne possèdent aucun moyen de détecter si IPSec protège leur trafic. Par conséquent, lorsque AH ou ESP IPSec est appliqué, les paquets UDP qui utilisent la taille totale de l'unité maximale de transfert sont fragmentés par l'hôte au moment de la transmission. D'une manière similaire, si les filtres de la stratégie IPSec n'exemptent pas ICMP, l'utilisation de l'outil Ping peut générer des paquets ICMP qui apparaissent en tant que paquets AH ou ESP IPSec fragmentés sur le réseau.

Pour plus d'informations, reportez-vous à l'article 233256 How to Enable IPSec Traffic Through a Firewall (Trafic via un pare-feu)  de la Base de connaissances Microsoft à l'adresse https://support.microsoft.com/?kbid=233256.

Prise en charge requise pour le trafic de diffusion et de multidiffusion

La conception de la stratégie IPSec dans le cadre de l'isolation de serveurs et de domaines utilise des filtres N'importe lequel <-> Sous-réseau. Ainsi, le filtre sortant Sous-réseau -> N'importe lequel correspondra au trafic de diffusion et de multidiffusion sortant envoyé par les hôtes à l'aide d'une adresse IP de sous-réseau interne. Toutefois, étant donné qu'IPSec ne peut pas sécuriser le trafic de diffusion ou de multidiffusion, il doit ignorer ce trafic s'il correspond au filtre. Le trafic de multidiffusion entrant ainsi que la plupart des trafics de diffusion ne correspondent pas au filtre entrant N'importe lequel -> Sous-réseau. Si le trafic de diffusion et de multidiffusion est requis, vous pouvez définir la clé de registre sur NoDefaultExempt=1, ce qui permet au trafic de diffusion et de multidiffusion d'éviter le filtrage IPSec sous Windows XP et Windows Server 2003. Cette configuration empêche l'apparition de problèmes connus avec les clients RTC (Real Time Communications, communications en temps réel) et le serveur Windows Media, qui utilisent tous deux le trafic de multidiffusion. Pour obtenir des détails sur l'utilisation et les implications en termes de sécurité de la clé de registre NoDefaultExempt, reportez-vous aux articles suivants de la Base de connaissances :

• 810207 IPSec default exemptions are removed in Windows Server 2003 (Les exemptions par défaut IPSec sont supprimées de Windows Server 2003)  à l'adresse https://support.microsoft.com/?kbid=810207

• 811832 - IPSec Default Exemptions Can Be Used to Bypass IPSec Protection in Some Scenarios (Les exemptions par défaut IPSec vous permettent d'ignorer la protection IPSec dans certains scénarios)  à l'adresse https://support.microsoft.com/?kbid=811832

  Remarque : Windows XP SP2 utilise les mêmes exemptions par défaut que Windows Server 2003.

La clé de registre peut être définie pour contrôler les exemptions par défaut sur toutes les plates-formes, selon les besoins. Le filtrage IPSec ne prend pas en charge la configuration des adresses de destination de diffusion ou de multidiffusion spécifiques.

Les diagnostics des périphériques réseau peuvent être inutiles

Avec l'utilisation de l'encapsulation IPSec, les applications qui supposent que le trafic TCP/IP est en texte clair ne peuvent plus inspecter le trafic du réseau. Il est peu probable que les outils de diagnostic réseau qui inspectent ou fournissent des rapports basés sur les ports TCP et UDP soient capables d'interpréter les paquets encapsulés par IPSec, même si le chiffrement AH ou ESP n'est pas utilisé. Des mises à jour de ces outils seront peut-être requises de la part des fournisseurs pour permettre l'inspection des paquets IPSec AH ou ESP-null.

Problèmes de carte d'interface réseau et de pilote

La perte de paquets IPSec peut parfois être provoquée par des cartes d'interface réseau (network interface cards, NIC) qui exécutent des fonctions spéciales. Vous devez tester les cartes qui effectuent des mises en cluster ou des regroupements pour savoir si elles sont compatibles avec IPSec. Les pilotes NIC qui accélèrent les fonctions non IPSec risquent de rencontrer des problèmes avec le trafic protégé par IPSec. Les cartes d'interface réseau qui accélèrent les fonctions TCP peuvent prendre en charge le calcul du total de contrôle TCP et la validation (déchargement du total de contrôle), ainsi que la possibilité d'envoyer efficacement des tampons de données TCP volumineux (déchargement d'envoi important). Windows 2000 et les versions ultérieures désactivent automatiquement ces fonctions de déchargement TCP dans la pile TCP/IP lorsque le pilote IPSec possède des filtres, même si IPSec effectue uniquement des fonctions autoriser et bloquer. Les pilotes de cartes réseau qui ne sont pas certifiés et signés par les laboratoires Microsoft de contrôle qualité du matériel (WHQL) risquent de provoquer des problèmes lorsque IPSec est utilisé pour protéger le trafic. Un jeu de tests étendu est utilisé par WHQL pour certifier les pilotes NIC conçus pour reconnaître le déchargement d'IPSec. Pour faciliter le dépannage, la pile TCP/IP de Windows 2000, Windows XP et Windows Server 2003 prend en charge une option de clé de registre permettant de désactiver toutes les formes de déchargement TCP/IP. Certains pilotes NIC prennent également en charge la désactivation du déchargement en utilisant les propriétés avancées de la connexion réseau. Vous devrez peut-être redémarrer votre ordinateur pour que les modifications de la configuration du pilote prennent effet.

Dépannage de la perte de paquets dans les protocoles IPSec

Les paquets peuvent être rejetés ou perdus, ce qui peut affecter la connectivité de l'application. Cette section détaille les cas courants de rejet des paquets par IPSec. Comme mentionné précédemment, certains périphériques réseau n'autorisent pas la transmission du protocole IP 50 ou 51 ou des ports UDP 500 ou 4500. De même, certains paquets encapsulés par IPSec peuvent se fragmenter et ne pas traverser le réseau. Dans ce cas de figure, un suivi de la surveillance réseau est généralement requis de la part des deux côtés de la communication pour permettre d'identifier et d'établir une corrélation entre les paquets envoyés et ceux reçus. Recherchez les transmissions signalées par des paquets de même taille apparaissant à plusieurs reprises. Il peut s'avérer nécessaire de réaliser un suivi du comportement type du protocole sans IPSec, puis de le comparer avec le comportement du protocole du trafic protégé par IPSec.

Erreur de l'événement 4285

Titre de l'événement : Échec d'authentification de hachage

IKE et IPSec offrent une protection contre la modification des paquets pendant qu'ils traversent le réseau. Si un périphérique modifie une partie du paquet protégé par un hachage d'intégrité, alors le pilote IKE ou IPSec récepteur rejettera ce paquet, ce qui entraînera l'erreur d'échec d'authentification de hachage consignée dans le journal système en tant qu'événement 4285. L'expérience a montré que certains périphériques, pilotes réseau et processeurs tiers de paquets endommagent parfois les paquets d'une taille donnée, ceux qui possèdent un certain nombre de fragments, ceux d'un certain type de protocole ou lorsque certaines conditions sont réunies (lorsque le périphérique est saturé, qu'il surveille le trafic ou qu'il redémarre). Cette erreur peut également être due à une attaque du paquet par une application malveillante ou par une application qui ignorait qu'il était protégé. Elle peut aussi indiquer une attaque par refus de service.

Vous pouvez utiliser les techniques suivantes pour détecter le rejet des paquets corrompus par IPSec. Cependant, il est également important d'établir une corrélation entre ces observations et le suivi de la surveillance du réseau pour permettre de détecter la source de la corruption.

• Examinez le compteur Paquets IPSec non authentifiés. Sous Windows Server 2003, vous pouvez vérifier ce compteur à l'aide du compteur IPSec de l'analyseur de performances, de la commande netsh ipsec dynamic show statsou en étudiant les statistiques du composant logiciel enfichable MMC Moniteur de sécurité IP. Sous Windows XP, vous pouvez vérifier ce compteur à l'aide de la commande ipseccmd show stats  ou en étudiant les statistiques du composant logiciel enfichable MMC Moniteur de sécurité IP. Sous Windows 2000, ce compteur apparaît dans l'affichage graphique d'ipsecmon.exe ou lorsque vous utilisez la commande
  netdiag /test:ipsec /v .

• Activez la journalisation du pilote IPSec et recherchez l'événement 4285 dans le journal système à partir d'IPSec source. Consultez la section Jeu d'outils de ce chapitre pour obtenir des détails sur la manière d'activer la journalisation du pilote IPSec. Le texte de l'événement sera similaire à ce qui suit :

  Échec lors de l'authentification du hachage de 5 paquet(s) reçu(s) de 192.168.0.10. Ce pourrait être un problème temporaire ; s'il persiste, arrêtez et redémarrez le service Agent de stratégie IPSEC sur cet ordinateur.  

Bien que le texte de l'événement suggère un redémarrage du service IPSec pour résoudre le problème, l'origine de la perte de la plupart des paquets n'est pas liée au système IPSec. Le redémarrage du service ne permettra pas de résoudre le problème et risque d'engendrer davantage de difficultés. Le service IPSec ne doit être arrêté qu'en dernier recours pour déterminer si un problème est lié à IPSec ou non.

La résolution de cette erreur requiert des recherches pour identifier un modèle des adresses IP source, des heures de la journée, des cartes réseau ou des conditions dans lesquelles l'erreur se produit. Si le nombre de paquets est peu élevé, il n'est peut-être pas utile d'effectuer des recherches. Il est important de commencer par exclure les sources de la corruption du système local. Désactivez le déchargement d'IPSec, essayez de désactiver les fonctions avancées ou de performances du pilote en utilisant la configuration fournie dans les propriétés avancées et procurez-vous les pilotes NIC les plus récents auprès de votre fournisseur. Utilisez de préférence des pilotes certifiés et signés par les laboratoires Microsoft de contrôle qualité du matériel. Étudiez ensuite les caractéristiques des chemins réseau via lesquels le paquet sera transmis. Recherchez d'autres preuves de la corruption du paquet dans les statistiques de rejet des paquets TCP/IP et sur les autres ordinateurs utilisant la même configuration. Le compteur IP des Datagrammes reçus et rejetés augmente chaque fois qu'IPSec rejette un paquet.

Remarque : pour désactiver la fonctionnalité de déchargement TCP/IP, utilisez la clé de registre suivante sur les ordinateurs exécutant Windows 2000, Windows XP ou Windows Server 2003 
**    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IPSEC\**
**    Valeur de registre EnableOffload DWORD définie sur 0**
    (Il est possible que cette clé s'affiche sur plusieurs lignes, mais il s'agit d'une seule ligne dans le registre.)
Redémarrez ensuite l'ordinateur.

Erreur de l'événement 4268

Titre de l'événement : Paquets reçus avec un index des paramètres de sécurité (Security Parameters Index, SPI) erroné

L'implémentation d'IKE sous Windows 2000 et Windows XP (y compris SP1) génère un problème connu qui entraîne la perte de paquets dans certaines conditions. Ce problème a été résolu pour Windows Server 2003 et Windows XP SP2. L'impact sur les communications du protocole de niveau supérieur est généralement négligeable car les protocoles subissent habituellement quelques pertes de paquets pour diverses autres raisons. Ce problème peut être identifié par les caractéristiques suivantes :

• Augmentation lente mais régulière des valeurs du compteur SPI erroné.

• Messages de l'événement 4268 dans le journal système (si activé). Par défaut, Windows 2000 consigne ces messages dans le journal système en tant qu'événement 4268. Windows XP ne consigne pas cet événement par défaut ; il faut que la journalisation du pilote soit activée. Le texte de l'événement est similaire à ce qui suit :

  <nombre> paquet(s) reçu(s) de <adresse ip> avec un index des paramètres de sécurité erroné. Ce pourrait être un problème temporaire ; s'il persiste, arrêtez et redémarrez le service Agent de stratégie IPSEC sur cet ordinateur.  

Bien que le texte de l'événement suggère un redémarrage du service IPSec pour résoudre le problème, l'origine de ce type de perte de paquets fait partie de la conception du système IPSec. Le redémarrage du service ne permettra pas de résoudre le problème et risque d'engendrer davantage de difficultés. Comme indiqué plus haut, le service IPSec ne doit être arrêté qu'en dernier recours pour déterminer si un problème est lié à IPSec ou non.

L'index des paramètres de sécurité IPSec est un indicateur du paquet qui informe le répondeur de l'association de sécurité à utiliser pour traiter le paquet. Si un SPI n'est pas reconnu, il est appelé « SPI erroné ».  Cette erreur signale que l'ordinateur récepteur a reçu des paquets formatés par IPSec alors qu'il ne disposait pas d'une association de sécurité IPSec pour les traiter. Par conséquent, l'ordinateur doit rejeter les paquets.

Ces messages d'erreur sont anodins, même si les paquets sont rejetés. Le nombre d'événements SPI erronés générés dépend du niveau d'activité des ordinateurs et de la rapidité de transmission des données protégées par IPSec au moment de la recomposition. Les conditions suivantes sont susceptibles de générer davantage d'événements de ce type :

• transfert de volumes importants de trafic IPSec via des connexions de 1 gigabit ou plus ;

• serveurs très encombrés (lents) et ordinateurs clients rapides ;

• clients lents communiquant avec un serveur rapide ;

• multiples clients actifs pour un serveur, ce qui oblige IKE à une recomposition constante avec plusieurs clients simultanément.  

Par conséquent, une connexion TCP protégée par IPSec va ralentir pendant quelques secondes pour retransmettre les données perdues. Si plusieurs paquets sont perdus, TCP risque de passer en mode d'évitement de saturation pour cette connexion. Après quelques secondes, la connexion doit retrouver sa vitesse normale. Pour les applications de copie de fichiers, Telnet, Terminal Server ainsi que les autres applications basées sur TCP, la perte de ces paquets passe inaperçue. Cependant, il peut arriver que TCP perde un groupe de paquets sur une liaison rapide et qu'il doive rétablir la connexion. Lorsque la connexion est rétablie, le socket est fermé et les applications sont averties de la rupture de connexion, ce qui peut interrompre les transferts de fichiers.

La cause la plus courante de cette erreur est un problème connu relatif à Windows 2000 qui implique le mode de synchronisation de la recomposition de la SA IPSec par IKE. Lorsque l'initiateur du mode rapide IKE est plus rapide que le répondeur, l'initiateur peut envoyer les nouveaux paquets sécurisés de l'association de sécurité IPSec plus rapidement que le répondeur ne peut les recevoir. Comme l'indique le document RFC (Requests for Comment, demande de commentaires) de l'IETF (Internet Engineering Task Force) relatif à IPSec, lorsque IKE établit une nouvelle association de sécurité IPSec, l'initiateur doit utiliser la nouvelle SA IPSec sortante pour transmettre les données alors que le répondeur plus lent reçoit le trafic protégé par IP qu'il ne reconnaît pas encore. Étant donné que la recomposition IKE dépend à la fois du temps écoulé et de la quantité de données envoyées sous la protection d'une SA IPSec, il est possible que des événements SPI erronés apparaissent périodiquement (mais pas nécessairement à des intervalles spécifiques).

Dans des scénarios d'interopérabilité de client tiers, une erreur de SPI erroné peut indiquer qu'un IPSec pair n'a pas accepté un message de suppression et ne l'a pas traité ou qu'il a rencontré des problèmes pour exécuter la dernière étape de la négociation du mode rapide IKE. Cette erreur peut également signifier qu'un attaquant submerge un ordinateur de paquets IPSec usurpés ou injectés. Le pilote IPSec compte ces événements et les consigne pour conserver un enregistrement de l'activité du SPI erroné.

La clé de registre LogInterval peut être utilisée pour identifier et minimiser ces événements. Lors du dépannage, définissez-la sur la valeur minimum (toutes les 60 secondes) pour que les événements soient enregistrés rapidement. Sous Windows 2000, vous pouvez arrêter et redémarrer le service Agent de stratégie IPSec pour recharger le pilote IPSec. Sous Windows XP et Windows Server 2003, vous devez redémarrer l'ordinateur pour recharger les pilotes TCP/IP et IPSec.

Sous Windows 2000, ces événements ne peuvent pas être supprimés par les paramètres de clé de registre actuels ou des correctifs. Par défaut, sous Windows XP et Windows Server 2003 ces événements ne sont pas signalés. Vous pouvez activer les rapports de ces événements en utilisant la configuration IPSecDiagnostics via l'option de ligne de commande netsh ipsec ou directement via la clé de registre.

Les techniques suivantes peuvent vous aider à minimiser ces erreurs :

• Ajustez les paramètres de la stratégie IPSec. Augmentez la durée de vie du mode rapide (si les exigences de sécurité le permettent) à 21 ou 24 heures (les associations de sécurité IPSec inactives sont effacées au bout de 5 minutes si elles ne sont pas utilisées). Pour éviter l'apparition de faiblesses potentielles au niveau de la sécurité due à l'utilisation de la même clé pour chiffrer trop de données, ne définissez pas une durée de vie supérieure à 100 Mo lorsque vous utilisez le chiffrement ESP.

• Utilisez la confidentialité de transmission parfaite (perfect forward secrecy, PFS) du mode principal ou du mode rapide qui ne provoque pas ce problème pour l'association de sécurité spécifique en cours de négociation. Cependant, ces paramètres augmentent considérablement la charge de l'ordinateur qui traite les requêtes de plusieurs clients et risquent ainsi de contribuer à accroître le délai de réponse aux autres négociations.

• Ajoutez un processeur ou un matériel permettant d'augmenter les performances ou de réduire les charges sur l'application.

• Installez une carte réseau d'accélération matérielle IPSec si l'ordinateur n'en dispose pas. Ces cartes réduisent considérablement l'utilisation du processeur par IPSec lors des transferts de données à débit élevé.

• Si l'utilisation du processeur reste élevée, pensez à utiliser un produit accélérateur de matériel pour accélérer les calculs Diffie-Hellman. Il s'agit en général d'une carte PCI dotée de la capacité de déchargement de l'élévation à la puissance Diffie-Hellman qui accélère les calculs Diffie-Hellman. Cette accélération est également bénéfique aux opérations de clé publique et de clé privée qui utilisent le protocole SSL (Secure Sockets Layer). Vérifiez auprès de votre fournisseur que sa carte prend en charge l'interface ModExpoOffload sous CAPI pour les calculs Diffie-Hellman.

• Si possible, créez un filtre qui autorise certains trafics à haute vitesse ne nécessitant pas la protection IPSec (par exemple, le trafic de sauvegarde d'un serveur sur un réseau local dédié).

Si ces options ne fonctionnent pas et que la mise à niveau vers Windows XP SP2 ou Windows Server 2003 est impossible, contactez les services de support technique Microsoft pour savoir s'il existe d'autres options disponibles.

Erreur de l'événement 4284

Titre de l'événement : Paquets en clair nécessitant une sécurisation

Cet événement indique qu'une association de sécurité IPSec a été établie à un moment où des paquets ont été reçus en clair alors qu'ils auraient dû faire partie de l'association de sécurité IPSec. Ces paquets ont été rejetés afin d'éviter toute attaque par injection de paquets sur les connexions sécurisées par IPSec. Bien que le compteur IP des Datagrammes reçus et rejetés augmente, IPSec ne possède pas de valeur de compteur qui enregistre le nombre de paquets rejetés pour cette raison. Ce problème peut uniquement être identifié à partir de l'événement 4284 du journal système :

<nombre> paquet(s) reçu(s) en clair de <adresse IP> alors qu'elles devraient être sécurisées.

Ce pourrait être un problème temporaire ; s'il persiste, arrêtez et redémarrez le service Agent de stratégie IPSEC sur cet ordinateur.

Comme pour les erreurs précédentes, la suggestion contenue dans l'événement ne doit pas être suivie. En effet, il est peu probable que le redémarrage du service IPSec permette de corriger l'erreur.

Cette erreur est probablement due à un problème de configuration de stratégie qui entraîne l'envoi du trafic en clair dans une direction à cause d'un filtre d'autorisation sortant plus spécifique. Par exemple, si le client possède un filtre pour sécuriser tout le trafic avec un serveur et que la stratégie du serveur possède un filtre plus spécifique qui autorise les réponses HTTP en texte clair, le serveur va sécuriser la totalité du trafic vers le client à l'exception des paquets HTTP sortants. Le client reçoit ces paquets, puis les rejette pour des raisons de sécurité car il s'attend à ce que la totalité du trafic vers/en provenance du serveur soit sécurisé dans la paire de l'association de sécurité IPSec.

Cet événement peut aussi se produire dans des conditions de fonctionnement normales et dans des cas d'interopérabilité de clients tiers lorsqu'un pair supprime une association de sécurité IPSec ou un filtre du pilote IPSec alors que le trafic circule entre les ordinateurs. Par exemple, l'une des extrémités de la communication peut supprimer l'attribution d'une stratégie IPSec ou réaliser une mise à jour de la stratégie qui supprime les actions de sécurité IPSec et les filtres. Puisqu'un pair a déjà supprimé le filtre alors qu'une communication du protocole de niveau supérieur a lieu, le message de suppression IKE risque de ne pas arriver et de ne pas être traité par l'autre pair avant l'arrivée des paquets en texte clair, ce qui provoque l'erreur. De même, le temps nécessaire au traitement du message de suppression dépend de la charge actuelle de l'ordinateur pair.

Le message d'erreur peut également apparaître lorsqu'une stratégie volumineuse est chargée, car les associations de sécurité IPSec peuvent être établies avant que le jeu complet de filtres ne soit appliqué au pilote IPSec. Si cette situation se produit, les associations de sécurité IPSec peuvent être négociées pour le trafic qui sera exempté une fois le chargement de la stratégie terminé.

Ce message d'erreur peut aussi révéler la présence d'une attaque par injection à l'endroit où le trafic en texte clair est envoyé correspondant (délibérément ou par hasard) aux sélecteurs de trafic d'une association de sécurité entrante active spécifique.

Ce problème doit être transféré au concepteur de la stratégie IPSec.

Délais d'expiration IPSec NAT-T lors de la connexion à des réseaux sans fil

Un problème récemment détecté provoque l'expiration des connexions lorsque des ordinateurs clients Windows Server 2003 ou Windows XP tentent de se connecter à un serveur sur un réseau sans fil utilisant IPSec NAT-T. Pour plus d'informations, reportez-vous à l'article 885267  de la Base de connaissances Microsoft à l'adresse https://support.microsoft.com/?kbid=885267.

Vérification de la stratégie IPSec appropriée

Cette section décrit les étapes de la détection de problèmes concernant l'attribution et l'interprétation de la stratégie IPSec. Les filtres d'une stratégie IPSec correctement interprétée doivent se trouver dans le pilote IPSec pour que IPSec puisse autoriser et bloquer les paquets, mais aussi déclencher la négociation par IKE des associations de sécurité IPSec avec les adresses IP distantes pour sécuriser le trafic. Des filtres appropriés doivent aussi être mis en place pour guider IKE en tant que répondeur. Dans cette solution, la conception de la stratégie IPSec requiert que tout le trafic (sauf ICMP) soit sécurisé par IPSec. La stratégie contient des filtres pour chaque adresse IP de la liste d'exemption.

Remarque : sous Windows 2000, le service IPSec est appelé Agent de stratégie IPSec ; sous Windows XP et Windows Server 2003, il est appelé Service IPSec.

Les ingénieurs du support technique doivent être familiarisés avec l'utilisation de la stratégie de groupe par IPSec, la priorité de la stratégie IPSec et son interprétation. Vous trouverez des références aux informations contenues dans ces rubriques dans la section Informations complémentaires à la fin de ce chapitre.  

Dépannage de la stratégie de groupe pour IPSec

La stratégie de groupe fournit le mécanisme d'attribution d'une stratégie IPSec de domaine à un membre du domaine. L'extraction d'objets GPO attribués par le membre du domaine permet d'attribuer la stratégie IPSec à un ordinateur hôte. Par conséquent, en cas de problème avec l'extraction des GPO, les ordinateurs n'appliquent pas la stratégie IPSec adéquate. Les problèmes courants concernant la stratégie de groupe pour la gestion de la stratégie IPSec incluent :

• retards de réplication de divers composants de configuration dans Active Directory ;

• problèmes liés au sondage de la stratégie de groupe et au processus de téléchargement ;

• manque de clarté par rapport à la version de la stratégie IPSec attribuée ;

• service IPSec non exécuté ;

• extraction de la stratégie IPSec impossible dans Active Directory, utilisation d'une copie mise en cache à la place ;

• retards dus au sondage de la stratégie IPSec pour extraire une stratégie IPSec actuellement attribuée.

La réplication peut être retardée en raison du nombre d'objets liés à IPSec dans Active Directory, comme les stratégies IPSec, les GPO, les changements d'attribut dans les attributions de la stratégie IPSec aux GPO et dans la stratégie IPSec ainsi que les informations sur les appartenances aux groupes de sécurité. La planification doit tenir compte de l'impact d'un changement dans la configuration IPSec qui influence progressivement les membres du domaine.

Pour obtenir des informations sur les procédures de dépannage de la stratégie de groupe, consultez les livres blancs suivants :

• Troubleshooting Group Policy in Windows 2000 (Dépannage de la stratégie de groupe sous Windows 2000)  à l'adresse https://support.microsoft.com/?kbid=810739.

• Troubleshooting Group Policy in Microsoft Windows Server  (Dépannage de la stratégie de groupe sous Microsoft Windows Server) à l'adresse www.microsoft.com/downloads/details.aspx
  FamilyId=B24BF2D5-0D7A-4FC5-A14D-E91D211C21B2&displaylang=en.  

L'attribution d'une stratégie IPSec basée sur le domaine est implémentée par deux composants :

• le composant logiciel enfichable MMC Gestion de stratégie IPSec (une extension du composant logiciel MMC Stratégie de sécurité) pour l'attribution d'une stratégie IPSec dans le GPO ;

• l'extension côté client (client side extension, CSE) de la stratégie de groupe pour IPSec (implémentée dans gptext.dll) qui traite les informations liées à IPSec dans le GPO.  

Le composant logiciel enfichable MMC Gestion de stratégie IPSec attribue une stratégie à un objet GPO en stockant les informations sur la stratégie IPSec sélectionnée dans le composant IPSec de l'objet GPO, référencé en tant que nom unique (Distinguished Name, DN) LDAP :

CN=IPSEC,CN=Windows,CN=Microsoft,CN=Machine,CN={GPOGUID},
CN=Stratégies,CN=Système,DC=domaine,DC=Woodgrove,DC=com

Le nom unique LDAP de la stratégie IPSec attribuée est stocké dans l'attribut du GPO ipsecOwnersReference.

Lorsque la stratégie de groupe extrait la liste d'objets GPO qui s'appliquent à l'ordinateur, les GPO contenant les attributions de la stratégie IPSec sont stockés dans le registre sous le GUID (Globally unique identifier, identifiant unique global) de l'extension IPSec côté client à l'emplacement suivant :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\Windows\CurrentVersion\Group Policy
\History\{e437bc1c-aa7d-11d2-a382-00c04f991e27}

L'extension IPSec côté client est activée par la CSE de la stratégie de sécurité chaque fois qu'une attribution de stratégie IPSec existe dans un objet GPO. S'il existe des problèmes de traitement de la stratégie de sécurité, il risque également d'y avoir des problèmes de traitement de la stratégie IPSec. Pour localiser le GUID de chaque extension de stratégie de groupe, consultez l'emplacement suivant dans le registre :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\WindowsNT\CurrentVersion\WinLogon\GPExtensions

Les GUID liés au déploiement d'IPSec pour les CSE de stratégie de groupe se présentent comme suit :

• Sécurité. {827D319E-6EAC-11D2-A4EA-00C04F79F83A}

• Sécurité IP.{E437BC1C-AA7D-11D2-A382-00C04F991E27}

• Scripts. {42B5FAAE-6536-11D2-AE5A-0000F87571E3}

La CSE IPSec copie le numéro unique LDAP ainsi que les informations associées sur la stratégie IPSec attribuée dans la clé de registre suivante :

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\
IPSec\GPTIPSECPolicy

Si plusieurs objets GPO contiennent des attributions de stratégie IPSec, alors la CSE IPSec est appelée pour chaque GPO. Les règles de priorité des GPO s'appliquent selon l'ordre dans lequel la CSE IPSec reçoit les GPO à traiter. L'ordre peut également être influencé par les paramètres des objets GPO et par les listes de contrôle d'accès (Access control list, ACL) en lecture qui empêchent l'extraction de certains objets GPO attribués. Chaque fois qu'une CSE IPSec est appelée, les informations IPSec associées situées dans le GPO (y compris le nom unique) sont écrasées dans la clé de registre. Une fois que tous les GPO ont été traités, la CSE avertit le service IPSec qu'une stratégie IPSec basée sur le domaine est attribuée. Le service IPSec lit ensuite la valeur GPTIPSecPolicy\DSIPSECPolicyPath afin d'extraire la stratégie IPSec appropriée.

Le service IPSec continue à rechercher les éventuels changements apportés à la stratégie IPSec attribuée en fonction de l'heure de la dernière mise à jour de l'un des objets d'annuaire de la stratégie IPSec attribuée. Ce service entretient la stratégie IP mise en cache et la considère comme la stratégie de domaine la plus récente.

Il existe un problème connu qui autorise le nom de la stratégie IPSec attribuée à ne plus être synchronisé avec le nom de la stratégie IPSec en cours d'utilisation (et mise en cache). Le service IPSec ne met pas à jour les informations de la clé de registre GPTIPSecPolicy, telles que DSIPSECPolicyName, et le nom de la stratégie IPSec change uniquement lorsque la CSE IPSec est appelée. Toutefois, la CSE IPSec n'est pas appelée à moins qu'il se produise un changement dans l'attribut de nom unique de la stratégie IPSec dans l'objet GPO. Cette valeur de registre est utilisée par le composant logiciel enfichable MMC Moniteur IPSec et les outils de ligne de commande pour indiquer le nom de la stratégie IPSec actuellement attribuée. Ainsi, les outils IPSec peuvent signaler le nom de la stratégie IPSec traitée en dernier par la CSE, et non celui de la stratégie en cours d'utilisation. Il existe plusieurs solutions pour éviter ce bogue. Pour plus d'informations, reportez-vous à la section Versions des stratégies du chapitre 5, Création de stratégies IPSec pour les groupes d'isolation de ce guide.

Remarque : Microsoft recommande que les conventions de dénomination des stratégies IPSec incluent un numéro de version dans le nom, afin qu'il soit plus aisé de retrouver la version de la stratégie actuellement appliquée. Il est impossible de détecter des changements de version si le nom d'une stratégie reste identique.

Si la stratégie IPSec correcte n'est pas attribuée, même après une actualisation forcée de la stratégie de groupe, les erreurs du journal des applications des sources Userenv ou SceCli signaleront des problèmes de traitement de la stratégie de groupe. Il est nécessaire que la journalisation de la stratégie de groupe soit activée pour que vous puissiez étudier ce problème en détail. Il existe différents types de journaux de stratégie de groupe et différents niveaux de journalisation. Les journaux de la CSE de sécurité sont nécessaires pour connaître les erreurs de traitement de la stratégie de sécurité ainsi que les erreurs signalées par la CSE IPSec. Il n'existe pas de journal spécifique à l'extension côté client IPSec. Les suivis de la surveillance réseau seront peut-être requis pour capturer le trafic au moment de l'actualisation de la stratégie de groupe pour confirmer quelle adresse IP de contrôleur de domaine est utilisée pour l'extraction de chaque objet. Vous pouvez rencontrer les difficultés suivantes :

• des problèmes de réplication ou de retard conduisant à l'impossibilité de trouver des objets ;

• la logique de l'équilibrage de charge du localisateur du contrôleur de domaine peut entraîner l'extraction d'un objet GPO à partir d'un contrôleur de domaine alors que la requête LDAP de la stratégie IPSec attribuée est extraite à partir d'un autre contrôleur de domaine du même site.

Pour créer un fichier journal détaillé de la CSE de sécurité, utilisez la clé de registre suivante :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\WindowsNT\CurrentVersion\CurrentVersion\Winlogon
\GpExtensions\{827d319e-6eac-11d2-a4ea-00c04f79f83a}\

Définissez l'entrée ExtensionDebugLevel sur une valeur REG_DWORD de 0x2.

Le fichier journal sera créé à l'emplacement %windir%\Security\Logs\Winlogon.log.

Remarque : une entrée DNS non valide peut signifier que les stratégies de groupe ne sont pas téléchargées depuis Active Directory, même si les connexions de l'utilisateur et de l'ordinateur ont réussi. Pour plus d'informations sur les problèmes DNS, reportez-vous à la section Problèmes de résolution de noms, plus haut dans ce chapitre.

Dépannage du service IPSec

Il n'est pas nécessaire que le service IPSec soit en cours d'exécution pour que vous puissiez utiliser le composant logiciel enfichable MMC Gestion de stratégie IPSec. Cependant, si un administrateur attribue par la suite une stratégie locale, la colonne Stratégie attribuée affiche une erreur.

Les problèmes courants suivants peuvent entraîner l'échec du service IPSec au démarrage :

• L'ordinateur a démarré en mode sans échec ou en mode de récupération Active Directory. Dans ces deux cas, le pilote IPSec fournit une communication sortante avec état par défaut si une stratégie IPSec est attribuée. La connectivité entrante sera bloquée jusqu'à ce qu'une exemption d'amorçage soit configurée.

• IKE ne peut pas obtenir le contrôle exclusif des ports UDP 500 et 4500. Utilisez la commande netstat –bov pour afficher les processus et les modules de code de chaque port. La commande portqry –local –v offre davantage de détails. Il est possible que des fournisseurs de services superposés (Layered Service Providers, LSP) Winsock installés interfèrent avec IPSec. Pour plus d'informations sur les LSP et IPSec, reportez-vous à la section Dépannage des problèmes liés aux applications* *plus loin dans ce chapitre.

• Corruption de la stratégie IPSec. La stratégie IP attribuée ne peut pas être lue ou appliquée en totalité, ce qui oblige le service IPSec à signaler des erreurs. Ces erreurs ne provoquent pas l'échec du service, mais peuvent entraîner des échecs de communication de plusieurs façons, en bloquant la stratégie de groupe et en empêchant le service IPSec d'extraire les stratégies corrigées, par exemple. Sous Windows XP et Windows Server 2003, vous devez veiller à ce que la conception d'une stratégie persistante ou locale soit « fiable » afin qu'elle soit appliquée en cas d'erreurs survenant lorsqu'une stratégie de domaine est appliquée. Les stratégies persistantes et les stratégies de démarrage de l'ordinateur (exemptions du mode d'amorçage) doivent faire partie des investigations de dépannage. Ces stratégies doivent autoriser l'accès distant à l'ordinateur par d'autres moyens dans le cas où elles sont les seules stratégies appliquées en raison d'autres conditions d'échec.

L'implémentation d'IPSec sous Windows 2000 utilise un module appelé Magasin de stratégies IPSec (polstore.dll) afin que les composants logiciels enfichables MMC Agent de stratégie IPSec et Gestion de stratégie IPSec puissent utiliser un module pour accéder aux trois emplacements de stockage des stratégies pris en charge : local, ordinateur distant et Active Directory. Cette conception a été modifiée et améliorée sous Windows XP et Windows Server 2003 avec l'ajout de nouveaux types de stratégies IPSec (stratégie de démarrage et persistante) et du composant Base de données de stratégies de sécurité (Security Policy Database, SPD), qui gère l'état d'exécution de la stratégie IPSec pour les requêtes de surveillance IPSec et les requêtes IKE. Cette modification d'ordre architectural signifie que le texte des événements IPSec consignés sous Windows 2000 a changé sous Windows XP et Windows Server 2003. Elle signifie également que des changements importants ont dû être apportés aux interfaces RPC utilisées pour la gestion à distance. Pour Windows Server 2003, les interfaces RPC ont subi d'importantes mises à jour. C'est pourquoi le composant logiciel enfichable MMC Gestion de stratégie IPSec n'est pas capable de se connecter à des ordinateurs distants qui ne possèdent pas la même version de système d'exploitation. En outre, le modèle de sécurité pour Windows XP SP2 et Windows Server 2003 SP1 a été radicalement modifié pour limiter les connexions RPC distantes et pour activer le pare-feu Windows par défaut. Pour plus d'informations, reportez-vous à Changes to Functionality in Microsoft Windows XP Service Pack 2 - Part 2: Network Protection Technologies (Modifications apportées à Microsoft Windows XP Service Pack 2 - Partie 2 : technologies de protection des réseau)  à l'adresse www.microsoft.com/technet/prodtechnol/winxppro/
maintain/sp2netwk.mspx.

En raison de ces changements, les interfaces RPC distantes du service IPSec ont été désactivées par mesure de sécurité. Par conséquent, les composants logiciels enfichables MMC Moniteur IPSec et Gestion de stratégie IPSec ne peuvent pas réaliser de surveillance à distance sur ces ordinateurs. La gestion distante d'IPSec doit être effectuée à l'aide de connexions Bureau à distance (Terminal Server), qui exécutent les composants logiciels enfichables MMC IPSec en tant que processus locaux.

Sous Windows 2000, le pilote IPSec est chargé par défaut à la fin du processus de démarrage par le service Agent de stratégie. Le pilote IPSec ne participe pas au traitement des paquets IP jusqu'à la première fois où le service Agent de stratégie informe le pilote IPSec d'une stratégie active. S'il n'existe pas de stratégie IPSec active, le pilote IPSec n'est pas inclus dans le traitement du trafic IP entrant et sortant. Sous Windows XP et Windows Server 2003, cette conception a été améliorée pour que le pilote IPSec soit chargé par le pilote TCP/IP au cours du processus de démarrage. Le pilote ne traite pas les paquets avant que des filtres soient chargés par le service IPSec.

Sous Windows 2000, il est possible que des erreurs soient consignées par l'Agent de stratégie IPSec pour des problèmes de démarrage du service. Ces erreurs sont les suivantes :

• L'Agent de stratégie de la sécurité IP n'a pas pu démarrer. Aucune stratégie de sécurité IP ne sera appliquée. Cette erreur est probablement due aux problèmes rencontrés par l'Agent de stratégie IPSec lors de son enregistrement auprès du sous-système RPC. Elle peut aussi provenir de l'échec d'initialisation d'IKE en raison de LSP Winsock tiers.

• Le Serveur RPC de l'Agent de stratégie n'a pas pu...

  • enregistrer la séquence de protocoles

  • enregistrer l'interface

  • enregistrer les liens d'interface

  • enregistrer le point de fin d'interface

  • enregistrer les mécanismes d'authentification

  • écouter

  Ces erreurs peuvent être dues à des changements apportés aux paramètres de sécurité avancés ou à des problèmes inhérents au service RPC qui ne permettent pas à l'Agent de stratégie IPSec de s'initialiser correctement au démarrage du service. Par conséquent, l'Agent de stratégie IPSec ne fonctionnera pas correctement, risquera de se bloquer ou de s'arrêter.

• L'Agent de stratégie n'a pas pu démarrer. Impossible de se connecter à la base de données SCM. Erreur : <numéro>. Le service IPSec ne peut pas ouvrir la base de données du gestionnaire de contrôle des services (Service Control Manager, SCM), ce qui peut être dû au fait que le service IPSec a été configuré pour être exécuté en tant que compte de service sans privilèges. Il doit être exécuté en tant que système local. Pour rechercher la cause de problèmes, utilisez le gestionnaire de contrôle des services.

• L'Agent de stratégie n'a pas pu se connecter au pilote IPSEC.  Le pilote IPSec n'a pas pu être chargé ni interfacé correctement avec la pile TCP/IP. Windows 2000 est conçu pour réaliser cette opération lorsque le service IPSec démarre. Il est possible qu'un logiciel tiers désactive la connexion ou que le système d'exploitation ne dispose pas de tous les modules de codes requis pour cette fonctionnalité.

• L'Agent de stratégie n'a pas pu charger les stratégies IPSEC. Une erreur s'est produite pendant que l'agent de stratégie IPSec chargeait tous les filtres dans le pilote IPSec. Cette erreur peut provenir d'un manque de mémoire du noyau ou de la mauvaise initialisation du pilote IPSec. Si le problème persiste, contactez les services de support technique Microsoft.

• L'Agent de stratégie n'a pas pu démarrer le service ISAKMP. Cette erreur se produit généralement car IKE ne peut pas obtenir le contrôle exclusif des ports UDP 500 ou 4500 étant donné qu'ils sont utilisés par un autre service. Elle peut aussi être provoquée par un logiciel de sécurité tiers qui empêche l'allocation des ports réseau ou parce que le service IPSec n'est pas exécuté dans le contexte du système local.

• Impossible de déterminer le nom principal SSPI pour le service ISAKMP/Oakley. Windows 2000 enregistre ce message lorsque l'appel de la fonction QueryCredentialsAttributes de l'interface du fournisseur de prise en charge de la sécurité (security support provider interface, SSPI) échoue. Cette échec peut signifier que l'ordinateur n'a pas réussi à se connecter au domaine.

• Impossible d'obtenir les informations d'identification du serveur Kerberos pour le service ISAKMP/Oakley. Ce message d'erreur de Windows 2000 apparaît couramment lorsque le service IPSec démarre (peut-être au démarrage de l'ordinateur) sur un réseau distant où une stratégie IPSec est attribuée (peut-être depuis le cache du registre de la stratégie de domaine) et nécessite l'authentification Kerberos alors qu'un contrôleur de domaine n'est pas disponible. C'est pourquoi l'authentification Kerberos ne fonctionne pas. Sur le réseau interne, cet événement est consigné sur un ordinateur non membre du domaine ou qui ne peut pas communiquer avec les contrôleurs de domaine à l'aide du protocole Kerberos lors de l'initialisation du service IPSec.

• Une stratégie de communication sécurisée ne peut pas être appliquée car le pilote de sécurité IP n'a pas pu démarrer. Contactez votre administrateur système immédiatement. Cette erreur est provoquée par un problème de chargement du pilote IPSec, sa liaison à la pile TCP/IP ou son initialisation avant l'ajout de la stratégie. La corruption de fichiers ou les autorisations peuvent être à l'origine de cette erreur. Vérifiez que les paramètres de sécurité ou un logiciel tiers ne désactivent pas le chargement du pilote. Si les signatures internes FIPS.sys ne peuvent pas être vérifiées au cours de l'initialisation, le chargement du pilote IPSec échoue également. L'échec de la signature FIPS.sys requiert le remplacement du fichier binaire signé d'origine ou un nouveau fichier binaire de Microsoft. Redémarrez l’ordinateur. Si le problème persiste, contactez les services de support technique Microsoft.  

Sous Windows XP et Windows Server 2003, les événements d'erreur du service IPSec suivants indiquent que le service ne peut pas démarrer :

• Les services IPSec n'ont pas pu initialiser le pilote IPSec, code d'erreur : <numéro>. Les services IPSec n'ont pas pu démarrer. Le pilote IPSec n'a pas pu se charger. Si le problème persiste, contactez les services de support technique Microsoft.

• Les services IPSec n'ont pas pu initialiser le module IKE, code d'erreur : <numéro>. Les services IPSec n'ont pas pu démarrer. Ce problème est fréquemment dû à des LSP Winsock tiers qui empêchent IKE d'utiliser certaines options de socket. Cette erreur est également signalée lorsque IKE ne peut pas obtenir l'accès exclusif des ports UDP 500 et 4500.

• Les services IPSec n'ont pas pu initialiser le serveur RPC, code d'erreur : <numéro>. Les services IPSec n'ont pas pu démarrer. Le service IPSec dépend du sous-système RPC pour la communication inter-processus entre IKE, le composant SPD et l'Agent de stratégie. Utilisez les techniques de dépannage RPC pour confirmer que le serveur RPC fonctionne correctement. Si le problème persiste après le redémarrage de l'ordinateur, contactez les services de support technique Microsoft.

• Les services IPSec ont expérimenté une défaillance critique et se sont arrêtés avec le code d'erreur : <numéro>. L'arrêt des services IPSec peut représenter un risque potentiel pour la sécurité de cet ordinateur. Contactez l'administrateur de votre ordinateur pour redémarrer le service. Le service IPSec a rencontré une erreur indiquée par le <numéro> dans le texte de l'événement et ne fonctionne plus. Le pilote IPSec est toujours chargé et utilise le mode normal (applique les filtres de la stratégie IPSec) ou le mode de blocage. Un événement distinct indiquerait que le pilote IPSec a été placé en mode de blocage. Si le pilote est en mode normal, alors les actions de filtrage autoriser et bloquer continuent à fonctionner comme prévu. Les filtres dotés d'une action négocier abandonnent tout simplement le trafic car IKE n'est pas disponible.

• Les services IPSec mettent le pilote IPSec en mode de blocage à cause du code d'erreur de défaillances <numéro>. Ce message signifie que le pilote IPSec a été placé en mode de blocage (utilisé en tant que comportement à tolérance de pannes) en raison des erreurs rencontrées au cours du traitement de la stratégie IPSec. Ce comportement est disponible sous Windows Server 2003 uniquement. Le mode de blocage permet néanmoins les exemptions entrantes configurées avec la commande netsh ipsec.  

Dépannage de l'extraction de la stratégie IPSec

Le service IPSec utilise une requête LDAP TCT authentifiée et chiffrée pour télécharger la stratégie IPSec attribuée pour toutes les plates-formes. Il existe des options permettant de signer et de sceller LDAP à l'aide de la clé de session Kerberos. Ainsi, le service IPSec exécuté en tant que système local doit être capable d'obtenir un ticket de service Kerberos pour le service LDAP sur le serveur Active Directory. Si la stratégie IPSec correcte est attribuée et que son stockage par la CSE IPSec est confirmé sous la clé de registre GPTIPSecPolicy et que le service fonctionne, alors les problèmes suivants risquent d'empêcher IPSec d'extraire la stratégie depuis Active Directory :

• problèmes de communication avec les contrôleurs de domaine ;

• problèmes de connexion des comptes de l'ordinateur à un contrôleur de domaine ;

• problèmes d'émission de tickets Kerberos ;

• problèmes liés à la disponibilité du service LDAP ;

• problèmes de recherche de la stratégie IPSec ou des objets de composant spécifiques requis dans la requête LDAP ;

• problèmes d'autorisation en lecture pour n'importe quel objet de la stratégie IPSec requis ;

• corruption de la stratégie en raison de problèmes lors de l'enregistrement d'objets dans le magasin ou en raison de la suppression accidentelle ou intentionnelle d'objets du magasin.  

Remarque : une stratégie IPSec créée dans Windows XP ou Windows Server 2003 et qui utilise de nouvelles fonctions alors disponibles dans ces versions risque de voir ces fonctions supprimées silencieusement si une stratégie est ultérieurement modifiée et enregistrée par le composant logiciel enfichable MMC Gestion de stratégie IPSec sous Windows 2000. Cependant, si un système Windows 2000 extrait une stratégie IPSec dotée de fonctions supplémentaires, il les ignore, ce qui peut, soit changer le comportement de la stratégie IPSec lorsqu'elle est utilisée sur un système Windows 2000, soit avoir aucun impact sur le comportement de la stratégie.

Un problème connu relatif au composant logiciel enfichable MMC Gestion de stratégie IPSec se produit lors de la gestion de la stratégie IPSec dans Active Directory ou sur un ordinateur distant. Si le composant logiciel MMC est exécuté sur une liaison lente, l'enregistrement de tous les changements d'une stratégie volumineuse peut être long. Si la fenêtre du composant logiciel MMC est fermée, tous les objets ou changements d'une stratégie IPSec qui ne sont pas encore enregistrés sont perdus. Cette fonctionnalité peut entraîner la corruption de la stratégie IPSec. Si le composant logiciel enfichable MMC Gestion de stratégie IPSec est exécuté sur une liaison lente, utilisez une session Bureau à distance pour exécuter le composant en tant que processus local.

Généralement, tout script d'outil de ligne de commande permettant de créer une stratégie IPSec doit être testé. Pour ce faire, créez une stratégie dans le magasin local et affichez-la en utilisant le composant MMC Gestion de stratégie IPSec pour vérifier son intégrité. Des ordinateurs de test doivent appliquer la stratégie locale et étudier les détails dans le composant MMC Moniteur IPSec pour confirmer l'ordre de filtrage attendu.

Les procédures permettant de dépanner et de résoudre des erreurs de lecture et de corruption de la stratégie IPSec dépendent de l'emplacement de stockage. Cette solution utilise une stratégie IPSec basée sur domaine uniquement, mais d'autres types de stratégies IPSec ont pu être configurés de façons qui entraînent des problèmes.

Les procédures de dépannage de chaque type de stratégie sont décrites dans le reste de cette section. Généralement, le support de niveau 2 doit être capable d'utiliser les outils de la ligne de commande ou les outils de l'interface graphique utilisateur pour confirmer que la stratégie IPSec appropriée est en cours d'extraction et que cette stratégie est correctement interprétée. Les étapes de la suppression de chaque type de stratégie sont indiquées ici. L'objectif de l'actualisation de la stratégie est d'installer une stratégie correcte. S'il est impossible d'extraire ou d'installer une stratégie correcte à partir des scripts, alors le problème est transféré au support de niveau 3.

Stratégie IPSec au démarrage

L'utilitaire Netsh permet la configuration d'options de mode d'amorçage et d'exemption d'amorçage prises en charge par Windows Server 2003 uniquement. La configuration est stockée dans les clés de registre suivantes avec les valeurs par défaut affichées :

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec\
  OperationMode=3 (avec état)

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec\
  BootExemptList = (exemption pour DHCP entrant, voir ci-dessous)

La valeur OperationMode par défaut nécessite que le pilote IPSec procède au filtrage avec état du trafic sortant. Si le service IPSec est en cours d'exécution, utilisez la commande
Netsh ipsec dynamic show config pour afficher la configuration de démarrage. Si le service IPSec n'est pas en cours d'exécution (par exemple, dans le cas d'un démarrage en mode sans échec), vous pouvez utiliser les outils du registre pour examiner la valeur de la clé du registre et la modifier.

Pour résoudre les problèmes de trafic provoqués par le filtrage avec état d'IPSec au démarrage, définissez le pilote IPSec afin qu'il autorise le trafic au démarrage au lieu d'effectuer le filtrage avec état. Si le service IPSec est en cours d'exécution, utilisez
netsh ipsec dynamic set config bootmode value=permit pour définir le mode de démarrage sur autoriser. Si le service IPSec n'est pas en cours d'exécution, utilisez un outil de registre pour modifier la valeur d'autorisation OperationsMode=1. En outre, le pilote IPSec n'applique pas le mode de sécurité au démarrage si le service IPSec est configuré pour un démarrage manuel ou s'il est désactivé. Une fois que le service est configuré pour un démarrage manuel ou qu'il est désactivé, redémarrez l'ordinateur pour que le pilote IPSec soit chargé en mode autoriser.

Stratégie IPSec persistante

La stratégie persistante est prise en charge par Windows XP et Windows Server 2003. L'une des situations d'erreur les plus courantes survient lorsqu'une stratégie persistante existante n'est pas supprimée avant la définition d'une nouvelle stratégie persistante et que cette dernière entre en conflit avec des paramètres déjà attribués. La solution décrite dans ce guide n'utilise pas la stratégie persistante. Cependant, puisque cette stratégie est utilisée dans certains environnements, des instructions de dépannage sont fournies dans ce chapitre.

La clé de registre de la stratégie persistante existe par défaut et est vide :

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\
IPSec\Policy\Persistent

Sous Windows XP, le meilleur moyen de détecter une stratégie persistante est de constater que la clé de registre n'est pas vide. La commande ipseccmd show indique la stratégie active contenue dans le service IPSec et ne signale pas qu'un paramètre particulier a été généré par la stratégie persistante. Le service IPSec supprime le nom des règles de la stratégie persistante lorsqu'il interprète la stratégie avec les paramètres actifs. Étant donné que la commande ipseccmd ne fournit pas le nom des filtres et des actions de filtrage, il n'est pas possible d'utiliser des conventions de dénomination pour indiquer les filtres et les actions de filtrage issus de la stratégie persistante. Les filtres portent des noms de type « text2pol{GUID} » chaque fois qu'ils sont créés par les outils ipsecpol.exe ou ipseccmd.exe, qui incluent des entrées de la stratégie persistante. Toutefois, les stratégies locales ou de domaine créées à l'aide de scripts pourront aussi porter ces noms.

La stratégie persistante est appliquée en premier et fusionne avec la stratégie IPSec locale ou de domaine. Ainsi, vous devez supprimer l'attribution des stratégies locale et de domaine avant de pouvoir afficher les paramètres persistants. Utilisez ipseccmd show all pour afficher toutes les stratégies actives, y compris les paramètres persistants, lorsque le service IPSec est démarré.

Pour supprimer tous les objets (règles, listes de filtres et actions de filtrage) associés à une stratégie persistante particulière, indiquez le nom de cette stratégie dans la commande suivante :

ipseccmd.exe -w PERS -p "policy name" –o

Pour vous assurer qu'une stratégie persistante est supprimée, supprimez toutes les sous-clés de la clé Persistent. Cependant, si vous supprimez la clé Persistent, puis que vous lancez de nouvelles commandes ipseccmd pour créer une stratégie persistante, celles-ci échoueront. Pour résoudre le problème de corruption des stratégies persistantes et les conflits, supprimez tous les objets présents dans le magasin de la stratégie persistante, puis reéxécutez le script ipseccmd pour recréer la stratégie.

Sous Windows Server 2003, la stratégie persistante possède des fonctionnalités de gestion complètes semblables à celles des stratégies IPSec locales et de domaine. La stratégie persistante est stockée à l'emplacement du registre référencé précédemment. Le script de commande Netsh suivant permet d'afficher la stratégie persistante configurée à l'aide des commandes du fichier show_persistent.netsh :

Netsh –f show_persistent.netsh 

Le fichier show_persistent.netsh est un fichier texte contenant les lignes suivantes :

Pushd ipsec static
Set store persistent
show all
exit

Le script de commande Netsh suivant sert à supprimer toutes les stratégies persistantes :

pushd ipsec static
set store persistent
delete all
exit

Stratégie IPSec locale

La stratégie IPSec locale est prise en charge par Windows 2000, Windows XP et Windows Server 2003, et elle est stockée sous la clé de registre suivante :

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\
IPSec\Policy\Local

Si une stratégie locale est attribuée, celle-ci sera stockée dans la clé de la manière suivante :

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\
IPSec\Policy\Local\ActivePolicy

Si aucune stratégie de domaine n'est attribuée, alors la stratégie locale attribuée sera ajoutée à une stratégie persistante configurée afin de devenir la stratégie active. Pour faciliter considérablement le dépannage, il est recommandé de modifier les stratégies IPSec créées par les scripts ipsecpol ou ipseccmd au moyen du composant logiciel enfichable MMC Gestion de stratégie IPSec afin de définir un nom pour chaque filtre avant de les utiliser dans des environnements de production. Vous pouvez aussi utiliser la commande netsh ipsec pour créer la stratégie sur un système Windows Server 2003, puis l'exporter vers un fichier compatible avec des systèmes Windows 2000 et Windows XP ou l'importer dans un domaine après que la stratégie aura été testée.

Sous Windows 2000, utilisez la commande netdiag /test:ipsec /debugpour afficher les détails de l'attribution de la stratégie et la stratégie active. Vous devez utiliser le composant logiciel enfichable MMC Gestion de stratégie IPSec ou les outils du registre pour supprimer les objets de la stratégie IPSec situés dans le magasin local. Pour forcer le rechargement de la stratégie IPSec attribuée, arrêtez puis redémarrez le service.

Sous Windows XP, utilisez la commande ipseccmd show gpo ou netdiag /test:ipsecpour afficher les détails de l'attribution de la stratégie et la stratégie active. Utilisez le composant logiciel enfichable MMC Gestion de stratégie IPSec, les outils du registre ou la commande
ipseccmd.exe -w REG -p "<policy_name>" –opour supprimer la stratégie IPSec nommée. Pour supprimer facilement une stratégie locale, supprimez toutes les sous-clés de l'emplacement de stockage précédemment référencé.

Pour obliger le service IPSec à recharger la stratégie, arrêtez le service IPSec, puis redémarrez-le ou supprimez l'attribution de la stratégie IPSec, puis attribuez-la de nouveau à l'aide du composant logiciel MMC Gestion de stratégie IPSec. Il est également possible d'utiliser la commande sc policyagent control 130pour recharger la stratégie. Une fois la stratégie rechargée, toutes les associations de sécurité IKE et IPSec sont supprimées, ce qui peut entraîner des retards ou des interruptions de connectivité sur les ordinateurs qui utilisaient activement les SA IPSec pour transmettre et recevoir le trafic.

Sous Windows Server 2003, utilisez la commande,
netsh ipsec static show gpoassignedpolicyle composant logiciel enfichable MMC Gestion de stratégie IPSec ou le nœud Stratégie active du moniteur IPSec pour afficher la stratégie locale actuellement attribuée.

Utilisez la commande netsh ipsec dynamic show allpour afficher la configuration de la stratégie active. Vous pouvez aussi utiliser le Moniteur IPSec pour inspecter différentes parties de la stratégie active.

Pour supprimer puis recharger la stratégie locale sous Windows Server 2003, utilisez les mêmes commandes que celles répertoriées pour Windows XP. La commande netsh ipsecpeut servir à supprimer l'attribution d'une stratégie, à l'attribuer de nouveau et à la supprimer.

Stratégie IPSec Active Directory

Cette stratégie est prise en charge par Windows 2000, Windows XP et Windows Server 2003. La stratégie IPSec de domaine attribuée est stockée dans le registre local à l'emplacement suivant :

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\
IPSec\GPTIPSECPolicy

Le cache du registre local de la stratégie de domaine est stocké sous :

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\
IPSec\Policy\Cache

Le magasin d'annuaire doit être géré par le composant logiciel enfichable MMC Gestion de stratégie IPSec ou par la commande netsh ipsec exécutée en tant que processus local dans Active Directory. Il n'existe aucun outil qui vous permette d'afficher directement le contenu du cache. Vous devez utiliser un outil du registre pour savoir si le cache existe et s'il possède le contenu approprié. De la même manière, les outils du registre servent à supprimer la stratégie de domaine en supprimant les clés de registre GPTIPSecPolicy et Cache. Ensuite, vous devez soit redémarrer le service IPSec, soit utiliser la commande de contrôle de services pour forcer le rechargement de la stratégie IPSec sans la stratégie de domaine.

Pour actualiser l'attribution de la stratégie IPSec de domaine, recharger la stratégie IPSec et mettre à jour le contenu du cache, utilisez la commande gpudpate /force.

Pour bloquer temporairement l'application de la stratégie de domaine à l'ordinateur local, vous pouvez configurer les autorisations sur les clés de registre GPTIPSecPolicy et Cache afin de refuser l'accès en lecture au compte système local. Le composant logiciel enfichable MMC Moniteur de sécurité IPSec et les outils de ligne de commande continueront à indiquer que la stratégie de domaine est attribuée car ces outils lisent les informations GPTIPSecPolicy exécutées dans le contexte de l'administrateur local. Pour un blocage à plus long terme de la stratégie IPSec basée sur le domaine, vous devez empêcher l'ordinateur de lire l'objet GPO approprié dans Active Directory.

Sous Windows 2000, vous pouvez rencontrer les erreurs suivantes en cas de problème lié à la stratégie :

• Impossible d'effectuer la liaison avec le schéma de l'annuaire. Le service Agent de stratégie IPSec n'a pas pu effectuer de liaison LDAP authentifiée au conteneur de stratégies de sécurité IP Active Directory. Cette erreur est probablement apparue parce que le compte de l'ordinateur n'a pas réussi à se connecter et à obtenir les informations d'identification Kerberos, ou parce que le protocole Kerberos ne réussit pas à émettre le ticket du service LDAP pour le service Agent de stratégie IPSec.

• Impossible d'effectuer la liaison avec l'objet Stockage de stratégie IPSEC. Un objet a été défini dans la stratégie IPSec (une règle ou une liste de filtrage, par exemple) qui n'existe pas. Il est possible que la stratégie IPSec ou la stratégie de stockage Active Directory soit corrompue, ou que l'objet ait été supprimé (bien que les stratégies IPSec existantes continuent à le référencer). Étudiez la stratégie IPSec en utilisant le composant logiciel enfichable MMC Gestion de stratégie IPSec pour voir si toutes les règles de la stratégie sont intactes et si les propriétés Échange de clés (de l'onglet Général) peuvent être affichées correctement.

• Impossible de trouver le contrôleur de domaine. Assurez-vous que l'ordinateur est membre du domaine et vérifiez la connectivité réseau. Le module de stockage de la stratégie IPSec n'a pas réussi à trouver un annuaire LDAP à partir duquel extraire la stratégie IPSec basée sur le domaine.

• Impossible de communiquer avec le service d'annuaire sur le contrôleur de domaine. Contactez votre administrateur système. Le module de stockage IPSec n'a pas réussi à utiliser les fonctions de signature et de scellement de LDAP pour télécharger la stratégie IPSec attribuée.

• Impossible de trouver l'objet dans l'emplacement de stockage. Cette erreur est généralement grave, car elle signifie que la stratégie IPSec ne peut pas être extraite en totalité et donc ne fonctionnera pas correctement. Le module Stockage de la stratégie IPSec n'a pas réussi à trouver le GUID de l'objet (règle, liste de filtres, action de filtrage ou paramètres ISAKMP) contenu dans la stratégie IPSec ou l'une des règles en utilisant un appel LDAP ou un appel de registre distant. Cette erreur peut être provoquée par :

  • des retards de réplication au cours desquels l'objet « référençant » arrive avant l'objet référencé ou des requêtes sont dirigées vers deux contrôleurs de domaine différents ;

  • la suppression de l'objet alors qu'il était toujours utilisé par la stratégie IPSec ;

  • des autorisations qui ne permettent pas d'énumérer ou de lire l'objet, ou le stockage de la stratégie IPSec a été restauré à une heure antérieure à la création de l'objet ;

  • la corruption de la stratégie IPSec qui génère un GUID incorrect dans la requête ;

  • l'indisponibilité de la connectivité réseau pour l'adresse IP de destination ;

  • l'indisponibilité du service LDAP ou du registre distant.

• Impossible de terminer l'opération requise. Le stockage de stratégie n'est pas ouvert. Il est impossible d'ouvrir le magasin Active Directory, de l'ordinateur distant ou de l'ordinateur local. Cette erreur est généralement causée par un échec d'autorisation ou d'authentification.

• L'utilisation de la stratégie de registre local actif, du fait que (i) il n'y a pas de stratégie de stockage Active Directory ou (ii) la stratégie de stockage Active Directory n'a pas pu être appliquée avec succès, et il n'y a pas de stratégie de cache. Cet événement indique que la stratégie IPSec est définie localement sur l'ordinateur et que la stratégie de domaine n'a pas pu être appliquée pour la remplacer.

• N'utiliser aucune stratégie Ipsec, du fait que (i) il n'y a pas de stockage Active Directory ou de stratégie de registre local active ou (ii) la stratégie de stockage Active Directory n'a pas pu être appliquée avec succès, et il n'y a pas de stratégie de cache ou pas de stratégie de registre local active. Cet événement identifie l'état par défaut dans lequel aucune stratégie n'est attribuée à l'ordinateur.

Sous Windows XP et Windows Server 2003, les événements suivants indiquent que le service IPSec n'a pas réussi à retrouver un type de stratégie spécifique. Si une stratégie locale ne peut pas être lue sous Windows Server 2003 et Windows XP SP2, elle est ignorée et la stratégie attribuée suivante dans l'ordre de persistance est lue.

• Le moteur PAStore n'a pas pu charger la stratégie IPSec de stockage persistant sur l'ordinateur pour <nomstratégie> avec le code d'erreur <numéro> . Le service IPSec a détecté qu'une stratégie persistante était attribuée et stockée dans le registre local, mais n'a pas réussi à lire le contenu d'au moins un des objets de la stratégie persistante. Vérifiez les autorisations dans les clés de registre. La stratégie est peut-être corrompue. Supprimez la stratégie persistante, puis recréez-la.

• Le moteur PAStore n'a pas pu charger la stratégie IPSec de stockage locale sur l'ordinateur pour <nomstratégie> avec le code d'erreur <numéro> . Le service IPSec a détecté qu'une stratégie locale était attribuée et a tenté de la lire, mais une erreur s'est produite lors de la lecture d'au moins un des objets associés à la stratégie attribuée. Vérifiez les autorisations dans les clés de registre. La stratégie est peut-être corrompue : vous devez la supprimer, puis la recréer.

• Le moteur PAStore n'a pas pu charger la stratégie IPSec de stockage d'annuaire sur l'ordinateur pour <nomstratégie> avec le code d'erreur <numéro> . Le service IPSec a rencontré au moins une erreur lors de la lecture de la stratégie IPSec attribuée à partir d'Active Directory. Ce problème peut être causé par une erreur de connectivité réseau avant que tous les objets aient pu être extraits ou par des objets absents de la stratégie IPSec ou par des objets ne possédant pas d'autorisation en lecture.

• Le moteur PAStore a effectué un sondage pour détecter des modifications apportées à la stratégie IPSec Active Directory, a détecté que Active Directory est inaccessible et a migré vers l'utilisation de la copie mise en cache de la stratégie IPSec Active Directory. Toutes les modifications apportées à la stratégie IPSec Active Directory depuis le dernier sondage n'ont pas été appliquées. Ce message indique simplement qu'à un intervalle de sondage régulier, le service IPSec n'a pas réussi à contacter Active Directory (par exemple, en raison de la perte du service DNS) et qu'aucune modification n'a été apportée à la stratégie IPSec active. La connectivité à Active Directory était disponible à l'origine lorsque la stratégie active était appliquée et que le service IPSec avait extrait et stocké la version la plus récente dans le cache. Par conséquent, le service IPSec considère à présent le cache du registre de la stratégie de domaine IPSec comme la source principale de stratégie. Le sondage en vue de contacter l'annuaire va continuer.  

Dépannage de l'interprétation de la stratégie IPSec

L'interprétation de la stratégie IPSec a lieu après l'extraction de la stratégie complète de l'emplacement de stockage approprié. Les adresses IP actuelles de l'interface réseau sont utilisées pour développer les filtres génériques de la stratégie en filtres spécifiques. Ensuite, la liste des filtres entrants et sortants spécifiques est chargée dans le pilote IPSec en vue du traitement des paquets. Les événements de modification de l'interface sont signalés au service IPSec, qui ajuste la configuration du filtre IPSec dans le pilote IPSec aussi rapidement que possible, si nécessaire (par exemple, pour les filtres Mon adresse IP).

Sous Windows 2000, les messages suivants peuvent indiquer un problème d'interprétation ou de configuration des composants IPSec pour appliquer la stratégie :

• L'attribut Type de données spécifie un format de données non reconnu. Une partie de la stratégie IPSec contient un format de données que le moteur de stockage de la stratégie ne reconnaît pas. Cette erreur est le signe d'une corruption de la stratégie ou peut indiquer un problème futur de version de la stratégie. Les fonctions de la stratégie IPSec de Windows XP et Windows Server 2003 sont conçues pour être transparentes pour l'Agent de stratégie IPSec de Windows 2000.

• Impossible de lire des données à partir du blob. Le format de données de l'attribut IPSecData dans un objet de stratégie IPSec ne correspond pas au format prévu. Cette erreur indique pratiquement toujours une corruption de la stratégie ou un problème de version. Vous devez la corriger avant de pouvoir appliquer tous les paramètres de la stratégie IPSec comme vous le souhaitez.

• L'Agent de stratégie n'a pas de liste d'interfaces. L'Agent de stratégie n'a pas trouvé d'interface réseau IP à filtrer. Notez que l'erreur dans le texte de ce message provient directement du code source Windows, et elle apparaîtra de la manière illustrée ici.

• L'Api d'aide publique Ip n'a pas pu obtenir la table d'interfaces. Les filtres basés sur les interfaces ne seront pas étendus et connectés au pilote Ipsec.  Une erreur s'est produite lorsque l'Agent de stratégie a tenté d'énumérer la liste des interfaces de l'ordinateur. Il est possible qu'il n'y ait pas d'interface réseau ou qu'il existe une erreur dans le gestionnaire des interfaces réseau. Des périphériques qui ne sont pas complètement compatibles PnP, la corruption des fichiers ou des problèmes liés au pilote NIC ou à d'autres composants réseau de Windows peuvent être à l'origine de cette erreur : les filtres IPSec basés sur le type d'interface, comme ceux configurés dans une règle pour un type de connexion particulier (l'accès à distance, par exemple) plutôt que pour toutes les connexions. Si le problème persiste après le redémarrage de l'ordinateur, contactez les services de support technique Microsoft.

• L'Api d'aide publique Ip n'a pas pu obtenir la table d'adresse IP. Les filtres basés sur les interfaces ne seront pas étendus et connectés au pilote Ipsec. Une erreur s'est produite lorsque l'Agent de stratégie IPSec a tenté d'énumérer toutes les adresses IP de l'ordinateur en utilisant un appel de fonction de l'API de l'application d'assistance IP. Il est possible qu'aucune adresse IP ne soit configurée ou qu'il existe des problèmes semblables à ceux mentionnés ci-dessus.

• L'index d'entrée de l'adresse IP n'a pas été trouvé dans la table d'interfaces. Rejet de l'adresse IP. L'Agent de stratégie IPSec confirme que toutes les adresses IP apparaissent dans la liste des interfaces réseau. Ce problème est dû à des conditions passagères lorsqu'une nouvelle interface réseau est ajoutée ou supprimée. Ce message indique que le service IPSec ne va pas créer de filtres spécifiques pour cette adresse IP rejetée, pour les filtres génériques Mon adresse IP de la stratégie, ce qui pourrait apparaître comme un comportement de connectivité inattendu lors de l'utilisation de cette adresse IP. Cette erreur peut également révéler un problème de l'état interne de la configuration de l'interface IP que les services de support technique Microsoft devront examiner en détail. Puisque l'adresse IP est rejetée par l'Agent de stratégie IPSec (non par la pile TCP/IP), aucun filtre IPSec ne sera créé pour cette adresse IP. Ainsi, aucune action de sécurité (de type autoriser ou bloquer, par exemple) et aucune négociation des associations de sécurité IPSec ne sera réalisée pour le trafic au moyen de cette adresse IP.

• Un miroir de filtre correspondant existe dans la liste des filtres. Cette erreur signale une condition de filtre dupliqué dans la stratégie IPSec. Vous devez analyser la conception de la stratégie IPSec pour vous assurer que les filtres spécifiques au mode rapide pour les directions entrante et sortante ne sont pas dupliqués.

• Aucun filtre n'a été ajouté à la liste de filtres principale. L'Agent de stratégie IPSec n'a trouvé aucun filtre dans la stratégie IPSec extraite du stockage. Il est possible que celle-ci contienne uniquement la règle de réponse par défaut ou que des erreurs soient survenues lors de la lecture des règles ou des listes de filtrage.

• Zéro offre pour la phase 1. Rejet de la stratégie ISAKMP. Si aucune méthode de sécurité en mode principal IKE n'a été trouvée (objets de stratégie ISAKMP), cela signifie que la stratégie IPSec est probablement corrompue.

• Zéro offre pour la phase 2. Rejet de la stratégie de négociation. Sans aucune méthode de sécurité dans l'action de filtrage (offres de la phase 2 du mode rapide IKE), IKE ne réussira pas les négociations en mode rapide pour le trafic adapté aux filtres correspondants. La stratégie IPSec est probablement corrompue.

• La stratégie ne contient pas d'offres valides. La stratégie IPSec ne contient aucune méthode de sécurité valide dans l'action de filtrage d'une règle ou ne contient aucun paramètre pour le mode principal IKE (paramètres Échange de clés configurés sous l'onglet Général).

• L'Agent de stratégie a tenté d'insérer un filtre existant dans IPSEC. Le pilote IPSec a détecté un filtre dupliqué et rejette le doublon. Cette situation est sans conséquence si le filtre dupliqué possède la même action que celui déjà traité par le pilote IPSec. Toutefois, si les actions des filtres sont différentes, la conception de la stratégie IPSec n'est pas prise en charge. Les résultats peuvent différer après une période donnée et dépendent de l'ordre dans lequel le changement de stratégie est traité. La stratégie IPSec doit être conçue de manière à éviter les filtres dupliqués.

• Impossible d'ajouter une entrée à la table de stratégies IPSEC. L'Agent de stratégie IPSec n'a pas réussi à ajouter un nouveau filtre au pilote IPSec. Cette erreur signifie que tout le trafic correspondant à ce filtre ne sera pas sécurisé. Elle peut avoir pour origine une condition de mémoire noyau faible. Si l'erreur persiste, contactez les services de support technique Microsoft.

• L'Agent de stratégie n'a pas pu insérer ou mettre à jour un filtre dans IPSEC. Comme pour le message précédent sur l'ajout d'un filtre, la liste des filtres du pilote IPSec ne correspond pas aux besoins de la stratégie IPSec appliquée. C'est pourquoi le niveau de sécurité offert n'est pas approprié.

• L'utilisation de la stratégie de cache, en tant que stratégie de stockage Active Directory n'a pas pu être appliquée correctement (réseau non joignable, intégrité de la stratégie non valide, etc.). Lorsqu'une stratégie IPSec de domaine est attribuée, l'Agent de stratégie IPSec tente de lire la toute dernière stratégie depuis Active Directory en premier lieu. Ce message indique que l'Agent n'a pas pu extraire la stratégie IPSec du service d'annuaire et qu'il applique la stratégie de la dernière stratégie de domaine, mise en cache dans le registre.  

Sous Windows Server 2003, les événements suivants indiquent qu'un problème d'interprétation de la stratégie IPSec a pu se produire. Dans la plupart des cas, Windows XP utilise le même texte d'événement. Ces problèmes doivent être résolus pour que la stratégie IPSec fonctionne correctement.

• Le moteur PAStore n'a pas pu appliquer la stratégie IPSec de stockage persistante sur l'ordinateur pour <nomstratégie> **avec le code d'erreur **: <numéro>. Le service IPSec a trouvé la stratégie persistante configurée dans le registre mais n'a pas réussi à l'appliquer. Toute stratégie persistante déjà appliquée est supprimée, et le pilote IPSec sera programmé en mode de blocage (avec des exemptions d'heure de démarrage) comme indiqué dans un message distinct.

• Le moteur PAStore n'a pas pu appliquer la stratégie IPSec de stockage du Registre local sur l'ordinateur pour <nomstratégie> *** *** avec le code d'erreur <numéro> . Ce message indique que le service a rencontré au moins une erreur lors de l'application de la stratégie IPSec locale à partir du registre local. Il peut aussi signifier que la stratégie est corrompue ou que les autorisations sont incorrectes.

• Le moteur PAStore n'a pas pu appliquer la stratégie IPSec de stockage Active Directory sur l'ordinateur pour le DN <CN=ipsecPolicy{GUID} avec le code d'erreur : <numéro>. Le service IPSec a trouvé la stratégie de domaine spécifiée par le nom de domaine dans la clé de registre GPTIPSecPolicy mais n'a pas réussi à l'appliquer. Il s'agit d'un message informatif qui indique dans la plupart des cas que les clients mobiles ne peuvent pas contacter le contrôleur de domaine ; ce message doit être suivi par une application réussie de la stratégie mise en cache (si elle existe). Cependant, il peut aussi indiquer qu'un objet GPO fournit une stratégie IPSec qui n'existe pas, qui ne peut pas être lue ou qui est corrompue.

• Le moteur PAStore n'a pas pu appliquer la copie mise en cache localement de la stratégie IPSec de stockage Active Directory sur l'ordinateur pour <nomstratégie> avec le code d'erreur : <numéro>. Ce message signale que le service IPSec sait que la stratégie de domaine doit être attribuée et qu'il a déjà échoué dans l'application de la stratégie extraite d'Active Directory. Il a maintenant rencontré au moins une erreur lors de l'application de la copie mise en cache de la stratégie de domaine attribuée à partir du registre local. Cette erreur peut signifier que le cache est corrompu ou que les autorisations sont incorrectes. Cette condition est grave car aucune stratégie de domaine n'a pu être appliquée, ce qui pourrait affecter la connectivité avec les autres membres du domaine d'isolation. La stratégie locale (si elle est définie) est la suivante dans l'ordre de priorité.

• Le moteur PAStore n'a pas pu appliquer certaines règles de la stratégie IPSec active <nomstratégie> sur l'ordinateur avec le code d'erreur : <numéro> . Exécutez le composant logiciel enfichable Moniteur IPSec pour diagnostiquer le problème. Ce problème se produit généralement en combinaison avec d'autres problèmes cités ici, lorsqu'il n'existe pas de méthode (offre) de sécurité en mode rapide, par exemple.

• Les services IPSec n'ont pas pu obtenir la liste complète des interfaces réseau de cet ordinateur. Cela peut représenter un risque potentiel pour la sécurité de cet ordinateur car certaines interfaces réseau n'obtiendront peut-être pas la protection telle qu'elle était voulue par les filtres IPSec appliqués. Exécutez le composant logiciel enfichable Moniteur IPSec pour diagnostiquer ce problème. Ce message remplace les différents messages de l'API de l'application d'assistance IP utilisés sous Windows 2000. Il s'agit d'une erreur bénigne si elle se produit lors de l'ajout et de la suppression d'interfaces ou lorsque l'état de la connexion change (quand un réseau sans fil n'est plus dans l'intervalle valide, par exemple). Elle est aussi sans importance si elle intervient durant une reprise après l'utilisation des modes Mise en veille ou Mise en veille prolongée et qu'une configuration d'interface réseau différente existe et est détectée au cours de l'étape de reprise.  

Problèmes de configuration de la stratégie avec le réseau privé virtuel RRAS

Comme nous l'avons mentionné dans la section consacrée au support de niveau 1 plus haut dans ce chapitre, le service RRAS est une source courante de conflits avec la stratégie IPSec dans certaines entreprises. Cette section explique pourquoi la stratégie IPSec intégrée aux serveurs VPN L2TP/IPSec crée un conflit avec la stratégie de domaine utilisée dans cette solution. Cette situation décrit le problème d'un filtre dupliqué.

Dans la discussion suivante, la conception de la stratégie IPSec utilisée dans le scénario Woodgrove Bank est utilisée pour illustrer les problèmes. Toutefois, les principes s'appliquent à de nombreux déploiements d'IPSec en entreprise.

La stratégie IPSec pour les serveurs L2TP/IPSec est automatiquement générée par le service du gestionnaire RAS (RASMAN) et comprend les filtres suivants :

• Depuis Toute adresse IP à Mon adresse IP, UDP, source 1701, dest N'importe laquelle (entrante)

• Depuis Mon adresse IP à Toute adresse IP, UDP, source N'importe laquelle, dest 1701 (sortante)

  Remarque : pour plus d'informations sur cette stratégie, reportez-vous à l'article 248750 de la Base de connaissances, Description of the IPSec policy created for L2TP/IPSec (Description de la stratégie IPSec créée pour L2TP/IPSec)  à l'adresse https://support.microsoft.com/?kbid=248750.

Par conséquent, le filtre spécifique au mode principal qui contrôle la réponse de la négociation IKE à ce serveur est l'adresse du filtre entrant :

• Depuis Toute adresse IP à Mon adresse IP -> Authentification par certificat

Notez que l'utilisation de Mon adresse IP provoque le développement du filtre entrant pour chaque adresse IP du serveur VPN. En supposant que le serveur VPN possède une adresse IP d'interface externe pour la connectivité Internet et une interface interne pour la connectivité LAN, les filtres entrants spécifiques au mode principal IKE sont :

• Depuis Toute adresse IP à <adresse IP de l'interface externe> -> Authentification par certificat

• Depuis Toute adresse IP à <adresse IP de l'interface LAN interne> -> Authentification par certificat

Le second filtre (pour l'interface LAN interne) est plus spécifique que le filtre entrant du mode principal IKE de l'isolation de serveurs et de domaines, c'est-à-dire :

• Depuis Toute adresse IP à Sous-réseau -> Authentification Kerberos

Par conséquent; lorsqu'un administrateur utilise un client approuvé pour gérer le serveur VPN, il initie IKE pour l'adresse IP interne du serveur VPN. La recherche de stratégie IKE entrante correspondra au filtre plus spécifique du mode principal et répondra avec les paramètres du mode principal IKE pour L2TP. L'authentification par certificat sera utilisée à la place de l'authentification Kerberos utilisée pour cette solution.

Un second cas de conflit peut survenir si le client VPN Internet utilise les fonctions de mise en quarantaine du client Gestionnaire de connexion. Ce client doit transmettre une « clé de quarantaine » à l'adresse IP LAN interne du serveur VPN pour mettre fin à la quarantaine et obtenir l'accès VPN total au réseau. Dans ce scénario, la stratégie IPSec de domaine du client VPN est appliquée à partir du cache lorsque le portable démarre. Lorsque la connexion de quarantaine VPN est établie, une adresse IP interne est attribuée au client VPN. L'adresse IP interne du client peut être dissimulée par l'un des filtres de sous-réseau (N'importe lequel <-> Sous-réseau interne) défini dans la stratégie IPSec de l'isolation de domaines. Ce filtre est requis pour que les clients VPN disposent d'un accès authentifié par IPSec de bout en bout via le tunnel VPN aux serveurs internes et aux autres stations de travail auxquelles ils accèdent.

Cependant, les filtres de sous-réseau de cette solution initient une négociation IKE à partir de l'adresse IP interne de l'interface virtuelle du tunnel VPN du client vers l'interface LAN interne du serveur VPN. Le mode principal IKE échouera car le serveur répondra pour accepter uniquement l'authentification par certificat, laquelle n'est pas compatible avec la stratégie utilisée pour l'isolation de domaines et de serveurs. Même si la stratégie n'a pas permis l'authentification par certificat, le mode rapide IKE du client proposera le filtre pour tout le trafic, et le serveur VPN échouera la négociation car le filtre proposé est trop général. Le serveur VPN n'acceptera que les filtres en mode rapide spécifiques à L2TP : UDP source 1701, destination N'importe laquelle ou UDP source 1701, destination 1701.

Vous pouvez utiliser les options suivantes pour résoudre le conflit entre la stratégie L2TP/IPSec du serveur RRAS et la stratégie d'isolation.

• Ajoutez les adresses IP LAN internes du serveur RRAS à la liste d'exemptions.

• Désactivez les ports L2TP sur les serveurs VPN. Utilisez uniquement les ports PPTP (Point to Point Tunneling Protocol, Protocole de tunnel point à point).

• Désactivez la stratégie IPSec automatique pour L2TP en utilisant la clé de registre ProhibitIPSec pour RASMAN. Personnalisez manuellement la configuration de la stratégie IPSec pour L2TP afin qu'elle utilise uniquement l'adresse IP externe pour l'authentification par certificat pour le trafic UDP 1701 et uniquement l'adresse IP interne pour l'authentification Kerberos pour le trafic d'isolation de domaines.

  Remarque : pour plus d'informations sur cette configuration, reportez-vous à l'article 240262 de la Base de connaissances How to Configure a L2TP/IPSec Connection Using Pre-shared Key Authentication (Comment faire pour configurer une connexion L2TP/IPSec en utilisant l'authentification par clé pré-partagée)  à l'adresse https://support.microsoft.com/kb/240262.

La solution la plus simple de cette liste est la première, qui exempt la carte réseau interne du serveur RRAS d'utiliser IPSec.

Dépannage d'IKE

L'échec d'IKE et d'IPSec lors du déploiement initial est principalement dû au filtrage réseau qui n'autorise pas les paquets du protocole UDP 500 ou IPSec. C'est pourquoi il est utile d'établir une station de travail IP ou un serveur IP statique pour les tests de stratégie simple, comme dans l'exemple de la stratégie prédéfinie de serveur (requête) qui utilise une clé pré-partagée. L'audit doit être activé pour capturer les événements d'audit IKE. Une stratégie IP de domaine par défaut est déployée pour tous les membres de domaine qui s'authentifient avec la même clé pré-partagée et contient une règle avec un filtre pour la totalité du trafic (y compris ICMP) pour tester l'adresse IP de l'ordinateur.

Ensuite, le script de connexion est déployé pour exécuter une requête ping <testserver> ou
nbtstat –n <testserver>, qui déclenchera la négociation IKE à partir de tous les membres de domaine en vue de tester le serveur. En analysant et en résumant les adresses IP dans les audits des succès du mode principal IKE, vous pouvez déterminer si tous les ordinateurs reçoivent la stratégie et vérifier que toutes les zones de votre réseau peuvent accéder à l'ordinateur test en utilisant les protocoles IKE et IPSec.

Un test plus avancé confirmerait que l'encapsulation IPSec fonctionne avec la fragmentation pour chaque zone du réseau à l'aide de ping –l 5000 <IP address> depuis le serveur test à destination des ordinateurs situés dans chaque zone. L'option –l 5000 entraîne la création d'une surchage de paquet ICMP de 5 000 octets par l'utilitaire Ping. Ce paquet IP complet sera encapsulé par le protocole IPSec, puis fragmenté par la couche IP avant d'être placé sur le réseau. Tous les fragments doivent être reçus à destination ; une réponse consistant en un nombre égal de fragments est renvoyée. L'expérience a montré que les périphériques encombrés ou servant de limite entre des réseaux aux vitesses différentes (par exemple, les réseaux Ethernet de 1 et 100 mégabits) peuvent rencontrer des problèmes de transmission des fragments. De la même manière, les hôtes résidant sur des liaisons MTU différentes, (comme le mode ATM (Asynchronous Transfer Mode, mode de transfert asynchrone), l'interface FDDI (Fiber Distributed Data Interface, interface de transmission de données réparties via fibre optique) et le mode Token Ring) requièrent des messages PMTU ICMP pour découvrir correctement l'unité MTU du chemin réseau pour les paquets TCP protégés par IPSec. Reportez-vous à l'article 314496 Default MTU Size for Different Network Topology (Taille de MTU par défaut pour différentes topologies de réseaux)  de la Base de connaissances à l'adresse https://support.microsoft.com/kb/314496 pour obtenir des informations sur les différentes valeurs MTU réseau par défaut.

Dépannage de la négociation IKE

Il peut s'avérer difficile de dépanner IKE car certaines erreurs peuvent se produire dans certaines conditions uniquement, par exemple, lorsque le mode rapide IKE est initié à partir d'un ordinateur qui est le répondeur. Les erreurs peuvent également être provoquées par des échecs du système d'authentification (erreurs du protocole Kerberos, par exemple) ou lorsque des conceptions de stratégie incompatibles ou des stratégies pré-existantes fusionnent avec la stratégie de domaine. Les défaillances d'IKE entraînent l'arrêt de la participation à la négociation IKE de l'ordinateur qui subit l'échec, alors que l'autre ordinateur participant à la négociation va tenter de se connecter jusqu'à épuisement du nombre de tentatives alloué. Si IKE échoue, étudiez cet échec et les journaux sans effectuer de modification. Vous pouvez activer l'audit standard de façon dynamique sans changer la configuration IPSec ou l'état d'exécution du service. Toutefois, sous Windows 2000, vous devez redémarrer le service IPSec pour activer la journalisation détaillée d'IKE dans le fichier Oakley.log. Sous Windows XP SP2 et Windows Server 2003, vous pouvez activer et désactiver la journalisation d'IKE via la ligne de commande lorsque cela est nécessaire.

Dans certaines situations, il est nécessaire d'arrêter puis de redémarrer le service IPSec afin d'étudier le trafic réseau et de capturer les résultats du fichier Oakley.log à partir d'un état sain. Lorsque le service IPSec est arrêté manuellement ou en tant que partie du redémarrage ou de l'arrêt de l'ordinateur, IKE tente d'envoyer des messages de suppression pour nettoyer l'état de l'association de sécurité IPSec sur tous les pairs connectés. Parfois, le système d'exploitation désactive la fonction d'envoi des paquets avant qu'IKE ait terminé l'envoi des messages de suppression à tous les ordinateurs pairs actifs ; ainsi, l'ordinateur pair conserve l'état de l'association de sécurité IPSec. Lorsque cela se produit, l'ordinateur pair peut « penser » qu'il est connecté de façon sécurisée à l'ordinateur redémarré. Après le redémarrage, si l'ordinateur n'initie pas une nouvelle négociation IKE avec le pair, ce dernier devra patienter cinq minutes pour que les associations de sécurité IPSec soient hors délai avant de tenter de les rétablir. Pour rétablir les associations de sécurité, une négociation en mode rapide est d'abord tentée pendant une minute, suivie d'une initiation en mode principal IKE.

La journalisation IKE a été améliorée dans toutes les versions à partir de Windows 2000. Les événements documentés dans cette section s'appliquent à Windows XP et à Windows Server 2003, bien que les événements Windows 2000 soient similaires.

Le journal de sécurité Windows est recommandé comme point de départ lorsque vous essayez de déterminer la raison d'un échec de négociation IKE. Pour afficher les événements IKE, l'audit des échecs et des succès doit être activé dans le paramètre de la stratégie de sécurité de groupe Auditer les événements de connexion. Une fois que l'audit est activé, le service IKE crée des entrées d'audit et offre une explication à l'échec de la négociation. Toutefois, l'explication des échecs de la négociation IKE est pratiquement toujours signalée comme un échec de l'événement 547, et il peut exister plusieurs causes possibles pour le même message d'erreur. La liste des échecs de l'événement 547 et les causes potentielles sont décrites en détail dans les sections suivantes.

Sous Windows XP SP2 et Windows Server 2003, vous pouvez désactiver tous les audits IKE grâce à la clé de registre DisableIKEAudits. Pensez à vérifier cette valeur sur les ordinateurs contrôlés. Vous pouvez désactiver les audits IKE lorsque ceux-ci génèrent trop d'événements de succès ou d'échec et que cela empêche les événements de la catégorie connexion/déconnexion d'être contrôlés de façon efficace.

Les valeurs du code d'erreur sont souvent signalées dans les événements d'audit IKE et les détails du journal. Vous trouverez une description de ces valeurs dans Microsoft MSDN®, à la page System Code Errors (12000-15999) (Erreurs du code système (12000-15999))  à l'adresse https://msdn.microsoft.com/library/en-us/debug/base/
system_error_codes__12000-15999_.asp.

Le dépannage de la négociation IKE requiert une connaissance approfondie du comportement attendu de la conception de la stratégie IPSec, du processus de négociation IKE et des événements d'échec IKE. Cette section décrit uniquement les événements les plus courants associés au scénario d'isolation de domaine Woodgrove Bank. Elle ne traite pas tous les événements d'audit IKE ni toutes les conditions d'échec.

Une fois que le processus de négociation IKE est bien compris, un suivi réseau depuis au moins un côté de la communication doit être obtenu (si possible) afin d'identifier les problèmes liés à IKE avant de tenter de remplir un fichier Oakley.log. Dans des scénarios d'isolation de serveurs et de domaines, les serveurs déployés doivent disposer de la possibilité d'effectuer un suivi à l'aide du Moniteur réseau.

Le fichier Oakley.log propose la journalisation la plus détaillée possible et peut être requis par les deux côtés de la négociation (avec des heures synchronisées). Cependant, si vous activez ce fichier journal, la négociation IKE risque d'être ralentie, ce qui va modifier les conditions de synchronisation et entraîner la perte de l'état existant si le service est redémarré pour lire de nouveau la clé de registre (requis sous Windows 2000 et Windows XP SP1). À l'heure actuelle, il n'existe pas d'instructions publiées permettant d'interpréter le fichier Oakley.log. Dans ce guide, cette interprétation est considérée comme partie intégrante de l'ensemble des compétences de niveau 3. En raison de contraintes liées à l'espace, les extraits issus des détails du journal fournis ici ne concernent que quelques erreurs. Pour obtenir de l'aide sur l'interprétation du fichier Oakley.log, contactez les services de support technique Microsoft.

Les quatre fichiers journaux suivants sont créés pour IKE :

• Oakley.log. Journal actuel d'IKE, limité à 50 000 lignes.

• Oakley.log.bak. Une fois que le fichier Oakley.log contient 50 000 lignes, ce fichier est créé et un nouveau fichier Oakley.log vide est utilisé. Ce fichier continue à être écrasé autant de fois que nécessaire par le nouveau fichier Oakley.log tant que le service IPSec est exécuté.

• Oakley.log.sav. Le fichier Oakley.log précédent est enregistré sous ce nom lorsque le service IPSec démarre.

• Oakley.log.bak.sav. Le fichier Oakley.log.bak précédent est enregistré sous ce nom lorsque le service IPSec démarre.

Au cours des opérations de dépannage, il arrive fréquemment que l'heure des deux ordinateurs sur lesquels sont effectués la journalisation et le suivi réseau ne soit pas synchronisée. Cette erreur rend la corrélation des journaux difficile, mais pas impossible. La corrélation entre les messages IKE et les paquets du suivi réseau doit faire l'objet d'une vérification croisée à l'aide des cookies d'en-tête ISAKMP et des champs d'ID de message en mode rapide IKE.

Comportements IKE attendus

Si l'initiation du mode principal IKE ne peut pas contacter l'adresse IP de destination souhaitée en raison d'un blocage réseau, la communication sécurisée par IPSec ne peut pas être négociée. Si l'initiateur n'est pas configuré pour la communication en texte clair, alors l'échec du contact de la destination apparaîtra en tant qu'événement d'audit 547 dans le journal de sécurité avec l'une des entrées de texte suivantes :

• Pas de réponse du pair

• Le délai d'attente a expiré pour la négociation.

• SA IKE supprimée avant que l'établissement ait été terminé  

Cependant, pour les clients d'isolation de domaines, il est possible que cette condition n'apparaisse pas comme un échec si leur stratégie autorise la communication en clair. Un événement 541 de succès en mode principal IKE est créé lorsqu'une association de sécurité logicielle est établie. Vous savez qu'un événement 541 affiche une SA logicielle lorsque le SPI sortant est égal à zéro et que tous les algorithmes sont affichés sous la forme Aucun. L'exemple suivant montre comment ces paramètres apparaissent dans un événement 541 :

ESP Algorithm None
HMAC Algorithm None
AH Algorithm None
Encapsulation None
InboundSpi 31311481 (0x1ddc679)
OutBoundSpi 0 (0x0)
Lifetime (sec) <whatever is configured for QM lifetime>
Lifetime (kb) 0

Remarque : les événements des SA logicielles vers la même adresse IP de destination porteront des dates différentes et des valeurs SPI entrantes différentes.

Des délais de connectivité d'une minute sont observés chaque fois que deux ordinateurs ne sont plus synchronisés parce qu'un mode principal IKE actif existe peut-être entre eux. Des délais de cinq minutes peuvent être observés si l'un des ordinateurs considère qu'il existe une paire d'associations de sécurité IPSec active entre eux et que l'autre ordinateur (un serveur, par exemple) a supprimé ces associations de sécurité et n'est pas en train d'initier une recomposition en mode rapide. Windows 2000 IKE prenait en charge des messages de suppression uniques qui étaient parfois perdus. Windows XP et Windows Server 2003 disposent d'une prise en charge fiable de la fonction de suppression sous la forme de messages de suppression multiples qui agissent comme une mesure de protection contre les paquets abandonnés.

Cette situation type se produit lorsque l'utilisateur d'un portable d'isolation de domaine retire l'ordinateur de la station d'accueil pour se rendre à une réunion. La station d'accueil possède une connexion Ethernet filaire, et le fait de retirer cette interface réseau nécessite le retrait de tous les filtres qui lui sont associés (s'il s'agit de filtres développés à partir de Mon adresse IP).

Toutefois, aucun filtre ayant une action de négociation n'utilise Mon adresse IP dans la solution d'isolation de domaines ; il s'agit de filtres de type N'importe lequel <-> Sous-réseau. Par conséquent, les états de l'association de sécurité IPSec et de l'association de sécurité IKE restent actifs sur le portable car ces filtres ne sont pas supprimés lors des changements d'adresse. Si les filtres avaient été développés depuis Mon adresse IP, ils auraient été supprimés au moment de la disparition de l'adresse IP.

Chaque fois qu'un filtre de type N'importe lequel est supprimé du pilote IPSec, ce dernier informe IKE que toutes les associations de sécurité IKE et IPSec utilisant cette adresse IP doivent également être effacées. IKE tentera d'envoyer des messages de suppression pour ces SA, puis les supprimera de façon interne. Ces messages de suppression auront la même adresse IP source que celle utilisée pour les SA IKE, même s'il est possible qu'une autre adresse IP source soit présente sur l'interface connectée au moment de l'envoi du message de suppression. L'adresse IP source n'est pas importante pour l'ordinateur distant si la paire de cookies d'en-tête ISAKMP est reconnue et que les vérifications cryptographiques du paquet sont valides. Cependant, il arrive fréquemment que les messages de suppression ne soient pas envoyés car il n'y a pas de connectivité réseau dans les secondes suivant la déconnexion (retrait du portable).

Dans le cas particulier de filtres N'importe lequel <-> Sous-réseau, les filtres ne sont jamais supprimés, ce qui signifie que les associations de sécurité IKE et IPSec ne sont pas immédiatement supprimées. Pendant ce temps, les SA IPSec expirent sur les ordinateurs distants auparavant connectés, et les messages de suppression en mode rapide IKE sont envoyés à l'adresse précédente du portable. Les SA en mode rapide IKE continuent à exister pendant 8 heures (par défaut) sur ces ordinateurs distants, mais peuvent être effacées à tout moment avant l'expiration de ce délai pour des raisons IKE internes. Bien entendu, les messages IKE de suppression des SA ne parviennent plus à l'ancienne adresse IP du portable. Lorsque le portable est finalement reconnecté à la station d'accueil, il reçoit de nouveau la même adresse IP. Les applications de partage de fichiers, clients de messagerie et autres se reconnectent généralement aux mêmes destinations. Cependant, il est maintenant possible qu'il existe une différence d'état IKE entre le portable et ces destinations distantes. Si le portable dispose toujours d'un mode principal IKE, il tentera de négocier en mode rapide IKE. Le mode rapide utilise un état cryptographique que le pair distant a supprimé, c'est pourquoi il ne reconnaît pas ces messages et n'y répond pas. Sur le portable, le nombre maximal de tentatives arrive à expiration au bout d'une minute ; IKE tente alors une nouvelle négociation en mode principal qui cette fois réussit. Par conséquent, l'utilisateur du portable peut remarquer un délai d'une minute lorsqu'il se reconnecte aux ressources distantes. Microsoft s'attache à améliorer ce comportement dans les futures mises à jour de toutes les versions de Windows prenant en charge IPSec.

La négociation IKE peut signaler l'expiration d'un délai pour diverses raisons. L'événement « Le délai d'attente a expiré pour la négociation » survient lors de l'échec des étapes de la négociation IKE (excepté l'étape de communication en clair) en raison de l'expiration du nombre limite de tentatives, sauf lorsque IKE termine la négociation par un événement « SA IKE supprimée avant que l'établissement ait été terminé ». Ces deux événements sont pratiquement identiques. Ils sont souvent courants, bénins et attendus au cours du fonctionnement normal des clients mobiles, qui modifient fréquemment et rapidement les états de la connectivité réseau lorsque les événements suivants se produisent :

• Les utilisateurs insèrent et retirent les ordinateurs portables des stations d'accueil.

• Les utilisateurs débranchent une connexion filaire.

• Les ordinateurs portables sont en mode de veille ou de veille prolongée.

• La plage attribuée à la connexion sans fil est dépassée.

• Une connexion VPN est déconnectée.

• Une carte réseau PCMCIA est éjectée alors qu'elle est connectée.

Pour un ordinateur distant, ces événements donnent l'impression que le pair vient de se déconnecter du réseau. L'ordinateur distant va tenter de recomposer ou de renégocier jusqu'à ce que le délai de négociation IKE expire.

Les échecs dus à l'expiration de la durée de négociation ont été améliorés dans Windows Server 2003 dans le but d'identifier le moment de la négociation IKE où le délai d'expiration a lieu par l'identification de la dernière étape réussie de la négociation. Ces événements peuvent également être provoqués par la traduction des adresses réseau (Network address translation, NAT) lorsque IKE négocie sans les fonctions NAT-T. Cependant, le délai de négociation IKE expire aussi si le pair distant rencontre un problème qui entraîne l'échec de la négociation IKE.

Ainsi, dans tous les cas d'expiration des délais de négociation et d'apparition d'événements « SA IKE supprimée avant que l'établissement ait été terminé », le support de niveau 2 doit identifier si l'ordinateur distant est responsable de l'échec en vérifiant les événements 547 d'audit des échecs sur cet ordinateur jusqu'à la minute précédant l'enregistrement de l'expiration du délai par IKE.

Événements de succès de la négociation IKE

Si la négociation IKE réussit, les SA en mode principal IKE s'affichent dans le composant logiciel enfichable Moniteur IPSec et via les outils d'interrogation de la ligne de commande.

Pour afficher la liste des associations de sécurité actives en mode principal IKE

• Sous Windows 2000 :

  ipsecmon.exe, netdiag /test:ipsec /v 
  

Remarque : cette commande affiche uniquement les associations de sécurité IPSec, et non les associations de sécurité en mode principal IKE.

• Sous Windows XP :

  IPSec monitor snapin, ipseccmd show sas 
  

• Sous Windows Server 2003 :

  Remarque : la ligne a été divisée en plusieurs lignes pour des raisons de lisibilité. Cependant, lorsque vous entrez cette commande dans un système, veillez à l'entrer sur une seule ligne.

  IPSec monitor snapin, netsh ipsec dynamic 
  show [mmsas | qmsas]
  

Les SA réussies en mode principal et en mode rapide génèrent les événements suivants dans le journal de sécurité si l'audit est activé.

• 541. Mode principal IKE ou mode rapide IKE établi

• 542. Mode rapide IKE supprimé

• 543. Mode principal IKE supprimé

Messages d'information du journal en mode principal IKE

Pour déterminer s'il existe un problème d'échange du mode principal, recherchez les événements consignés suivants dans les journaux des événements des ordinateurs :

Tableau 7.5 : Messages d'information du journal en mode principal IKE

Texte du journal	Description
La nouvelle stratégie a invalidé les SA formés avec l'ancienne stratégie	Message de Windows 2000 indiquant que la modification d'une stratégie IPSec a entraîné la suppression des associations de sécurité IKE ou IPSec actuelles. Cette erreur est sans conséquence. Les nouvelles associations de sécurité IPSec seront formées selon le flux de trafic actuel qui utilise la nouvelle stratégie IPSec.
IKE a un grand nombre de requêtes d'établissement d'association de sécurité en attente, et démarre le mode de prévention de refus de service.	Cette condition peut être normale, causée par une surcharge de l'ordinateur, et/ou un grand nombre de tentatives de connexions client. Cela pourrait également être le résultat d'une attaque de refus de service contre IKE. Si tel est le cas, il y aura plusieurs audits de négociations IKE ayant échoué vers des adresses IP factices. Dans le cas contraire, cela signifie simplement que l'ordinateur est extrêmement surchargé. Ce message indique que IKE pense avoir été submergé de requêtes d'établissement de SA en mode principal IKE. La stratégie de réponse à l'attaque de refus de service va consister pour IKE à rejeter la plupart de ces requêtes.
IKE ne subit plus le mode de prévention de refus de service et a repris un fonctionnement normal.	IKE a récupéré après ce qu'il considérait comme une condition d'attaque de refus de service, et a repris un fonctionnement normal.

La présence de ces entrées n'indique pas un échec de communication. Il s'agit de données informatives qui peuvent servir à fournir des informations supplémentaires en vue de déterminer la vraie cause d'un problème.

Événements 547 relatifs à l'échec de la négociation en mode principal IKE

Les événements d'échec IKE suivants peuvent se produire lorsqu'une négociation en mode principal IKE échoue :

• Pas de réponse du pair. Cet événement est attendu pour les connexions sortantes aux ordinateurs qui n'utilisent pas IPSec et qui ne sont pas membres de la liste d'exemption. Toutefois, le support de niveau 2 doit être conscient des problèmes de connectivité qui bloquent la négociation IKE, qui génèrent également cet événement.

• Aucune stratégie configurée. Cet événement signale un problème si l'adresse IP source est située dans les sous-réseaux internes ou signale la présence d'un jeu de filtres incompatible. Il peut être prévu que les ordinateurs n'aient pas de règle pour négocier avec certaines plages d'adresses ou sous-réseaux. Les ordinateurs de ces sous-réseaux peuvent tenter une initiation IKE, mais n'obtiendront aucune réponse car aucune stratégie n'est configurée.

• Les attributs de sécurité IKE ne sont pas acceptables. Cet événement ne doit pas se produire sur les systèmes correctement configurés. Réalisez les procédures de la section Vérification de la stratégie IPSec appropriée pour trouver l'origine du problème.

Les messages d'expiration de délai suivants peuvent être attendus pour les raisons mentionnées précédemment. Ils peuvent également indiquer que l'ordinateur distant a échoué la négociation IKE. En général, le support de niveau 2 se concentre sur la recherche des causes de l'échec IKE sur l'ordinateur distant, plutôt que sur l'expiration des délais de négociation (très fréquente sur les ordinateurs déconnectés) et sur l'incompatibilité de la conception de la stratégie dans laquelle le répondeur à une négociation en mode principal IKE ou en mode rapide IKE ne trouve pas de filtre spécifique correspondant à la requête entrante.

• Le délai d'attente a expiré pour la négociation.

• Le délai d'attente a expiré pour la négociation. Première charge utile (SA) traitée. Répondeur durée Delta 63.

• Le délai d'attente a expiré pour la négociation. Seconde charge utile (KE) traitée. Initiateur durée Delta 63.

• Le délai d'attente a expiré pour la négociation. Seconde charge utile (KE) traitée. Répondeur

Échecs d'audit en mode rapide IKE (547)

Les événements d'échec IKE suivants peuvent se produire lorsqu'une négociation en mode rapide IKE échoue :

• Aucune stratégie configurée. Troisième charge utile (ID) traitée. Initiateur

• Échec de la négociation d'association de sécurité dû à la non correspondance d'attributs.

• Erreur de traitement générale.

• Impossible d'obtenir un nouveau SPI pour la SA entrante à partir du pilote Ipsec.

• Le pilote IPSEC n'a pas réussi la négociation Oakley avec car aucun filtre n'existe.

• Impossible d'ajouter une association de sécurité au pilote IPSec.

• Le délai d'attente a expiré pour la négociation.

Le mode rapide IKE ne doit pas échouer pour les stratégies IPSec correctement conçues et les charges de travail ordinaires. Si vous recevez l'une de ces erreurs, le support de niveau 2 doit en premier lieu suivre les étapes de la section Vérification de la stratégie IPSec appropriée. Il doit ensuite tenter d'établir une corrélation entre ces événements et des conditions de performances inhabituelles, comme une utilisation à 100 % du processeur ou des conditions de mémoire du noyau très faibles.

Notez que des échecs du mode rapide IKE avec expiration du délai de négociation seraient attendus si l'ordinateur n'utilisait plus sa précédente adresse IP pour l'une des raisons expliquées précédemment.

Dépannage des échecs IKE provoqués par l'authentification

Les messages suivants sont associés aux échecs de l'authentification IKE :

• La cible spécifiée est inconnue / Aucune autorité n'a pu être contactée pour l'authentification.

• La cible spécifiée est inconnue ou inaccessible. Première charge utile (SA) traitée. Initiateur durée Delta 0.

• Les informations d'authentification IKE ne sont pas acceptables.

• La tentative d'ouverture de session a échoué.

• Échec de l'authentification dans l'utilisation de Kerberos.

• IKE n'a pas trouvé de certificat ordinateur valide.

Les deux premiers messages indiquent que l'identité Kerberos de l'ordinateur distant ne peut pas être utilisée pour obtenir un ticket de service pour l'ordinateur distant. Cette situation a pu se produire parce qu'il n'existe pas d'approbation de domaine ou parce que l'accès aux contrôleurs de domaine n'est pas disponible.

Si une négociation IKE entrante échoue en raison des paramètres Accéder à cet ordinateur à partir du réseau, la négociation IKE depuis l'ordinateur chargé des droits d'accès signalera un événement 547 Échec de l'authentification dans l'utilisation de Kerberos, comme expliqué plus haut. Cet événement n'indique pas de manière spécifique que le problème est l'échec lorsque les paramètres Accéder à cet ordinateur à partir du réseau sont vérifiés ; c'est pourquoi vous devez obtenir le fichier Oakley.log du serveur pour rechercher l'erreur spécifique générée. L'appartenance de l'initiateur IKE à un groupe doit être vérifiée pour déterminer s'il fait partie d'un groupe autorisé. Si l'ordinateur fait partie d'un groupe disposant d'un accès, il est possible qu'il ne possède pas les tickets Kerberos reflétant son appartenance au nouveau groupe ou qu'il ne soit pas en mesure d'obtenir les tickets Kerberos adéquats. Complétez les procédures traitées dans la section Vérification de la connectivité et de l'authentification avec les contrôleurs de domaine, plus haut dans ce chapitre.

Dépannage des problèmes liés aux applications

Cette section explique pourquoi la conception des applications peut interagir avec l'utilisation d'IPSec sous Microsoft Windows. Le concepteur de la stratégie IPSec ainsi que le personnel du support doivent comprendre ces impacts afin de pouvoir aider à la classification et à l'identification rapide du problème. L'application de la stratégie IPSec doit être transparente pour les applications. Cependant, dans certaines circonstances où la stratégie IPSec est attribuée ou protège le trafic, l'application peut se comporter de manière inhabituelle. Les sections suivantes illustrent ces situations dans le contexte du scénario d'isolation de domaine Woodgrove Bank.

ICMP autorisé, mais IPSec requis par les protocoles TCP et UDP

Certaines applications utilisent un message de demande d'écho (Ping) ICMP pour déterminer si une adresse de destination est accessible. Par exemple, comme IPSec ne protège pas le trafic ICMP de cette solution, une application peut recevoir une réponse ICMP depuis une destination cible. Cependant, l'application ne pourra peut-être pas se connecter à la destination cible à l'aide du trafic TCP et UDP protégé par IPSec lorsque la négociation IKE échoue.

Délai de connexion initial

La négociation IKE nécessite davantage de traitement et plus de temps pour s'exécuter qu'un processus de connexion en trois étapes ou qu'un seul paquet de requête/réponse Nbtstat non authentifié. Les applications qui attendent une réponse de connexion TCP ou UDP rapide de la part de la destination cible peuvent considérer que la destination ne répond pas et entreprendre une autre action, comme signaler une erreur ou essayer de se connecter à une autre destination. Les négociations IKE à l'aide de l'authentification Kerberos réussissent généralement au bout d'une à deux secondes. Cependant, ce délai dépend de plusieurs facteurs, notamment l'utilisation du processeur sur les deux ordinateurs et la perte des paquets réseau. La communication en texte clair requiert toujours trois secondes avant d'autoriser l'envoi du premier paquet TCP non protégé.

L'application se bloque en attendant la réponse du réseau

Certaines applications sont conçues pour supposer que le délai de connexion ou de réception d'un message d'erreur est très bref. Ces applications attendent que la connexion soit effective (opération de liaison au socket terminée) avant d'afficher les modifications dans l'interface utilisateur. Lorsque le trafic de cette application est protégé par IPSec, l'application peut se bloquer brièvement lors de connexions réussies. Ce phénomène peut continuer jusqu'à ce que l'application soit fermée ou qu'elle rencontre d'autres erreurs inhabituelles si la connexion ne réussit pas en raison d'un échec de négociation IKE ou d'un filtre bloquant IPSec. La couche du socket réseau ne reconnaît pas les filtres IPSec et ne sait pas que IKE négocie la sécurité du trafic. L'application interprète généralement ces conditions comme une panne de l'hôte distant ou une défaillance du réseau. Cependant, les applications peuvent également interpréter les échecs de connexion aux contrôleurs de domaine par l'indisponibilité de l'ordinateur de destination ou le refus de la connexion.

Traitement des paquets réseau en mode noyau affecté

Les applications qui impliquent des pilotes réseau ou le traitement de paquets au niveau du noyau risquent de ne pas fonctionner correctement lorsque IPSec sécurise le trafic. Ces applications peuvent apporter des modifications au paquet, ce qui entraînera l'abandon du paquet par IPSec. Ou encore, l'application peut ne pas comprendre les modifications d'IPSec, ce qui peut se traduire par une erreur système (écran bleu).

Analyse réseau de la part des hôtes d'un domaine d'isolation affectée

Les outils hôtes qui tentent de sonder rapidement les adresses IP distantes ou les ports ouverts du réseau peuvent fonctionner beaucoup plus lentement si IPSec tente de sécuriser leur trafic. Le trafic destiné au sondage peut provoquer un refus de service sur l'hôte local en déclenchant l'initiation de centaines d'adresses IP par IKE en quelques secondes ou minutes. Certains outils basés sur SNMP dépendent de l'envoi d'événements d'interruption SNMP à des hôtes non approuvés qui agissent en tant que collecteurs d'événements. Même si IPSec est autorisé à utiliser les communications en clair, les paquets d'interruption SNMP sortants risquent d'être rejetés par le pilote IPSec avant que l'association de sécurité logicielle ne soit établie. De la même manière, certaines applications basées sur le protocole UDP (comme NTP et le localisateur de contrôleur de domaine Windows) attendent trois secondes seulement qu'une réponse soit reçue, ce qui entraîne l'échec de l'application ou des rapports erronés indiquant qu'une destination ne peut pas être contactée.

Problèmes liés au fournisseur de services superposés Winsock

Certaines applications légitimes (comme les pare-feu personnels) et malveillantes (comme les logiciels espions) peuvent causer des problèmes en insérant leurs propres fonctions d'inspection du trafic, appelées services superposés Winsock (LSP). Le composant IKE de l'implémentation Microsoft d'IPSec utilise une fonction API Winsock étendue dont le pointeur de fonction est déterminé par l'appel de WSAIoctl(). Si l'appel de cette fonction n'est pas autorisé à traverser les LSP installés, IKE ne peut pas contrôler les ports UDP requis. Sous Windows Server 2003, IPSec interprète cela comme une incapacité du composant à faire appliquer la stratégie de sécurité, et il réagit de façon défensive. La fonction Échec du mode sécurisé est appelée et le pilote IPSec est placé en mode de blocage. L'administrateur doit se connecter en utilisant une connexion de bureau pour pouvoir arrêter le service IPSec et restaurer la connectivité. Si le service IPSec ne répond pas à la requête d'interruption, il doit être configuré comme désactivé, et l'ordinateur doit être redémarré.

Même si IKE a été correctement initialisé, la capacité de l'ordinateur à envoyer et à recevoir des protocoles IKE et IPSec peut être bloquée par le LSP ou un programme tiers.

Pour le support de niveau 2, le dépannage du LSP Winsock consiste à identifier l'existence de LSP. Le support de niveau 3 doit ensuite mener d'autres investigations visant à identifier l'application qui a installé les LSP, puis à les organiser ou à les supprimer si le service IPSec ou IKE ne rencontre plus de difficulté. Outils permettant de détecter les fournisseurs de services superposés Winsock :

• Sporder.exe. Il s'agit d'une applet permettant d'afficher les LSP dans la partie Winsock 2.0 du kit de développement logiciel (Software Development Kit, SDK) de la plate-forme Windows.

• Netdiag /debug.

Clients tiers de réseau privé virtuel IPSec

Des problèmes peuvent survenir lorsqu'une implémentation IPSec tierce est installée dans le cadre d'un client VPN d'accès à distance. En général, ces clients désactivent le service IPSec et n'entrent pas en conflit avec le service IPSec Windows natif. Toutefois, pour les membres du domaine approuvé de cette solution, le service IPSec natif est requis. C'est pourquoi les implémentations IPSec tierces peuvent créer des conflits pour les raisons suivantes :

• Les deux implémentations IKE ont besoin du port UDP 500.

• Le traitement des paquets du noyau IPSec nécessite le protocole ESP pour les deux ordinateurs.

• Les fonctions LSP Winsock sont installées dans le cadre du client.

• La fonction de pare-feu est fournie par le client VPN.

• La superposition empêche les paquets IKE et IPSec natifs encapsulés d'être transmis via le tunnel IPSec tiers.

Les fournisseurs VPN permettent généralement de savoir si les VPN prennent en charge le service IPSec Windows natif activé et s'ils prennent en charge le trafic en mode transport protégé par IPSec de bout en bout via leur connexion d'accès à distance. Dans certains cas, la passerelle du fournisseur VPN prend en charge les clients VPN L2TP/IPSec et PPTP sous Windows 2000 et Windows XP. Les clients VPN Windows natifs sont compatibles avec le mode de transport IPSec de bout en bout via le tunnel VPN.

Dépannage de niveau 3

Si le dépannage réalisé par le niveau 2 ne permet pas de résoudre un problème, un niveau d'expertise supplémentaire est requis pour analyser le problème et trouver une solution. Ce niveau d'expertise est appelé support de niveau 3. Dans plusieurs cas, ce support est fourni par des spécialistes IPSec contractuels ou des entreprises de support technique, comme les services de support technique Microsoft.

Le support IPSec de niveau 3 requiert une connaissance approfondie du fonctionnement d'IPSec et de la pile TCP/IP de Microsoft. Les membres du personnel du support de niveau 3 ont besoin d'une formation avancée sur IPSec et son utilisation dans des scénarios d'isolation de serveurs et de domaines. Grâce aux compétences acquises, le personnel du support de niveau 3 peut devenir responsable de la formation du personnel technique des niveaux inférieurs et concevoir de la documentation d'assistance  ; par exemple, des résumés techniques, des Livres blancs, des guides de maintenance, des questions fréquentes et des informations sur l'architecture IPSec et la classification. Le support de niveau 3 peut aussi être chargé d'élaborer et de documenter des plans de récupération d'urgence.

Intervention des services de support technique Microsoft

Si les procédures de dépannage décrites dans ce chapitre ne vous aident pas à résoudre le problème ou si votre entreprise ne dispose pas des compétences requises pour utiliser les techniques de dépannage avancées, vous devrez peut-être transférer le problème aux services de support technique Microsoft. Il est important de recueillir autant d'informations de diagnostic que possible, comme les fichiers journaux et les données de surveillance réseau avant de contacter les services de support technique. Utilisez cette liste pour réunir les informations nécessaires au support de niveau 3 ou aux services de support technique Microsoft pour analyser le problème :

• Conditions de sécurité requises pour l'authentification entrante et sortante et l'autorisation de chaque ordinateur. Vous devez disposer d'une brève description expliquant comment la configuration IPSec et la stratégie de groupe de l'ordinateur remplissent ces conditions.

• Diagramme représentatif du scénario, affichant le nom des ordinateurs source et cible, leur adresse IP au moment de la collecte des fichiers journaux et la version de leur système d'exploitation (y compris des informations sur le Service Pack). Pensez également à noter l'adresse IP des serveurs DNS, WINS et des contrôleurs de domaine.

• Suivi par le Moniteur réseau des communications de chaque côté pendant que la stratégie IPSec est active, de préférence simultanément pour que les paquets puissent facilement être mis en corrélation dans les deux fichiers de suivi. Les suivis réseau doivent inclure tout le trafic entrant et sortant sur chaque ordinateur (si possible) pour que les demandes d'authentification, les recherches DNS et tout autre trafic associé puissent être identifiés. De même, si les communications échouent alors que la stratégie IPSec est active et qu'elles réussissent lorsqu'elle est désactivée ou que le service est arrêté, un suivi du trafic réseau lorsque IPSec est inactif doit également être disponible. Il est très important que l'heure du système soit synchronisée entre ces systèmes afin qu'il soit possible d'établir une corrélation entre les fichiers journaux et les fichiers de suivi.

• Sous Windows 2000, Windows XP et Windows Server 2003, exécutez
  netdiag /debug >netdiag-debug-computername.txt juste avant ou juste après la capture du suivi réseau. (Netdiag génère un trafic réseau important, qui n'a pas besoin de faire partie du suivi réseau.) Sous Windows XP et Windows Server 2003, exécutez également
  portqry -v -local >portqry-v-computername.txt.

• Les fichiers Oakley.log IKE de chaque côté de la communication sont collectés au moment où le problème survient et au moment où les suivis du moniteur réseau sont enregistrés. Le nom de ces fichiers doit indiquer le nom de l'ordinateur. Si un client RAS ou VPN Windows est concerné, vous devez utiliser l'outil RASDIAG pour collecter les informations.

• Les journaux système, de sécurité et des applications complets de chaque ordinateur au moment où les fichiers Oakley.log et les fichiers de suivi réseau sont collectés.

• Tous les fichiers journaux spécifiques à la stratégie de groupe créés au moment où les fichiers Oakley.log et de suivi réseau sont capturés.

• Les détails de la stratégie IPSec de chaque ordinateur. Si les stratégies IPSec qui s'appliquent à chaque ordinateur peuvent être facilement enregistrées, elles doivent être incluses. Cependant, la stratégie IPSec active de l'ordinateur est souvent une combinaison de plusieurs types de stratégies IPSec et pas uniquement une stratégie de domaine ou locale. Pour analyser la stratégie active d'un ordinateur, répertoriez les filtres spécifiques au mode principal IKE et les filtres spécifiques au mode rapide IKE à partir du composant logiciel enfichable MMC Moniteur IPSec.

Pour créer un fichier texte mis en forme à partir de ces filtres

1. Cliquez avec le bouton droit de la souris sur le nœud Filtres spécifiques du mode rapide IKE dans le volet gauche de l'arborescence.

2. Sélectionnez Exporter la liste.

3. Enregistrez le fichier texte délimité par des tabulations sous IKE-qm-<nomordinateur-spécifique>.txt ou sous une convention de dénomination similaire comprenant le nom de l'ordinateur.

Un fichier texte délimité par des tabulations comprenant tous les détails du filtrage peut être importé dans une feuille de calcul ou un document de traitement de texte.

Résumé

Ce chapitre vous a fourni des informations détaillées sur les processus qui aident le support de niveau 1 (support technique) et le support de niveau 2 (spécialistes informatiques du support réseau) à résoudre les problèmes de communication IPSec courants. Il est impossible de fournir des informations sur toutes les erreurs potentielles, car le fonctionnement d'IPSec et la sécurité réseau sont trop complexes pour permettre de répertorier toutes les variantes. Lorsque cela est possible, les développeurs de ce chapitre ont souligné les options possibles pour mettre l'accent sur les zones susceptibles de rencontrer des problèmes dans le type d'environnement d'isolation de serveurs et de domaines détaillé dans ce guide.

Les exemples de scripts fournis dans ce guide ont été testés au cours de l'implémentation test du scénario Woodgrove Bank afin de prouver leur efficacité. Toutefois, ces scripts sont conçus pour être personnalisés en fonction des besoins d'une entreprise et ne sont donc pas pris en charge par Microsoft.

Aux yeux du lecteur, le dépannage d'IPSec doit sembler techniquement complexe et requiert des compétences dans divers domaines technologiques autres qu'IPSec, comme les réseaux, Active Directory et les stratégies de groupe. Cependant, les informations fournies dans ce chapitre doivent permettre au lecteur de résoudre une grande partie des problèmes rencontrés, sauf les plus compliqués qui peuvent affecter la solution d'isolation de serveurs et de domaines.

Pour les lecteurs qui souhaitent développer leurs connaissances et entrer dans la catégorie du support de niveau 3, la section suivante répertorie d'autres sources de documentation qui pourront les occuper pendant quelques années !

Informations complémentaires

• Pour obtenir des informations de base sur IPSec, reportez-vous à la référence technique How IPSec Works  de Windows Server 2003 à l'adresse www.microsoft.com/resources/documentation/
  WindowsServ/2003/all/techref/en-us/w2k3tr_IPSec_how.asp

• Pour obtenir des informations détaillées sur la résolution des problèmes liés à TCP/IP, reportez-vous aux références techniques suivantes :

  • TCP/IP in Windows 2000 Professional  (TCP/IP sous Windows 2000 Édition Professionnel) à l'adresse www.microsoft.com/resources/documentation/Windows/
    2000/server/reskit/en-us/prork/prcc_tcp_slnb.asp

  • Chapitre TCP/IP Troubleshooting  (Dépannage du protocole TCP/IP) du kit de ressources Windows XP à l'adresse www.microsoft.com/resources/documentation/Windows/
    XP/all/reskit/en-us/prcc_tcp_gfhp.asp

  • How to troubleshoot TCP/IP connectivity with Windows XP (Dépannage de la connectivité TCP/IP sous Windows XP)  à l'adresse https://support.microsoft.com/?kbid=314067

  • Windows Server 2003 TCP/IP Troubleshooting  à l'adresse www.microsoft.com/technet/prodtechnol/windowsserver2003/
    operations/system/tcpiptrb.mspx

• Pour consulter l'aide en ligne et la documentation du kit de ressources concernant le dépannage d'IPSec sous Windows 2000, Windows XP et Windows Server 2003, reportez-vous aux références suivantes :

  • Basic IPSec troubleshooting in Microsoft Windows 2000 Server  à l'adresse
    https://support.microsoft.com/?kbid=257225

  • Microsoft Windows 2000 Advanced Documentation  (Documentation avancée de Microsoft Windows 2000) à l'adresse
    www.microsoft.com/windows2000/en/advanced/help/
    sag_ipsectrouble.htm?id=3352

  • Basic L2TP/IPSec Troubleshooting in Windows XP  (Résolution élémentaire des problèmes liés à IPSec sous Windows XP) à l'adresse
    https://support.microsoft.com/?kbid=314831

  • Aide de Windows Server 2003 – Troubleshooting tools  (Outils de dépannage) IPSec à l'adresse
    www.microsoft.com/technet//prodtechnol/
    windowsserver2003/proddocs/standard/
    sag_ipsec_tools.asp?frame=true#iketrace_enable

  • Diagramme de présentation de l'architecture dans le Livre blanc Windows 2000 TCP/IP Implementation Details  (Informations de l'implémentation TCP/IP) sous Windows 2000 à l'adresse
    www.microsoft.com/windows2000/
    techinfo/howitworks/communications/networkbasics/
    tcpip_implement.asp

  • Windows 2000 Network Architecture  (Architecture réseau sous Windows 2000), figure B.1 à l'adresse
    www.microsoft.com/resources/documentation/windows/
    2000/server/reskit/en-us/cnet/cnad_arc_jypf.asp

  • How TCP/IP Works  (Fonctionnement de TCP/IP) à l'adresse
    WindowsServ/2003/all/techref/en-us/w2k3tr_tcpip_how.asp

  • How IPSec Works  (Fonctionnement d'IPSec) à l'adresse
    WindowsServ/2003/all/techref/en-us/w2k3tr_ipsec_how.asp

Télécharger la solution complète

Isolation de serveurs et de domaines à l'aide d'IPSec et de stratégies de groupe