Isolation de serveurs et de domaines à 

l'aide d'IPSec et de stratégies de 
groupe 
Présentation
Paru le 17/03/2005

Microsoft a parfaitement conscience que la sécurisation des réseaux constitue pour les grandes 
entreprises un défi de plus en plus complexe. Au fur et à mesure que les entreprises se développent 
et que les relations commerciales évoluent, le contrôle de l'accès physique à un réseau relève 
presque d'une mission impossible. Vos clients, fournisseurs et consultants peuvent avoir besoin, pour 
des raisons commerciales valables, de connecter leurs périphériques mobiles à votre réseau. 
L'apparition des technologies de réseau et de connexion sans fil a simplifié plus que jamais l'accès 
réseau. Cette connectivité améliorée signifie que les membres d'un réseau interne sont de plus en 
plus exposés aux risques non négligeables que constituent les autres ordinateurs de ce réseau 
interne, sans compter les brèches éventuelles dans le périmètre de sécurité.

Le concept d'isolation logique présenté dans ce guide englobe deux solutions : l'isolation de serveurs, 
pour qu'un serveur accepte uniquement les connexions réseau des membres du domaine approuvés 
ou d'un groupe spécifique de membres du domaine, et l'isolation de domaines, pour isoler les 
membres du domaine des connexions non approuvées. Ces solutions peuvent être utilisées 
séparément ou ensemble, dans le cadre d'une solution d'isolation logique globale.

L'isolation de serveurs et de domaines permet aux administrateurs du système informatique de 
restreindre les communications TCP/IP des membres du domaine identifiés comme ordinateurs 
approuvés. Les ordinateurs approuvés peuvent être configurés pour autoriser uniquement les 
connexions entrantes des autres ordinateurs approuvés ou d'un groupe spécifique d'ordinateurs 
approuvés. Pour contrôler les droits de connexion réseau, les contrôles d'accès sont gérés de façon 
centralisée par les stratégies de groupes de Microsoft® Active Directory®. La plupart des connexions 
TCP/IP peuvent être sécurisées sans avoir à modifier les applications. En effet, IPSec fonctionne au 
niveau de la couche réseau située sous la couche des applications, pour assurer une authentification 
et une sécurité par paquet, de bout en bout entre les ordinateurs. Le trafic réseau peut être 
authentifié, ou authentifié et chiffré, dans divers scénarios personnalisables.

Avantages métier
Les avantages qui découlent de la mise en œuvre d'une couche d'isolation logique sont, entre autres, 
les suivants :

•Sécurité renforcée. Une couche d'isolation logique offre une sécurité supplémentaire à tous les 
ordinateurs gérés du réseau.
•Contrôle plus strict de l'accès à des informations spécifiques. Lorsque cette solution est mise en 
œuvre, les ordinateurs qui se connectent au réseau n'ont pas automatiquement accès à l'ensemble 
des ressources du réseau.

•Coût moindre. L'implémentation de cette solution est bien moins onéreuse qu'une solution 
d'isolation physique.

•Nombre d'ordinateurs gérés plus important. Si seuls les ordinateurs gérés ont accès au système 
d'informations d'une entreprise, tous les périphériques doivent devenir des systèmes gérés pour 
autoriser l'accès à leurs utilisateurs.

•Niveaux de protection optimisés pour lutter contre les attaques des logiciels malveillants. La 
solution d'isolation réduit considérablement le risque qu'un ordinateur non approuvé accède à des 
ressources approuvées. Par conséquent, l'attaque d'un logiciel malveillant émanant d'un ordinateur 
non approuvé échoue car la connexion n'est pas autorisée, même si le pirate s'est procuré un nom 
d'utilisateur et un mot de passe valides.

•Système de chiffrement des données réseau. Avec l'isolation logique, il est possible de demander 
le chiffrement de l'ensemble du trafic réseau entre des ordinateurs donnés.

•Isolation d'urgence rapide. Cette solution offre, en cas d'attaque, un mécanisme permettant d'isoler 
rapidement et de façon efficace des ressources spécifiques du réseau.

•Audit amélioré. Cette solution permet de consigner et d'auditer l'accès réseau par des ressources 
gérées.

Présentation de ce guide
L'objectif de ce guide est de vous aider à mettre en place une solution d'isolation de serveurs et de 
domaines tout au long du cycle de vie informatique, de la phase initiale d'évaluation et d'approbation, 
au déploiement, au test et à la gestion de l'implémentation. Pour cette raison, les chapitres de ce 
guide ont été rédigés de façon à répondre aux besoins des différents lecteurs.

Cette section présente brièvement le contenu des différents chapitres du guide Isolation de serveurs 
et de domaines à l'aide d'IPSec et de stratégies de groupe.

Chapitre 1 : Introduction à l'isolation de serveurs et de domaines

Le premier chapitre (celui­ci) est constitué d'une synthèse et d'une brève introduction présentant le 
contenu des chapitres de ce guide. Il présente le concept d'isolation logique ainsi que différentes 
approches de l'isolation de serveurs et de domaines pour une entreprise, met en évidence l'intérêt 
commercial et illustre l'intégration de ces approches dans une infrastructure informatique type. Ce 
chapitre donne également des informations sur le scénario de la Woodgrove National Bank, adopté à 
des fins de démonstration, de conception et de test.

Chapitre 2 : Présentation de l'isolation de serveurs et de domaines

Le chapitre 2 définit le concept des hôtes approuvés et explique comment utiliser l'approbation pour 
créer des solutions d'isolation de domaines ou de serveurs. Il décrit les relations entre le concept 
d'isolation de serveurs et de domaines, IPSec et les stratégies de groupe. Ce guide comprend des 
explications techniques détaillées de l'objectif attendu de la solution, en ce qui concerne les menaces 

2
de sécurité qu'elle prévient. Il explique également les problèmes techniques éventuels liés à 
l'utilisation d'IPSec pour créer une solution d'isolation de domaines et de serveurs.

Chapitre 3 : Détermination de l'état actuel de votre infrastructure 
informatique

Avant d'entreprendre un projet, les concepteurs de la solution doivent impérativement avoir 
connaissance d'informations précises, à jour, sur l'infrastructure informatique actuelle. Ils doivent 
notamment connaître l'état actuel de tous les systèmes réseau, des configurations des serveurs et 
des stations de travail, et des approbations de domaine. Ce chapitre aborde également les 
répercutions éventuelles sur d'autres technologies de réseau, telles que NAT, les clients VPN distants 
basés sur IPSec, les proxies et les pare­feu internes, et le filtrage de ports internes. Il donne aussi des 
explications sur les informations requises dans le cadre de la planification et présente les étapes 
permettant d'obtenir ces informations.

Chapitre 4 : Conception et planification de groupes d'isolation

Ce chapitre explique comment intégrer les besoins de l'entreprise dans la conception de l'isolation de 
serveurs et de domaines. Il présente une approche détaillée vous permettant de créer un groupe 
d'isolation qui répond aux besoins de sécurité de votre entreprise en matière d'isolation. Ce chapitre 
décrit également plusieurs approches de déploiement qui peuvent vous servir à limiter les 
conséquences sur l'entreprise lors du déploiement et à optimiser les chances de réussite de 
l'implémentation. Toutes les étapes et les procédures de ce chapitre sont illustrées par des exemples 
basés sur le scénario de la Woodgrove Bank.

Chapitre 5 : Création de stratégies IPSec pour les groupes d'isolation

La stratégie IPSec est le mécanisme que vous utilisez pour appliquer les règles qui autorisent les 
ordinateurs à communiquer entre eux. Ces règles sont affectées et distribuées aux membres du 
domaine approuvé par le biais d'objets de stratégie de groupe (GPO). Ce chapitre contient les 
informations indispensables à la création des stratégies IPSec, et il explique comment déployer ces 
dernières sur les ordinateurs des destinataires.

Chapitre 6 : Gestion d'un environnement d'isolation de serveurs et de 
domaines

Une fois la solution implémentée et opérationnelle, vous devez comprendre et noter un certain nombre 
de processus qui vous aideront à assurer au quotidien une prise en charge et une gestion correcte de 
la solution. Ce chapitre inclut un modèle de prise en charge et présente plusieurs processus et 
procédures de gestion à utiliser dans le cadre d'une structure de fonctionnement plus vaste, telle que 
Microsoft Operations Framework (MOF). Pour plus d'informations sur MOF, reportez­vous au site Web 
Microsoft Operations Framework  , à l'adresse www.microsoft.com/mof.

Chapitre 7 : Dépannage d'IPSec

Des problèmes surviendront forcément durant le déploiement et l'utilisation de la solution. Ce chapitre 
présente des procédures de dépannage d'IPSec, des tâches, des outils et des conseils qui vous 
permettront de savoir si IPSec est à l'origine des problèmes rencontrés, puis de les résoudre, le cas 
échéant.

Outre les principaux chapitres, ce guide comprend des supports de référence, des aides pour les 
travaux ainsi que des scripts utilisés, au cours de l'élaboration de ce guide, dans la planification, le 

3
test et le déploiement de l'environnement du laboratoire de test chez Microsoft. Les informations 
figurant dans ces annexes peuvent vous aider à implémenter vos propres solutions d'isolation de 
serveurs et de domaines. Elles sont destinées à vous aider durant toutes les phases du projet, depuis 
l'idée initiale de la solution jusqu'au fonctionnement au quotidien d'une solution entièrement déployée.

4
Table des matières
 Isolation de serveurs et de domaines à l'aide d'IPSec et de stratégies de groupe                          
 
........................
   
 1
 Présentation                                                                                                                                            
 
...........................................................................................................................................   
 1
 Avantages métier                                                                                                                                     
 
....................................................................................................................................
   
 1
 Présentation de ce guide                                                                                                                         
 
........................................................................................................................
   
 2
 Table des matières                                                                                                                                  
 
.................................................................................................................................
   
 5
 Chapitre    1    : Introduction à l'isolation de serveurs et de domaines                                                  
 
.................................................
   
 8
 Synthèse                                                                                                                                                  
 
.................................................................................................................................................
   
 8
 Défi métier                                                                                                                                               
 
..............................................................................................................................................   
 9
 Création d'une équipe de projet                                                                                                             
 
............................................................................................................
    
 12
 Présentation du scénario                                                                                                                       
 
......................................................................................................................
    
 13
 Résumé                                                                                                                                                 
 
................................................................................................................................................    
 18
 Chapitre    2    : Présentation de l'isolation de serveurs et de domaines                                              
 
.............................................
    
 19
 Connaissances préalables requises pour ce chapitre                                                                            
 
...........................................................................
    
 19
 À qui s'adresse ce chapitre                                                                                                                    
 
...................................................................................................................    
 20
 Exigences au niveau de l'entreprise                                                                                                      
 
.....................................................................................................    
 20
 Identifications des ordinateurs approuvés                                                                                             
 
............................................................................................    
 24
Comment l'isolation de serveurs et de domaines s'intègre­t­elle dans ma stratégie de sécurité réseau 
 globale    ?                                                                                                                                                
 
...............................................................................................................................................    
 29
 Rappel terminologique                                                                                                                           
 
..........................................................................................................................    
 32
 Comment l'isolation de serveurs et de domaines peut­elle être mise en place    ?                                     
..................................
    
 36
 De quoi nous protège l'isolation de serveurs et domaines    ?                                                                  
 
.................................................................
    
 45
 Comment déployer l'isolation de serveurs et de domaines    ?                                                                 
 
................................................................
    
 46
 Résumé                                                                                                                                                 
 
................................................................................................................................................     
 47
 Chapitre    3    : Détermination de l'état actuel de votre infrastructure informatique                          
 
.........................
    
 48
 Connaissances préalables requises pour ce chapitre                                                                            
 
...........................................................................
    
 48
 À qui s'adresse ce chapitre                                                                                                                    
 
...................................................................................................................
    
 50
 Analyse de l'état actuel                                                                                                                          
 
.........................................................................................................................    
 50
 Considérations relatives à la capacité                                                                                                   
 
.................................................................................................    
 61
 Problèmes de prédéploiement                                                                                                               
 
..............................................................................................................
    
 62
 Définition de l'approbation                                                                                                                     
 
....................................................................................................................    
 65
 Identification des coûts de mise à niveau des hôtes actuels                                                                 
 
................................................................    
 69
 Résumé                                                                                                                                                 
 
................................................................................................................................................    
 71
 Chapitre    4    : Conception et planification de groupes d'isolation                                                     
 
....................................................
    
 73
 Connaissances préalables requises pour ce chapitre                                                                            
 
...........................................................................
    
 73
 Création de la conception d'isolation de serveurs et de domaines                                                        
 
.......................................................    
 74
 Méthodes d'implémentation de groupe                                                                                                  
 
.................................................................................................    
 92
 Implémentation des groupes pour Woodgrove Bank                                                                             
 
............................................................................    
 96
 Résumé                                                                                                                                                 
 
................................................................................................................................................    
 96
 Chapitre     5    : Création de stratégies IPSec pour les groupes d'isolation                                        
 
.......................................
    
 99
 Connaissances préalables requises pour ce chapitre                                                                            
 
...........................................................................
    
 99
 Création de stratégies IPSec dans Active    Directory                                                                            
 
...........................................................................    
 101
 Autorisation de l'accès en entrée à un groupe d'isolation                                                                    
 
...................................................................
    
 136
 Autres considérations relatives à IPSec                                                                                              
 
.............................................................................................    
 137
 Résumé                                                                                                                                               
 
..............................................................................................................................................    
 141
 Chapitre    6    : Gestion d'un environnement d'isolation de serveurs et de domaines                     
 
....................
    
 143
 Connaissances préalables requises pour ce chapitre                                                                          
 
.........................................................................
    
 143
 Gestion des modifications                                                                                                                    
 
...................................................................................................................
    
 144
 Considérations relatives à la sauvegarde et la récupération                                                               
 
..............................................................    
 160

5
 Réduction des risques d'infection sur le réseau                                                                                   
 
..................................................................................
    
 162
 Résumé                                                                                                                                               
 
..............................................................................................................................................    
 164
 Chapitre    7    : Dépannage d'IPSec                                                                                                       
 
......................................................................................................
    
 166
 Niveaux de support et transfert des incidents                                                                                      
 
.....................................................................................
    
 166
 Dépannage de niveau    1                                                                                                                       
 
......................................................................................................................    
 167
 Préparation du dépannage de niveau    2                                                                                               
 
..............................................................................................
    
 175
 Processus de dépannage d'IPSec                                                                                                       
 
......................................................................................................
    
 184
 Dépannage de niveau    3                                                                                                                       
 
.....................................................................................................................
    
 227
 Résumé                                                                                                                                               
 
..............................................................................................................................................     
 228

6
7
Chapitre 1 : Introduction à l'isolation de 
serveurs et de domaines
Pendant bon nombre d'années il était courant d'isoler physiquement les ordinateurs et les réseaux, 
pour éviter de compromettre les données et les communications. L'isolation physique pose cependant 
un problème : elle ne permet pas de protéger facilement derrière des limites physiques l'infrastructure 
informatique d'un grand nombre d'entreprises. La forte croissance des clients mobiles et la nature des 
environnements réseau distribués rendent ces limites physiques trop rigides à implémenter et à 
utiliser.

Avec l'isolation de serveurs et de domaines, il est possible de créer une couche de sécurité pour isoler 
logiquement le trafic réseau entre des ordinateurs ou des réseaux. Si une personne malveillante 
parvient à accéder physiquement au réseau interne d'une entreprise et si elle tente d'accéder à un 
serveur contenant des ressources stratégiques, l'isolation de serveurs et de domaines est en mesure 
de bloquer cet accès, tout simplement parce que l'ordinateur utilisé dans le cadre de cette attaque ne 
fait pas partie des systèmes approuvés de l'entreprise, même si la personne malveillante a utilisé un 
compte d'utilisateur et un mot de passe valides.

L'isolation logique via des techniques d'isolation de serveurs et de domaines permet d'élaborer une 
solution d'isolation souple, évolutive et gérable, qui garantit la sécurité de l'isolation tout en évitant le 
coût et la rigidité des limites physiques.

Synthèse
Microsoft a parfaitement conscience que la sécurisation des réseaux constitue pour les grandes 
entreprises un défi de plus en plus complexe. Au fur et à mesure que les entreprises se développent 
et que les relations commerciales évoluent, le contrôle de l'accès physique au réseau relève presque 
d'une mission impossible. Tous les jours, pour des raisons commerciales valables, vos clients, 
fournisseurs et consultants connectent leurs équipements mobiles à votre réseau. L'apparition des 
technologies de réseau et de connexion sans fil, telles que GPRS et Bluetooth, a simplifié plus que 
jamais l'accès réseau. Cette connectivité améliorée signifie que les membres d'un réseau interne sont 
de plus en plus exposés aux risques non négligeables que constituent les autres ordinateurs de ce 
réseau interne, sans compter les brèches éventuelles dans le périmètre de sécurité. Les pare­feu 
personnels ou basés sur l'hôte participent à la protection des clients lors d'une connexion à Internet, 
mais ils ne permettent pas encore de protéger les clients et les serveurs internes.

L'isolation de serveurs et de domaines est intéressante pour l'entreprise. Elle offre avant tout une 
couche de sécurité réseau qui réduit considérablement le risque qu'un hôte non approuvé accède aux 
membres du domaine approuvés du réseau interne d'une entreprise. L'isolation de serveurs et de 
domaines peut jouer un rôle stratégique important dans le cadre de la lutte contre la propagation des 
virus, de la protection contre les pirates internes, contre les utilisations erronées de la part des 
employés et contre le vol d'informations. En outre, elle peut être utilisée pour demander 
l'appartenance au domaine de tous les clients cherchant à accéder à des ressources approuvées, qu'il 
s'agisse de clients ou de serveurs, de sorte qu'elles puissent être mieux gérées par le personnel 
informatique. L'isolation de serveurs et de domaines peut également servir de stratégie principale ou 
complémentaire pour répondre aux besoins en matière de protection ou de confidentialité des 
données sur le réseau, sans avoir à modifier les applications Microsoft® Windows® existantes ou à 
déployer un tunnel VPN sur le réseau.

8
L'isolation de serveurs et de domaines permet aux administrateurs du système informatique de 
restreindre les communications TCP/IP des membres du domaine identifiés comme ordinateurs 
approuvés. Les ordinateurs approuvés peuvent être configurés pour autoriser uniquement les 
connexions entrantes à partir des autres ordinateurs approuvés ou d'un groupe spécifique 
d'ordinateurs approuvés. Pour contrôler les droits de connexion réseau, les contrôles d'accès sont 
gérés de façon centralisée par les stratégies de groupe Active Directory®. La plupart des connexions 
TCP/IP peuvent être sécurisées sans avoir à modifier les applications. En effet, IPSec (Internet 
Protocol security) fonctionne au niveau de la couche réseau située sous la couche des applications, 
pour assurer une authentification et une sécurité de pointe par paquet, de bout en bout entre les 
ordinateurs. Le trafic réseau peut être authentifié, ou authentifié et chiffré, dans divers scénarios 
personnalisables. Les configurations d'IPSec et des stratégies de groupe sont gérées de façon 
centralisée dans Active Directory.

Le concept d'isolation logique présenté dans ce guide englobe deux solutions : l'isolation de domaines 
pour isoler les membres du domaine des connexions non approuvées, et l'isolation de serveurs pour 
qu'un serveur accepte uniquement les connexions réseau des membres du domaine approuvés ou 
d'un groupe de membres du domaine spécifique. Ces solutions peuvent être utilisées séparément ou 
ensemble, dans le cadre d'une solution d'isolation logique globale.

La solution testée présentée dans ce guide requiert la configuration minimale suivante pour les 
différentes plates­formes :

• Windows 2000 avec le Service Pack 4 ou ultérieur
• Microsoft Windows Server™ 2003
• Windows XP avec Service Pack 2 ou ultérieur

Ces configurations garantissent le niveau de révision requis pour les composants d'IPSec. Les 
communications avec les plates­formes non­Windows ou avec des systèmes non approuvés sont 
contrôlées via la configuration d'IPSec, répertoriant les exemptions et/ou étant autorisée à revenir à 
des communications en texte clair (non­IPSec). Avec les nouvelles fonctions transversales de 
traduction d'adresses réseau (NAT), les traducteurs d'adresses réseau n'empêchent plus l'utilisation 
d'IPSec sur le réseau local.

Ce guide utilise le scénario de la Woodgrove National Bank pour illustrer l'implémentation de l'isolation 
de serveurs et de domaines dans un environnement de laboratoire représentatif. Il présente 
également l'expérience acquise par Microsoft lors de l'implémentation de ces deux solutions en 
interne, ainsi que dans des environnements clients. Ce guide a été conçu par une équipe d'experts de 
Microsoft. Il a ensuite été contrôlé par le personnel informatique de Microsoft et par des clients via un 
programme bêta.

Comme les scénarios d'isolation de serveurs et de domaines ont tous deux été implémentés dans le 
réseau interne mondial de Microsoft, l'entreprise dépend véritablement de la sécurité de ces solutions. 
Par ailleurs, en recommandant ces solutions à ses clients, Microsoft soutient les entreprises qui 
ciblent à long terme une infrastructure véritablement sécurisée et gérable, pour un environnement 
informatique plus sûr.

Défi métier
Aujourd'hui, la nature même des entreprises connectées et des équipements réseau mobiles est 
susceptible de mettre en péril l'infrastructure informatique de votre entreprise. Ces risques peuvent 
avoir diverses origines. Ils peuvent notamment provenir de l'ordinateur d'un client, d'un vendeur ou 
d'un employé mobile, outre les ordinateurs distants des petites succursales et les ordinateurs 
domestiques des employés. Dans bon nombre de cas, ces risques consistent principalement en 

9
l'attaque d'un logiciel malveillant (également appelé malware), tel qu'un virus ou un vers, téléchargé 
ou installé par inadvertance sur l'ordinateur d'un utilisateur crédule.

L'isolation logique ne peut pas être considérée comme une protection antivirus. Elle peut toutefois 
s'intégrer dans une solution antivirus plus vaste, car elle met en place une couche de sécurité 
complémentaire qui réduit les risques d'attaque et leurs effets. Par exemple, un client de passage 
dans votre entreprise qui connecte son ordinateur portable à votre réseau pour vous présenter une 
feuille de calcul introduit un risque dans l'infrastructure informatique de votre entreprise. En se 
connectant directement à votre réseau physique, ce client a contourné le périmètre de sécurité mis en 
place pour lutter contre les attaques réseau.

Si le réseau auquel se connecte ce client n'autorise pas l'accès direct aux serveurs de votre 
entreprise, le risque est limité. La question qui se pose est la suivante : comment autoriser l'accès à 
ces ressources de l'entreprise uniquement aux ordinateurs qui en ont besoin ? Avec l'isolation de 
serveurs et de domaines ! Cette technique permet d'identifier et d'authentifier un ordinateur afin de 
déterminer les ressources auxquelles il est autorisé à accéder. L'authentification a lieu avant que 
l'utilisateur se connecte, et elle reste active une fois l'ordinateur connecté. Avec cette approche, il est 
possible de réduire le risque que constituent pour vos données stratégiques les ordinateurs non 
identifiés et non gérés qui se connectent à votre réseau.

Remarque : pour plus d'informations sur les logiciels malveillants et pour connaître les moyens 
spécifiques à mettre en place afin de vous protéger, consultez la page The Antivirus Defense­in­Depth  
Guide   (Guide de défense antivirus renforcée), sur le site Web de TechNet, à l'adresse 
http://go.microsoft.com/fwlink/?LinkId=28732.

Avantages métier

Les avantages qui découlent de la mise en œuvre d'une couche d'isolation logique sont, entre autres, 
les suivants :

• Sécurité renforcée. Une couche d'isolation logique offre une sécurité supplémentaire à tous les 
ordinateurs gérés du réseau.

• Contrôle plus strict de l'accès à des informations spécifiques. Lorsque cette solution est mise 
en œuvre, les ordinateurs qui se connectent au réseau n'ont pas automatiquement accès à 
l'ensemble des ressources du réseau.

• Coût moindre. L'implémentation de cette solution est bien moins onéreuse qu'une solution 
d'isolation physique.

• Nombre d'ordinateurs gérés plus important. Si seuls les ordinateurs gérés ont accès au 
système d'informations d'une entreprise, tous les systèmes doivent devenir des systèmes gérés 
pour autoriser l'accès à leurs utilisateurs.

• Niveaux de protection optimisés pour lutter contre les attaques des logiciels malveillants. 
La solution d'isolation réduit considérablement le risque qu'un ordinateur non approuvé accède à 
des ressources approuvées. Par conséquent, l'attaque d'un logiciel malveillant émanant d'un 
ordinateur non approuvé échoue car la connexion n'est pas autorisée, même si le pirate s'est 
procuré un nom d'utilisateur et un mot de passe valides.

• Système de chiffrement des données réseau. Avec l'isolation logique, il est possible de 
demander le chiffrement de l'ensemble du trafic réseau entre des ordinateurs donnés.

• Isolation d'urgence rapide. Cette solution offre, en cas d'attaque, un mécanisme permettant 
d'isoler rapidement et de façon efficace des ressources spécifiques du réseau.

10
• Protection des connexions réseau en accès libre. Certains points de connexion réseau, tels 
que les points de connexion dans un « hall », n'offrent pas un accès direct à l'ensemble des 
ressources de votre réseau.

• Audit amélioré. Cette solution permet de consigner et d'auditer l'accès réseau par des ressources 
gérées.

Défi technologique

Il n'est facile de protéger une infrastructure informatique moderne contre les attaques tout en 
permettant aux employés de travailler de la façon la plus souple possible et d'être aussi productifs que 
possible. Le fait de comprendre l'ensemble des technologies qui contribuent à sécuriser un 
environnement est déjà suffisamment complexe pour bon nombre de personnes. Il convient de 
repérer précisément où se situe la solution d'isolation dans une infrastructure informatique type et de 
comprendre de quelle manière elle complète les solutions de protection réseau existantes.

La figure suivante présente une infrastructure réseau type constituée d'un certain nombre de couches 
de protection réseau. Elle indique à quel endroit intervient l'isolation logique dans un environnement 
type :

Figure 1.1 Zones de l'infrastructure et couches de protection réseau

La figure 1.1 illustre simplement les diverses technologies que vous pouvez mettre en œuvre pour 
sécuriser en profondeur une infrastructure réseau type. Ce type d'infrastructure comprend 
généralement les éléments suivants :

• Travailleurs et réseaux distants. Ces entités distantes utilisent généralement des réseaux privés 
virtuels (VPN) pour se connecter au réseau interne de l'entreprise et accéder à son infrastructure 
informatique.

• Internet. Le réseau interne de l'entreprise est souvent connecté à Internet via un ou plusieurs 
pare­feu de périmètre. Ces périphériques résident en général dans un réseau de périmètre qui 
fournit un niveau de protection élevé contre les menaces externes liées aux connexions Internet.

11
• Réseau de périmètre. Ce réseau est sciemment placé à l'écart pour les serveurs et les systèmes 
qui ont besoin d'un accès direct à Internet ou auxquels il doit être possible d'accéder à partir 
d'Internet. Ils sont, par conséquent, plus exposés aux attaques.

• Réseau interne. En général, ce réseau regroupe les réseaux de l'entreprise situés physiquement 
sur les sites qui lui appartiennent et gérés comme partie intégrante de l'infrastructure informatique.

• Réseau de quarantaine. Ce réseau est un nouveau composant qui offre une connexion limitée 
aux ordinateurs qui ne répondent pas aux conditions minimales requises par l'entreprise en matière 
de normes de sécurité. Une fois que les tests exigés ont été menés à bien, l'ordinateur et 
l'utilisateur sont autorisés à accéder à l'ensemble du réseau interne. En cas d'échec des tests, le 
réseau de quarantaine leur accorde une connexion suffisante pour télécharger et installer les 
éléments requis qui leur permettront de mener à bien les tests. Grâce à la protection de l'accès au 
réseau (NAP, Network Access Protection), Microsoft offre de nouvelles possibilités aux ordinateurs 
distants mis en quarantaine. Pour plus d'informations, reportez­vous à la page Network Access 
Protection   du site de Microsoft, à l'adresse www.microsoft.com/nap.

• Réseaux partenaires. Compte tenu que ces réseaux n'appartiennent pas à l'entreprise ou que 
celle­ci ne les gère pas, un contrôle d'accès strict est généralement appliqué pour autoriser 
l'exécution de processus ou d'applications spécifiques de l'entreprise via un tunnel VPN ou un 
routeur de périmètre diffusant des communications extranet.

La figure 1.1 illustre le fait que l'isolation logique est axée directement sur les communications des 
hôtes du réseau interne. Les VPN sont gérés par les services d'accès à distance (RAS) pour autoriser 
la connexion sécurisée du trafic des travailleurs et réseaux distants. Les pare­feu réseau latéraux 
protègent les communications entre Internet et les réseaux internes. Les services RAS et la protection 
NAP permettent de gérer les connexions des travailleurs distants par le biais d'un réseau de 
quarantaine.

À l'heure actuelle, ces couches de protection réseau sont en général installées et gérées en tant que 
composants distincts d'un réseau de protection renforcée. Toutefois, dans les années à venir, ces 
composants seront probablement intégrés dans une solution de protection réseau commune 
susceptible d'être implémentée comme solution unique, de bout en bout.

Aujourd'hui, ce qui manque souvent dans bon nombre de réseaux, c'est la possibilité de protéger les 
ordinateurs du réseau interne les uns des autres. Parfois, les réseaux internes étendus prennent en 
charge plusieurs organisations, et dans certains cas, plusieurs services informatiques doivent gérer 
les ordinateurs et les points d'accès physiques. Par conséquent, il ne faut pas considérer le réseau 
interne simplement comme un réseau dans lequel tous les ordinateurs physiquement connectés sont 
approuvés et bénéficient d'une connexion réseau complète entre eux.

L'isolation logique vise à segmenter et à isoler le réseau interne afin de fournir un niveau de sécurité 
supérieur sans avoir recours aux limites physiques. Le véritable défi technologique de l'isolation 
logique consiste à mettre en œuvre la solution de sorte qu'elle soit à la fois gérable et évolutive. Si 
votre conception est trop complexe et restrictive, elle risque d'empêcher les utilisateurs d'effectuer 
leurs tâches, ce qui peut être pire que l'absence d'une solution d'isolation. Vous devez réaliser une 
planification et des tests avant et pendant le déploiement de la solution. Grâce à ce guide, vous avez 
la possibilité de mettre en place une solution évolutive et gérable, susceptible d'être déployée de 
façon contrôlée, et qui permet d'effectuer des tests à différents stades de la phase de déploiement.

Lorsque l'isolation logique est en place, la couche de sécurité complémentaire contribue à réduire les 
risques qu'encourent vos ressources d'informations sur le réseau, et ce, sans restreindre les 
possibilités d'action des clients autorisés.

Création d'une équipe de projet

12
Cette solution peut avoir une incidence sur l'ensemble des communications du réseau interne de 
l'entreprise, ce qui risque par conséquent d'affecter tous les services et toutes les personnes qui 
utilisent ces communications. Par conséquent, il est primordial que les attentes et les besoins de 
l'organisation soient communiqués, répertoriés, compris et pris en compte à chaque étape de ce 
projet.

Dans la mesure où une seule personne ne peut pas réaliser toutes les tâches requises dans un projet 
d'une telle ampleur dans une entreprise type, il est vivement recommandé de mettre en place une 
équipe de projet. Cette équipe de projet doit être constituée de représentants de tous les services de 
l'entreprise, et elle doit intégrer les principaux secteurs de technologie de l'infrastructure informatique 
actuelle. Étant donné que ce guide n'a pas pour but d'expliquer le fonctionnement d'une équipe de 
projet, nous partons du principe qu'une équipe de projet convenable est mise en place et que les 
parties prenantes et les utilisateurs sont informés des exigences et des objectifs de la solution tout au 
long du projet. Pour plus d'informations sur l'organisation d'un projet comme celui­ci, reportez­vous au 
site Web Microsoft Solutions Framework (MSF)  , à l'adresse www.microsoft.com/msf.

Présentation du scénario
Les solutions d'isolation de serveurs et de domaines ont toutes deux été déployées en interne sur le 
réseau interne de Microsoft. Toutefois, nous avons également testé une implémentation de laboratoire 
physique représentative, basée sur le scénario client de la Woodgrove Bank, pour proposer un 
modèle public et concret pour cette solution. Pour élaborer ce guide, les besoins de l'entreprise et les 
exigences techniques de cette organisation fictive ont été ajoutés à ceux de Microsoft. Ce guide 
contient des techniques de gestion et de prise en charge utilisées régulièrement par les 
administrateurs du système informatique interne de Microsoft. Des notes particulières ont été ajoutées 
lorsque les exigences et le personnel de la Woodgrove Bank différaient de ceux de la conception 
propre à Microsoft.

Qu'est­ce que la Woodgrove Bank ?

La Woodgrove National Bank est une organisation fictive de démonstration utilisée par Microsoft 
comme exemple de client tangible pour vous aider à déployer la solution. Microsoft a tiré parti de sa 
longue expérience avec ses clients professionnels pour dresser la liste des exigences de la 
Woodgrove Bank. Comme la Woodgrove Bank est une banque, elle s'appuie sur une solution de 
sécurité pour assurer la sécurité de ses ressources monétaires et des données privées de ses clients. 
La Woodgrove Bank doit également respecter les obligations réglementaires émises par le 
gouvernement et les groupes industriels. Dans cet exemple, les obligations réglementaires et 
législatives ne sont pas abordées pour éviter que la solution présentée ne soit spécifique à un pays ou 
une région.

La Woodgrove Bank est une importante banque d'investissement mondiale au service d'instituts, 
d'entreprises, du gouvernement et de particuliers dans son rôle d'intermédiaire financier. Ses activités 
incluent les hypothèques, les ventes et le commerce, les services de conseil financier, la recherche de 
placements, le capital de risque et les services de courtage pour les institutions financières.

La Woodgrove Bank est une filiale appartenant intégralement à la société WG, entreprise de services 
financiers mondiale majeure, dont le siège social est basé à Londres (Angleterre). La société WG 
possède les cinq entreprises suivantes : Woodgrove National Bank, Northwind Trading, Contoso, Ltd., 
Litware Financials et Humongous Insurance. Toutes les entreprises de la société WG sont de vastes 
organisations, comptant chacune plus de 5 000 personnes.

13
Situation géographique

La Woodgrove Bank emploie plus de 15 000 personnes, dans plus de 60 bureaux répartis dans le 
monde entier. Elle possède des sièges sociaux (sites satellites) qui comptent un grand nombre 
d'employés, à New York (5 000 personnes), à Londres (5 200 personnes) et à Tokyo (500 personnes). 
Chaque site satellite prend en charge des sites secondaires de petite taille (par exemple, le siège de 
New York prend en charge les sites de Boston et d'Atlanta). Outre ses sites satellites, la 
Woodgrove Bank possède également deux autres sites principaux, respectivement basés à Sydney et 
à Johannesburg, chacun possédant ses propres serveurs de fichiers dédiés, d'impression et 
d'applications.

Connectivité entre les sites

Tokyo et Londres sont connectées aux sièges de l'entreprise à New York via des connexions Internet 
privées. Les bandes passantes allouées sont respectivement de 6 mégabits par seconde (Mbits/s) et 
de 10 Mbits/s. Tous les sites satellites sont connectés aux sièges et bénéficient d'une connexion de 2 
à 10 mégaoctets (Mo). Les filiales autonomes bénéficient d'une connexion de 2 Mo. Les micro­fililales 
ont généralement une connexion de réseau étendu (WAN) de 1 Mo. La figure 3.1 du chapitre 3, 
« Détermination de l'état actuel de votre infrastructure informatique », de ce guide détaille ces 
connexions.

Défis informatiques de l'entreprise

La Woodgrove Bank est confrontée aux mêmes défis que la plupart des entreprises. Elle souhaite en 
effet augmenter son chiffre d'affaires et réduire les coûts tout en diminuant le coût des 
immobilisations. Ces défis ont toujours des répercutions sur les services informatiques. La Woodgrove 
Bank est confrontée à un certain nombre d'initiatives d'entreprise qui affectent également les services 
informatiques. Parmi ces initiatives figurent les suivantes :

• Conquérir de nouveaux marchés via des fusions et des acquisitions
• Gagner la satisfaction des clients
• Améliorer la productivité des employés
• Améliorer les processus et le fonctionnement
• Fournir un environnement sécurisé

Ces initiatives affectent les services informatiques, mais les responsables informatiques sont 
également confrontés à d'autres défis spécifiques, tels que les suivants :

• Réduire le coût global des services informatiques.
• Réduire les frais d'exploitation ; améliorer la gestion et réduire ses coûts ; réduire le nombre de 
serveurs dans l'environnement ; regrouper des applications et services hétérogènes sur des 
serveurs uniques.
• Tirer parti des investissements informatiques existants.
• Créer une infrastructure informatique souple.

• Améliorer le retour sur investissement.
• Accroître l'utilisation.
• Améliorer la disponibilité et la fiabilité.
• Exploiter de nouvelles plates­formes matérielles.

• S'assurer que les employés, partenaires et clients utilisent l'environnement le plus sûr.

14
• Autoriser les accords sur le niveau de service (en interne et en externe).
• Améliorer la souplesse de l'entreprise en fournissant un véritable accès en temps réel aux 
informations, quel que soit l'endroit.

Profil informatique de l'organisation

La Woodgrove Bank est dotée d'un environnement serveur mixte sous Windows et UNIX, mais son 
infrastructure est exécutée sur une dorsale Windows Server. Elle compte au total 1 712 serveurs 
Windows. La plupart d'entre eux exécutent Windows 2000 ou une version ultérieure :

785
• Serveurs de fichiers et d'impression
123
• Serveurs Web
476
• Serveurs d'infrastructure
98
• Serveurs Microsoft Exchange
73
• Serveurs Microsoft SQL Server™
73
• Serveurs de développement
33
• Serveurs d'analyse
51
• Autres (Lotus Notes, Oracle)

La plupart des serveurs sont répartis dans les trois sièges sociaux de l'entreprise (New York, Londres 
et Tokyo).

Environnement PC

La plupart des employés de la Woodgrove Bank possèdent au moins un ordinateur personnel. Les 
employés sont généralement équipés d'ordinateurs de bureau. Quant aux commerciaux, ils sont 
équipés d'ordinateurs portables. Au total, la Woodgrove Bank possède plus de 17 000 ordinateurs 
personnels. Environ 85 % de ces ordinateurs sont des ordinateurs de bureau et 15 % sont des 
ordinateurs portables. Plus de 95 % des ordinateurs personnels sont dotés de la technologie Intel et 
exécutent une version de Windows. Pour les applications LOB (Line of Business), des services 
spécifiques utilisent des postes de travail Macintosh et quelques postes de travail UNIX.

Présentation de l'architecture du système et de l'architecture de 
gestion

Le réseau de la Woodgrove Bank est constitué de plusieurs zones informatiques : un centre de 
données d'entreprise, deux sites satellites, deux succursales et un réseau de périmètre permettant 
d'assurer la prise en charge des utilisateurs distants. Pour centraliser la gestion des serveurs et des 
ordinateurs de bureau à New York, la Woodgrove Bank applique un modèle de gestion centralisée 
(voir figure ci­dessous).

15
Figure 1.2 Modèle de gestion informatique centralisée de la Woodgrove Bank

Service d'annuaire

Pour sa structure Active Directory, la Woodgrove Bank a opté pour un modèle de forêt du fournisseur 
de service. Ce modèle offre en effet la possibilité de mettre en place une forêt pour le périmètre et une 
forêt partagée distincte pour les ressources internes. Cette souplesse permet de répondre aux 
exigences d'isolation des serveurs dans le réseau de périmètre. La Woodgrove Bank n'a pas choisi le 
modèle de forêt unique car celui­ci ne permet pas d'isoler les serveurs du périmètre des données 
stratégiques de l'entreprise. La figure suivante représente la structure logique Active Directory utilisée 
par la Woodgrove Bank :

Figure 1.3 Configuration du service Active Directory de la Woodgrove Bank

La forêt du périmètre utilise le modèle de domaine de forêt unique. Il suffit en effet à assurer la gestion 
des serveurs du périmètre. Dans le périmètre, les exigences de réplication sont faibles ; il n'est donc 
pas nécessaire de mettre en place des limites de réplication ou d'avoir recours au modèle de 
domaines régionaux multiples pour segmenter la forêt. Notez bien que la Woodgrove Bank a choisi 
cette configuration uniquement pour la gestion des serveurs du périmètre. Si les comptes d'utilisateurs 
avaient été placés dans le périmètre et que ce dernier s'était trouvé dans plusieurs sites, une autre 
configuration de domaine aurait été requise.

16
La forêt interne est basée sur un modèle de domaines régionaux multiples. La Woodgrove Bank a 
créé trois domaines régionaux : Amérique, Europe et Asie. Par ailleurs, la Woodgrove Bank a 
implémenté une racine de forêt dédiée pour gérer les fonctionnalités au niveau de la forêt. Ce modèle 
permet de gérer la topologie de la réplication et de déléguer à chaque région l'administration de 
l'autonomie au niveau du domaine.

La topologie de site de la Woodgrove Bank est partagée en trois zones régionales : Amérique, Europe 
et Asie (Asie­Pacifique). New York, Londres et Tokyo sont les routeurs principaux de l'ensemble de la 
topologie.

Les concepteurs de la configuration de la Woodgrove Bank ont opté pour une unité d'organisation 
(UO) principalement orientée objet. La structure d'UO est répliquée dans son intégralité dans chaque 
domaine régional, et un sous­ensemble de la structure d'UO est créé dans la racine de la forêt. La 
figure 3.2 du chapitre 3 de ce guide représente en détail la structure d'UO utilisée par la 
Woodgrove Bank.

Stratégie de déploiement de l'isolation de serveurs et de domaines de la Woodgrove Bank

Pour définir au mieux la configuration qui répond à ses attentes, la Woodgrove Bank a créé un projet 
de laboratoire. Ce projet consiste en l'implémentation d'un petit laboratoire qui permettra de tester la 
configuration prévue par la Woodgrove Bank (voir figure suivante).

Figure 1.4 Configuration expérimentale de la Woodgrove Bank

Ce schéma représente le sous­ensemble des ordinateurs utilisés dans le scénario de la 
Woodgrove Bank pour tester les scénarios présentés dans ce guide. L'objectif de ce projet de 
démonstration était de fournir une diversité de configuration suffisamment importante dans le 

17
laboratoire pour s'assurer que la solution fonctionne comme prévu, tout en évitant les répercutions sur 
les serveurs de production et les utilisateurs.

Les exemples proposés dans ce guide sont basés sur les résultats de l'infrastructure expérimentale 
représentée dans la figure 1.4.

Remarque : comme l'isolation modifie plusieurs aspects du réseau, Microsoft recommande vivement 
de tester, dans un premier temps, chaque scénario d'isolation dans un environnement de laboratoire 
afin d'éviter les répercutions sur les environnements de production. Les administrateurs du système 
informatique doivent se reporter aux chapitres 6 et 7 pour obtenir des informations sur la prise en 
charge, les procédures opérationnelles et le dépannage.

Lorsqu'un projet d'implémentation en laboratoire s'était déroulé avec succès, un groupe de serveurs 
était identifié pour implémenter un scénario élémentaire d'isolation de serveurs. Ces serveurs 
correspondent à ceux qui ont le moins de répercutions sur l'entreprise, en cas problème de connexion. 
Les administrateurs du système informatique et les techniciens du support technique ont suivi un 
entraînement aux techniques de dépannage. Ces serveurs ont été étroitement surveillés pour mesurer 
l'impact de l'implémentation sur les performances et sur les appels au support technique. Les rôles de 
gestion organisationnelle, les processus et les méthodes de support ont été testés. Ensuite, l'un des 
plus petits domaines de la Woodgrove Bank a été choisi pour tester l'isolation de domaines. Il a été 
possible de réduire l'impact de ce projet d'isolation de domaines en utilisant IPSec uniquement pour 
les sous­ensembles du réseau dans lesquels se trouvait la majorité des membres du domaine. Par 
ailleurs, il a également été possible de réduire l'impact sur l'entreprise en autorisant les 
communications non­IPSec lorsque les membres de ce domaine communiquaient avec des 
ordinateurs n'appartenant pas au projet expérimental. Une fois ces tests terminés, l'équipe de projet 
possédait toutes les informations nécessaires à la création et à l'implémentation d'une configuration 
complète pour l'ensemble de l'organisation.

Résumé
Ce chapitre constitue une introduction à l'isolation logique. Il explique comment l'isolation de serveurs 
et de domaines peut être utilisée pour créer une solution de niveau entreprise avec IPSec et des 
stratégies de groupe. En outre, il comprend une synthèse et une brève description de chaque chapitre 
de ce guide. Grâce à l'ensemble des informations de ce chapitre, vous pouvez comprendre les 
avantages que représente cette solution pour votre entreprise, comprendre comment elle s'intègre 
dans une infrastructure informatique type et cerner les compétences nécessaires à la réussite de sa 
mise en œuvre.

18
Chapitre 2 : Présentation de l'isolation 
de serveurs et de domaines
À l'époque où les réseaux locaux (LAN) devenaient la norme, les professionnels de l'informatique 
rivalisaient d'efforts pour proposer des services réactifs, hautement disponibles, tout en maintenant un 
niveau de sécurité adéquat. Un grand nombre de technologies ont été mises au point pour fonctionner 
avec TCP/IP, afin de répondre au problème de l'implémentation de la sécurité au niveau des couches 
réseau et de transport. Parmi ces technologies figurent notamment IPv6, 802.1X, les commutateurs 
réseau, la segmentation du réseau local virtuel (VLAN) et IPSec (Internet Protocol security).

Le résultat indirect de l'introduction de ces technologies n'est autre qu'une sécurité réseau basée sur 
plusieurs couches. Ces couches peuvent permettre de séparer, de segmenter ou d'isoler un ou 
plusieurs hôtes ou réseaux d'autres hôtes ou réseaux. L'objectif de ce chapitre consiste à organiser la 
couche de sécurité IPSec en fonction des autres couches et à expliquer son fonctionnement avec les 
stratégies de groupe dans une solution d'isolation gérable et évolutive dans un environnement à 
l'échelle de l'entreprise.

Connaissances préalables requises pour ce chapitre
Avant d'exploiter les informations fournies dans ce chapitre, vous devez parfaitement maîtriser les 
technologies et les concepts suivants. Vous pouvez tirer parti de ce guide sans ces connaissances 
préalables, mais si vous les maîtrisez, la réussite de l'implémentation sera pratiquement garantie.

Connaissances requises

Vous devez posséder des connaissances sur les éléments suivants de 
Microsoft® Windows Server™ 2003 :

• concepts du service d'annuaire Active Directory® (notamment la structure et les outils 
Active Directory, manipulation d'utilisateurs, de groupes et d'autres objets Active Directory, et 
utilisation des stratégies de groupe) ;

• concepts d'authentification, notamment l'utilisation du protocole Kerberos version 5 et de 
l'infrastructure de clés publiques (PKI) ;

• sécurité du système Microsoft Windows® ; concepts de sécurité tels que les utilisateurs, les 
groupes, l'audit et les listes de contrôle d'accès (ACL) ; utilisation des modèles de sécurité ; 
concepts d'authentification mutuelle ; méthodes et concepts standards de résolution de noms tels 
que le système de noms de domaine (DNS, Domain Name System) et le service WINS (Windows 
Internet Naming Service) ; outils de diagnostic et concepts de dépannage standards Windows ; 
utilisation des stratégies de groupe ou des outils de ligne de commande pour appliquer des 
modèles de sécurité ;

• protocole TCP/IP, notamment l'organisation des sous­réseaux, les masques réseau et le routage ; 
fonctionnalités de bas niveau, protocoles et termes tels que ICMP (Internet Control Message 
Protocol), ARP (Address Resolution Protocol) et unité maximale de transfert (MTU, Maximum 
Transmission Unit).

• principes de gestion des risques de sécurité.

19
Remarque : le chapitre 6, « Deploying IPSec » (Déploiement d'IPSec) du Kit de déploiement de  
Windows Server 2003 présente des scénarios relatifs au mode de transport IPSec qui n'étaient 
auparavant pas recommandés. Toutefois, le travail réalisé par Microsoft dans le cadre de son propre 
déploiement interne d'IPSec et la disponibilité de conseils supplémentaires ont aujourd'hui permis de 
modifier ces recommandations. 
Le trafic de diffusion et de multidiffusion ne peut pas encore utiliser IPSec, mais tous les types de 
trafic IP monodiffusion peuvent être sécurisés via IPSec. Chaque client doit mesurer les avantages du 
déploiement d'IPSec dans des scénarios d'isolation de domaines ou de serveurs par rapport aux 
coûts, aux impacts et à d'autres compromis. Microsoft recommande et encourage désormais la 
généralisation de l'utilisation d'IPSec sur les réseaux de ses clients conformément à ce guide.

Conditions requises pour l'organisation

La planification de la sécurité d'une organisation ne peut pas être affectée à une seule personne. Les 
informations qui permettent de déterminer les exigences exactes d'une organisation proviennent 
souvent de plusieurs sources de l'organisation. Contactez d'autres personnes de votre entreprise 
susceptibles d'être concernées par la planification de l'isolation, notamment les personnes suivantes :

• les dirigeants ;
• Représentants de groupes d'utilisateurs
• les personnes chargées de l'audit et de la sécurité ;
• Groupe de gestion des risques
• les ingénieurs, les administrateurs et les équipes opérationnelles Active Directory ;
• Personnel technique, d'administration et des opérations DNS, du serveur Web et du réseau

Remarque : selon la structure de votre organisation informatique, plusieurs personnes peuvent 
occuper un même poste, ou une personne peut occuper plusieurs postes.

L'étendue d'un projet d'isolation de serveurs et de domaines nécessite l'intervention d'une équipe 
complète de personnes afin de bien cerner les exigences de l'entreprise, les problèmes techniques, 
l'impact sur les utilisateurs et le processus du projet dans son ensemble. Il peut être intéressant 
qu'une personne faisant preuve d'autorité joue le rôle de contact principal pour ce projet lorsque des 
observations à plus grande échelle sont requises, telles que celles du personnel de support ou des 
utilisateurs qui seront affectés au cours du déploiement. Une planification et une communication 
insuffisantes sont les deux principales causes d'échec des projets complexes. L'équipe de projet doit 
comprendre ces risques éventuels et s'assurer que des mesures ont été prises pour les limiter.

À qui s'adresse ce chapitre
Ce chapitre s'adresse aux architectes et décisionnaires techniques chargés de concevoir une solution 
personnalisée d'isolation de serveurs et de domaines pour une organisation. Pour exploiter au mieux 
ce chapitre, il est souhaitable de posséder de solides connaissances techniques sur les technologies 
abordées et sur l'infrastructure actuelle de l'entreprise.

Exigences au niveau de l'entreprise
Vous devez bien comprendre que ce sont les exigences de l'entreprise qui influent sur la solution. 
L'isolation peut être définie comme une séparation logique ou physique entre un ou plusieurs 
ordinateurs et d'autres ordinateurs, les empêchant ainsi de communiquer entre eux sur un réseau. Les 

20
restrictions de sécurité affecteront nécessairement le travail quotidien des employés au sein d'une 
organisation. Les modifications apportées dans le cadre de la solution modifieront la façon dont les 
ordinateurs communiquent les uns avec les autres et avec les ordinateurs non approuvés. Pour la 
conception de cette solution, l'équipe de projet a besoin de temps pour planifier et analyser la 
faisabilité de l'implémentation, le personnel de support informatique doit suivre une formation, et au 
moins un programme d'information des employés doit être mis en place. Les services de sécurité 
supplémentaires destinés au trafic réseau peuvent nécessiter de la mémoire serveur supplémentaire, 
voire des cartes réseau d'accélération matérielle. Il est également possible d'avoir recours à d'autres 
solutions pour atteindre ou les mêmes objectifs d'isolation ou des objectifs similaires. Par conséquent, 
il est important de déterminer l'impact financier de la solution sur l'entreprise. 

Garantie du respect des réglementations

Plus les informations personnelles sont stockées dans les ordinateurs, plus l'intérêt pour la 
confidentialité des données est grand. Le contrôle de l'accès aux informations des clients et des 
employés n'est plus seulement une bonne pratique commerciale. Selon les lois en vigueur dans 
chaque pays, une entreprise qui ne respecte pas ses obligations en termes de protection des 
informations confidentielles devient vulnérable à des attaques financières et légales. Par exemple, les 
organisations travaillant aux États­Unis pourraient avoir à respecter (intégralement ou partiellement) 
les réglementations suivantes :

• FISMA (Federal Information Security Management Act)
• Sarbanes­Oxley Public Company Accounting Reform and Investor Protection Act
• GLBA (Gramm­Leach­Bliley Financial Services Modernization Act)
• HIPAA (Health Insurance Portability and Accountability Act)
La réglementation HIPAA comporte des directives strictes sur la façon dont les organismes de santé 
doivent gérer les informations médicales personnelles électroniques (ePHI). Elle n'oblige et ne 
recommande pas de technologie particulière ; elle indique simplement les caractéristiques requises 
pour être en conformité avec la protection des ePHI et comment limiter les risques. Considérez 
l'isolation de domaines ou de serveurs avec protection IPSec comme une mesure de protection 
technique pour répondre aux exigences des sections de l'HIPAA suivantes :

• Contrôle d'accès 164.312(a)(1) : protéger l'accès réseau entrant vers des ordinateurs approuvés 
via des autorisations de stratégie de groupe et utiliser le chiffrement pour empêcher la divulgation 
des EPHI sur le trafic réseau.

• Contrôles d'audit 164.312(b) : auditer les ordinateurs qui communiquent entre eux.
• Intégrité 164.312(c)(1) : limiter l'accès réseau entrant vers des ordinateurs abritant des ePHI 
uniquement à un groupe spécifique d'ordinateurs et d'utilisateurs autorisés et approuvés. 
Empêcher l'altération des ePHI lors des transmissions réseau en assurant l'intégrité et l'authenticité 
de tous les paquets réseau des connexions applicatives.

• Authentification des personnes ou des entités164.312(d) : requérir l'authentification et l'autorisation 
des ordinateurs approuvés pour l'accès réseau entrant vers d'autres ordinateurs approuvés.

• Sécurité des transmissions 164.312(e)(1) : assurer l'authenticité, l'intégrité et le chiffrement.

En général, vous pouvez répondre à ces exigences en utilisant le protocole SSL (Secure Sockets 
Layer) et TLS (Transport Layer Security). Pour être en conformité avec les réglementations de 
sécurité de l'HIPAA, les applications peuvent, par exemple, avoir recours à la technologie 
Microsoft .NET avec SSL/TLS. Pour plus d'informations, reportez­vous au Livre blanc « Healthcare 
Without Boundaries: IntegrationTechnology for the New Healthcare Economy   » à l'adresse 
suivante : www.microsoft.com/Resources/Healthcare/HealthcareEconomy.aspx.

21
Les communications entre applications doivent toutefois intégrer correctement les contrôles 
d'algorithme et l'utilisation de SSL/TLS. Les principaux avantages d'une solution d'isolation IPSec sont 
les suivants : une protection de toutes les applications et du système d'exploitation des ordinateurs 
hôtes, et une sécurité du trafic réseau pour les applications existantes, sans avoir à les modifier. Pour 
plus d'informations, reportez­vous à la section « Comparaison entre SSL/TLS et IPSec », plus loin 
dans ce chapitre.

Conformité de cette solution avec les réglementations du gouvernement américain

Le 16 décembre 2003, l'Office of Management and Budget (OMB) du gouvernement américain a 
publié un mémorandum sur l'« E­Authentication Guidance for Federal Agencies   », disponible à 
l'adresse suivante : http://www.whitehouse.gov/omb/memoranda/fy04/m04­04.pdf. Ce mémorandum 
indique que le niveau de risque d'une altération de l'authentification correspond au niveau auquel 
l'authentification électronique (e­authentification) est requise. 

La publication spéciale 800­63 du NIST (National Institute of Standards and Technology) « Electronic 
Authentication Guideline: Recommendations of the National Institute of Standards and Technology » 
(Guide de l'authentification électronique : recommandations du NIST), identifie les exigences 
techniques des niveaux d'authentification 1­4. Dans de nombreux cas, les niveaux élevés (3 et 4) 
d'authentification de l'utilisateur requièrent une réécriture ou un remplacement des applications. Si les 
risques de sécurité peuvent être réduits dans leur ensemble, vous pouvez utiliser une solution 
d'authentification de l'utilisateur moins onéreuse pour assurer l'accès aux informations très sensibles 
de votre organisation. Sur la plate­forme Windows, les solutions d'isolation de serveurs et de 
domaines ajoutent une première couche d'authentification des ordinateurs approuvés, de contrôle 
d'accès, d'authentification du trafic réseau et de chiffrement, en amont de l'authentification de 
l'utilisateur au niveau de la couche application. Ainsi, l'utilisation d'une solution d'isolation de serveurs 
peut permettre de réduire ou de temporiser les modifications d'application requises et contribuer à 
répondre aux obligations en matière de gestion des risques.

Pour être conforme aux réglementations gouvernementales relatives aux produits d'assurance des 
informations, la société Microsoft s'est engagée à suivre plusieurs processus de certification. 
Windows 2000 est certifié conforme aux critères communs pour l'évaluation de la sécurité des 
technologies de l'information (Common Criteria for IT Security Evaluation) (norme ISO 15408) niveau 
d'assurance 4 (EAL4), avec ALC_FLR.3 (Systematic Flaw Remediation). Cette certification s'applique 
aux systèmes d'exploitation et aux catégories de protection des données sensibles.

Remarque : au moment de la rédaction de cet article, les plates­formes Windows XP et 
Windows Server 2003 étaient en cours de certification.

Les composants cryptographiques IPSec de Windows 2000, Windows XP et Windows Server 2003 
sont certifiés et répondent aux exigences cryptographiques de la norme FIPS 140­1. Ainsi, les 
solutions d'isolation de serveurs et de domaines peuvent être utilisées pour des applications militaires 
ou gouvernementales et dans des environnements informatiques associés. Pour plus d'informations, 
reportez­vous aux liens suivants :

•  NSTISSP No. 11 Fact Sheet: National 
Information Assurance Acquisition Policy  , à l'adresse suivante : http://niap.nist.gov/cc­scheme/
nstissp_11_revised_factsheet.pdf

•  Validated Products List (by Technology Type)   , à l'adresse suivante : http://niap.nist.gov/cc­
scheme/vpl/vpl_type.html

•  Overview: Windows    2000 Common Criteria Certification  
, à l'adresse suivante : 
www.microsoft.com/technet/security/prodtech/Windows2000/
w2kccwp.mspx

22
•  FIPS 140 Evaluation   , à l'adresse suivante : www.microsoft.com/technet/archive/security/topics/
issues/fipseval.mspx

Les informations de cette section concernent uniquement les organisations basées aux États­Unis. 
Toutefois, des réglementations connexes voient le jour dans le monde entier, comme en témoignent 
des lois telles que la directive européenne sur la protection des données (1988) et la loi canadienne 
sur la protection des renseignements personnels et les documents électroniques (PIPEDA), qui 
imposent toutes deux des instructions strictes concernant la gestion des identités et la confidentialité 
des données.

Évaluation des risques liés à l'infrastructure informatique

L'évaluation des risques de l'entreprise consiste à identifier la dépendance entre l'entreprise et son 
infrastructure informatique. L'évaluation des risques de sécurité informatique consiste à identifier et à 
définir un ordre de priorité des risques liés à l'intégrité des informations et à la stabilité des services. 
L'évaluation des risques de sécurité doit justifier la nécessité de prévention de ces risques et évaluer 
les coûts liés à la non­anticipation de ces risques. Les évaluations des coûts jouent un rôle très 
important dans l'évaluation des différentes solutions techniques, et ce pour chaque problème. Étant 
donné qu'une seule solution ne permet pas d'éviter 100 % des risques, comparez les solutions et leurs 
différents coûts.

Les décisionnaires peuvent, par exemple, évaluer le coût d'une solution d'isolation en termes de 
réduction des risques liés à un service dégradé ou interrompu suite à l'attaque d'un virus ou d'un vers. 
Pour certaines organisations, lorsqu'un pirate parvient à accéder à leurs données stratégiques, 
l'impact et les coûts résultant de l'attaque peuvent être dramatiques. 

Remarque : dans certains pays et dans certains états, la loi oblige les entreprises à informer leurs 
clients des violations de sécurité éventuelles dont ils pourraient être victimes. Pour obtenir des 
réponses aux questions juridiques relatives à votre organisation, contactez votre organisme public 
local ou un conseiller juridique.

Les catégories suivantes peuvent vous aider à évaluer le coût total d'un incident de sécurité :

• Coût occasionné par une perte de service. Pour déterminer le coût total qu'occasionne une 
perte de service sur un serveur réseau, faites la somme des coûts suivants :
• Temps de réponse requis par le personnel de support en cas d'incident jklhl kjhlkj hkjlh lkjh kjlh 
kjh kjh ljkh 
• Manque à gagner suite à l'interruption de l'application
• Perte de productivité interne

• Coût occasionné par le vol d'informations. Pour déterminer le coût total qu'occasionne le vol 
d'informations enregistrées sur un serveur réseau interne, faites la somme des coûts suivants :
• Perte de la propriété intellectuelle requise pour développer l'information
• Perte des recettes à venir sur tous les produits, en raison d'une perte de confiance des clients 
(suite à la médiatisation du vol)
• Perte de valeur marchande, en raison d'une perte de confiance des investisseurs (suite à la 
médiatisation du vol)
• Temps de réponse requis en interne par les services de marketing et de développement
• Perte de recettes éventuelles, en raison d'efforts de réponse en interne
• Temps nécessaire pour limiter l'utilisation malveillante des informations à l'encontre de 
l'entreprise, des employés ou des clients

23
• Coût occasionné par la compromission des informations d'identification d'administration 
sur le serveur. Pour déterminer le coût total qu'occasionne la compromission des informations 
d'identification d'administration sur un serveur réseau interne, faites la somme des coûts suivants :
• Efforts requis en interne pour répondre à l'attaque et remplacer le serveur
• Protection en interne des ordinateurs susceptibles d'être attaqués suite à la compromission des 
informations d'identification d'administration sur le serveur 

• Coût occasionné par des mesures de réglementation ou des actions juridiques ultérieures. 
Pour déterminer le coût total qu'occasionnent les exigences d'une action en justice, faites la 
somme des coûts suivants :
• Coût d'une action en justice si l'attaquant a été identifié mais la décision de la cour vous est 
défavorable 
• Coût d'une action en justice si l'attaquant a été identifié et la décision de la cour vous est 
favorable, mais l'accusé est dans l'impossibilité de payer le montant des dommages
• Coût des amendes, audits, restrictions et autres efforts visant à restaurer l'environnement de 
travail actuel 

Investissement dans des solutions de sécurité des informations sur le 
long terme

La protection de l'accès au réseau (NAP, Microsoft Network Access Protection) constitue un moyen 
efficace de contrôler si les périphériques qui se connectent au réseau ou les uns aux autres sont 
conformes aux stratégies. La mise en quarantaine des accès à distance et l'isolation de serveurs et de 
domaines sont deux moyens allant en ce sens et pouvant désormais être implémentés sous 
Windows 2000 et des plates­formes ultérieures. En associant les atouts du périmètre et de l'isolation 
en interne, l'organisation est armée pour lutter contre les infections et tout autre type d'attaque lancés 
à partir d'ordinateurs non approuvés et découlant d'informations d'identification compromises. 

Pour plus d'informations sur l'initiative NAP, reportez­vous à la page Network Access Protection   du 
site Microsoft à l'adresse : www.microsoft.com/nap.

Pour plus d'informations sur les réseaux privés virtuels (VPN) et le contrôle d'accès des quarantaines, 
reportez­vous à la page Virtual Private Networks for Windows
      Server    2003    du site Microsoft à 
l'adresse : www.microsoft.com/vpn.

Dans les prochaines versions de Windows, Microsoft prévoit de proposer une protection d'accès 
réseau encore plus facile à gérer et plus complète. Pour plus d'informations, reportez­vous au Livre 
blanc « Introduction to Network Access Protection   », à l'adresse : 
www.microsoft.com/windowsserver2003/techinfo/
overview/napoverview.mspx.

Identifications des ordinateurs approuvés
L'approbation et le fonctionnement de l'approbation avec les ordinateurs est un point important de 
l'isolation de serveurs et de domaines. L' isolation permet à n'importe quel hôte approuvé de définir les 
personnes autorisées à accéder au réseau. Quel que soit le type de connexion établi entre les 
ordinateurs distants et l'extrémité distante de la connexion (par exemple, une connexion sans fil, de 
réseau local ou Internet), l'ordinateur distant doit utiliser IPSec pour négocier l'approbation et sécuriser 
le trafic TCP/IP de bout en bout avec l'ordinateur de destination. Ce modèle de sécurité de bout en 
bout offre un niveau de protection des communications réseau que ne proposent pas les autres 
technologies de sécurité et de contrôle d'accès réseau (par exemple, VPN, 802.1x, 802.11 WEP). 

24
Pour empêcher le vol, l'altération ou l'utilisation malveillante des informations d'identification, il est 
primordial d'approuver d'abord l'ordinateur distant.

Dans le cadre de cette solution, l'approbation permet à une organisation d'être presque certaine qu'un 
ordinateur est dans un état connu et qu'il répond aux exigences minimales de sécurité définies par 
l'organisation. Ces exigences peuvent être d'ordre technique, axées sur la sécurité, liées à l'activité 
professionnelle de l'entreprise ou à plusieurs de ces points. Ces exigences déterminent également 
l'état dans lequel doit se trouver un ordinateur avant d'établir une communication avec d'autres 
ordinateurs. Microsoft recommande que la spécification des ordinateurs approuvés inclue une liste à 
jour des mises à jour de sécurité et des services packs requis. Dans l'idéal, vous devez gérer et 
appliquer ces mises à jour via un système de gestion des correctifs tel que le service Windows Update 
ou Microsoft Systems Management Server (SMS). La fréquence d'application de ces mises à jour 
dépend de la durée nécessaire à votre organisation pour tester et déployer chaque mise à jour. 
Cependant, pour une sécurité optimale, vous devez appliquer les mises à jour de votre environnement 
dès que possible.

Les ordinateurs non approuvés sont des ordinateurs susceptibles de ne pas répondre aux exigences 
de sécurité. En règle générale, un ordinateur n'est pas approuvé s'il n'est pas géré ou s'il n'est pas 
sécurisé.

L'isolation de serveur et de domaine vise à limiter les risques qu'encourent les ressources approuvées 
de l'entreprise, en implémentant des outils, des technologies et des processus chargés de les 
protéger. La solution garantit que :

• seuls les ordinateurs approuvés (ceux qui répondent à des exigences de sécurité spécifiques) 
peuvent accéder à des ressources approuvées ;

• les ordinateurs non approuvés n'ont pas accès aux ressources approuvées, sauf si une raison 
professionnelle précise justifie de courir le risque.

Vous devez autoriser, par défaut, l'accès réseau aux ressources approuvées uniquement à partir 
d'autres ressources approuvées. Par ailleurs, vous devez contrôler l'accès à la couche réseau, en 
utilisant les fonctions d'accord ou de refus d'autorisation et les listes de contrôle d'accès (ACL) pour 
des utilisateurs et des ordinateurs spécifiques au sein de l'environnement approuvé.

En créant cet environnement approuvé et en limitant les communications autorisées à l'intérieur et à 
l'extérieur de cet environnement, l'entreprise limite l'ensemble des risques qu'encourent ses données. 
Parmi les autres avantages métier figurent notamment les suivants :

• grande compréhension du flux des données dans des zones spécifiques du réseau ;
• meilleure adoption des programmes de sécurité utilisés pour obtenir le statut « approuvé » ;
• création d'un inventaire, à jour, des hôtes et périphériques réseau.

Par exemple, dans le scénario Woodgrove Bank, les ordinateurs approuvés sont tous les ordinateurs 
qui exécutent Windows 2000 Service Pack (SP) 4, Windows XP SP2 ou une version ultérieure, ou 
Windows Server 2003 ou ultérieur dans l'un des domaines appartenant à la Woodgrove Bank et gérés 
par cette dernière. En outre, les ressources approuvées, notamment tous les ordinateurs (exécutant 
Windows 2000 ou une version ultérieure) qui utilisent des stratégies de groupe pour fournir des 
paramètres de sécurité, sont régulièrement examinées par le personnel informatique pour vérifier 
qu'elles restent conformes aux exigences minimales. Le personnel informatique examine également 
les ressources approuvées pour vérifier que l'installation et la configuration des logiciels de sécurité 
spécialisés (tel qu'un antivirus) sont contrôlées de façon centralisée selon les exigences de sécurité 
propres à la Woodgrove Bank. Pour plus d'informations sur l'identification des ordinateurs approuvés 

25
dans le cadre de la solution, reportez­vous à la section « Définition de l'approbation » du chapitre 3 
« Détermination de l'état actuel de votre infrastructure informatique » de ce guide.

Ordinateurs non gérés

Un ordinateur non géré est un ordinateur dont les paramètres de sécurité ne sont pas contrôlés de 
façon centralisée par le service informatique. En outre, tout ordinateur qui ne présente pas les 
fonctionnalités de gestion de sécurité requises est également considéré comme non géré. Les 
ordinateurs non gérés sont considérés comme non approuvés car l'organisation ne peut pas garantir 
qu'ils répondent aux exigences de sécurité des ordinateurs approuvés auxquels ils essaient d'accéder.

Ordinateurs non sécurisés

Les ordinateurs non approuvés incluent également les ordinateurs qui exécutent un système 
d'exploitation qui n'est pas configuré, ou ne peut pas être configuré, pour atteindre le niveau de 
sécurité requis. Les ordinateurs non sécurisés peuvent entrer dans l'une des quatre catégories 
suivantes :

• Faible niveau de sécurité du système d'exploitation. Cette catégorie inclut les ordinateurs qui 
exécutent un système d'exploitation ne possédant pas le niveau d'infrastructure de sécurité requis. 
Parmi ces systèmes d'exploitation figurent notamment : Windows 9x, Microsoft Windows NT® et 
Windows CE. En général, les fonctionnalités requises pour l'infrastructure de sécurité sont 
présentes dans les systèmes d'exploitation plus récents, comme Windows XP et 
Windows Server 2003. Ces fonctionnalités incluent : les contrôles d'accès (par exemple, les 
autorisations sur les fichiers), les fonctions de sécurité réseau de chiffrement des paquets, et 
d'authentification et d'autorisation renforcées, différents niveaux de privilège (utilisateur et 
administrateur), la prise en charge d'une gestion centralisée des paramètres de sécurité, la prise 
en charge permettant d'assurer la confidentialité et l'intégrité des données, et la prise en charge 
d'autres technologies de sécurité (comme le protocole d'authentification Kerberos et les services 
de certificats).

• Configuration incorrecte. Même les systèmes d'exploitation les plus fiables peuvent être 
configurés de façon incorrecte, et donc à la merci d'une attaque. Ces ordinateurs doivent 
également être considérés comme des périphériques non sécurisés.

• Absence d'un niveau de mise à jour requis. Comme la sécurité informatique est en constante 
évolution, la plupart des éditeurs de logiciels proposent des mises à jour logicielles pour corriger 
les vulnérabilités de leurs produits. Une organisation peut définir un niveau minimum de mise à jour 
pour considérer un hôte comme approuvé. Dans ce cas, les ordinateurs qui ne possèdent pas le 
niveau de mise à jour requis sont considérés comme des périphériques non sécurisés.

• Ordinateurs approuvés pouvant être compromis. Il est possible qu'un ordinateur approuvé soit 
compromis, en général, par une personne malveillante à laquelle vous faisiez confiance. Lorsque 
la sécurité d'un ordinateur approuvé est compromise, l'ordinateur n'est plus considéré comme 
approuvé tant que cette situation de risque n'a pas été résolue. Comprenez bien que si vous 
n'avez pas confiance en l'utilisateur d'un ordinateur, vous ne pouvez pas avoir confiance en son 
ordinateur.

Les périphériques qui entrent dans l'une de ces quatre catégories sont considérés comme étant non 
approuvés car l'organisation n'a pas la certitude qu'ils n'ont pas été compromis d'une manière ou 
d'une autre. Ils représentent donc un risque significatif pour les ordinateurs approuvés auxquels ils 
tentent d'accéder.

26
Isolation de serveurs et de domaines : objectifs directement 
réalisables

Avant toute chose, l'isolation de serveurs et de domaines vise à limiter les risques d'accès non 
autorisé, lorsqu'un ordinateur non approuvé tente d'accéder à un ordinateur approuvé. Avec les 
plates­formes actuelles, l'isolation d'un ordinateur distant en limitant l'accès réseau entrant repose sur 
la possibilité d'authentifier avec succès un ordinateur comme membre du domaine par le biais du 
protocole de négociation de sécurité IKE (Internet Key Exchange) d'IPSec. L'authentification de 
l'utilisateur intervient uniquement une fois l'authentification de l'ordinateur réussie et lorsque les 
associations de sécurité IPSec protègent toutes les connexions d'applications et de protocoles de 
niveau supérieur entre deux ordinateurs. L'isolation de serveurs et de domaines vous permet donc 
d'atteindre les objectifs suivants :

• Isoler les ordinateurs membres du domaine approuvé des périphériques non approuvés au niveau 
du réseau.

• Vérifier que l'accès réseau entrant à un membre du domaine approuvé sur le réseau interne 
requiert l'utilisation d'un autre membre du domaine approuvé.

• Autoriser les membres du domaine approuvé à limiter l'accès réseau entrant à un groupe 
spécifique d'ordinateurs membres du domaine.

• Concentrer les risques d'attaque sur un petit nombre d'hôtes, constituant une barrière de protection 
du domaine approuvé, où les stratégies de minimisation des risques maximum (journalisation, 
surveillance, détection d'intrusion, etc.) peuvent être appliquées de façon plus efficace.

• Mettre l'accent et la priorité sur la surveillance proactive et les efforts de conformité avant toute 
attaque.

• Se concentrer sur les efforts de réparation et de récupération, avant, pendant et après toute 
attaque, et être plus rapide sur ces points.

• Améliorer la sécurité en ajoutant l'authentification mutuelle par paquet renforcée, l'intégrité, l'anti­
relecture et le chiffrement, sans avoir à modifier les applications et les protocoles de niveau 
supérieur, tels que SMB (Server Message Block) ou NetBT.

L'isolation de serveurs et de domaines vise à protéger tous les services réseau sur l'hôte approuvé 
contre toute attaque ou accès réseau non approuvé. L'isolation de serveurs et de domaines rend les 
hôtes moins vulnérables aux failles et aux erreurs présentes dans d'autres types de sécurité réseau, 
et aux failles de protection des informations d'identification de l'utilisateur. Enfin, les solutions 
d'isolation de serveurs et de domaines permettent d'éviter des menaces réseau similaires, mais elles 
fournissent des niveaux de contrôle d'accès réseau et de protection du trafic différents de ceux des 
autres types de technologie de sécurité réseau. Par exemple, une solution d'isolation de serveurs et 
de domaines peut autoriser l'accès entrant à des ordinateurs hôtes approuvés spécifiques en fonction 
de l'identité du domaine de l'utilisateur et de l'hôte, ce qui garantit la protection de bout en bout de la 
communication autorisée. Les autres technologies de sécurité réseau, quant à elles, ne prennent 
généralement en charge que l'identité de l'utilisateur.

Isolation de serveurs et de domaines : risques évités

Le tout premier risque que permet d'éviter l'isolation de serveurs et de domaines est celui de l'accès 
non autorisé, lorsqu'un ordinateur non approuvé tente d'accéder à un ordinateur approuvé. La solution 
seule ne permet pas de limiter complètement tous les risques de sécurité. Si ces risques de sécurité 
ne sont pas pris en charge par des processus et technologies de sécurité complémentaires, il est 
possible que vous ne tiriez pas parti des avantages de la solution d'isolation. Il existe plusieurs risques 
de sécurité graves que cette solution ne permet pas d'éviter directement, par exemple :

27
• Risque de vol ou de divulgation de données sensibles par des utilisateurs approuvés. La 
solution d'isolation permet de contrôler les communications des ordinateurs au sein du réseau 
interne, mais les administrateurs peuvent compromettre ce contrôle. Cette solution ne permet pas 
de réduire le risque qu'un utilisateur approuvé copie ou divulgue des données sensibles.

• Risque de compromission des informations d'identification des utilisateurs approuvés. Pour 
protéger les informations de connexion réseau, un administrateur peut décider de chiffrer la plus 
grande partie du trafic IPSec, mais la protection IPSec du trafic d'ouverture de session utilisateur 
vers les contrôleurs de domaine n'est pas prise en charge. L'isolation de serveurs et de domaines 
peut obliger une personne malveillante à utiliser un hôte approuvé pour attaquer d'autres hôtes 
approuvés. Une personne malveillante peut également attaquer des hôtes approuvés en utilisant 
des informations d'identification compromise d'hôtes qui sont dispensés d'utiliser IPSec avec des 
hôtes approuvés (par exemple, des contrôleurs de domaine et des serveurs DNS) ou d'hôtes qui 
acceptent des connexions entrantes d'ordinateurs non approuvés. Un administrateur peut 
déterminer si les hôtes approuvés communiquent vers l'extérieur, vers des hôtes non approuvés, 
mais la solution ne permet pas de limiter le risque qu'un utilisateur approuvé perde ses 
informations d'identification en se laissant abuser par un attaquant l'ayant incité à divulguer son 
mot de passe.

• Utilisateurs malveillants. Cette catégorie inclut les utilisateurs légitimes qui profitent de leurs 
droits d'accès. Par exemple, cette solution ne permet pas de réduire le risque qu'un utilisateur 
contrarié décide de voler des informations en utilisant les hôtes approuvés auxquels son poste 
dans l'entreprise lui donne accès. L'accès physique à un ordinateur hôte approuvé peut permettre 
à une personne malveillante d'obtenir un accès non autorisé et administratif à cet hôte. Comme les 
administrateurs peuvent désactiver la protection d'isolation de serveurs et de domaines, il est 
primordial de limiter l'accès et le nombre d'administrateurs (y compris les administrateurs de 
l'entreprise, les administrateurs de domaine et les administrateurs locaux sur des stations de travail 
ou des serveurs membres).

• Risque que des ordinateurs non approuvés accèdent à d'autres ordinateurs non approuvés. 
Cette solution ne permet pas de limiter le risque que des ordinateurs non approuvés utilisés par 
une personne malveillante s'en prennent à d'autres ordinateurs non approuvés.

• Risque que des ordinateurs non approuvés attaquent certains ordinateurs approuvés. Les 
solutions d'isolation de serveurs et de domaines sont conçues pour protéger les hôtes approuvés. 
Cependant, pour des raisons pratiques de déploiement, cette solution identifie les membres du 
domaine approuvés qui, pour diverses raisons, n'ont pas recours à IPSec pour négocier un accès 
approuvé à d'autres hôtes approuvés. Ces ordinateurs approuvés, mais non­IPSec, font partie 
d'une liste d'exemptions (par exemple, les contrôleurs de domaine). Cette solution identifie 
également des hôtes approuvés auxquels peuvent accéder des ordinateurs non approuvés pour 
fournir des services de limite pour le domaine d'isolation. Une personne malveillante qui parvient à 
obtenir le contrôle d'un hôte exempté ou d'un hôte de limite peut attaquer tous les autres hôtes 
approuvés se trouvant dans le domaine d'isolation. 

• Garantie que les hôtes approuvés sont conformes aux exigences de sécurité. Cette solution 
donne des conseils sur la définition de l'approbation des hôtes et requiert surtout qu'ils soient 
membres d'un domaine Windows 2000 ou Windows Server 2003. Cette solution dépend 
uniquement de la réussite de l'authentification IPSec IKE basée sur le domaine (Kerberos) pour 
établir l'approbation et la connectivité protégée par IPSec. Avec le temps, les hôtes approuvés 
peuvent, pour diverses raisons, ne plus répondre totalement aux critères exigés des hôtes 
approuvés mais être toujours en mesure de s'authentifier avec succès comme membres du 
domaine. Les systèmes et processus de gestion informatique de l'organisation doivent s'assurer 
que les membres du domaine sont conformes à la définition des hôtes approuvés.

Pour résoudre ces problèmes, les configurations et modèles recommandés de renforcement de la 
sécurité ont été appliqués à tous les systèmes dans l'environnement de laboratoire de la 
Woodgrove Bank. Pour plus d'informations sur les procédures de gestion et les technologies de 

28
sécurité de la plate­forme Windows, reportez­vous à la page TechNet Security Resource Center   
du site Web Microsoft, à l'adresse : www.microsoft.com/technet/security/.

Comment l'isolation de serveurs et de domaines 
s'intègre­t­elle dans ma stratégie de sécurité 
réseau globale ?
L'isolation de serveurs et de domaines est utilisée en complément d'autres mécanismes préventifs et 
réactifs pour protéger le réseau et les périphériques qui y connectés, y compris les ordinateurs. 
Comme la sécurité est un problème complexe nécessitant une protection à plusieurs couches, il peut 
être utile de rappeler en quoi consiste une protection renforcée, ainsi que les concepts importants qui 
y sont rattachés. Une stratégie de sécurité réseau complète applique les technologies appropriées 
pour réduire les risques les plus importants sans dépendance significative vis­à­vis des points de 
défaillance uniques. Par exemple, si le périmètre de sécurité échoue suite à une configuration 
incorrecte ou à l'intervention d'un employé malveillant, quelle autre couche de protection peut 
empêcher les hôtes approuvés internes de subir des infections et attaques réseau ? Qu'est­ce qui 
pourrait permettre de bloquer des attaques ciblant les hôtes approuvés d'Europe et d'Asie, alors que 
la personne malveillante est connecté à un port Ethernet, dans une salle de réunion de n'importe quel 
bureau américain ?

Protection renforcée 

La protection renforcée peut être définie comme une approche par couche permettant de protéger un 
ordinateur, au lieu de se fier à un dispositif de protection unique. Pour mettre en place des couches de 
protection efficaces, il est indispensable d'identifier avant tout les sources d'infection et les adversaires 
susceptibles d'attaquer une organisation, ainsi que leurs cibles potentielles. Par exemple, un 
adversaire peut être un concurrent louant les services d'une société d'espionnage industriel pour 
subtiliser des informations sur un nouveau produit ou un nouveau service en cours de développement. 
Lorsque vous avez cerné vos adversaires potentiels et leurs cibles probables, vous devez appliquer 
des procédures de réponse aux incidents pour les ordinateurs susceptibles d'être compromis. 
L'authentification, l'autorisation, la confidentialité et la non­répudiation comptent notamment parmi ces 
méthodes. Une organisation qui respecte la pratique recommandée protection­détection­réaction 
prend conscience que des attaques peuvent survenir et comprend que la détection anticipée de ces 
attaques et la réduction des interruptions de service ou des pertes de données sont primordiales. 
Étant donné que les probabilités d'attaque sont élevées, la méthode protection­détection­réaction 
permet de comprendre qu'il est nécessaire de concentrer davantage les efforts sur la protection des 
données et des ressources plutôt que sur la prévention des attaques. En règle générale, il est plus 
rentable de se protéger d'une attaque que de réparer les dégâts qu'elle peut occasionner.

Tous les dispositifs de protection des informations mettent l'accent sur les personnes, les processus et 
les technologies. L'isolation tient compte de l'ensemble de ces trois facteurs : elle se réalise via une 
identification précise des risques, des exigences et des ressources à protéger. Cette identification 
englobe les facteurs « personnes » et « processus ». En outre, l'isolation requiert des connaissances 
sur l'état actuel du réseau et de ses périphériques, sur les exigences de communication qui 
définissent l'interaction entre ordinateurs, et sur les exigences de sécurité qui risquent de limiter les 
exigences visant à obtenir le parfait équilibre entre sécurité et communication.

Pour plus d'informations sur ce sujet reportez­vous au Livre blanc « Defense in Depth   » (protection 
renforcée) de la NSA (National Security Agency), à l'adresse : 
http://www.nsa.gov/snac/support/defenseindepth.pdf.

29
Pour plus d'informations et des exemples pratiques pour l'exécution de ce processus, reportez­vous 
au chapitre Enterprise Design   (Configuration entreprise) du guide Windows Server System  
Reference Architecture (Architecture de référence des systèmes de serveurs Windows) sur le site 
Web de Technet, à l'adresse www.microsoft.com/technet/itsolutions/wssra/
raguide/Security_Architecture_1.mspx.

La figure suivante illustre l'intégration d'une solution d'isolation logique dans une approche de 
protection renforcée utilisée dans l'architecture de référence des systèmes de serveurs Windows :

Figure 2.1 Protection renforcée avec l'isolation logique 

Dans cette figure, il est important de comprendre que la couche de sécurité de l'isolation logique 
sécurise directement l'ordinateur hôte via le contrôle des communications réseau. Il s'agit d'un rôle 
très similaire à celui d'un pare­feu pour hôte. Toutefois, au lieu d'autoriser et de bloquer les services 
sur les ports comme un pare­feu pour hôte, IPSec autorise et bloque les services et négocie les 
services d'accès réseau approuvés. Une fois l'accès accordé, IPSec peut sécuriser tous les paquets 
entre les deux ordinateurs. Comme indiqué dans le cadre de cette solution, une solution d'« isolation 
logique » telle que l'isolation de serveurs et de domaines :

• ne sécurise pas les périphériques réseau, comme les routeurs ;
• n'offre pas un contrôle d'accès réseau physique (ex. : définition des ordinateurs autorisés à établir 
une connexion VPN d'accès à distance) ou les protections que proposent les pare­feu réseau ;

• ne sécurise pas les liaisons réseau, telles que 802.1x pour les contrôles d'accès et le 
chiffrement 802.11 WEP pour les liaisons sans fil. IPSec offre toutefois une protection de bout en 
bout sur toutes les liaisons réseau entre l'adresse IP source et l'adresse IP de destination ;

30
• ne sécurise pas l'ensemble des hôtes sur le réseau, mais uniquement ceux qui sont inclus dans la 
solution d'isolation ;

• ne sécurise pas les chemins du niveau application, tels que le chemin de bout en bout via lequel 
sont acheminés les messages électroniques et .NET, ni les requêtes HTTP (Hypertext 
Transmission Protocol) pouvant être en proxy à plusieurs reprises entre le client et la destination 
du serveur Web. 

Vous devez considérer la sécurité au niveau de chaque couche comme une partie intégrante de 
l'analyse de réduction des risques de sécurité informatique. Par exemple, si un ordinateur n'est pas 
autorisé à accéder à un serveur au niveau de la couche d'isolation logique, l'utilisateur qui se connecte 
à cet ordinateur importe peu. Tous les utilisateurs, même les administrateurs, se verront refuser 
l'accès au serveur.

Comparaison entre SSL/TLS et IPSec

IPSec n'est pas destiné à remplacer la sécurité de niveau application, telle que SSL/TLS. L'un des 
principaux avantages d'IPSec est qu'il permet de sécuriser le trafic réseau pour les applications 
existantes, sans avoir à les modifier. L'utilisation d'IPSec dans des environnements dans lesquels des 
applications utilisent SSL/TLS offre les avantages suivants :

• Il aide à protéger l'ensemble des applications et le système d'exploitation des attaques lancées 
depuis des ordinateurs non approuvés et d'autres périphériques.

• Il met en place une protection renforcée contre toute utilisation inappropriée ou non conforme de 
SSL/TLS (par exemple, si toutes les données eHPI ne sont pas chiffrées et authentifiées).

• Il contribue à empêcher la saisie des informations d'identification de l'utilisateur sur des ordinateurs 
non approuvés, car les utilisateurs ne sont pas invités à se connecter à un site Web SSL/TLS 
interne tant qu'IPSec établit une approbation mutuelle entre le client et le serveur.

• Il offre une sécurité lorsque vous ne pouvez pas utiliser les paramètres du registre de Windows 
pour sélectionner des algorithmes SSL/TLS conformes à la réglementation. Windows 2000, 
Windows XP et Windows Server 2003 fournissent des contrôles de clé de registre pour les 
algorithmes SSL/TLS, présentés dans l'article 245030 « How to Restrict the Use of Certain 
Cryptographic Algorithms and Protocols in Schannel.dll   » (Comment limiter l'utilisation de 
certains protocoles et algorithmes de chiffrement dans Schannel.dll) de la Base de connaissances 
Microsoft, à l'adresse suivante : http://support.microsoft.com/?kbid=245030.

• Il offre une sécurité lorsque les certificats ne sont pas disponibles.

IPSec sécurise le trafic entre les adresses IP source et de destination. SSL/TLS peut sécuriser le trafic 
sur tout le chemin de l'application (par exemple, d'un navigateur Web, via un proxy Web, vers un 
serveur Web).

L'institut NIST (National Institute for Standards and Technology) développe actuellement un guide 
d'utilisation de TLS. La publication spéciale 800­52, « Guidelines on the Selection and Use of 
Transport Layer Security » (Guide de sélection et d'utilisation de TLS) est un guide sur 
l'implémentation de TLS dans un gouvernement fédéral. Pour plus d'informations sur ce guide, 
reportez­vous au site Web de la NIST Computer Security Division  , à l'adresse 
http://csrc.nist.gov/publications/index.html. Il n'existe pas de guide similaire pour l'utilisation d'IPSec. 
Toutefois, la NSA a publié des guides sur l'utilisation d'IPSec avec Windows 2000. Ces guides sont 
disponibles sur le site Web de la NSA  , à l'adresse 
http://nsa2.www.conxion.com/win2k/download.htm. Les organisations qui sont dans l'obligation de se 
conformer aux recommandations de la NSA doivent analyser cette solution et consulter les guides de 
la NSA. 

31
IPSec avec l'authentification par certificat offre une protection similaire à SSL/TLS, à quelques 
différences près. Windows IPSec prend en charge un petit sous­ensemble des algorithmes de 
chiffrement gérés par TLS et recommandés dans la publication spéciale 800­52 de la NIST (par 
exemple, 3DES, SHA­1 et Diffie­Hellman éphémère 1024 bits). La solution présentée dans ce guide 
utilise les signatures de protocole Kerberos pour l'authentification IKE entre membres du domaine, et 
non les signatures basées sur les certificats. La négociation IKE Windows IPSec établit l'approbation 
mutuelle entre les ordinateurs qui utilisent le protocole Kerberos et l'authentification basée sur les 
certificats. Comme l'authentification IKE n'est pas intégrée dans les applications, elle ne peut pas 
vérifier si le nom de l'ordinateur de destination correspond bien à celui de l'ordinateur auquel doit se 
connecter l'application. De ce fait, une attaque du type « man­in­the­middle » lancée depuis un autre 
hôte approuvé peut avoir lieu. Mais comme l'application s'intègre à SSL/TLS, le nom de l'ordinateur de 
destination est authentifié (approuvé) et peut également être comparé au nom de l'ordinateur auquel 
doit se connecter l'application.

Rappel terminologique
Avant de poursuivre ce chapitre, il peut être intéressant de revoir certains termes qui sont souvent 
utilisés dans le cadre de cette solution. Si vous connaissez déjà la signification de ces termes, vous 
pouvez passer directement à la section suivante. En revanche, si vous ne connaissez pas vraiment 
ces termes, vous risquez de ne pas bien comprendre certaines explications fournies dans ce guide.

Termes relatifs à l'isolation

Les termes suivants sont uniquement employés pour le concept d'isolation logique. Assurez­vous de 
bien comprendre ces termes avant de poursuivre la lecture de ce chapitre :

• Isolation. Séparation logique entre un ou plusieurs ordinateurs et d'autres ordinateurs.
• Isolation de domaines. Ce terme définit le type d'isolation qui vise à séparer les ordinateurs 
approuvés des ordinateurs non approuvés. Pour être isolé, un ordinateur doit posséder des 
informations d'identification valides et être authentifié avec succès via IKE. Le domaine peut être 
n'importe quel domaine dans le chemin d'accès à l'approbation, accessible via une approbation 
bidirectionnelle entre les deux hôtes tentant de sécuriser leurs communications.

• Isolation de serveurs. Ce terme définit la manière dont les serveurs peuvent limiter l'accès entrant 
à un groupe spécifique d'ordinateurs approuvés, en utilisant IPSec et l'autorisation « Accéder à cet 
ordinateur à partir du réseau ».

• Isolation logique. Il s'agit d'un terme plus général utilisé pour les technologies d'isolation. Il peut 
notamment inclure l'isolation de domaines, l'isolation de serveurs et la protection de l'accès au 
réseau (NAP) pour isoler des ordinateurs au niveau de la couche réseau.

• Groupe d'isolation. Regroupement logique d'ordinateurs hôtes approuvés partageant les mêmes 
stratégies de sécurité des communications, notamment et principalement les mêmes exigences en 
termes de trafic réseau entrant et sortant. Vous pouvez implémenter les contrôles d'accès entrant 
et sortant d'un groupe d'isolation à l'aide d'une stratégie IPSec en utilisant des actions 
autoriser/bloquer, ou en faisant en sorte qu'IPSec négocie la sécurité conjointement avec les droits 
de connexion réseau de la stratégie de groupe (et éventuellement avec d'autres paramètres de 
configuration ou de connexion réseau). Les applications, services réseau et protocoles doivent 
bénéficier d'une configuration spécifique pour répondre aux exigences de trafic au niveau de leur 
couche. Par exemple, un groupe de serveur Exchange requiert qu'un ordinateur client ou serveur 
soit membre du domaine pour établir une connexion TCP/IP entrante. Ce groupe, qui n'est pas 
autorisé à établir des connexions TCP/IP sortantes vers des membres n'appartenant pas au 
domaine (sauf certaines exceptions) est appelé groupe d'isolation Exchange Server.

32
• Domaine d'isolation. Il s'agit d'un groupe d'isolation dans lequel les membres du groupe sont les 
mêmes que ceux du domaine Windows. Si le domaine possède des domaines approuvés 
bidirectionnels, les membres de ces domaines appartiennent au domaine d'isolation. Comme dans 
un groupe d'isolation, les exigences en termes de trafic réseau entrant et sortant sont simples : les 
connexions entrantes ne peuvent provenir que d'autres membres du domaine de l'hôte approuvé. 
Un serveur placé dans le groupe d'isolation de serveurs peut avoir des clients qui appartiennent au 
domaine isolé.

• Groupe d'accès réseau. Ce terme fait référence au groupe de sécurité de domaine de Windows, 
utilisé pour contrôler l'accès réseau à un ordinateur, en utilisant des paramètres de sécurité de 
stratégie de groupe pour les droits de connexion réseau. Ces paramètres sont créés pour 
appliquer les exigences d'accès entrant pour les groupes d'isolation. Chaque groupe d'isolation 
peut comprendre un groupe d'accès réseau autorisé (ANAG, Allow network access group) et un 
groupe d'accès réseau refusé (DNAG, Deny network access group).

• Approbation. Ce terme est utilisé pour définir le fait qu'un ordinateur accepte l'identité validée via 
le processus d'authentification. L'approbation de domaine implique que tous les membres du 
domaine approuvent le contrôleur de domaine pour établir l'identité et fournir correctement les 
informations d'appartenance au groupe à cette identité. L'approbation est nécessaire pour 
communiquer avec un ordinateur distant en utilisant IPSec. L'approbation signifie également qu'un 
utilisateur ou un ordinateur est considéré comme un élément avec lequel il est possible de 
communiquer et ne présentant vraisemblablement qu'un faible risque de menace.

• Hôte de confiance. Ce terme désigne un ordinateur susceptible d'être configuré pour répondre 
aux exigences de sécurité minimales d'une organisation, mais pouvant être, ou non, un hôte 
approuvé. Il est primordial de connaître les ordinateurs dignes de confiance lors de la planification 
des membres d'un groupe d'isolation approuvé.

• Hôte approuvé. Ce terme fait référence à une plate­forme exécutant Windows 2000, Windows XP 
ou Windows Server 2003, appartenant au moins à un domaine de sécurité de Windows 2000 et 
capable d'appliquer une stratégie IPSec. Les hôtes approuvés sont en général définis pour 
répondre à des exigences de gestion et de sécurité supplémentaires. La configuration de l'hôte est 
contrôlée de façon à ce que les risques de sécurité de l'hôte soient faibles et gérables. Les hôtes 
approuvés sont moins susceptibles d'être à l'origine d'une infection ou d'un acte malveillant. Pour 
plus d'informations à ce sujet, reportez­vous au chapitre 3 de ce guide « Détermination de l'état 
actuel de votre infrastructure informatique ».

• Hôte non approuvé. Ordinateur hôte qui n'est pas un hôte approuvé. Cet ordinateur possède une 
configuration inconnue ou non gérée. Il ne peut être garanti que l'hôte (ou utilisateur de l'hôte) ne 
sera pas à l'origine d'une source d'infection ou d'un acte de malveillance en cas de connexion au 
réseau.

• Hôte de limite. Hôte approuvé qui est exposé au trafic réseau d'hôtes approuvés et non 
approuvés. Il doit par conséquent faire l'objet d'une surveillance plus étroite et être doté de moyens 
de protection plus importants que les autres hôtes approuvés pour lutter contre les attaques. Il doit 
y avoir le minimum d'hôtes de limite possible car ces derniers constituent une menace importante 
pour les autres hôtes approuvés.

• Exemption. Ordinateur faisant partie ou non d'un domaine et n'utilisant pas IPSec. Il existe deux 
types d'exemptions. Nous avons, d'une part, les ordinateurs qui utilisent une adresse IP statique 
dont les adresses sont incluses dans la « liste d'exemptions », de sorte que les hôtes approuvés 
n'utilisent pas IPSec avec ces ordinateurs. Et d'autre part, nous avons les ordinateurs exemptés 
d'utiliser la stratégie IPSec pour négocier des connexions sécurisées. Cette dernière catégorie peut 
apparaître ou non dans la liste d'exemptions. Une exemption peut répondre aux exigences d'un 
hôte approuvé, mais n'utilise pas la protection IPSec pour communiquer avec les autres hôtes 
approuvés du domaine d'isolation.

Termes relatifs à la sécurité

33
Assurez­vous de bien comprendre les termes suivants :

• Autorisation. Il s'agit d'une autorisation accordée à une personne, un ordinateur, un processus ou 
un périphérique pour accéder à des informations, des services ou des fonctionnalités spécifiques. 
L'autorisation est octroyée selon l'identité de la personne, de l'ordinateur, du processus ou du 
périphérique demandant l'accès. Cette identité est vérifiée lors de l'authentification.

• Authentification. Il s'agit d'un processus de validation des informations d'identification d'une 
personne, d'un processus informatique ou d'un périphérique. Pour être authentifié(e), la personne, 
le processus ou le périphérique effectuant cette requête doit fournir une représentation des 
informations permettant de prouver son identité. Les informations d'identification les plus courantes 
sont les clés privées pour les certificats numériques, un secret configuré par l'administrateur sur 
deux périphériques (clé pré­partagée), un mot de passe secret de connexion de l'utilisateur ou de 
l'ordinateur au domaine, ou un élément biologique tel qu'une empreinte digitale ou une analyse 
rétinienne.

• Usurpation. Dans ce guide, l'usurpation désigne l'attaque consistant à usurper l'identité d'une 
adresse IP autorisée dans le but d'interrompre les communications ou d'intercepter des données.

• Non­répudiation. Cette technique est utilisée pour garantir qu'une personne effectuant une action 
sur un ordinateur ne peut nier qu'elle a effectué cette action. La non­répudiation offre la preuve 
irréfutable qu'un utilisateur ou un périphérique a effectué une action spécifique comme un transfert 
d'argent, une autorisation d'achat ou l'envoi d'un message.

• Texte chiffré. Il s'agit des données qui ont été chiffrées. Le texte chiffré est le résultat du 
processus de chiffrement. Il peut retrouver une forme lisible (en texte clair) grâce à la clé de 
déchiffrement appropriée.

• Texte clair (ou texte en clair). Il s'agit des communications et des données dans leur format non 
chiffré. 

• Hachage. Il s'agit d'un résultat de taille fixe obtenu en appliquant une fonction mathématique 
unidirectionnelle (parfois appelée algorithme de hachage) à un volume arbitraire de données 
d'entrée. En cas de modification des données d'entrée, le hachage change. Les fonctions de 
hachage sont choisies de sorte que la probabilité que deux entrées produisent le même résultat de 
hachage soit extrêmement faible. Le hachage peut être utilisé dans de nombreuses opérations, 
notamment dans l'authentification et la signature numérique. Il est également appelé « résumé du 
message ».

Termes relatifs au réseau

Les termes suivants font référence aux éléments réseau de cette solution :

• Initiateur. Ordinateur qui initialise la communication réseau avec un autre ordinateur.
• Répondeur. Ordinateur qui répond à la demande de communication sur le réseau.
• Chemin de communication. Chemin de connexion mis en place pour le trafic réseau qui a lieu 
entre un initiateur et un répondeur.

Termes relatifs aux stratégies de groupe

Les termes suivants sont associés aux stratégies de groupe de Windows :

• GPO (ou objet de stratégie de groupe). Les paramètres de stratégie de groupe que vous créez se 
trouvent dans un objet de stratégie de groupe (GPO). En associant un GPO aux conteneurs 
système d'Active Directory sélectionnés (sites, domaines et unités d'organisation (UO)), vous 

34
 pouvez appliquer les paramètres de stratégie de l'objet de stratégie de groupe aux utilisateurs et 
ordinateurs présents dans ces conteneurs Active Directory. Pour créer un GPO, utilisez l'Éditeur 
d'objets de stratégie de groupe, et la console de gestion des stratégies de groupe pour gérer les 
GPO au sein d'une entreprise.

• Stratégie de domaine. Stratégie stockée de façon centralisée dans Active Directory.
• Stratégie locale. Stratégie stockée sur un ordinateur.

Termes élémentaires relatifs à IPSec

Assurez­vous de bien comprendre les termes suivants :

• Stratégie de sécurité IP. Ensemble des règles de sécurité permettant de traiter le trafic réseau au 
niveau de la couche IP. Une règle de sécurité contient des filtres de paquets associés aux actions 
autoriser, bloquer ou négocier. Lorsque la négociation est requise, la stratégie de sécurité IP 
contient des méthodes d'authentification et de sécurité qui lui permettent de négocier avec 
l'ordinateur homologue.

• Stratégie de sécurité IP persistante. Type de sécurité IP introduit dans Windows XP et 
Windows Server 2003, permettant d'appliquer les paramètres de stratégie IPSec de façon 
persistante. La stratégie persistante s'applique d'abord au démarrage du service IPSec, afin de 
pouvoir remplacer les paramètres de la stratégie IPSec locale ou du domaine.

• Négociation IKE. Processus qui a lieu au lancement d'une connexion réseau, pour déterminer si 
un ordinateur utilisant IPSec autorise la connexion. 

• Associations de sécurité. Accords définis entre deux hôtes concernant la façon d'utiliser IPSec 
pour communiquer et les divers paramètres qui définissent cette négociation.

• Associations de sécurité en mode principal. Ces associations de sécurité sont établies avant 
les autres lors de la négociation IKE entre l'initiateur et le répondeur.

• Associations de sécurité en mode rapide. Ces associations sont négociées une fois les 
associations de sécurité en mode principal établies pour chaque session de communication entre 
les hôtes.

• Communiquer en texte clair. Cette option permet à un initiateur IKE d'autoriser un trafic TCP/IP 
normal (non­IKE ou non­IPSec) si le répondeur ne renvoie pas de réponse IKE. Il s'agit de l'option 
Autoriser une communication non sécurisée avec un ordinateur qui n'utilise pas IPSec 
disponible sur la page des propriétés des actions de filtrage de l'outil Gestion de stratégie IPSec.

• Relais entrant. Cette option autorise un ordinateur IPSec à accepter un paquet entrant TCP/IP 
normal (non­IKE ou non­IPSec) d'un ordinateur distant. La réponse normale du protocole de niveau 
supérieur est un paquet sortant qui lance une initiation IKE vers l'ordinateur distant. Il s'agit de 
l'option Accepter les communications non sécurisées mais toujours répondre en utilisant 
IPSec, disponible sur la page des propriétés des actions de filtrage de l'outil Gestion de stratégie 
IPSec.

Remarque : Si le relais entrant est activé, mais que l'option Communiquer en texte clair n'est pas 
activée sur un répondeur, celui­ci ne parviendra pas à communiquer avec un initiateur qui n'utilise pas 
IPSec.

Il est également très important de comprendre les termes spécifiques aux éléments d'IPSec. 
L'annexe A, « Présentation des concepts relatifs à la stratégie IPSec », de ce guide définit les termes 
relatifs à IPSec et explique le processus IPSec global que les ordinateurs des groupes d'isolation 
créés dans cette solution vont utiliser.

35
Comment l'isolation de serveurs et de domaines 
peut­elle être mise en place ?
L'idée d'isoler les ordinateurs des risques n'a rien de nouveau. L'utilisation de pare­feu pour permettre 
la segmentation, la mise en place de filtres et de contrôles d'accès au niveau des routeurs et la 
segmentation physique du trafic réseau font partie des techniques qui fournissent un niveau 
d'isolation.

La solution présentée dans ce guide est conçue pour fonctionner avec les techniques et périphériques 
existants de votre infrastructure réseau. Pour implémenter l'isolation, il faut apporter des modifications 
au logiciel hôte existant dans Windows 2000 et sur des plates­formes ultérieures. Les technologies et 
procédures telles que la segmentation réseau, les réseaux locaux virtuels (VLAN), les contrôles 
d'accès au réseau de périmètre, la mise en quarantaine réseau et la détection d'intrusions dans le 
périmètre du réseau peuvent être mises en place en implémentant ou en modifiant la configuration 
des périphériques réseau. L'isolation de serveurs et de domaines complète l'ensemble de ces 
techniques existantes et offre un niveau de protection supplémentaire pour les membres du domaine 
Windows gérés. Les administrateurs du système informatique Windows peuvent implémenter 
l'isolation de serveurs et de domaines en ne modifiant que très peu, voire pas du tout, les méthodes 
de connexion et chemins d'accès existants, les applications, et avec une infrastructure de domaine 
Windows 2000 ou Windows Server 2003 existante.

Composants de l'isolation de serveurs et de domaines

L'isolation de serveurs et de domaines intègre des composants importants qui, ensemble, constituent 
la solution. Les sous­sections ci­après présentent ces composants.

Hôtes approuvés

Les hôtes approuvés sont des ordinateurs que l'organisation informatique peut gérer pour répondre 
aux exigences minimales de sécurité. En général, vous pouvez obtenir le statut « approuvé » 
uniquement si l'ordinateur exécute un système d'exploitation fiable et géré, un antivirus et les mises à 
jour les plus récentes des applications et du système d'exploitation. Une fois l'ordinateur identifié 
comme « approuvé », le composant suivant de la solution est chargé de confirmer le statut de 
l'ordinateur, via l'authentification. Pour plus d'informations sur l'identification de l'état, reportez­vous au 
chapitre 3, « Détermination de l'état actuel de votre infrastructure informatique ».

Remarque : IPSec n'est pas capable de déterminer si un ordinateur est conforme aux critères d'un 
hôte donné. Une technologie de surveillance est requise pour déterminer la configuration élémentaire 
d'un ordinateur et signaler toute modification de cette configuration.

Authentification de l'hôte

Le mécanisme d'authentification de l'hôte permet de déterminer si l'ordinateur qui tente de lancer une 
session possède des informations d'authentification valides, telles que les informations d'identification 
du ticket Kerberos, un certificat ou une clé pré­partagée. À l'heure actuelle, deux technologies 
permettent de réaliser ce type d'authentification pour les ordinateurs Windows. Les sections ci­après 
présentent ces deux technologies.

Le protocole 802.1X

Le protocole 802.1X est un protocole d'authentification des utilisateurs et des périphériques basé sur 
des standards. Il autorise ou non la connexion via un port réseau de couche de liaison, tel qu'une 

36
connexion sans fil 802.11ou un port Ethernet 802.3. Il permet de contrôler les opérations des 
utilisateurs (à des fins de facturation), les autorisations et d'autres fonctions. Ce protocole requiert un 
ou plusieurs serveurs dédiés, par exemple, le service RADIUS (Remote Authentication Dial­In User 
Service), et une infrastructure réseau qui prend en charge le protocole. Le protocole 802.1X est conçu 
pour permettre de contrôler l'accès réseau et les clés de chiffrement pour le chiffrement WEP (Wired 
Equivalent Privacy) 802.11 du trafic sans fil entre le client et le point d'accès sans fil. Lorsque le 
périphérique est autorisé à accéder au réseau, il bénéficie en général d'un accès à l'ensemble du 
réseau interne. Les données sont déchiffrées au point d'accès sans fil, puis transférées au format 
TCP/IP normal en texte clair vers leur destination, susceptible d'être sécurisée par divers mécanismes 
de couche application. 

La sécurité de la Woodgrove Bank requiert la protection de tous les hôtes approuvés contre les 
ordinateurs non approuvés du réseau interne. Le protocole 802.1X pourrait imposer que seuls les 
ordinateurs approuvés bénéficient d'un accès via une connexion sans fil ou filaire, mais les 
commutateurs utilisés pour la plupart des ports Ethernet 802.3 internes ne peuvent pas effectuer 
l'authentification 802.1X. Un coût non négligeable d'achat matériel et d'installation aurait pu être requis 
pour mettre à niveau toutes les prises LAN murales physiques et tous les bureaux répartis dans les 
différents pays. La Woodgrove Bank a décidé d'utiliser le protocole 802.1X pour la sécurité sans fil, 
mais pas pour les ports Ethernet câblés. 

Une des autres exigences de sécurité de la Woodgrove Bank consistait à chiffrer le trafic de bout en 
bout entre les clients approuvés et les serveurs de chiffrement. Le protocole 802.1X n'a pas été mis 
au point pour permettre le chiffrement des connexions câblées, mais uniquement celui des connexions 
sans fil. Même lorsque les connexions sans fil sont chiffrées, les données ne sont pas protégées 
lorsque les paquets sont transférés sur le réseau local interne, après avoir été déchiffrés par le point 
d'accès sans fil. Par conséquent le protocole 802.1X ne permet pas de répondre à l'exigence de 
chiffrement de bout en bout.

Bien que le protocole 802.1X ne permette pas de répondre à l'ensemble des exigences de la 
Woodgrove Bank, il est toutefois utilisé pour la sécurité sans fil. Microsoft recommande d'utiliser le 
protocole 802.1X pour sécuriser les réseaux sans fil et permettre, lorsque cela est possible, un 
contrôle d'accès pour les réseaux filaires. Pour plus d'informations sur l'utilisation du protocole 802.1X, 
reportez­vous à la page Wi­Fi   du site Web de Microsoft, à l'adresse http://www.microsoft.com/wifi.

IPSec

IPSec est le protocole de sécurité standard de l'IETF (Internet Engineering Task Force) pour le 
protocole IP. Il s'agit d'un mécanisme général de sécurité de couche IP basé sur des stratégies. Il 
convient parfaitement pour l'authentification hôte par hôte. Une stratégie IPSec possède des règles et 
paramètres de sécurité qui contrôlent sur un hôte le flux du trafic IP entrant et sortant. La stratégie 
peut être gérée de façon centralisée dans Active Directory en utilisant des objets de stratégie de 
groupe (GPO) pour l'attribution des stratégies aux membres du domaine. IPSec permet d'établir des 
communications sécurisées entre les hôtes. IPSec utilise le protocole de négociation IKE (Internet Key 
Exchange) pour négocier entre deux hôtes des options relatives à la communication sécurisée à l'aide 
d'IPSec. Les accords définis entre deux hôtes concernent la façon d'utiliser IPSec pour communiquer, 
et les divers paramètres qui définissent cette négociation constituent des associations de sécurité. La 
négociation IKE établit une association de sécurité en mode principal (également appelée association 
de sécurité ISAKMP) et une paire d'associations de sécurité en mode rapide (également appelées 
associations de sécurité IPSec), l'une pour le trafic entrant et l'autre pour le trafic sortant. IKE requiert 
une authentification mutuelle pour établir l'association de sécurité en mode principal. Windows IKE 
peut utiliser l'une des trois méthodes suivantes :

• protocole d'authentification Kerberos version 5 ;

37
• un certificat numérique X.509 avec la paire de clés RSA (Rivest, Shamir et Adleman) publique et 
privée correspondante ;

• une clé pré­partagée (une phrase de passe, pas véritablement un mot de passe).

Bon nombre de personnes ne souhaitent pas déployer IPSec car elles estiment, à tort, qu'IPSec 
requiert des certificats d'infrastructure de clés publiques (PKI), souvent difficiles à déployer. Pour 
éviter d'avoir recours à une infrastructure de clés publiques, Microsoft a intégré l'authentification de 
domaine (Kerberos) de Windows 2000 dans le protocole de négociation IKE.

La négociation Windows IKE peut être configurée pour autoriser les communications avec un 
ordinateur ne répondant pas à la requête de négociation IKE. Cette caractéristique correspond à 
Communiquer en texte clair. Elle est d'une grande utilité lors du déploiement d'IPSec. Dans le cadre 
d'un fonctionnement normal, il est pratique de pouvoir autoriser des hôtes approuvés à communiquer 
avec des ordinateurs ou périphériques non approuvés, uniquement lorsque l'hôte approuvé lance la 
requête de connexion. IPSec utilise l'expression association de sécurité logicielle pour désigner une 
communication qu'IPSec ne peut pas protéger en utilisant les formats d'en­tête d'authentification (AH) 
ou d'encapsulation de charge utile de sécurité (ESP). IPSec enregistre cette communication dans le 
journal de sécurité comme audit de succès avec l'adresse IP de destination, et contrôle l'activité du 
trafic. Lorsque le trafic cesse après une durée d'inactivité (5 min par défaut) une nouvelle tentative de 
négociation de sécurité est requise lorsque de nouvelles connexions sortantes sont établies.

IPSec ne prend pas en charge le filtrage dynamique du trafic sortant, qu'il s'agisse du trafic dans une 
association de sécurité AH ou ESP, ou du trafic en texte clair impliqué dans une association de 
sécurité logicielle. Ainsi, lorsque vous utilisez les modèles de stratégie IPSec présentés dans ce guide 
pour l'isolation de domaines et de serveurs, l'hôte approuvé peut recevoir des connexions entrantes 
lancées depuis un ordinateur non approuvé sur n'importe quel port, par le biais de l'association de 
sécurité logicielle. Ceci constitue une vulnérabilité et par conséquent un point d'attaque potentiel. Mais 
il existe également un modèle prenant en charge des protocoles qui négocient les ports ouverts pour 
recevoir des connexions entrantes. Il est possible d'utiliser le filtrage dynamique des connexions 
sortantes pour compléter la protection IPSec, notamment à l'aide d'un pare­feu pour hôte tel que Pare­
feu Windows. Le trafic réseau bénéficiant de la protection IPSec AH ou ESP sans chiffrement n'est 
pas considéré comme étant en texte clair car il n'est pas authentifié ni protégé contre l'usurpation et la 
modification.

Comme IPSec encapsule les paquets IP normaux dans un format sécurisé, les paquets 
n'apparaissent plus comme des paquets TCP (Transmission Control Protocol) et UDP (User 
Datagram Protocol) lorsqu'ils transitent sur le réseau. La tentative de déploiement d'IPSec dans le cas 
de la Woodgrove Bank a montré que la plupart des outils de gestion réseau considéraient que les 
applications pouvaient être directement identifiées par leur numéro de port TCP ou UDP (par exemple, 
le port 25 pour le trafic de la messagerie électronique et le port 80 pour le trafic Web). Lorsque vous 
utilisez IPSec, le trafic devient plus complexe et les routeurs et le système de détection des intrusions 
réseau ne parviennent ni à identifier les applications en cours d'utilisation ni à inspecter les données 
du paquet. Ce facteur crée un problème de gestion réseau, car il déprécie la valeur des outils 
actuellement utilisés pour surveiller le trafic, filtrer la sécurité, mettre en file d'attente de façon juste et 
pondérée, et classer la qualité des services.

Malheureusement, cette hypothèse sur la visibilité du trafic n'est pas tout à fait juste et devient même 
rapidement obsolète, même sans utiliser IPSec. La relation entre les numéros de port et les 
applications est de plus en plus fine. Il est par exemple possible d'exécuter un serveur Web sur un 
numéro de port arbitraire et d'indiquer le numéro de port dans l'URL du site. Il est également possible 
de contourner les efforts de filtrage de messagerie électronique entrepris par certains fournisseurs 
d'accès Internet (FAI), en exécutant un service de messagerie sur un numéro de port différent. Un 
grand nombre d'applications homologue­à­homologue (P2P) sont astucieuses dans la gestion des 
ports. Elles choisissent en réalité des numéros de port au hasard pour éviter d'être détectées. Les 

38
applications basées sur les services d'appel de procédure distante (RPC) sont également habiles 
dans la gestion des ports. En effet, les services RPC choisissent au hasard des numéros de port 
éphémères (supérieurs à 1024) pour différents services.

L'utilisation croissante de services Web va très probablement accélérer les problèmes d'identification 
du trafic, car le trafic pour ces services s'exécute au­dessus du protocole HTTP ou HTTPS, via le 
port 80 ou 443. Les clients et les serveurs utilisent ensuite l'URL HTTP pour identifier le trafic. Toutes 
les applications déplacées vers une architecture de services Web apparaissent comme un flux de 
données indifférencié unique pour les routeurs, car le trafic de ces services Web est exécuté sur un 
seul port ou sur un petit nombre de ports. Chaque application ou service n'est pas exécuté sur un 
numéro de port distinct. L'utilisation de SSL et de TLS pour les connexions HTTPS et le chiffrement 
RPC déprécie la valeur de l'inspection du réseau en tant que dispositif de défense contre les attaques. 
Comme les applications de gestion réseau étaient toujours capables d'analyser les adresses des 
paquets et qu'elles bénéficiaient d'une visibilité suffisante pour tous les autres trafics non protégés par 
IPSec, la Woodgrove Bank a décidé que la perte de certaines fonctionnalités de gestion réseau n'était 
pas suffisamment significative pour modifier les plans de ce projet. En outre, certains fournisseurs 
d'outils de gestion réseau souhaitaient modifier leurs outils pour analyser les formes non chiffrées de 
paquets IPSec.

La plupart des applications basées sur l'hôte n'ont pas besoin d'être modifiées pour fonctionner 
correctement alors qu'IPSec sécurise l'ensemble du trafic entre les adresses IP. L'objectif de cette 
solution n'est pas d'utiliser IPSec uniquement pour des applications ou des protocoles spécifiques, car 
il existe des risques d'attaque réseau sur d'autres services réseau. Si des applications ne fonctionnent 
pas correctement avec IPSec, l'administrateur a la possibilité d'autoriser ce trafic sans la protection 
IPSec et en fonction des adresses IP utilisées pour les serveurs. Il n'est pas recommandé d'autoriser 
des applications en fonction d'un port connu car cela ouvre une brèche d'entrée statique aux 
personnes malveillantes qui peuvent ainsi établir des connexions entrantes sur n'importe quel port 
ouvert, annihilant de ce fait l'objectif de l'isolation. Les applications qui utilisent des ports alloués 
dynamiquement ne peuvent pas être autorisées sans protection IPSec. Les applications qui utilisent 
l'adressage IP de multidiffusion et de diffusion risquent de rencontrer des problèmes avec IPSec dans 
le cadre de l'isolation de serveurs et de domaines. Windows IPSec peut autoriser tout le trafic de 
multidiffusion et de diffusion, à l'exception de certains types. Si vous rencontrez des problèmes de 
compatibilité avec certaines applications, renseignez­vous auprès du fournisseur de l'application 
concernée pour savoir si un correctif ou une mise à niveau est disponible pour résoudre ce problème. 
Si l'application ne peut pas être mise à jour ou remplacée par une application qui serait compatible, 
les ordinateurs qui doivent utiliser cette application risquent de ne pas pouvoir être intégrés dans 
l'isolation de domaines ou de groupes.

Outre ses fonctionnalités d'authentification, IPSec offre également deux autres services très utiles de 
communication hôte : la vérification de l'intégrité des adresses et le chiffrement du trafic réseau.

• Vérification de l'intégrité des adresses. IPSec peut utiliser des en­têtes d'authentification (AH) 
pour assurer l'intégrité des données et des adresses pour chaque paquet. Les AH de Windows 
utilisent un mécanisme de hachage avec clé dans le pilote Windows IPSec. L'utilisation des AH 
permet d'éviter que des attaques par relecture ne se produisent, et elle offre une intégrité renforcée 
en confirmant qu'aucun des paquets reçus n'a été modifié, de l'envoi à la réception effective. Un 
AH ne fonctionnera pas correctement s'il passe par un périphérique qui effectue une traduction 
d'adresses réseau (NAT), car la technologie NAT remplace l'adresse source dans l'en­tête IP, 
violant ainsi la sécurité mise en place par IPSec AH.

• Chiffrement du trafic réseau. IPSec assure la confidentialité et l'intégrité des données grâce au 
chiffrement, en utilisant l'option d'encapsulation de charge utile de sécurité (ESP) pour le protocole 
IP. Bien que l'ESP n'assure pas l'intégrité des adresses (sauf lorsqu'elle est utilisée avec les AH), il 
est possible de faire en sorte qu'elle traverse avec succès un périphérique NAT en utilisant une 
encapsulation UDP. Si les réseaux internes sont segmentés avec des périphériques qui utilisent 
NAT, l'ESP est le choix logique qui s'impose car l'encapsulation de charge utile de sécurité 

39
 n'impose pas le chiffrement des paquets. Windows IPSec prend en charge RFC 2410, qui définit 
l'utilisation de l'ESP avec chiffrement nul (ESP/null). ESP/null permet d'assurer l'authentification, 
l'intégrité et l'anti­relecture des données, sans requérir de chiffrement. Le Moniteur réseau de 
Windows Server 2003 est capable d'analyser une ESP non chiffrée pour exposer les protocoles de 
niveau supérieur TCP/IP normaux. Si le chiffrement ESP est utilisé, la surveillance des paquets 
n'est possible que si l'ordinateur utilise une carte réseau d'accélération matérielle IPSec, qui 
déchiffre d'abord les paquets entrants.

Remarque : l'ESP avec chiffrement ou utilisant le chiffrement null permet des relations poste à poste 
IPSec renforcées avec authentification, tout comme les en­têtes d'authentification. Elle offre 
également une protection contre les relectures et peut traverser correctement un périphérique NAT. 
Pour ces raisons, la Woodgrove Bank a choisi de ne pas implémenter d'en­tête d'authentification. Elle 
utilise uniquement ESP/null et ESP avec chiffrement sur son réseau d'entreprise.

IPSec peut fonctionner dans les deux modes suivants : le mode de tunnel et le mode de transport :

• Mode de transport IPSec. Le mode de transport IPSec est l'option recommandée pour sécuriser 
le trafic entre des hôtes de bout en bout. Le pilote IPSec ajoute simplement un en­tête IPSec après 
l'en­tête IP d'origine. L'en­tête IP d'origine est conservé et les paquets restants sont sécurisés via 
un processus de chiffrement AH ou ESP. Les filtres IPSec contrôlent le trafic bloqué, autorisé ou 
encapsulé par IPSec. Les filtres IPSec spécifient les adresses IP (ou sous­réseaux) source et 
destination, le protocole (ICMP ou TCP, par exemple) et les ports source et de destination. Les 
filtres peuvent donc s'appliquer spécifiquement à un ordinateur ou à tous les protocoles et 
adresses de destination possibles. Le mode de transport avait été conçu pour les adresses IP 
dynamiques, en mettant à jour automatiquement les filtres configurés avec « Mon adresse IP ». Il 
est moins surchargé et, dans l'ensemble, plus simple à utiliser que le mode de tunnel IPSec. Le 
mode de transport de négociation IKE constitue un moyen efficace d'autorisatio n des co nnexions 
entrantes protégées par IPSec. Les problèmes liés à l'utilisation du mode de transport IPSec sont 
les suivants :
• Délai initial. Il doit s'écouler de une à deux secondes avant qu'IKE ne puisse lancer et réaliser 
une négociation complète réussie. Alors que la communication est en cours, IKE tente 
d'actualiser les clés de chiffrement qui protègent automatiquement le trafic.
• Ordre de priorité prédéfini des filtres. Les filtres de stratégie IPSec peuvent se chevaucher et 
ainsi suivre un ordre de priorité prédéfini, le plus spécifique en premier. Pour cela, les deux 
parties en communication doivent posséder, pour la négociation IKE, un ensemble de filtres de 
mode de transport IPSec compatibles. Par exemple, cette solution utilise un filtre plus général 
pour « tout le trafic » qui négocie la sécurité IPSec et un filtre plus spécifique pour autoriser 
uniquement le trafic ICMP plutôt que de sécuriser ce trafic avec IPSec.
• Consommation importante de puissance de calcul. Le chiffrement du mode de transport 
ESP IPSec peut consommer énormément de puissance de calcul. La copie d'un fichier chiffré 
peut nécessiter l'utilisation de 80 à 100 % des ressources de processeur. Windows 2000, 
Windows XP et Windows Server 2003 possèdent des interfaces de cartes réseau qui 
permettent d'accélérer au niveau matériel les opérations de chiffrement IPSec.

• Mode de tunnel IPSec. Le mode de tunnel IPSec est en général utilisé pour les tunnels VPN de 
passerelle à passerelle entre des adresses IP statiques de passerelles VPN. Le mode de tunnel 
crée un nouvel en­tête IP avec un en­tête IPSec. Le paquet d'origine doté de l'en­tête IP d'origine 
est encapsulé intégralement pour former un paquet tunnel. Dans les scénarios de l'isolation de 
serveurs et de domaines, le mode de tunnel peut être utilisé pour sécuriser le trafic d'un serveur IP 
statique vers un routeur prenant en charge IPSec. Cela peut même s'avérer nécessaire si l'hôte de 
destination ne prend pas en charge IPSec. La Woodgrove Bank n'a pas utilisé de scénario 
nécessitant l'utilisation du mode de tunnel.

40
Pour plus d'informations techniques sur le mode de transport et le mode de tunnel dans IPSec, 
reportez­vous à la section « Determining Your IPSec Needs   » (Détermination de vos besoins 
IPSec) du chapitre « Deploying IPSec » (Déploiement d'IPSec) dans la partie « Deploying Network 
Services » (Déploiement de services réseau) du Kit de déploiement de Windows Server 2003, à 
l'adresse www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/
en­us/dnsbj_ips_wclw.asp.

Autorisation de l'hôte

Lorsque l'hôte a déterminé que la communication qu'il reçoit provient d'une source vérifiable, il doit 
déterminer s'il doit ou non autoriser l'accès à l'ordinateur source et à l'utilisateur. Cela est très 
important car ce n'est pas parce qu'un périphérique peut être authentifié qu'il sera pour autant autorisé 
à accéder à un hôte donné.

L'approche que recommande Microsoft consiste à utiliser des groupes Windows standards afin de 
limiter les possibilités d'accès des utilisateurs et des ordinateurs aux ressources des autres 
ordinateurs de l'organisation. Cette méthode crée une nouvelle couche d'autorisation pour les 
comptes ordinateur et utilisateur au niveau de la couche réseau et application en utilisant les 
autorisations des attributions des droits de l'utilisateur de la stratégie locale sur l'hôte auquel l'accès 
doit être accordé. En utilisant les attributions des droits de l'utilisateur « Accéder à cet ordinateur à 
partir du réseau » (AUTORISER) et « Interdire l'accès à cet ordinateur à partir du réseau » 
(REFUSER), il est possible de restreindre l'accès d'un ordinateur ou d'un utilisateur à une ressource, 
même s'ils partagent des paramètres de stratégie IPSec communs et si l'utilisateur connecté possède 
le droit d'accéder à la ressource. Ce niveau de contrôle supplémentaire est fondamental dans 
l'approche de l'isolation présentée dans cette solution.

Les privilèges des groupes d'Active Directory classent les ordinateurs et les utilisateurs de telle sorte 
qu'il est possible d'assigner les niveaux d'autorisation requis de façon simple et évolutive. Pour faciliter 
la distinction entre les groupes créés spécifiquement pour obtenir l'autorisation d'accès à l'hôte et les 
groupes bénéficiant d'autorisations d'accès standard au partage, ce guide utilise le terme groupes  
d'accès réseau.

La figure suivante illustre les principales étapes du processus global d'autorisation hôte/utilisateur de 
la solution.

41
Figure 2.2 Processus d'autorisation utilisateur/hôte

Le processus en cinq étapes (détaillées ci­après) illustré par la figure 2.2 est suivi pour toutes les 
communications réseau, une fois la solution d'isolation en place.

1. Un utilisateur tente d'accéder à un partage situé sur un serveur départemental. Un 
utilisateur connecté à l'ordinateur client tente d'accéder à un partage sur un hôte approuvé, 
dans la solution d'isolation logique. L'ordinateur client tente donc de se connecter à l'hôte 
approuvé en utilisant le protocole de partage de fichiers (en général, le protocole SMB, via le 
port de destination TCP 445). Dans le cadre de la solution, une stratégie IPSec est affectée au 
client. La requête de connexion TCP sortante lance une négociation IKE vers le serveur. Le 
client IKE obtient un ticket Kerberos lui permettant d'être authentifié par le serveur.
2. Négociation de mode principal IKE. Lorsque le serveur reçoit la requête de communication 
IKE initiale émise par l'ordinateur client, il procède à l'authentification du ticket Kerberos. 
Pendant le processus d'authentification, IKE vérifie que l'ordinateur client possède les droits 
d'accès à l'hôte requis, qui doivent être conformes aux droits d'utilisateurs AUTORISER ou 
REFUSER de la stratégie de groupe. Si l'ordinateur client possède l'attribution des droits 
utilisateur requise, la négociation IKE se termine et une association de sécurité en mode 
principal IPSec est établie.
3. Négociation de la méthode de sécurité IPSec. Une fois la négociation de l'association de 
sécurité en mode principal IKE terminée, les méthodes de sécurité de la stratégie IPSec sont 
vérifiées afin de négocier une connexion en utilisant les méthodes de sécurité des 
associations de sécurité IPSec acceptables par les deux hôtes.

L'organigramme suivant illustre le processus complet de l'étape 2 à l'étape 3 :

42
Figure 2.3 Processus de vérification des autorisations d'accès à l'hôte de l'ordinateur

4. Vérifications des autorisations d'accès à l'hôte de l'utilisateur. Une fois la communication 
protégée par IPSec établie, le protocole SMB procède à l'authentification en utilisant le compte 
utilisateur du client. Sur le serveur, le compte utilisateur est analysé pour vérifier qu'il bénéficie 
bien des autorisations d'accès à l'hôte requises, qui doivent être conformes aux droits 
d'utilisateurs AUTORISER et REFUSER de la stratégie de groupe pour l'hôte approuvé. Le 
diagramme suivant illustre ce processus :

43
Figure 2.4 Processus de vérification des autorisations d'accès à l'hôte de l'utilisateur.

Si le compte d'utilisateur bénéficie de l'attribution des droits utilisateur requise, le processus se 
termine et le jeton de connexion utilisateur est créé. Une fois ce processus terminé, les vérifications de 
sécurité de la solution d'isolation logique sont terminées.

5. Vérifications des autorisations d'accès aux fichiers et au partage. Enfin, le serveur vérifie 
les autorisations d'accès aux fichiers et au partage Windows standard pour contrôler que 
l'utilisateur est membre d'un groupe bénéficiant des autorisations requises pour accéder aux 
données demandées par l'utilisateur.

L'utilisation de groupes d'accès réseau permet de bénéficier d'un niveau de contrôle très élevé dans la 
solution.

Le scénario suivant donne un exemple pratique des étapes de la solution d'isolation logique :

Au cours d'une réunion, une sous­traitante connecte son ordinateur portable à un point de connexion 
d'une salle de réunion, pour copier des données sur un partage situé sur le serveur RH d'un employé. 
Dominique, membre du service des RH, indique au sous­traitant le chemin d'accès au partage du 
serveur RH. Comme l'ordinateur portable du sous­traitant n'est pas un hôte connu ou approuvé, le 
service informatique ne gère pas l'ordinateur et le niveau de sécurité mis en place dans l'ordinateur 
portable n'est pas connu. Par conséquent, il est possible que les fichiers contiennent un logiciel 
malveillant susceptible d'infecter les ordinateurs internes. Lorsque l'ordinateur du sous­traitant tente 
de se connecter au serveur RH, les ordinateurs échouent à l'étape 2 du processus. Les ordinateurs ne 
peuvent pas négocier une association de sécurité en mode principal IKE car l'ordinateur portable n'est 
pas en mesure de fournir le ticket Kerberos requis pour permettre la vérification des informations 
d'identification de l'ordinateur. L'ordinateur portable n'appartient pas à un domaine approuvé. Les 
exigences de la stratégie IPSec du groupe d'isolation auquel appartient le serveur RH n'autorisent pas 
le serveur à communiquer avec un hôte qui n'utilise pas IPSec. Par conséquent, toutes les tentatives 

44
de communication émises par cet ordinateur non approuvé sont bloquées. En résumé, la solution 
d'isolation logique aide à protéger l'infrastructure informatique des menaces que peuvent représenter 
des ordinateurs non approuvés et non gérés, même lorsque ceux­ci bénéficient d'un accès physique 
au réseau interne.

Cet exemple explique comment implémenter l'isolation selon une approche hôte par hôte. La 
proposition d'une isolation à des coûts administratifs réduits fait également partie des exigences 
importantes de la solution. Il est possible de regrouper des ordinateurs, tout comme cela est possible 
pour les utilisateurs, puis d'attribuer à ces groupes les droits d'utilisateur AUTORISER ou REFUSER 
dans toutes les stratégies locales des ordinateurs. Cette approche est toutefois difficile à gérer et 
n'évolue pas correctement sans utiliser la fonction de centralisation de la stratégie de groupe et 
d'Active Directory, et sans une compréhension solide des chemins de communication requis. En 
outre, cette approche seule ne permet pas de réaliser une authentification fiable ou de chiffrer les 
données. Lorsque ces autorisations d'accès à l'hôte sont associées à IPSec et que les hôtes sont 
organisés dans des groupes d'isolation, les relations entre les groupes sont plus claires et les chemins 
de communication, plus faciles à définir (une fois les exigences clairement répertoriées). Pour plus 
d'informations sur la configuration et la structure des groupes d'isolation, reportez­vous au chapitre 4, 
« Conception et planification de groupes d'isolation ».

De quoi nous protège l'isolation de serveurs et 
domaines ?
L'isolation de serveurs et de domaines consiste à mettre en place des limites de communication entre 
des ordinateurs et d'autres ordinateurs ou périphériques tentant d'établir les communications. Ces 
limites ou frontières permettent de limiter les communications en définissant le niveau auquel un 
périphérique est considéré comme approuvé. La mise en place de limites comme l'authentification, 
l'autorisation et l'emplacement réseau autour d'un hôte en utilisant une stratégie IPSec est un 
excellent moyen de réduire bon nombre de menaces. IPSec ne constitue pas une stratégie de 
sécurité complète mais ajoute une couche de protection supplémentaire dans une stratégie de 
sécurité globale.

La section suivante présente des menaces types et évoque brièvement la modélisation des menaces. 
Pour plus d'informations sur les périphériques approuvés dans le scénario de Woodgrove Bank et sur 
le processus de conception utilisé par la Woodgrove Bank pour identifier et classer les ordinateurs 
comme dignes de confiance, reportez­vous à la section « Définition de l'approbation » du chapitre 3 
« Détermination de l'état actuel de votre infrastructure informatique ».

Modélisation et classification des menaces

Ces dernières années, les attaques ciblant les applications et serveurs réseau sont devenues de plus 
en plus fréquentes et complexes. Ce qui est intéressant, c'est que les styles et types d'attaque ainsi 
que les méthodes élémentaires permettant de les déjouer n'ont pas véritablement évolué. Certaines 
fonctions et méthodes d'implémentation de ces défenses sont toutefois différentes. Pour être en 
mesure de déterminer la planification que requiert une solution d'isolation de serveurs et de domaines, 
votre organisation doit d'abord entreprendre une analyse détaillée des risques de menace présents et 
comprendre comment déjouer ces risques en faisant appel à plusieurs technologies et processus.

Les processus permettant d'identifier, de classer et de répertorier les menaces encourues par une 
organisation sont à l'heure actuelle bien connus. Cette documentation présente une méthodologie 
pouvant être utilisée pour la modélisation des menaces commerciales, environnementales et 
techniques communes auxquelles doivent faire face les organisations. Pour la modélisation de la 
menace, Microsoft utilise la méthode STRIDE. STRIDE représente les catégories de menace contre 
lesquelles se protéger. Ces catégories sont les suivantes :

45
S    usurpation

T    falsification

R    répudiation

I     divulgation d'informations

D    refus de service

E    élévation de privilèges

Il est primordial de consacrer le temps et les ressources nécessaires à la définition, la plus précise 
possible, d'un modèle de menace, pour assurer la protection de toutes les ressources à protéger. 
Pour obtenir plus d'informations sur les menaces et attaques spécifiques que l'isolation de serveurs et 
de domaines aide à limiter, reportez­vous à l'annexe D, « Catégories de menaces informatiques », de 
ce guide. Pour une présentation détaillée des modèles de menace, reportez­vous au chapitre 2, 
« Defining the Security Landscape » (Définition du paysage de sécurité), de la solution Microsoft  
 Solution for Securing Windows    2000    Server    pouvant être téléchargée à l'adresse suivante : 
www.microsoft.com/technet/security/prodtech/
win2000/secwin2k/02defsls.mspx.

Comment déployer l'isolation de serveurs et de 
domaines ?
Lorsque vous avez pris connaissance des menaces auxquelles doit faire face votre organisation et 
que vous avez compris comment la solution permet de réduire ces risques, étudiez un déploiement 
possible de la solution. Cette section décrit le processus de déploiement.

Collecte d'informations

Avant même de commencer le processus de conception, vérifiez que vous disposez d'une 
représentation à jour et précise de l'état actuel du réseau de votre organisation, notamment des 
configurations des stations de travail et serveurs, et des chemins de communication. Il est impossible 
de développer une solution d'isolation logique efficace sans connaître de façon précise les éléments 
que la solution doit protéger.

Le chapitre 3, « Détermination de l'état actuel de votre infrastructure informatique », décrit de façon 
détaillée les moyens qui vous permettent d'obtenir des informations sur l'état actuel de votre réseau et 
sur les périphériques qui y sont connectés. Ce processus fournit toutes les informations requises dans 
les chapitres suivants de cette solution et offre un grand intérêt pour les autres projets entrepris dans 
l'organisation. Ce processus permet avant tout à l'organisation d'analyser et d'examiner avec soin les 
chemins de communication requis pour ses systèmes d'information et d'effectuer des choix judicieux 
quant aux compromis éventuels sur les risques, les exigences de communication et les exigences de 
l'entreprise.

Présentation du processus de déploiement d'IPSec 

Lorsque vous avez choisi et créé une conception, vous devez mettre en place un processus 
d'implémentation de cette conception dans l'organisation, de sorte que l'implémentation soit gérable et 
qu'elle ait peu de répercutions sur les utilisateurs. Le chapitre 4, « Conception et planification de 

46
groupes d'isolation », présente de façon détaillée plusieurs approches dont vous pouvez vous inspirer. 
Le processus élémentaire peut être résumé comme suit :

Tester la conception et les stratégies IPSec dans un laboratoire de validation technique. Testez 
les stratégies IPSec envisagées dans un environnement hors production, isolé, pour vous assurer que 
la conception fonctionne comme prévu et pour tester les problèmes susceptibles de survenir dans les 
paramètres de la stratégie ou dans les mécanismes de déploiement.
1. Expérimenter la configuration testée et approuvée. Lorsque l'équipe est convaincue que la 
conception fonctionne comme prévu dans l'environnement du laboratoire, l'étape suivante du 
processus consiste à identifier dans un environnement de production un petit nombre 
d'ordinateurs à inclure dans un déploiement expérimental de la solution. Pour s'assurer que 
les problèmes susceptibles de survenir pendant le test auront le moins d'impact possible sur 
l'activité des utilisateurs, un support préventif doit être dispensé aux ordinateurs et aux 
utilisateurs identifiés.
2. Implémenter un déploiement progressif de la solution. La dernière étape du processus 
consiste à planifier le déploiement de la conception pour l'ensemble de l'organisation. Ce 
processus est très important ! Vous devez être extrêmement prudent lorsque vous planifiez 
cette étape. Il est possible de mettre en œuvre (après la simple modification d'un paramètre de 
la stratégie IPSec) une conception qui peut priver bon nombre d'ordinateurs de l'accès aux 
ressources réseau. Testez et organisez votre plan de déploiement pour que les modifications 
introduites par la solution soient implémentées de sorte qu'il soit possible de retrouver 
rapidement un état de fonctionnement satisfaisant, au cas où une erreur de conception ou de 
configuration n'aurait pas été détectée lors de la phase de test.

Le chapitre 4, « Conception et planification de groupes d'isolation », donne des informations détaillées 
sur le processus de conception de domaines d'isolation et présente des options de déploiement 
progressif de la solution.  

Résumé
Ce chapitre décrit les objectifs et les processus de la solution présentée dans ce guide. Depuis de 
nombreuses années déjà, les professionnels de l'informatique ont compris les avantages d'IPSec, 
toutefois, en raison de la nature complexe de cette technologie, rares en sont les implémentations. 
L'implémentation d'IPSec peut entraîner de graves problèmes si la solution ne bénéficie pas d'une 
conception solide, d'un déploiement parfaitement planifié et d'une méthodologie de test fiable.

Les informations présentées dans ce chapitre montrent que l'isolation logique est une couche de 
sécurité supplémentaire qui exploite les techniques d'isolation de serveurs et de domaines, et les 
fonctions de la plate­forme Windows, d'IPSec, des stratégies de groupe et d'Active Directory pour 
constituer une solution d'entreprise gérable et évolutive, capable de réduire les risques auxquels sont 
exposées les données.

Les informations présentées dans les chapitres suivants mettent l'accent sur les étapes requises pour 
la planification et l'implémentation de la solution. Le chapitre 6, « Gestion d'un environnement 
d'isolation de serveurs et de domaines », présente des procédures à implémenter dans le cadre du 
fonctionnement quotidien d'un environnement d'exploitation utilisant l'isolation de serveurs et de 
domaines. Le chapitre 7, « Dépannage d'IPSec », contient des informations relatives à la prise en 
charge et au dépannage d'IPSec.

47
Chapitre 3 : Détermination de l'état 
actuel de votre infrastructure 
informatique
Ce chapitre explique comment obtenir les informations nécessaires à la planification et au 
déploiement d'une solution d'isolation de serveurs et de domaines. Un déploiement réussi exige une 
connaissance à jour et précise de votre infrastructure informatique. Après avoir lu le présent chapitre, 
vous serez parfaitement au fait des informations nécessaires à la mise en place d'une solution 
d'isolation de serveurs et de domaines.

La dernière partie du chapitre explique comment maîtriser et documenter les ordinateurs identifiés et 
susceptibles de fonctionner comme ordinateurs « approuvés » au sein de la solution. Ces informations 
seront utiles à l'équipe chargée de la mise en place de la solution au moment de planifier cette 
dernière.

Connaissances préalables requises pour ce chapitre
Avant d'exploiter les informations contenues dans ce chapitre, assurez­vous que vous et votre 
organisation respectez les exigences suivantes. Les instructions fournies dans ce chapitre sont 
spécifiquement adaptées aux besoins d'une organisation répondant de manière stricte à ces 
exigences. L'absence de conformité à l'ensemble des conditions requises n'a pas nécessairement un 
impact négatif sur votre projet mais en respectant ces exigences, vous donnerez d'autant plus de 
valeur aux instructions qui vous sont fournies.

Connaissances requises

Vous devez être familiarisé avec les concepts liés à IPSec et disposer de connaissances solides dans 
les domaines suivants :

• Authentification Microsoft® Windows® (plus précisément, le protocole d'authentification Kerberos 
version 5)

• Concepts relatifs au service d'annuaire Active Directory® (notamment les outils et la structure 
Active Directory), la manipulation d'utilisateurs, de groupes et d'autres objets Active Directory et 
enfin l'utilisation de la stratégie de groupe

• Sécurité du système Windows, notamment les concepts de sécurité, tels que les utilisateurs, les 
groupes, l'audit et les listes de contrôle d'accès

• Conventions système d'attribution de noms de l'organisation
• Emplacements physiques et logiques de l'organisation
• Méthodes de gestion des risques adoptées dans l'organisation
• Concepts réseau clés, notamment le filtrage de port à l'aide de pare­feu  

Avant de poursuivre la lecture de ce chapitre, lisez également les chapitres précédents de ce guide 
pour bien comprendre les concepts de la solution proposée en termes d'architecture et de conception.

48
Conditions requises pour l'organisation

En règle générale, la planification de groupes d'isolation dans une organisation implique plusieurs 
intervenants aux compétences diverses. Les informations nécessaires à une évaluation rigoureuse 
des exigences proviennent souvent de diverses sources disséminées dans l'organisation. Vous devez 
consulter les membres de votre organisation susceptibles de participer au processus de planification 
de ces groupes, notamment les personnes suivantes :

• les cadres exécutifs ;
• les personnes chargées de l'audit et de la sécurité ;
• les ingénieurs, les administrateurs et les équipes opérationnelles Active Directory ;
• les propriétaires d'applications, de serveurs Web et de domaines DNS (Domain Name System) ;
• le personnel des opérations et d'administration réseau ;
• le personnel de formation et d'assistance interne.  

Remarque : selon la structure de votre organisation informatique, ces rôles peuvent être remplis par 
plusieurs personnes, ou une même personne peut remplir plusieurs rôles.

Outre les informations recueillies auprès des personnes citées ci­avant, un point crucial à retenir est la 
mise à jour des pratiques opérationnelles actuellement en vigueur avec l'introduction d'IPSec dans 
l'environnement concerné. Il est possible que des composants logiciels et matériels, notamment le 
BIOS et les microprogrammes des périphériques réseau, exigent aussi une mise à jour. Enfin, des 
outils réseau supplémentaires seront peut­être nécessaires afin de faciliter la prise en charge et le 
dépannage de l'environnement IPSec.

Configuration requise pour l'infrastructure informatique

Ce chapitre part également du principe que l'infrastructure informatique suivante est disponible :

• Un domaine Microsoft Windows Server™ 2003 Active Directory fonctionnant en mode mixte ou 
natif. Cette solution utilise des groupes universels pour l'application des objets Stratégie de groupe 
(GPO). Si l'organisation ne fonctionne pas en mode mixte ou natif, il reste possible d'appliquer 
l'objet Stratégie de groupe à l'aide de configurations de groupes locaux et globaux standards. 
Cependant, cette option étant plus complexe à gérer, cette solution ne l'utilise pas.
Remarque : Windows Server 2003 a introduit un certain nombre d'améliorations qui affectent les 
stratégies IPSec. Aucune spécificité de cette solution ne l'empêche de fonctionner avec 
Windows 2000. Cependant, la solution n'a été testée qu'avec Windows Server 2003 Active Directory.
Pour plus d'informations sur les améliorations apportées à IPSec dans Windows Server 2003, 
reportez­vous à la page New features for IPSec   (Nouvelles fonctionnalités d'IPSec) sur le site Web 
de Microsoft à l'adresse 
www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en­
us/ipsec_whatsnew.asp.

• Les outils et les compétences requis pour surveiller le réseau, analyser les données de 
surveillance et prendre des décisions de planification de capacité sur la base de ces données.
Remarque : l'usage des outils de surveillance réseau est soumis à des restrictions dans de 
nombreuses organisations. Soyez vigilant et assurez­vous que les procédures opérationnelles suivies 
lors de l'utilisation de ces outils sont les bonnes.

49
• Un outil déjà installé et capable de recueillir des données de configuration réseau sur les hôtes du 
réseau. Par exemple, vous pouvez faire appel à des systèmes de gestion des ressources pour 
collecter ces informations. Pour plus d'informations, consultez la section « Détection d'hôtes » plus 
loin dans ce chapitre.

À qui s'adresse ce chapitre
Ce chapitre s'adresse aux professionnels informatiques chargés de créer l'infrastructure informatique 
que les architectes et les concepteurs de solutions utiliseront. Ces professionnels sont généralement 
des membres du personnel du support ou des opérations de l'organisation concernée. Pour tirer le 
meilleur parti des informations figurant dans ce chapitre, vous devez disposer d'un bon de niveau de 
connaissance technique des outils et des technologies impliqués dans le processus de recueil des 
informations ainsi que de l'infrastructure actuelle de l'organisation.

Analyse de l'état actuel
Recueillir et tenir à jour des données fiables sur les ordinateurs, les logiciels et les périphériques 
réseau d'une organisation est un défi informatique classique. La réussite d'un projet dépend des 
informations relevées au cours de ce processus. Avant d'entamer la planification d'un projet d'isolation 
de serveurs et de domaines, vous devez recueillir et analyser des données mises à jour sur les 
ordinateurs, le réseau et les services d'annuaire déjà déployés au sein de l'organisation. Ces données 
vous permettront de concevoir une solution qui tient compte de tous les éléments possibles de 
l'infrastructure existante. Si les informations recueillies manquent de précision, des problèmes liés à 
des périphériques et des ordinateurs non pris en compte au cours de la phase de planification 
peuvent survenir lors de l'implémentation. Les sections suivantes décrivent les informations requises 
dans chaque domaine et fournissent des exemples issus des informations recueillies dans le cadre de 
la solution d'isolation de serveurs et de domaines développée pour la Woodgrove Bank.

Détection réseau

L'aspect le plus primordial de la planification d'une solution d'isolation de serveurs et de domaines est 
l'architecture réseau, puisque le protocole de sécurité IPSec intervient au niveau du protocole Internet 
(IP). Une maîtrise partielle ou erronée du réseau se traduira par l'échec de toute solution d'isolation. 
La compréhension de l'agencement des sous­réseaux, des schémas d'adressage IP et des modèles 
de trafic est une condition qui participe à cet effort mais les deux composants suivants sont 
indispensables pour mener à terme la phase de planification du projet :

• Documentation de la segmentation du réseau
• Documentation du modèle de trafic réseau actuel

L'objectif recherché est de disposer de suffisamment d'informations pour identifier une ressource en 
fonction de son emplacement sur le réseau, en plus de son emplacement physique.

Il est préférable de débuter avec une architecture réseau soigneusement pensée, dotée de plages 
d'adresses facilement identifiables et du nombre le plus réduit possible de chevauchements ou de 
plages discontinues. Il est possible que certains impératifs commerciaux ou circonstances (par 
exemple, dans le cas de fusions et d'acquisitions) ne permettent pas la mise en place d'un réseau 
« rationalisé » mais en prenant soin de documenter et de comprendre l'état actuel, vous faciliterez 
votre travail d'identification du réseau et des ressources qu'il gère. N'utilisez pas un réseau complexe 
et mal documenté comme point structurel de départ ; il risque de laisser un trop grand nombre de 
domaines non identifiés susceptibles de causer des problèmes lors de l'implémentation.

50
Ces instructions sont un moyen d'obtenir les informations les plus pertinentes pour la planification 
d'une solution d'isolation de serveurs et de domaines mais n'ont pas pour vocation de chercher à 
résoudre d'autres problèmes, notamment les questions de masque de sous­réseau de longueur 
variable et d'adressage TCP/IP, de segmentation de réseau local virtuel (VLAN) ou d'autres méthodes 
et techniques d'optimisation des réseaux. Les informations obtenues servent à formuler les 
composants opérationnels et d'implémentation de la solution d'isolation de serveurs et de domaines.

Documentation de la segmentation du réseau

Si l'architecture actuelle de votre organisation n'est pas documentée et disponible en guise de 
référence, vous devez vous procurer les documents nécessaires dès que possible avant de 
poursuivre la mise en œuvre de la solution. Si les informations documentées ne sont pas à jour ou 
n'ont pas été récemment validées, deux options simples vous sont proposées :

• Accepter le fait que les informations exposent le projet à des risques.
• Engager un processus de détection et de découverte, soit manuellement, soit par le biais d'un outil 
d'analyse réseau capable de fournir les informations nécessaires à la documentation de la 
topologie réseau actuelle.

Les informations requises peuvent être présentées de différentes façons, mais une série de 
représentations schématiques s'avère souvent la méthode la plus efficace pour illustrer et expliquer la 
configuration actuelle du réseau. Lorsque vous créez le schéma d'un réseau, évitez d'y insérer trop 
d'informations. Si nécessaire, utilisez plusieurs schémas illustrant différents niveaux de détail.

Prenons pour exemple le scénario imaginé pour la Woodgrove Bank. Le schéma créé et illustré ci­
dessous offre une vision détaillée de son réseau étendu et de l'environnement du site :

Figure 3.1 Réseau étendu et architecture du site de la Woodgrove Bank

51
Après avoir développé ce schéma, l'équipe de la Woodgrove Bank a entrepris de créer des schémas 
détaillés de chaque site, puis de chaque sous­réseau à l'intérieur de chaque site.

Tout en documentant votre réseau, vous rencontrerez peut­être des applications et des services 
réseau incompatibles avec IPSec. Parmi les risques d'incompatibilité actuels figurent les points 
suivants :

• Sur les routeurs, la technologie Cisco NetFlow ne peut pas analyser les paquets entre des 
membres IPSec à partir du protocole ou du port.

• La qualité de service (QoS) mise en place sur le routeur ne peut pas utiliser les ports ou les 
protocoles pour définir la priorité du trafic. L'utilisation d'adresses IP spécifiques reste néanmoins 
possible pour la hiérarchisation du trafic. Par exemple, tandis qu'une règle attribuant la priorité de 
« quiconque à quiconque utilisant le port 80 » ne fonctionnerait pas, une règle définissant une 
priorité de « quiconque à 10.0.1.10 » ne serait nullement affectée.

• Certains équipements ne prennent pas en charge ou n'autorisent pas le protocole IP 50, le port 
adopté par le protocole ESP (Encapsulating Security Payload).

• La technique WFQ (Weighted Fair Queuing) et d'autres méthodes de définition de la priorité du 
trafic sur routeur fondées sur le flux peuvent échouer.

• Les moniteurs réseau peuvent être incapables d'analyser les paquets ESP non chiffrés (ESP­Null).
Remarque : le Moniteur réseau Microsoft a ajouté un analyseur ESP à la version 2.1 destiné à 
faciliter la résolution des problèmes liés aux paquets IPSec non chiffrés. L'outil Moniteur réseau est 
fourni avec Microsoft Systems Management Server (SMS). Pour plus d'informations, consultez la 
page Microsoft Systems Management Server   sur le site www.microsoft.com/smserver/.

• Si le système ne peut pas procéder à une analyse ESP, aucune liste de contrôle d'accès (ACL) 
spécifiant des règles de port ou de protocole n'est traitée dans les paquets ESP.

• Si le système dispose d'un analyseur ESP et utilise le chiffrement, les listes de contrôle d'accès qui 
spécifient des règles de port ou de protocole ne sont pas traitées dans les paquets ESP.

IPSec annule la définition des priorités fondées sur le réseau et la gestion du trafic fondée sur les 
ports et les protocoles lorsque des ports et des protocoles sont utilisés. Il n'existe malheureusement 
aucune solution alternative pour les paquets chiffrés. Si la gestion du trafic ou la définition des priorités 
doit être fondée sur les ports ou le protocole, l'hôte lui­même doit être en mesure d'assumer ces 
fonctions de gestion du trafic et de hiérarchisation.

Enfin, il est primordial d'enregistrer avec exactitude les informations nécessaires pour les divers 
périphériques du réseau.

Périphériques de l'infrastructure réseau

Les périphériques qui composent l'infrastructure réseau (routeurs, commutateurs, équilibreurs de 
charge et pare­feu) communiquent avec IPSec après l'implémentation de la solution. C'est pourquoi il 
est primordial d'examiner les caractéristiques suivantes des périphériques du réseau pour s'assurer 
de leur capacité à gérer les exigences techniques et matérielles de la conception :

• Marque/modèle. Vous pouvez utiliser ces informations pour déterminer les fonctionnalités prises 
en charge par le périphérique. De plus, vérifiez le BIOS ou le logiciel exécuté sur le périphérique 
pour être certain qu'IPSec est pris en charge.

• Quantité de mémoire vive (RAM). Cette information peut être précieuse lorsque vous souhaitez 
évaluer la capacité ou l'impact d'IPSec sur le périphérique.

52
• Analyse du trafic. Ces informations (heure d'utilisation maximale et tendances quotidiennes et 
hebdomadaires indiquant le taux d'utilisation journalier du périphérique) peuvent toujours s'avérer 
utiles. En rapport avec IPSec, les informations fournies offrent un aperçu du périphérique et de son 
utilisation sur une période donnée. Si des problèmes surgissent après l'implémentation d'IPSec, 
ces mêmes informations peuvent permettre de déterminer si les causes sont liées à une utilisation 
intensive du périphérique.

• Listes de contrôle d'accès (ACL) affectant directement IPSec. Les listes de contrôle d'accès 
ont un impact direct sur la capacité de fonctionnement de certains protocoles. Par exemple, si vous 
n'autorisez pas le protocole Kerberos (protocole UDP (User Datagram Protocol) et port TCP 88) ou 
le protocole IP (le protocole, pas le port) 50 ou 51, IPSec ne fonctionnera pas. Les périphériques 
doivent également être configurés pour permettre la circulation du trafic IKE (UDP 500 et 4500) 
lorsque vous utilisez la traduction d'adresses réseau NAT­Traversal (NAT­T).

• Réseaux/sous­réseaux connectés à des interfaces de périphériques. Ces informations vous 
permettent d'effectuer la meilleure analyse possible de la structure du réseau interne. La définition 
des limites du réseau à partir d'une plage d'adresses est une opération simple et permet d'identifier 
si d'autres adresses sont non gérées ou étrangères au réseau interne (par exemple, les adresses 
Internet). Ces informations sont nécessaires pour les décisions de stratégies IPSec prises au cours 
des chapitres suivants du présent guide.

• Le périphérique autorise ou non la traduction d'adresses réseau (NAT). La traduction 
d'adresses réseau est fréquemment utilisée pour soumettre une plage d'adresses tout entière en 
tant qu'adresse IP unique à un réseau connecté ou à Internet. Le planificateur de solutions doit 
savoir où ce processus intervient sur le réseau.

Remarque : l'article 818043 de la Base de connaissances Microsoft, « Mise à jour NAT­T pour le 
 protocole L2TP et la sécurité IP dans Windows    XP et Windows    2000    » 
(http://support.microsoft.com/kb/818043) propose la fonctionnalité NAT­T en tant que correctif 
téléchargeable pour Windows XP Service Pack (SP) 1 et Windows 2000 SP4. En revanche, aucun 
répondeur IPSec ne fonctionnera correctement si vous n'avez pas installé Windows XP SP2 ou 
Windows Server 2003 SP1.

• Segmentation des réseaux locaux virtuels (VLAN). En déterminant le mode d'implémentation 
actuel des réseaux locaux virtuels (VLAN) sur le réseau, vous comprendrez mieux les modèles de 
trafic ou les exigences de sécurité existantes et pourrez déterminer comment IPSec augmentera 
ces exigences ou sera potentiellement amené à interférer avec elles.

• Liens de connexion du périphérique. Ces informations vous permettront de détecter les 
connexions que le périphérique entretient entre des réseaux spécifiques. Elles peuvent également 
être utilisées pour identifier le réseau logique et les connexions à divers emplacements d'une 
interface donnée.

• Taille de l'unité de transmission maximale (MTU) sur les interfaces des périphériques. 
L'unité de transmission maximale (MTU) désigne le plus grand datagramme qu'il est possible de 
transmettre sur une interface donnée sans le diviser en plus petites unités de transmission 
(processus également appelé « fragmentation »). Dans les communications IPSec, le MTU a pour 
but de déterminer les zones dans lesquelles la fragmentation aura lieu. Le routeur doit suivre la 
fragmentation des paquets afin de détecter le protocole ISAKMP (Internet Security Association and 
Key Management Protocol). IPSec configure la taille MTU de la session selon le MTU minimal 
détecté dans le chemin de communication utilisé, puis définit le bit DF (Do not Fragment) à 1.
Remarque : si la découverte du PMTU (Path MTU) est activée et fonctionne comme il se doit, vous 
n'avez pas besoin de recueillir la taille MTU sur les interfaces des périphériques. Certaines sources, 
notamment le Windows Server 2003 Hardening Guide (Guide de renforcement de la sécurité de 
Windows Server 2003), recommandent de désactiver la fonction de découverte PMTU. En revanche, 
cette fonction doit être activée pour permettre à IPSec de fonctionner correctement.

53
Notez également qu'IPSec peut affecter un système IDS (système de détection d'intrusion) puisqu'un 
analyseur spécifique est nécessaire à l'interprétation des données à l'intérieur des paquets. Si le 
système IDS n'est pourvu d'aucun analyseur, il ne peut pas examiner les données de ces paquets 
pour déterminer si une session particulière est une menace potentielle. Dans ce cas, la décision 
d'utiliser IPSec indique que votre organisation a davantage besoin d'IPSec que du système IDS.

Les informations identifiées dans cette section sont essentielles à la réussite du projet puisqu'elles 
vous permettent de comprendre la configuration actuelle et la santé de l'infrastructure du réseau avant 
même de configurer l'utilisation d'IPSec sur les périphériques concernés (ou d'y placer une charge 
supplémentaire s'ils sont déjà configurés pour la circulation du trafic IPSec). Par l'étude des 
informations relatives aux pics de charge, vous pouvez déterminer si le périphérique est en mesure 
d'utiliser IPSec dans son état actuel ou s'il exige une mise à niveau de la mémoire ou du 
microprogramme afin de supporter la charge attendue. Les informations sur la marque et le modèle 
s'avéreront utiles au moment de vous procurer le matériel de mise à niveau des périphériques (si 
nécessaire). Les informations sur les paramètres de configuration ou les fonctionnalités propres à 
cette marque et ce modèle peuvent également vous être utiles. Le nombre de listes de contrôle 
d'accès configurées sur les périphériques vous aidera à estimer l'effort requis pour configurer les 
périphériques afin de prendre en charge IPSec. Si aucun périphérique du réseau n'est configuré pour 
autoriser le trafic IPSec et que le réseau dispose d'un grand nombre de routeurs, la configuration des 
périphériques risque de représenter une importante charge de travail.

Une fois ces informations à votre disposition, vous pouvez rapidement déterminer s'il est nécessaire 
ou non de mettre à niveau les périphériques afin qu'ils répondent aux exigences du projet, de modifier 
les listes de contrôle d'accès ou de prendre d'autres mesures pour vous assurer que les périphériques 
seront capables de gérer les charges qui leur seront confiées.

Analyse du modèle de trafic réseau actuel

Après avoir recueilli les informations d'adressage et d'infrastructure réseau, l'étape suivante consiste 
logiquement à examiner avec soin le flux des communications. Par exemple, si un service comme 
celui des ressources humaines s'étend sur plusieurs bâtiments et si vous souhaitez utiliser IPSec pour 
chiffrer les informations de ce service, vous devez savoir comment les bâtiments concernés sont 
connectés pour déterminer le niveau de « confiance » envers la connexion. Un bâtiment hautement 
sécurisé relié par un câble en cuivre à un autre bâtiment sans protection peut être la proie d'une 
écoute clandestine ou d'une attaque par relecture de données. Si une attaque de ce type représente 
une menace, IPSec peut fournir une authentification mutuelle renforcée et le chiffrement du trafic des 
hôtes approuvés. Néanmoins, la solution ne résout pas le fait qu'un manque de sécurité physique sur 
les hôtes approuvés constitue toujours une menace.

Au moment d'examiner le flux de trafic, regardez de près comment tous les périphériques gérés et 
non gérés interagissent, y compris les périphériques non­Windows, tels que Linux, UNIX et Mac, ainsi 
que les versions Windows antérieures à Windows 2000 SP4. Posez­vous certaines questions, 
notamment : certaines communications ont­elles lieu au niveau du port ou du protocole ou bien existe­
t­il un grand nombre de sessions intervenant entre les mêmes hôtes sur un large éventail de 
protocoles ? Comment les serveurs et les clients communiquent­ils ensemble ? Existe­t­il des 
systèmes de sécurité ou des projets actuellement mis en œuvre ou planifiés susceptibles d'avoir un 
impact sur le projet d'isolation ? Par exemple, l'utilisation de Windows XP SP2 et du Pare­feu 
Windows pour "verrouiller" certains ports, tels que le port UDP 500, risque de provoquer l'échec de la 
négociation IKE.

Lorsque vous appliquez le processus de modélisation des menaces décrit dans le chapitre  2 
(« Présentation de l'isolation de serveurs et de domaines ») afin d'examiner les différents types de 
trafic réseau, vous pouvez aisément rechercher les protocoles et les applications qui génèrent un 
trafic devant être protégé contre les périphériques non approuvés ou non gérés. Certains des 
protocoles et des applications les plus fréquemment rencontrés sont les suivants :

54
• NetBIOS sur TCP/IP (NetBT) et SMB (Server Message Block). Dans un réseau local, on trouve 
souvent les ports 137, 138 et 139 activés pour NetBT et le port 445 activé pour SMB. En plus 
d'autres fonctionnalités, ces ports offrent des services de résolution des noms NetBIOS. 
Malheureusement, ils entraînent aussi la création de sessions NULL. Une session NULL est une 
session établie sur un hôte qui n'utilise pas le contexte de sécurité d'une entité ou d'un utilisateur 
connu. Ces sessions sont souvent anonymes.

• Appel de procédure distante (RPC). En règle générale, l'appel de procédure distante opère en 
présentant un port d'écoute à une application (également appelé « mappeur de point de 
terminaison », port TCP 135) qui suggère alors à « l'appelant » (souvent une autre application) 
d'engager la communication sur un autre port de la plage éphémère. Dans un réseau segmenté 
par des pare­feu, cette communication RPC soulève un véritable défi en termes de configuration 
puisqu'elle implique d'ouvrir le port d'écoute RPC et tous les ports au­dessus du port 1024. 
L'ouverture de tous ces ports augmente la surface exposée aux attaques sur la totalité du réseau 
et réduit l'efficacité des pare­feu. En revanche, l'avantage de l'appel de procédure distante (RPC) 
est qu'il fournit les fonctionnalités des couches 1 à 4 du modèle OSI (Open Systems 
Interconnection) pour les applications qui l'utilisent, ce qui évite aux développeurs d'effectuer des 
appels de bas niveau sur le réseau pour leurs applications distribuées. Du fait que de nombreuses 
applications dépendent de l'appel de procédure distante (RPC) pour leurs fonctionnalités de base, 
la stratégie IPSec devra tenir compte du service RPC. Pour plus d'informations sur la création 
d'une stratégie IPSec, consultez le chapitre 5, « Création de stratégies IPSec pour les groupes 
d'isolation ».

• Autre trafic. IPSec peut sécuriser les transmissions entre hôtes en authentifiant les paquets en 
plus de chiffrer les données qu'ils contiennent. L'important est d'identifier ce qui doit être protégé et 
les risques à minimiser. Tout autre trafic ou type de trafic à sécuriser doit être examiné et modélisé 
comme il se doit. Il peut, par exemple, s'agir d'une base de données visant un objectif précis et à 
laquelle seuls quelques clients sont autorisés à accéder, ou bien d'une application spécialisée 
destinée aux ressources humaines et exclusivement réservée aux cadres de ce service. 

Après avoir documenté le réseau logique et physique, la prochaine étape consiste à examiner les 
modèles de trafic actuels et à répondre aux questions suivantes :

• Disposez­vous à l'heure actuelle de sous­réseaux dédiés à des types spécifiques de trafic (par 
exemple, des stations de travail Mac et UNIX ou des connexions entre ordinateur central et 
terminal) ?

• Avez­vous besoin de séparer les différents types de trafic ou le trafic d'un emplacement à un 
autre ?

Active Directory

Après le réseau, Active Directory est le deuxième élément clé à partir duquel il vous faudra rassembler 
des données. Vous devrez comprendre la structure des forêts, notamment l'agencement des 
domaines, l'architecture des unités d'organisation et la topologie du site. Ces informations permettent 
de connaître la position actuelle des ordinateurs, leur configuration et l'impact des modifications 
apportées à Active Directory suite à l'implémentation d'IPSec. La liste ci­dessous décrit les 
informations nécessaires à la réalisation de cette étape du processus de découverte.

• Nombre de forêts. Étant donné que la forêt est la limite de sécurité dans une implémentation 
Active Directory, il est nécessaire de comprendre l'architecture Active Directory actuelle pour 
déterminer les hôtes à isoler et les modalités de l'isolation.

• Noms et nombre de domaines. L'authentification IPSec intervient suite au processus de 
négociation IKE. Dans cette solution, la méthode d'authentification est le protocole Kerberos. Ce 
protocole suppose que les ordinateurs sont associés à des domaines et qu'ils répondent aux 

55
 exigences de version requises en matière de système d'exploitation (Windows 2000, Windows XP 
ou Windows Server 2003).

• Nombre et types d'approbations. Connaître le nombre et les types d'approbations est crucial 
puisque les approbations affectent les limites logiques de l'isolation et permettent de définir la 
manière dont peut (ou doit) survenir l'authentification IKE dans la solution.

• Noms et nombre de sites. L'architecture du site s'aligne généralement sur la topologie du réseau. 
En maîtrisant le mode de définition des sites dans Active Directory, vous comprendrez mieux la 
réplication et d'autres processus. Dans cette solution, l'architecture du site offre une description 
plus approfondie de l'implémentation Active Directory tel qu'elle existe à l'heure actuelle.

• Structure d'unités d'organisation. Lorsque vous créez une structure d'unités d'organisation, un 
minimum de planification permet d'augmenter considérablement l'efficacité opérationnelle. Les 
unités d'organisation sont des constructions logiques. Elles peuvent donc être modelées pour 
répondre à divers objectifs et exigences. La structure d'unités d'organisation est le laboratoire idéal 
à partir duquel vous pouvez examiner l'utilisation de la stratégie de groupe et l'agencement des 
unités d'organisation. Les chapitres 4 et 5 de cette solution décrivent l'architecture des unités 
d'organisation et expliquent en détail comment en faire usage pour appliquer la stratégie IPSec.

• Utilisation actuelle de la stratégie IPSec. L'objectif ultime de ce projet étant l'implémentation de 
la stratégie IPSec, il est primordial que vous sachiez comment votre réseau exploite actuellement 
IPSec (si tel est le cas). Que vous utilisiez de simples filtres IPSec (comme ceux prescrits dans un 
guide de renforcement de la sécurité) ou implémentiez des stratégies complètes, la connaissance 
de votre utilisation actuelle et des conditions mêmes de cette utilisation permettront une intégration 
plus efficace dans la solution.

Le scénario de la Woodgrove Bank présente une seule et unique forêt (corp.woodgrovebank.com) 
composée de quatre domaines répartis sur cinq sites. Chaque site peut comporter un contrôleur de 
domaine (DC), un contrôleur principal de domaine (PDC) ou un serveur de catalogue global (GC) 
comme le montre le tableau ci­dessous.

Tableau 3.1 : Informations Active Directory de la Woodgrove Bank

Site physique Domaine Utilisateurs Type de contrôleur de 

domaine
New York, NY corp.woodgrovebank.com,  5 000 Catalogue global racine de 
americas.corp.woodgrovebank.com la forêt PDC GC régional, 
Amériques DC régional, 
Europe DC régional, Asie

Chicago, IL americas.corp.woodgrovebank.com 750 GC régional, Amériques

Atlanta, GA americas.corp.woodgrovebank.com 1 450 GC régional, Amériques

Boston, MA americas.corp.woodgrovebank.com 480 GC régional, Amériques

San Francisco, CA americas.corp.woodgrovebank.com 250 GC régional, Amériques

Pittsburgh, PA americas.corp.woodgrovebank.com 50 GC régional, Amériques

Phoenix, AZ americas.corp.woodgrovebank.com 50 GC régional, Amériques

Miami, FL americas.corp.woodgrovebank.com 50 GC régional, Amériques

Washington, DC americas.corp.woodgrovebank.com 75 GC régional, Amériques

Cambridge, MA americas.corp.woodgrovebank.com 36 GC régional, Amériques

Toronto, Canada americas.corp.woodgrovebank.com 25 GC régional, Amériques

56
Londres, R.U. europe.corp.woodgrovebank.com,  5 200 GC racine de la forêt 
corp.woodgrovebank.com Émulateur PDC GC 
régional, Europe DC 
régional, Amériques DC 
régional, Asie

Genève, Suisse  europe.corp.woodgrovebank.com 350 GC régional, Europe

Amsterdam, Pays­ europe.corp.woodgrovebank.com 295 GC régional, Europe

Bas

Munich, Allemagne europe.corp.woodgrovebank.com 149 GC régional, Europe

Rome, Italie europe.corp.woodgrovebank.com 80 GC régional, Europe

Dublin, Irlande europe.corp.woodgrovebank.com 79 GC régional, Europe

Édimbourg, Écosse europe.corp.woodgrovebank.com 40 GC régional, Europe

Johannesburg,  europe.corp.woodgrovebank.com 37 GC régional, Europe

Afrique du Sud

Tokyo, Japon asia.corp.woodgrovebank.com,  500 GC racine de la forêt 

corp.woodgrovebank.com Émulateur PDC GC 
régional, Asie DC régional, 
Europe DC régional, 
Amériques

Hong­Kong, Chine asia.corp.woodgrovebank.com 100 GC régional, Asie

Bangkok, Thaïlande asia.corp.woodgrovebank.com 150 GC régional, Asie

Singapour asia.corp.woodgrovebank.com 210 GC régional, Asie

Sydney, Australie asia.corp.woodgrovebank.com 45 GC régional, Asie

Bangalore, Inde  asia.corp.woodgrovebank.com 35 GC régional, Asie

Taipei, Taïwan asia.corp.woodgrovebank.com 65 GC régional, Asie

La structure Active Directory de la Woodgrove Bank utilisait les relations d'approbation bidirectionnelle 
automatiquement créées par la forêt. Aucune approbation supplémentaire entre forêts ou externe 
n'était disponible.

La figure suivante donne un exemple de la structure d'unités d'organisation de haut niveau adoptée à 
la Woodgrove Bank. Cette structure a fait l'objet d'une utilisation cohérente sur les trois domaines 
régionaux principaux (Amériques, Europe et Asie).

57
Figure 3.2 Exemple de structure d'unités d'organisation Woodgrove Bank

Le projet d'isolation de serveurs et de domaines étant la première implémentation IPSec réalisée par 
la Woodgrove Bank, aucune stratégie IPSec active et existante n'était en place.

Détection d'hôtes

L'avantage le plus précieux d'un projet de découverte des ressources est la quantité considérable de 
données recueillies sur les hôtes (stations de travail et serveurs) du réseau. Les décisions prises et 
décrites au chapitre 4, « Conception et planification de groupes d'isolation », exigeront des 
informations précises sur l'état de l'ensemble des hôtes afin de garantir leur aptitude à participer aux 
communications IPSec de la solution.

Données requises concernant les hôtes

Cette section décrit les informations nécessaires sur les hôtes et explique comment les représenter de 
manière physique et logique.

• Nom de l'ordinateur. Il s'agit du nom NetBIOS ou DNS de l'ordinateur permettant d'identifier ce 
dernier sur le réseau. Du fait qu'un ordinateur peut disposer de plusieurs adresses MAC (Media 
Access Control) et/ou IP, le nom d'ordinateur constitue l'un des critères en fonction desquels vous 
pouvez déterminer l'unicité sur le réseau. Les noms des ordinateurs peuvent être dupliqués dans 
certaines circonstances de sorte que l'unicité ne soit pas jugée comme absolue.

• Adresse(s) IP de chaque carte d'interface réseau. L'adresse IP désigne l'adresse utilisée avec 
le masque de sous­réseau pour identifier un hôte sur le réseau. Une adresse IP n'est pas une 
méthode efficace d'identification d'une ressource parce qu'elle est change fréquemment.

• Adresse MAC de chaque carte d'interface réseau. L'adresse MAC est une adresse 48 bits 
unique utilisée pour identifier une interface réseau. Elle peut servir à différencier plusieurs 
interfaces réseau sur le même périphérique.

• Système d'exploitation, service pack et versions de correctifs. La version du système 
d'exploitation est un facteur clé permettant de déterminer l'aptitude d'un hôte à communiquer avec 
IPSec. Il est également primordial de contrôler l'état actuel des service packs et des correctifs 
susceptibles d'être installés car ces éléments sont souvent utilisés pour déterminer si les normes 
de sécurité minimales sont respectées.

• Appartenance au domaine. Ces informations sont utilisées pour déterminer si un ordinateur peut 
se procurer la stratégie IPSec à partir d'Active Directory ou s'il doit utiliser une stratégie IPSec 
locale.

58
• Emplacement physique. Cette information représente simplement l'emplacement du périphérique 
de votre organisation. Vous pouvez l'utiliser pour déterminer si un périphérique doit participer à un 
groupe d'isolation particulier en fonction de son emplacement ou de l'emplacement des 
périphériques avec lesquels il communique régulièrement.

• Type/rôle du matériel. Ces informations ne sont parfois pas accessibles via un processus 
automatisé. Certains outils de détection d'hôtes peuvent permettre de les obtenir en sondant les 
informations liées au matériel, puis en exécutant des applications pour déterminer le type (serveur, 
station de travail ou Tablet PC). Vous pouvez également exploiter ces données afin d'évaluer le 
droit d'un ordinateur spécifique à participer au processus d'isolation et de définir le groupe 
d'isolation dans lequel le placer.
Remarque : les informations ayant trait au type de matériel sont obtenues par interpolation des 
données ou par le biais d'un logiciel soumettant des requêtes en vue de se procurer ces informations. 
Par exemple, il est évident qu'un HP Evo n800 est un ordinateur portable. Si vous avez la possibilité 
de soumettre une requête au niveau du matériel (ou de le munir d'une étiquette d'inventaire 
l'identifiant en tant que tel), vous pouvez plus facilement déterminer la stratégie IPSec appropriée à 
attribuer au périphérique.

Après avoir collecté toutes ces informations et les avoir regroupées dans une base de données, 
procédez à intervalles réguliers à des opérations de détection afin de les tenir à jour. Vous aurez 
besoin d'un état complet et à jour des hôtes gérés sur les réseaux pour concevoir une solution 
conforme aux exigences de votre organisation.

Vous pouvez employer diverses méthodes pour recueillir des données sur les hôtes du réseau. Il peut 
s'agir de systèmes haut de gamme entièrement automatisés ou bien d'un processus d'extraction des 
données entièrement manuel. En règle générale, le recours aux méthodes automatisées de recueil 
des données est préférable aux méthodes manuelles pour des raisons de vitesse et de sécurité. 
Néanmoins, quelle que soit la méthode adoptée, les informations requises restent les mêmes. La 
seule différence concerne le temps nécessaire à l'obtention de ces données. Les processus manuels 
soulèvent généralement plusieurs difficultés : risque d'informations en double, portée de l'effort 
engagé (tous les réseaux ont­ils été analysés ? Les informations recueillies concernent­elles tous les 
hôtes ou simplement les sous­réseaux de clients ?) et recueil des données en temps utile. L'étude de 
tous les éléments d'un audit complet du système informatique dépasse le cadre de ce projet. 
Cependant, il est important de comprendre que ces informations d'audit jouent un rôle crucial pour 
l'organisation, un rôle qui dépasse largement les seuls besoins de cette solution. Le suivi des 
ressources et la gestion des risques de sécurité sont deux exemples de processus clés qui justifient la 
nécessité d'un inventaire système actualisé et minutieux.

Détection automatisée

L'emploi d'un système de gestion réseau avec audit automatisé, tel que SMS, permet d'obtenir des 
informations précieuses sur l'état actuel de l'infrastructure informatique. Les systèmes automatisés 
posent cependant un problème lié au fait que les hôtes hors connexion, débranchés ou en état 
d'incapacité physique (ou logique) de répondre à des demandes d'information n'apparaissent pas 
dans la base de données finale. Même les systèmes les plus automatisés exigent un degré de gestion 
manuelle pour s'assurer que les hôtes sont accessibles et pris en compte comme il se doit.

Nombre de produits et d'outils sont, dans ce domaine, proposés par divers fournisseurs. Certaines 
méthodes font appel à un mécanisme d'analyse centralisé, d'autres utilisent des agents installés sur 
les ordinateurs clients. L'objectif du présent guide n'est pas de comparer et de conseiller des produits 
à acheter mais la solution exige que les données de découverte et de détection détaillées dans ce 
chapitre soient disponibles pour les considérations de conception émises dans les chapitres 4 et 5. 

Pour plus d'informations sur la manière dont SMS 2003 peut contribuer à la gestion des ressources 
(ou aider à recueillir les informations nécessaires à ce projet), accédez à la démonstration et à la fiche 

59
technique consacrée à la gestion des ressources à partir de la page SMS 2003 Asset 
Management   (Gestion du parc informatique avec Systems Management Server 2003) à 
l'adressewww.microsoft.com/smserver/evaluation/capabilities/asset.asp.

Détection manuelle

La différence majeure entre les méthodes de détection manuelles et les méthodes automatisées est le 
temps. L'obtention manuelle des données requises pour ce projet peut mobiliser une bonne dizaine de 
personnes et exiger des jours ou des semaines, voire peut­être plus dans une entreprise de plus 
grande échelle. Si vous envisagez de recourir à une méthode manuelle pour procéder à un audit de 
l'état actuel de votre infrastructure, il est primordial que les informations recueillies soient disponibles 
dans un format électronique (par exemple, dans une feuille de calcul ou une base de données). Le 
volume de données susceptible d'être généré peut rendre le processus de filtrage et d'analyse très 
fastidieux si vous ne parvenez pas à soumettre avec rapidité et précision des requêtes spécifiques 
capables de renvoyer les informations requises. Qui plus est, vous pouvez faire appel aux 
administrateurs informatiques pour vous procurer les informations ou valider toutes les informations 
recueillies précédemment.

Même si votre organisation ne bénéficie pas d'un outil d'audit automatisé, il existe toujours une part 
d'automatisation possible via les interfaces de script et de gestion à distance standards disponibles 
sur la plate­forme Windows. La principale difficulté liée à l'utilisation de ces outils est de veiller à 
n'oublier aucun client simplement parce qu'il n'est pas compatible avec le script ou l'outil de gestion.

Vous pouvez utiliser l'environnement d'exécution de scripts Windows, Microsoft Visual Basic® 
Scripting Edition (VBScript) et Windows Management Instrumentation (WMI) pour créer un fichier de 
script capable de collecter des informations de configuration système. Le tableau ci­dessous décrit la 
disponibilité de VBScript et WMI par plate­forme.

Tableau 3.2 : Disponibilité de VBScript et WMI par plate­forme

Plate­forme VBScript WMI

Windows 95 Installer WSH 5.6 Installer WMI CORE 1.5

Windows 98 Intégré  Installer WMI CORE 1.5

Windows Millennium Intégré  Intégré

Microsoft Windows NT®  Installer WSH 5.6 Installer WMI CORE 1.5

version 4.0

Windows 2000 Intégré Intégré

Windows XP Intégré  Intégré

Windows Server 2003 Intégré  Intégré

Remarque : vous pouvez télécharger la mise à jour de Microsoft Windows Script 5.6 depuis la page 
Microsoft Windows Script Downloads   (téléchargements de Microsoft Windows Script) à l'adresse 
http://msdn.microsoft.com/library/default.asp?url=/downloads/list/webdev.asp.

Vous pouvez télécharger également le fichier d'installation de Windows Management Instrumentation 
(WMI) CORE 1.5   depuis le Centre de téléchargement Microsoft à l'adresse 
www.microsoft.com/downloads/details.aspx?FamilyID=afe41f46­e213­4cbf­9c5b­
fbf236e0e875&DisplayLang=en.

60
Un exemple VBScript intitulé Discovery.vbs est fourni dans le dossier Tools and Templates de cette 
solution. Ce script utilise le service WMI pour extraire l'ensemble des données répertoriées dans la 
section « Données requises concernant les hôtes » de ce chapitre, à l'exception du rôle et de 
l'emplacement physique. Les informations sont rassemblées dans le fichier texte 
C:\Discovery\<systemname>_info.txt sur l'ordinateur local. Vous pouvez modifier le script pour 
collecter d'autres informations ou placer les informations collectées sur un partage de fichiers distant.

Si WMI ou VBScript n'est pas disponible sur l'ordinateur hôte, vous pouvez recueillir certaines 
informations à l'aide d'un script de commandes et d'outils externes. La difficulté vient du fait que le 
langage de commandes est extrêmement limité en termes de fonctionnalités et que les informations 
de configuration ne sont pas faciles à extraire de la ligne de commande dans les versions antérieures 
de Windows.

Pour procéder à une détection d'hôtes, il est nécessaire d'interroger les hôtes et de fournir un 
emplacement pour stocker les résultats obtenus.

Que vous optiez pour une méthode de collecte des données manuelle, automatique ou hybride, l'une 
des plus grandes difficultés pour garantir la validité de la conception consiste à connaître les 
modifications survenues entre l'analyse d'inventaire d'origine et le début de l'implémentation. Une fois 
la première analyse terminée, vous devez informer votre personnel de support que toutes les 
modifications futures doivent être enregistrées et les mises à jour consignées dans l'inventaire.

Cet inventaire est indispensable à la planification et l'implémentation des stratégies IPSec (sujets 
abordés dans les chapitres suivants).

Considérations relatives à la capacité 
Une fois le processus de collecte des informations achevé, vous devez vous intéresser à l'impact 
d'IPSec, notamment en termes de planification de la capacité. Cette section décrit certains des 
éléments essentiels d'une planification en bonne et due forme d'IPSec dans votre environnement.

Impact d'IPSec 

Du fait des diverses techniques cryptographiques auxquelles il fait appel, IPSec peut entraîner une 
consommation importante des ressources de l'ordinateur. Les scénarios qui exigeront une analyse 
plus profonde sont ceux qui préconiseront un chiffrement. Par exemple, un scénario peut envisager 
l'utilisation des algorithmes 3DES (Triple Data Encryption Standard) et SHA­1 (Secure Hash 
Algorithm) pour vérifier l'intégrité dans des situations qui exigent la plus forte protection disponible en 
termes d'échange de clés et de chiffrement. Un autre scénario impliquera la négociation de 
l'association de sécurité. Vous pouvez opter pour une durée plus courte pour l'association de sécurité 
en mode principal (par exemple, trois heures) mais comme dans toutes considérations ayant trait à la 
sécurité, soyez prêt à faire des compromis. Chaque association de sécurité en mode principal 
consomme environ 5 Ko de mémoire vive (RAM). Une situation dans laquelle un serveur est contraint 
de négocier des dizaines de milliers de connexions simultanées peut entraîner une consommation 
abusive. D'autres facteurs concernent l'utilisation du processeur sur les serveurs de l'infrastructure 
réseau, la consommation accrue des ressources sur les serveurs et les stations de travail exécutant 
IPSec (surtout les serveurs puisque, dans la plupart des cas, ils comportent un plus grand nombre 
d'associations de sécurité en mode principal que les clients) et le temps de réponse du réseau plus 
long résultant de la négociation IPSec.

Remarque : dans le cadre de son propre scénario de déploiement de cette solution, Microsoft a 
constaté qu'une augmentation possible (de l'ordre de un à trois pour cent) de la charge réseau est tout 
à fait normale. Cette augmentation est une conséquence directe de l'utilisation d'IPSec.

61
Un autre problème majeur concerne les réseaux reliés par un périphérique de traduction d'adresses 
réseau (NAT). Il vient du fait que la traduction d'adresses réseau (NAT) n'autorise pas les 
conversations d'authentification de l'en­tête (AH) entre les hôtes parce qu'elle est contraire au principe 
même du protocole AH : l'authentification d'un paquet inchangé, y compris l'en­tête. Si des 
périphériques NAT existent sur le réseau interne, préférez le protocole ESP au protocole AH. Le 
protocole ESP offre la possibilité de chiffrer les données mais n'exige pas le chiffrement. Ce facteur 
est essentiel en terme d'évaluation de la capacité puisque le chiffrement implique une surcharge dont 
il faut tenir compte pendant les phases de planification et de conception du projet. Le protocole ESP 
peut également être implémenté sans chiffrement et, ainsi, offrir la communication homologue à 
homologue la plus forte sans rompre les communications avec la traduction d'adresses réseau (NAT). 
Utilisé sans chiffrement, son impact serait donc plus faible qu'une solution ESP avec chiffrement.

Impact de la stratégie

La stratégie IPSec et la stratégie de groupe ont toutes les deux un impact sur les temps de démarrage 
des ordinateurs et sur le temps nécessaire aux utilisateurs pour se connecter. Lors de la phase de 
recueil des données, il peut être utile de relever les temps de démarrage des ordinateurs et les temps 
de connexion des utilisateurs avant d'implémenter la solution. L'enregistrement de ces données 
fournira un élément de base avec lequel vous pourrez comparer les systèmes testés lors de l'étape 
pilote afin de déterminer l'impact sur le temps global nécessaire à un utilisateur pour se connecter.

Problèmes de prédéploiement
Les sections précédentes décrivaient les informations à recueillir à partir du réseau, d'Active Directory 
et des hôtes pour garantir le succès d'un projet d'isolation. Cette section signale les domaines de 
préoccupation à examiner de près avant de déployer IPSec.

Infrastructure réseau

Le recueil d'informations vous permet de planifier une isolation IPSec sur un réseau. Une fois ces 
informations collectées, vous pourrez procéder à une analyse minutieuse des données qui révèlera la 
majorité des problèmes auxquels vous serez confronté lors de la phase pilote et du déploiement. Bien 
que les éléments suivants ne soient pas exhaustifs, il est important de les prendre en considération au 
moment d'entamer l'analyse des informations recueillies avant les tests et le déploiement.

Périphériques surexploités

Vous devrez peut­être mettre à niveau ou reconfigurer les commutateurs ou les routeurs exploités 
actuellement à plus de 75 pour cent pour permettre un trafic accru sur le périphérique et garantir une 
marge d'utilisation supplémentaire en cas de pointes de trafic. Dans le contexte d'une implémentation 
IPSec, la planification en bonne et due forme de la capacité est plus une affaire de tests et de charges 
de trafic anticipées que de calculs précis. Parce qu'il est fort improbable que le scénario, les modèles 
de trafic, les groupements d'utilisateurs et les applications soient les mêmes pour deux clients, une 
planification appropriée et la prise en compte de l'impact sur les périphériques du réseau sont 
indispensables. Par exemple, certains aspects d'IPSec sont totalement prévisibles. Chaque paquet 
utilisant IPSec avec ESP sera exactement 36 octets plus volumineux que le même paquet n'utilisant 
pas IPSec. Savoir que la création d'une seule association de sécurité en mode principal exige six 
messages permet de se représenter plus facilement quel sera l'impact de son utilisation sur un 
périphérique donné. Vous pouvez utiliser des outils tels que l'application PROVISO de Quallaby   
(disponible sur www.quallaby.com), ou d'autres solutions d'analyse réseau pour faciliter votre travail 
de planification de la capacité IPSec dans votre environnement informatique.

62
Périphériques incompatibles

Les périphériques qui ne sont pas compatibles avec IPSec ne peuvent pas participer aux 
communications IPSec. Si ces périphériques ont besoin de communiquer avec un périphérique géré, 
placez­les dans la liste d'exemptions IPSec. Une autre solution consiste à mettre à niveau le matériel 
ou les logiciels des périphériques afin qu'ils prennent en charge IPSec. Une autre encore est de 
permettre à ces périphériques non gérés de communiquer avec des ordinateurs voisins lorsqu'ils 
communiquent en texte clair pour leurs communications sortantes.

Périphériques mal configurés

Des périphériques mal configurés peuvent augmenter le risque d'échec des communications et de 
charge accrue sur le périphérique, mais aussi compromettre leur intégrité. Les méthodes de 
configuration, d'administration et de sécurité conseillées ci­après permettront de réduire les risques.

Adressage IP

Parce que les adresses IP constituent la pierre d'angle d'une solution IPSec, il est primordial que 
l'adressage soit aussi net que possible. Des espaces d'adresses se chevauchant, des adresses en 
double, des masques de sous­réseau incorrects et bien d'autres problèmes peuvent compliquer les 
opérations réseau classiques. L'apport d'IPSec à un réseau de ce type ne fera que compliquer le 
dépannage et incitera les utilisateurs à penser qu'IPSec est la source de tous ces problèmes. La 
croissance des entreprises, les fusions et les acquisitions, et bien d'autres facteurs encore, peuvent 
rapidement contribuer au développement d'une image fausse et obsolète de l'adressage IP sur un 
réseau. Pour éviter les problèmes majeurs liés à IPSec, assurez­vous que le réseau est divisé en 
sous­réseaux qui ne se chevauchent pas, que les tables de routage sont récapitulées comme il se doit 
et que l'agrégation par adresses est facile à déterminer.

Informations Active Directory

Si l'implémentation actuelle d'Active Directory fonctionne correctement (résolutions des noms, DHCP 
(Dynamic Host Configuration Protocol), application de la stratégie de groupe, relations d'approbation, 
etc.), rien ne saurait affecter IPSec. Surveillez attentivement les modifications effectuées entre le 
moment où Active Directory a été examiné et le début du projet d'isolation pour vous assurer qu'aucun 
problème de compatibilité ne surviendra.

Informations concernant les hôtes

Grâce aux sections précédentes, vous avez pu recueillir suffisamment d'informations sur les hôtes de 
votre réseau. Après avoir déterminé les clients et les serveurs aptes à utiliser IPSec, réfléchissez sur 
la manière de les isoler et aux applications nécessaires pour évaluer avec soin l'impact que la solution 
d'isolation peut avoir sur eux.

Évaluation de la participation client/serveur

Une fois les informations concernant les hôtes rassemblées, il est relativement simple de sélectionner 
les hôtes susceptibles d'être intégrés à la solution d'isolation. Par exemple, seuls des ordinateurs 
Windows 2000, Windows Server 2003 et Windows XP peuvent communiquer avec IPSec. Toutefois, 
tous les clients aptes à participer ne doivent pas nécessairement le faire. Une étape clé du processus 
de conception consiste à déterminer à partir des informations recueillies dans ce chapitre quels 
ordinateurs et périphériques seront inclus dans la solution et dans quel groupe ils résideront.

63
Définition des services devant être isolés

Dans le contexte d'un projet d'isolation de serveurs et de domaines, un service désigne une 
application (par exemple, Microsoft Exchange Server, Microsoft SQL Server™ ou 
Internet Information Services/IIS) qui offre ses services à des clients du réseau. Vous devez évaluer 
ces services de manière individuelle afin de déterminer s'ils sont des candidats à l'isolation de 
serveurs et de domaines. Plusieurs raisons peuvent justifier l'intégration de ces services dans la 
solution. Cela peut être une question de stratégie d'organisation, d'exigence réglementaire ou 
d'impératif commercial. Par exemple, une stratégie de l'organisation peut stipuler que toutes les 
communications entre les serveurs de messagerie doivent être sécurisées avec IPSec, mais pas les 
communications entre les clients et les serveurs. Le chapitre 4, « Conception et planification de 
groupes d'isolation », aborde le processus d'isolation plus en détail. Lorsque vous tentez d'isoler des 
services, examinez avec soin les serveurs qui font intervenir plusieurs services, comme dans le cas 
d'un serveur de fichiers offrant des services Web et un service FTP (File Transfer Protocol) et faisant 
également office de serveur de messagerie.

Équilibrage de la charge réseau et clusters

Les organisations qui utilisent l'isolation de serveurs et de domaines peuvent choisir d'exclure les 
ordinateurs ayant recours à l'équilibrage de la charge réseau et aux clusters. IPSec n'est pas 
compatible avec l'équilibrage de la charge réseau en mode « sans affinité » puisqu'il empêche 
différents ordinateurs d'exploiter la même connexion cliente. Du fait de cette incompatibilité, il est 
préférable d'éviter l'équilibrage de la charge réseau en mode « sans affinité » avec IPSec.

Gestion des exceptions

La gestion des exceptions est une étape essentielle de la planification IPSec. Savoir où utiliser les 
ordinateurs qui autoriseront l'accès depuis les hôtes non approuvés et comment contrôler l'accès 
entre les ordinateurs gérés et non gérés est un paramètre essentiel de l'isolation. La meilleure 
méthode conseillée dans ce domaine est de maintenir le nombre d'exceptions aussi réduit que 
possible. Les besoins techniques peuvent exiger que certains ordinateurs ou services soient 
exemptés d'IPSec, notamment les contrôleurs de domaine et les serveurs DHCP, DNS et WINS. Étant 
donné la nécessité de gérer en permanence ces ordinateurs, le risque encouru est plus faible que 
d'autoriser les ordinateurs non gérés à communiquer avec des ordinateurs gérés et approuvés.

Périphériques non­Windows

La plupart des réseaux d'entreprise ne sont pas homogènes. Vous devez tenir compte de la diversité 
des éléments, tels que les systèmes d'exploitation, l'infrastructure réseau et les plates­formes 
matérielles lorsque vous planifiez le déploiement d'IPSec. Si votre organisation possède des 
ordinateurs exécutant un système autre que Windows, vous devez comprendre que la consommation 
de la stratégie IPSec hors du domaine Windows n'est actuellement pas possible. Une organisation 
peut décider de faire face à cette restriction en traitant certaines plates­formes comme approuvées 
mais la solution d'isolation de serveurs et de domaines ne les protègera pas puisque ces plates­
formes sont dans l'incapacité d'exploiter la stratégie IPSec. La section qui suit explique comment 
déterminer l'approbation.

Périphériques de gestion et de contrôle

Un aspect d'IPSec souvent ignoré lors de la phase de planification initiale est son impact sur la 
gestion et le contrôle du trafic du réseau. Parce qu'IPSec exige une authentification et autorise le 
chiffrement, certains périphériques ne sont plus en mesure de contrôler ou de gérer les ordinateurs 
activés avec IPSec. Dans certains cas exigeant un chiffrement, une organisation peut supposer que la 
sécurité est plus importante que le besoin opérationnel de contrôler les données tandis qu'elles 
transitent sur le réseau. Dans d'autres cas, il sera nécessaire d'évaluer les modifications que vous 

64
pouvez apporter à une application ou un périphérique pour activer le contrôle IPSec (par exemple, un 
analyseur ESP capable d'examiner le trafic ESP). S'il s'avère impossible de mettre à niveau les 
périphériques de contrôle ou de gestion pour la prise en charge d'IPSec, il est crucial alors que vous 
enregistriez ces informations. L'architecte de la solution et l'équipe qui l'entoure auront besoin de ces 
informations au chapitre 4, « Conception et planification de groupes d'isolation ».

Définition de l'approbation
Après avoir rassemblé des informations sur les périphériques hôtes qui composent actuellement votre 
infrastructure informatique, vous devez déterminer de manière fondamentale ce qui affecte 
directement la capacité d'un hôte à participer à la solution. L'objectif est de décider jusqu'à quel point 
un hôte peut être considéré comme approuvé. Le terme « approuvé » peut signifier différentes choses 
pour différentes personnes ; il est donc important de parvenir à une définition précise afin de la 
communiquer à toutes les parties prenantes. Ne pas le faire, c'est risquer d'exposer la sécurité de 
l'environnement approuvé à des problèmes puisque la sécurité globale ne peut aller au­delà du niveau 
de sécurité défini par le client le moins sécurisé autorisé à adopter l'état approuvé.

Pour comprendre ce concept, tenez compte des quatre états de base applicables aux hôtes d'une 
infrastructure informatique classique. Ces états sont (par degré de risque, avec le risque le plus faible 
en premier) les suivants :

1. Approuvé
2. Digne de confiance
3. Connu, non approuvé
4. Inconnu, non approuvé

Le reste de cette section définit ces états et explique comment déterminer dans votre organisation 
quels hôtes appartiennent à quel état.

État Approuvé

Le classement d'un hôte comme approuvé ne signifie pas que l'hôte en question est parfaitement 
sécurisé ou invulnérable. Fondamentalement, « approuvé » signifie que les risques de sécurité de 
l'hôte sont gérés. La responsabilité de cet état géré revient aux administrateurs et aux utilisateurs 
informatiques responsables de la configuration de l'hôte. Un hôte approuvé mal géré peut devenir une 
faiblesse et mettre en péril la solution tout entière.

Lorsqu'un hôte est considéré comme approuvé, les autres hôtes approuvés doivent pouvoir 
légitimement partir du principe que cet hôte ne commettra aucun acte malveillant. Par exemple, des 
hôtes approuvés ne peuvent s'attendre à une attaque de virus de la part d'autres hôtes puisque tous 
les hôtes approuvés doivent recourir à des mécanismes (notamment un logiciel antivirus) visant à 
minimiser les risques de virus.

La communication entre hôtes approuvés ne doit pas être gênée par l'infrastructure du réseau. Par 
exemple, si un hôte approuvé peut librement partir du principe qu'aucun autre hôte approuvé ne 
commettra d'acte malveillant à son encontre, le blocage des paquets au niveau IP destiné à limiter 
l'accès d'autres hôtes approuvés n'est généralement pas nécessaire. Vous devez appliquer toutes les 
restrictions nécessaires au contrôle des communications des hôtes par port ou protocole en utilisant 
un pare­feu basé sur l'hôte sur l'ordinateur lui­même, pas en utilisant IPSec.

Dans le scénario imaginé pour la Woodgrove Bank, l'équipe de la sécurité a défini les cinq objectifs 
clés suivants afin de planifier les technologies nécessaires à l'hôte pour atteindre l'état approuvé :

65
• L'identité de l'ordinateur ou de l'utilisateur n'a pas été compromise.
• Les ressources requises sont sécurisées et disponibles, quel que soit leur emplacement dans 
l'environnement géré.
• Une ressource jugée sécurisée est protégée contre tout risque de falsification, de virus ou de 
tentative d'accès non autorisé.
• Une ressource signalée comme étant disponible respecte ou dépasse les niveaux attendus de 
durée active et est protégée contre toute faille de sécurité.
• Un environnement considéré comme géré dispose d'ordinateurs dotés de Windows 2000 SP4 
(ou une version ultérieure) et de la configuration et des correctifs appropriés.

• Les données et les communications sont privées, ce qui signifie que seuls les destinataires 
concernés peuvent lire et utiliser ces informations.

• Le propriétaire ou l'opérateur du dispositif comprend et accepte de se conformer aux stratégies et 
aux procédures afin de maintenir la confiance accordée à l'environnement.

• La réaction face aux risques et aux menaces intervient en temps utile.

Forte de ces objectifs, l'équipe du support de la Woodgrove Bank a pu définir un ensemble 
d'exigences technologiques permettant de déterminer si un hôte peut être considéré comme 
approuvé.

Au moment de définir l'état approuvé, assurez­vous que les propriétaires des ressources impliquées 
sont libres de définir des conditions de sécurité supplémentaires répondant aux besoins commerciaux 
d'une ressource ou d'un actif donné. Par exemple, votre service des ressources humaines peut exiger 
un mécanisme d'ouverture de session biométrique pour des serveurs spécifiques. Cette exigence 
n'aura aucune incidence sur la confiance à accorder aux serveurs dans le contexte de cette solution. 
Néanmoins, vous devez rester vigilant et veiller à ce que les exigences d'une ressource particulière 
n'entrent pas en conflit avec celles de l'état approuvé.

Consacrez un peu de temps à la définition des objectifs et des besoins technologiques que votre 
organisation juge convenables en tant que configuration minimale pour l'octroi de l'état approuvé à un 
hôte.

Par exemple, l'équipe de conception a dressé ci­dessous la liste des exigences technologiques 
requises dans le cadre du scénario de la Woodgrove Bank.

• Système d'exploitation. Un hôte approuvé doit exécuter Windows XP SP2 ou 
Windows Server 2003, ou au minimum Windows 2000 SP4.

• Appartenance au domaine. Un hôte approuvé appartient à un domaine géré, ce qui signifie que 
le service informatique doit posséder des droits de gestion de la sécurité.

• Client de gestion. Tous les hôtes approuvés doivent exécuter un client de gestion réseau 
spécifique pour permettre une gestion centralisée et un contrôle des stratégies de sécurité, des 
configurations et des logiciels.

• Logiciel antivirus. Tous les clients approuvés doivent être dotés d'un logiciel antivirus configuré 
en vue de mettre à jour automatiquement et quotidiennement les derniers fichiers de signatures de 
virus.

• Système de fichiers. Tous les hôtes approuvés seront configurés avec le système de 
fichiers NTFS.

• Paramètres du BIOS. Tous les ordinateurs portables approuvés seront configurés avec un mot de 
passe au niveau du BIOS contrôlé par l'équipe du support informatique.

66
• Conditions requises pour les mots de passe. Les clients approuvés doivent utiliser des mots de 
passe forts.  

Un élément essentiel à comprendre est le fait que l'état approuvé n'est pas constant. C'est un état de 
transition soumis à des normes de sécurité qui évoluent et au besoin de se conformer à ces normes. 
De nouvelles menaces et de nouveaux principes de défense apparaissent constamment. C'est 
pourquoi il est impératif que les systèmes de gestion de l'organisation vérifient en permanence les 
hôtes approuvés pour garantir une conformité continue. Qui plus est, ces systèmes doivent être 
capables d'émettre des mises à jour ou des changements de configuration s'ils sont chargés de 
maintenir l'état approuvé.

Un hôte apte à répondre en permanence à l'ensemble des exigences de sécurité peut être considéré 
comme approuvé. Néanmoins, il est fort probable que la plupart des ordinateurs hôtes identifiés au 
cours du processus de détection et de découverte abordé plus haut dans ce chapitre ne répondent 
pas à ces exigences. Il est donc primordial de distinguer les hôtes qui peuvent être approuvés de ceux 
qui ne le peuvent pas (considérés alors comme non approuvés). Pour faciliter ce processus, vous 
pouvez définir un état Digne de confiance intermédiaire. Le reste de cette section aborde les différents 
états et leurs implications.

État Digne de confiance

Si nécessaire, il peut être utile d'identifier au plus vite dans votre infrastructure actuelle les hôtes aptes 
à devenir approuvés. Un état Digne de confiance peut être attribué à l'hôte actuel pour confirmer son 
aptitude physique à devenir approuvé en effectuant les modifications requises au niveau des logiciels 
et de la configuration.

Pour chaque ordinateur auquel vous attribuez un état Digne de confiance, pensez à ajouter une note 
de configuration consignant les conditions permettant à l'hôte d'atteindre l'état approuvé. Ces 
informations revêtent une importance toute particulière pour l'équipe de conception du projet (afin 
d'estimer les coûts résultant de l'ajout de l'hôte à la solution) et le personnel du support (pour pouvoir 
appliquer la configuration requise). En règle générale, les hôtes dignes de confiance tombent dans 
l'un des deux groupes suivants :

• Configuration requise. Le matériel utilisé, le système d'exploitation et le logiciel actuels 
permettent à l'hôte d'atteindre un état Digne de confiance. En revanche, des changements de 
configuration supplémentaires sont nécessaires avant de parvenir aux niveaux de sécurité requis. 
Par exemple, si l'organisation exige un système de fichiers sécurisé avant de pouvoir considérer un 
hôte comme approuvé, un hôte avec un disque dur de format FAT32 ne pourra pas satisfaire cette 
exigence.

• Mise à niveau requise. Ce groupe d'ordinateurs exige des mises à niveau système avant d'être 
considéré comme approuvé. La liste suivante fournit quelques exemples sur le type de mise à 
niveau que les ordinateurs de ce groupe peuvent exiger :
• Mise à niveau du système d'exploitation requise. Si le système d'exploitation actuel de l'hôte 
n'est pas capable de prendre en charge les exigences de sécurité de l'organisation, une mise à 
niveau sera nécessaire pour que l'hôte puisse accéder à l'état approuvé.
• Logiciel requis. Un hôte non doté de l'application de sécurité requise (par exemple, un outil 
d'analyse antivirus ou un client de gestion) ne peut être considéré comme approuvé tant que les 
applications nécessaires n'ont pas été installées et activées.
• Mise à niveau matérielle requise. Dans certains cas, un hôte peut exiger une mise à niveau 
matérielle spécifique avant d'être déclaré comme approuvé. Il s'agit généralement d'une mise à 
niveau du système d'exploitation ou d'un logiciel supplémentaire forçant la mise à niveau 
matérielle requise. Par exemple, un logiciel de sécurité nécessitant un espace de stockage 
supplémentaire exigera davantage d'espace sur le disque dur.

67
 • Changement d'ordinateur requis. Cette catégorie est réservée aux hôtes inaptes à satisfaire les 
exigences de sécurité de la solution du fait de leur incapacité matérielle à prendre en charge la 
configuration minimale acceptable. Il peut s'agir d'un ordinateur incapable d'exécuter un 
système d'exploitation sécurisé parce qu'il est doté d'un processeur trop ancien (par exemple, 
un ordinateur x86 de 100 mégahertz).

Utilisez ces groupes pour répartir les coûts d'implémentation de la solution sur des ordinateurs 
exigeant des mises à niveau.

État Connu, non approuvé

Lors du processus de catégorisation des hôtes d'une organisation, vous identifierez certains hôtes 
incapables de parvenir à un état approuvé pour des raisons bien connues et clairement définies. Ces 
raisons peuvent être de type suivant :

• Financier. Les fonds nécessaires à la mise à niveau du matériel ou des logiciels de cet hôte ne 
sont pas disponibles.

• Politique. L'hôte doit demeurer dans un état non approuvé en raison d'une situation politique ou 
commerciale qui ne lui permet pas de satisfaire les exigences de sécurité minimales dictées par 
l'organisation. Nous vous conseillons alors fortement de contacter le responsable de l'entreprise ou 
le fournisseur de logiciels indépendant de l'hôte pour débattre de la valeur ajoutée de l'isolation de 
serveurs et de domaines.

• Fonctionnel. L'hôte a besoin d'exécuter un système d'exploitation non sécurisé ou d'opérer de 
manière non sécurisée pour accomplir son rôle. Par exemple, l'hôte doit peut­être être utilisé avec 
un système d'exploitation plus ancien en raison d'une série d'applications commerciales 
spécifiques ne fonctionnant que sur ce système.

Beaucoup de raisons fonctionnelles peuvent justifier le maintien d'un hôte en état connu non 
approuvé. La liste suivante présente quelques exemples de motifs fonctionnels susceptibles de 
justifier un classement dans cet état :

• Ordinateurs dotés de Windows 9x ou Windows Millennium Edition. Les ordinateurs munis de 
ces versions particulières du système d'exploitation Windows ne peuvent pas être classées comme 
dignes de confiance car ces systèmes d'exploitation ne prennent en charge aucune infrastructure 
de sécurité de base. En fait, de par leur conception, ces systèmes ne disposent d'aucune 
infrastructure de sécurité. Qui plus est, les fonctions de gestion centrale rudimentaires dont ils sont 
pourvus ne concernent que des configurations informatiques pour utilisateurs (via la stratégie 
système et les scripts d'ouverture de session). Pour finir, ces systèmes d'exploitation n'offrent 
aucune des fonctionnalités requises pour la gestion de la sécurité.

• Ordinateurs dotés de Windows NT. Les ordinateurs dotés de Windows NT ne peuvent pas être 
classés comme dignes de confiance dans le contexte de l'isolation de serveurs et de domaines 
puisque ce système ne prend pas intégralement en charge une infrastructure de sécurité 
élémentaire. Par exemple, Windows NT ne prend pas en charge les listes de contrôle d'accès de 
refus dans les ressources locales, toute méthode visant à garantir la confidentialité et l'intégrité des 
communications réseau, les cartes à puce pour une authentification renforcée ou une gestion 
centralisée des configurations d'ordinateurs (bien qu'une gestion centralisée limitée des 
configurations d'utilisateurs soit possible). Windows NT n'offre aucun moyen de protéger la 
confidentialité des données et de maintenir leur intégrité, tel que le système EFS (Encrypting File 
System) de Windows 2000.
En outre, il ne prend pas en charge l'ensemble des fonctionnalités de sécurité requises. Par exemple, 
il ne prend pas en charge la stratégie de groupe ou les stratégies IPSec et ne fournit aucun 
mécanisme garantissant un accès au niveau Administrateur local si cela est nécessaire. Enfin, ses 

68
configurations de sécurité n'étant pas réappliquées régulièrement, il n'existe aucune garantie qu'elles 
demeurent effectives.
Remarque : la description de Windows NT comme système n'étant pas digne de confiance se limite 
strictement au contexte de l'isolation de serveurs et de domaines et ne concerne d'aucune manière 
son utilisation en tant que système d'exploitation dans le sens large du terme. Pour les serveurs de ce 
projet, la mise à niveau vers la plate­forme Windows Server 2003 représente la solution la plus sûre et 
la plus facile à gérer.

• Ordinateurs autonomes. Les ordinateurs dotés d'une version quelconque de Windows et 
configurés comme ordinateurs autonomes ou en qualité de membres d'un groupe de travail sont, 
en règle générale, incapables de parvenir à un état digne de confiance. Même si ces systèmes 
d'exploitation prennent intégralement en charge l'infrastructure de sécurité de base minimale 
requise, il est peu probable que les fonctionnalités requises pour la gestion de la sécurité soient 
garanties lorsque l'ordinateur n'est pas membre d'un domaine approuvé.

• Ordinateurs dans un domaine non approuvé. Un ordinateur membre d'un domaine qui n'est pas 
approuvé par le service informatique d'une organisation ne peut pas être classé comme approuvé. 
Un domaine non approuvé est un domaine qui n'offre pas les fonctionnalités de sécurité requises à 
ses membres. Même si les systèmes d'exploitation des ordinateurs membres de ce domaine non 
approuvé prennent intégralement en charge l'infrastructure de sécurité de base minimale requise, 
les fonctionnalités requises pour la gestion de la sécurité ne peuvent pas être garanties à 100 % 
lorsque les ordinateurs ne résident pas dans un domaine approuvé. Par exemple, dans un 
domaine non approuvé, il n'existe aucun mécanisme garantissant l'octroi d'un accès de niveau 
Administrateur local pour un utilisateur approuvé. De même, les configurations de sécurité (y 
compris celles qui peuvent être gérées de manière centrale) peuvent facilement être remplacées 
par les administrateurs du domaine non approuvé. Enfin, le respect de la configuration de sécurité, 
des logiciels, des stratégies et des normes ne peut être garanti et les mesures chargées de 
contrôler de manière efficace toutes les règles de conformité ne sont pas disponibles.

• Ordinateurs dans un domaine Windows NT. Les ordinateurs membres d'un domaine fondé sur 
Windows NT ne peuvent pas être classés comme étant approuvés. Même si leurs systèmes 
d'exploitation prennent intégralement en charge l'infrastructure de sécurité de base minimale 
requise, les fonctionnalités requises pour la gestion de la sécurité ne sont pas entièrement prises 
en charge lorsque les ordinateurs appartiennent à un domaine Windows NT.

Néanmoins, si l'hôte doit être pris en compte lors de la conception parce qu'il joue un rôle 
indispensable pour l'organisation, il est préférable que vous lui affectiez un état connu, non approuvé. 
Cela signifie alors que la solution a identifié un risque qu'elle ne peut minimiser. Vous devez faire 
appel à d'autres techniques pour répondre à cette menace connue. En raison de la nature variée des 
hôtes appartenant à cette catégorie, aucune instruction spécifique concernant ces techniques ne peut 
être fournie. Néanmoins, l'objectif de ces techniques doit être de minimiser les risques posés par cet 
hôte.

État Inconnu, non approuvé

L'état Inconnu, non approuvé doit être utilisé comme état par défaut pour tous les hôtes. Du fait de la 
configuration inconnue des hôtes affichant cet état, aucune confiance ne peut leur être accordée. Le 
processus tout entier de planification des hôtes dans cet état doit partir du principe que l'hôte risquait 
ou risque d'être compromis et constitue, par conséquent, un risque inacceptable pour l'organisation. 
Les personnes chargées de concevoir la solution doivent s'efforcer de minimiser l'impact potentiel des 
ordinateurs dotés de cet état sur leurs organisations.

Identification des coûts de mise à niveau des hôtes 
actuels

69
L'ultime étape de ce chapitre concerne le processus d'enregistrement du coût approximatif de la mise 
à niveau des ordinateurs en vue de rendre ces derniers aptes à contribuer à la solution. Plusieurs 
décisions seront à prendre lors de la phase de conception du projet et exigeront que vous répondiez 
aux questions suivantes :

• L'ordinateur répond­il aux exigences de configuration matérielle requises pour l'isolation ?
• L'ordinateur répond­il aux exigences de configuration logicielle requises pour l'isolation ?
• Quelles modifications devez­vous apporter à la configuration pour intégrer cet ordinateur à la 
solution d'isolation ?

• Quel coût prévisionnel ou impact suite aux modifications proposées peut permettre de parvenir à 
un état approuvé ?

En répondant à ces questions, vous pouvez rapidement déterminer le niveau d'effort et le coût 
approximatif requis pour intégrer un hôte ou un groupe d'hôtes particulier à l'échelle du projet. Il est 
fort probable qu'aucune personne, voire plusieurs personnes dans un seul rôle, ne rassemble toutes 
ces données. Certaines de ces données peuvent être recueillies par des techniciens du support 
technique ou d'un service de terrain ; d'autres exigeront le point de vue d'un architecte ou d'un 
membre de la direction. Gardez toujours à l'esprit que l'état d'un ordinateur est transitif et qu'en 
entreprenant les actions correctives présentées, vous pouvez changer l'état d'un ordinateur et le faire 
passer de non approuvé à approuvé. Après avoir décidé si un ordinateur doit être approuvé ou non, 
vous êtes p rêt à entamer le proce ssus de planification et de conception, thèmes que le chapitre 4 
(« Conception et planification de groupes d'isolation ») aborde plus loin dans ce guide.

Le tableau ci­dessous est un exemple de fiche à l'aide de laquelle vous pouvez identifier l'état actuel 
d'un hôte et les conditions de son passage à un état approuvé.

Tableau 3.3 : Exemple de données collectées sur l'hôte

Nom de  Config.  Config.  Configuration.  Détails Coût 

l'hôte matérielle  logicielle  requise prévisionnel
conforme conforme
HOST­NYC­ Non Non Mise à niveau  Le système  $XXX.
001 matérielle et  d'exploitation 
logicielle actuel est 
Windows NT 4.0. 
L'ancien matériel 
n'est pas 
compatible avec 
Windows XP SP2
.

SERVER­ Oui Non Intégrer  Aucun logiciel  $XXX.

LON­001 domaine  antivirus présent.
approuvé, 
mettre à 
niveau de NT 4 
vers 
Windows 2000 
ou ultérieur.

La liste suivante explique chaque colonne du tableau 3.3 :

70
• Nom de l'hôte. Nom du dispositif hôte sur le réseau.
• Configuration matérielle conforme. Indique si un ordinateur répond aux exigences de 
configuration matérielle requises pour participer à la solution.

• Configuration logicielle conforme. Indique si un ordinateur répond aux exigences de 
configuration logicielle requises pour participer à la solution. Le minimum requis pour la Woodgrove 
Bank est Windows 2000 SP4, Windows XP SP2 ou Windows Server 2003, ainsi que tous les 
correctifs de sécurité requis pour chaque système d'exploitation. De plus, tous les ordinateurs 
doivent appartenir à un domaine approuvé (soit un domaine géré centralement par le personnel 
informatique de la Woodgrove Bank) et fournir de manière spécifique aux administrateurs 
informatiques un accès à l'ordinateur.

• Configuration requise. Indique quelle action entreprendre pour permettre à l'ordinateur d'atteindre 
l'état approuvé.

• Détails. Décrit les raisons pour lesquelles l'ordinateur n'affiche actuellement pas un état approuvé.
• Coût prévisionnel. Indique le coût prévisionnel qui permettra au périphérique d'accéder à un état 
approuvé. Ce coût doit inclure des estimations portant sur les logiciels, le matériel, la perte de 
productivité et le support. Ces informations permettront de déterminer s'il est pratique ou valable du 
point de vue commercial d'ajouter à la solution un ordinateur particulier en tant qu'ordinateur 
approuvé.

Dans le tableau précédent, l'hôte HOST­NYC­001 est actuellement « connu, non approuvé ». 
Néanmoins, il peut être considéré comme digne de confiance si les mises à niveau requises sont 
possibles. Cependant, si un grand nombre d'ordinateurs exigent les mêmes mises à niveau, le coût 
global de la solution peut considérablement augmenter.

L'hôte SERVER­LON­001 répond aux conditions matérielles requises mais doit être mis à niveau vers 
un système d'exploitation capable d'exploiter la stratégie IPSec et associé à un domaine. Il requiert 
également un logiciel antivirus. Le coût prévisionnel correspond à la somme des efforts requis pour 
mettre à niveau le système d'exploitation et installer des logiciels antivirus, plus le coût des licences 
du système d'exploitation et des logiciels antivirus.

Après vous être procuré les informations décrites dans le tableau 3.3, enregistrez­les avec les autres 
informations rassemblées au cours de ce chapitre afin que l'architecte ou l'équipe de conception 
puisse les exploiter. Ces informations constitueront la base des efforts entrepris au chapitre 4 qui se 
concentre sur la conception des groupes d'isolation.

Notez que les coûts identifiés dans cette section concernent uniquement le coût prévisionnel des 
mises à niveau des hôtes. Beaucoup d'autres coûts liés à la conception, au support, aux tests et à la 
formation viendront se greffer au projet. Ces coûts supplémentaires devront être pris en compte dans 
le plan global du projet si un coût précis doit être évalué pour le projet.

Résumé
Ce chapitre offre un aperçu des informations requises pour mener un projet d'isolation de serveurs et 
de domaines, notamment les considérations d'impact. Vous pouvez utiliser les instructions de ce 
chapitre pour effectuer les opérations suivantes :

• Identifier les ressources sur le réseau.
• Rassembler des informations sur le réseau.
• Rassembler des informations sur les hôtes.

71
• Définir les données du trafic actuel.
• Examiner l'architecture Active Directory actuelle et recueillir des informations pertinentes la 
concernant.

• Examiner les éléments à considérer en terme de capacité IPSec.
• Afficher les considérations de prédéploiement pour IPSec.
• Expliquer ce que sont des dispositifs dignes ou non dignes de confiance et comment ils ont été 
classés dans le scénario imaginé pour la Woodgrove Bank.

La réalisation de ces tâches permettra de réunir toutes les informations dont vous aurez besoin pour 
lancer la conception de groupes d'isolation au chapitre suivant.

Informations complémentaires

Cette section fournit des liens vers des informations supplémentaires pouvant s'avérer utiles lors de 
l'implémentation de cette solution :

• Pour plus d'informations sur la configuration des pare­feu pour la prise en charge d'IPSec pour 
Windows Server 2003, consultez la page Configuring Firewalls   (Configuration des pare­feu) de 
la documentation Windows Server 2003 à l'adresse www.microsoft.com/resources/documentation/
WindowsServ/2003/all/deployguide/en­us/dnsbj_ips_schx.asp.

• Vous pouvez télécharger le pack d'installation de Windows Management Instrumentation (WMI) 
CORE 1.5 (Windows 95/98/NT 4.0)   depuis le Centre de téléchargement de Microsoft à 
l'adresse www.microsoft.com/downloads/details.aspx?FamilyID=afe41f46­e213­4cbf­9c5b­
fbf236e0e875&DisplayLang=en.

• Pour plus d'informations sur WMI, consultez la documentation Windows Management 
Instrumentation   sur MSDN® à l'adresse http://msdn.microsoft.com/library/en­us/wmisdk/
wmi/wmi_start_page.asp.

• Vous pouvez télécharger Microsoft Windows Script 5.6 pour Windows
      2000 et XP    depuis le 
Centre de téléchargement de Microsoft à l'adresse www.microsoft.com/downloads/details.aspx?
FamilyId=C717D943­7E4B­4622­86EB­95A22B832CAA&displaylang=en.

• Vous pouvez télécharger Microsoft Windows Script 5.6 pour Windows
      98, Windows Millennium  
 Edition et Windows    NT 4.0    depuis le Centre de téléchargement de Microsoft à l'adresse 
www.microsoft.com/downloads/details.aspx?FamilyId=0A8A18F6­249C­4A72­BFCF­
FC6AF26DC390&displaylang=en.

• Vous pouvez télécharger la documentation de Windows Script 5.6   depuis le Centre de 
téléchargement de Microsoft à l'adresse www.microsoft.com/downloads/details.aspx?
FamilyId=01592C48­207D­4BE1­8A76­1C4099D7BBB9&displaylang=en.

72
Chapitre 4 : Conception et planification 
de groupes d'isolation
Ce chapitre détaille la définition de groupes d'isolation répondant aux exigences de sécurité 
commerciale décrites dans le chapitre 2, « Présentation de l'isolation de serveurs et de domaines ». 
Cette solution utilise une combinaison de l'identité de l'ordinateur dans le domaine de service 
d'annuaire Active Directory®, de la stratégie IPSec pour authentifier cette identité et de la stratégie de 
sécurité Microsoft® Windows® pour définir et appliquer des groupes d'isolation. Les administrateurs 
informatiques peuvent utiliser le concept de groupes d'isolation pour gérer le trafic dans leurs réseaux 
internes de manière sécurisée transparente aux applications. Cette possibilité peut réduire 
sensiblement la menace de dommages provenant d'infections et d'attaques via le réseau.

Par le biais du scénario Woodgrove Bank, ce guide fournit les principaux détails sur la manière dont 
une organisation peut transformer ses exigences de sécurité en groupes d'isolation déployés. Il 
indique également comment IPSec peut être combiné à d'autres paramètres de sécurité pour élaborer 
une solution d'isolation de serveurs et de domaines détaillée, maniable et évolutive.

Chaque organisation devra élaborer la solution en fonction des exigences qui lui sont propres, et les 
modèles utilisés dans ce guide ne sont pas destinés à être suivis sans question ni modification. Les 
organisations utilisant ce guide devront déterminer ce qui est requis et possible dans leur propre 
environnement, et apporter les modifications appropriées à la conception du modèle de groupe 
d'isolation en vue de l'adapter au mieux aux exigences spécifiques de leur activité.

Connaissances préalables requises pour ce chapitre
Cette section contient des informations qui vous aideront à déterminer l'approche de votre 
organisation par rapport à la solution d'isolation de serveurs et de domaines. La réussite de la solution 
dépend des conditions préalables requises identifiées dans cette section.

Connaissances requises

Vous devez connaître les concepts et la terminologie associés à IPSec. Il est également important 
d'avoir des connaissances concernant Microsoft Windows Server™ 2003 dans les domaines 
suivants :

• Stratégie et filtres IPSec, actions de filtrage et listes de filtres
• Concepts relatifs à Active Directory (notamment la structure et les outils Active Directory, la 
manipulation des utilisateurs, des groupes et d'autres objets Active Directory, les services de 
résolution de noms et utilisation d'une stratégie de groupe)

• Concepts d'authentification, comprenant le processus d'ouverture de session de Windows et le 
protocole Kerberos version 5

• Sécurité du système Windows (concepts de sécurité tels que les utilisateurs, les groupes, l'audit et 
les listes de contrôle d'accès, l'utilisation des modèles de sécurité et l'application des modèles de 
sécurité à l'aide de la stratégie de groupe ou des outils de ligne de commande).

Avant de poursuivre la lecture de ce chapitre, vous devez avoir lu les chapitres précédents de ce 
guide.

73
Conditions requises pour l'organisation

Vous devez consulter les membres de votre organisation qui peuvent être impliqués dans 
l'implémentation de cette solution, notamment :

• les cadres exécutifs ;
• les personnes chargées de l'audit et de la sécurité ;
• les ingénieurs, les administrateurs et les équipes opérationnelles Active Directory ;
• les ingénieurs et les personnes chargées de l'administration et de l'exploitation du réseau et du 
DNS (Domain Name System).
Remarque : selon la structure de votre organisation informatique, ces rôles peuvent être remplis par 
plusieurs personnes, ou une même personne peut remplir plusieurs rôles. Cependant, il est important 
d'identifier un seul point de contact pour aider à coordonner les efforts des équipes d'organisation à 
travers les diverses phases du projet.

Ce chapitre suppose également que vous avez satisfait les exigences répertoriées dans le chapitre 2, 
« Présentation de l'isolation de serveurs et de domaines », et le chapitre 3, « Détermination de l'état 
actuel de votre infrastructure informatique », notamment la collecte d'informations à partir des hôtes, 
du réseau et d'Active Directory. Le recensement des exigences commerciales et l'obtention du support 
de la direction sont également abordés.

Enfin, vous devez disposer d'un plan en place pour former les divers personnels d'assistance et de 
support aux nouveaux concepts, terminologies et technologies de cette solution. Cette solution 
affectant de nombreux domaines de l'organisation, le personnel de support doit être formé pour gérer 
tout problème apparaissant durant le déploiement.

Configuration requise pour l'infrastructure informatique

Ce chapitre suppose l'existence de l'infrastructure informatique suivante :

• Un domaine Active Directory Windows Server 2003 fonctionnant en mode mixte ou natif. Cette 
solution utilise des groupes universels pour l'application de l'objet Stratégie de groupe. Si 
l'organisation ne fonctionne pas en mode mixte ou natif, il reste possible d'appliquer l'objet 
Stratégie de groupe à l'aide de groupes globaux et locaux standards. Cependant, cette option étant 
plus complexe à gérer, cette solution ne l'utilise pas.
Remarque : Windows Server 2003 a introduit un certain nombre d'améliorations qui affectent les 
stratégies IPSec. Aucune spécificité de cette solution ne l'empêche de fonctionner avec 
Windows 2000. Cependant, la solution n'a été testée qu'avec Windows Server 2003 Active Directory.
Pour plus d'informations sur les améliorations apportées à IPSec dans Windows Server 2003, 
reportez­vous à la page New features for IPSec   (Nouvelles fonctionnalités d'IPSec) sur le site Web 
de Microsoft à l'adresse www.microsoft.com/resources/documentation/
WindowsServ/2003/standard/proddocs/en­us/ipsec_whatsnew.asp.

Création de la conception d'isolation de serveurs et 
de domaines
La conception de la solution dépend largement des exigences de l'entreprise et des informations 
collectées dans les chapitres précédents. Le chapitre 2, « Présentation de l'isolation de serveurs et de 
domaines », et l'annexe D, « Catégories de menaces informatiques », décrivent les composants de la 

74
solution et identifient les menaces auxquelles elle peut ou non répondre. Le chapitre 3, 
« Détermination de l'état actuel de votre infrastructure informatique », fournit des informations sur la 
manière de collecter des données de planification, telles que l'architecture réseau actuelle et les 
ressources d'hôtes sur le réseau. Ce chapitre utilise les informations et exigences collectées pour 
Woodgrove Bank, qui sont enregistrées en détail dans le fichier Business_Requirements.xls 
(disponible dans le dossier Tools and Templates). Reportez­vous à ce fichier durant le processus de 
conception détaillé dans ce chapitre pour mieux comprendre les choix effectués pour la conception de 
la solution. Le processus de conception de la solution implique les principales tâches suivantes :

• Modélisation de groupes de base
• Planification des groupes d'ordinateurs et d'accès au réseau
• Création de groupes d'isolation supplémentaires
• Modélisation des exigences de trafic réseau
• Affectation de membres au groupe d'ordinateurs et au groupe d'accès réseau

Les sections suivantes expliquent chacune de ces tâches.

Modélisation de groupes de base

Pour la plupart des implémentations, il est recommandé de se baser sur un point de départ commun 
pour les groupes d'isolation initiaux. L'illustration suivante présente les deux groupes d'isolation 
initiaux à envisager.

Figure 4.1 Groupes d'isolation de base

Les groupes de base offrent des conteneurs logiques constituant un excellent point de départ pour la 
conception de groupes d'isolation.

75
Systèmes non approuvés

Conceptuellement, le mieux est de commencer par les ordinateurs non détenus, ni gérés, voire ceux 
dont l'existence est inconnue du service informatique de l'organisation. Ces ordinateurs sont 
généralement désignés comme hôtes non approuvés ou non gérés et sont les premiers systèmes à 
identifier dans la conception. Ils ne feront pas partie de la solution car ils ne seront pas en mesure 
d'utiliser les stratégies IPSec affectées par le domaine.

Exemples d'ordinateurs rattachés à ce groupe :

• Ordinateurs et périphériques non Windows. Les stations de travail Macintosh et UNIX ainsi que 
les assistants numériques personnels (PDA) peuvent ne pas disposer de fonctionnalités IPSec 
prêtes à l'emploi.

• Anciennes versions du système d'exploitation Windows. Les ordinateurs exploitant Microsoft 
Windows NT® version 4.0 et Windows 9x ne peuvent pas utiliser IPSec basé sur une stratégie de 
groupe.

• Ordinateurs Windows non rattachés à un domaine approuvé. Les ordinateurs autonomes ne 
seront pas en mesure de s'authentifier à l'aide d'une approbation de domaine Kerberos dans 
Internet Key Exchange (IKE). Un ordinateur rattaché à un domaine non approuvé par la forêt 
utilisée comme limite sécurisée pour l'authentification IKE ne sera pas en mesure de participer à la 
solution d'isolation de domaines ou de serveurs.

• Autres clients VPN ou d'accès distant non Microsoft. Si un client de réseau privé virtuel (VPN) 
IPSec non Microsoft est utilisé pour une solution d'accès distant d'une organisation, l'installation a 
probablement désactivé le service IPSec Windows natif. Si le service IPSec Windows natif ne peut 
pas être utilisé, l'hôte ne pourra pas participer à cette solution. 

Même si le service IPSec Windows natif est actif, le client VPN doit permettre la communication IKE et 
IPSec de bout en bout via la connexion de tunnel VPN. Si IPSec de bout en bout ne fonctionne pas 
via la connexion VPN, il est possible de créer une exemption pour tous les sous­réseaux IP utilisés 
pour l'accès distant. Lorsque ce client distant se reconnecte au réseau interne, il peut à nouveau 
participer à la solution d'isolation.

Domaine d'isolation

Le domaine d'isolation offre le premier conteneur logique pour les hôtes approuvés. Les hôtes de ce 
groupe utilisent une stratégie IPSec pour contrôler les communications entrantes et sortantes 
autorisées. Le terme domaine est utilisé dans ce contexte pour représenter une zone de confiance 
plutôt que pour suggérer un domaine Windows. Dans cette solution, les deux constructions sont très 
similaires car l'authentification de domaine Windows (Kerberos) est requise pour accepter les 
connexions entrantes d'hôtes approuvés. Cependant, de nombreux domaines (ou forêts) Windows 
peuvent être liés à des relations de confiance pour fournir un seul domaine d'isolation logique. Ils ne 
doivent donc pas être confondus.

L'objectif des caractéristiques de communications du domaine d'isolation est de fournir les règles 
« normales » ou standards pour la majorité des ordinateurs de l'organisation. Ainsi, pour la plupart des 
implémentations, un domaine d'isolation contiendra le plus grand nombre d'ordinateurs. D'autres 
groupes d'isolation peuvent être créés pour la solution si leurs exigences de communication sont 
différentes de celles du domaine d'isolation. Conceptuellement, un domaine d'isolation est juste un 
type de groupe d'isolation.

76
Groupe de limite

Presque toutes les organisations comprennent un certain nombre de stations de travail, ou serveurs, 
incapables de communiquer via IPSec. C'est par exemple probablement le cas des ordinateurs tels 
que les stations de travail Mac ou UNIX. Ces ordinateurs doivent souvent communiquer dans 
l'entreprise avec des hôtes approuvés du domaine d'isolation. Dans un monde idéal, tous les hôtes du 
réseau interne seraient en mesure d'être approuvés au même niveau et d'utiliser IPSec, et la 
conception serait plus simple. Cependant, dans la réalité, tous les systèmes d'exploitation n'offrent 
pas le même degré de prise en charge d'IPSec.

Dans cette situation, il est recommandé de créer un groupe d'isolation (désigné comme groupe de 
limite dans ce guide) contenant les hôtes qui seront autorisés à communiquer avec des systèmes non 
approuvés. Ces hôtes seront exposés à un niveau de risque supérieur, car ils peuvent recevoir des 
communications entrantes provenant directement d'ordinateurs non approuvés.

Les ordinateurs du groupe de limite sont des hôtes approuvés pouvant communiquer à la fois avec 
d'autres hôtes approuvés et avec des hôtes non approuvés. Les hôtes du groupe de limite tenteront 
de communiquer à l'aide d'IPSec en lançant une négociation IKE avec l'ordinateur d'origine. Si aucune 
réponse IKE n'est reçue dans les trois secondes, l'hôte communique en texte clair et tente alors 
d'établir des communications en texte clair sans IPSec. Les hôtes du groupe de limite peuvent avoir 
une adresse IP dynamique car ils utilisent une stratégie IPSec comme tout autre hôte approuvé du 
domaine d'isolation. Puisque ces hôtes du groupe de limite seront autorisés à communiquer avec des 
hôtes approuvés utilisant des communications réseau sécurisées par IPSec et des hôtes non 
approuvés utilisant les communications en texte clair, ils doivent être hautement sécurisés par 
d'autres moyens. La compréhension et l'atténuation de ce risque supplémentaire doivent constituer 
une part importante du processus de décision du placement éventuel d'un ordinateur dans le groupe 
de limite. Par exemple, la définition d'un processus de justification d'entreprise formel pour chaque 
ordinateur avant de convenir de le placer dans ce groupe peut aider à garantir que toutes les parties 
concernées comprennent pourquoi ce risque supplémentaire doit être pris. L'illustration suivante 
montre un exemple de processus pouvant faciliter une telle décision.

77
Figure 4.2 Organigramme décisionnel d'exemple de processus d'appartenance au groupe de limite

L'objectif de ce processus est de déterminer si le risque d'ajout d'un hôte au groupe de limite peut être 
atténué à un niveau acceptable pour l'organisation. En dernier ressort, il doit être supposé que si le 
risque ne peut pas être atténué, l'appartenance au groupe doit être refusée. 

78
Création de listes d'exemptions

Les modèles de sécurité d'isolation de serveurs et de domaines subissent tous quelques contraintes 
lorsqu'ils sont implémentés dans un environnement réel. Les principaux serveurs d'infrastructure tels 
que les contrôleurs de domaine et les serveurs DNS et DHCP (Dynamic Host Configuration Protocol) 
sont généralement disponibles pour tous les systèmes du réseau interne. Il est évident qu'ils doivent 
être sécurisés au maximum contre les attaques réseau. Cependant, comme ils sont disponibles pour 
tous les systèmes du réseau, et non simplement les membres du domaine, ces services de serveur ne 
peuvent pas exiger IPSec pour l'accès entrant, ni profiter de l'utilisation de la protection du mode de 
transport IPSec pour tout leur trafic. Parce qu'un délai de basculement en clair de trois secondes pour 
accéder à ces services, en particulier DNS, aurait un sérieux impact sur les performances de tout 
l'accès au réseau interne, ils ne sont pas candidats pour le groupe de limite. De plus, les hôtes 
approuvés exigent un accès au serveur DHCP pour obtenir une adresse IP (Internet Protocol) durant 
le démarrage de l'ordinateur ou lorsque le câble ou la carte réseau est branché(e) sur un ordinateur 
portable. Les hôtes approuvés exigent également DNS pour localiser les contrôleurs de domaine afin 
de pouvoir se connecter au domaine et recevoir des informations d'identification Kerberos. Par 
conséquent, une liste de serveurs et de services (protocoles) exempts d'utiliser IPSec sera requise 
pour qu'IPSec fonctionne correctement, ainsi que pour permettre à tous les hôtes internes de partager 
l'infrastructure commune de réseau interne. La liste d'ordinateurs qui ne peuvent pas être sécurisés 
avec IPSec est appelée liste d'exemptions et est implémentée dans chaque stratégie IPSec conçue. Il 
peut également y avoir d'autres serveurs sur le réseau auxquels des hôtes approuvés ne peuvent pas 
accéder à l'aide d'IPSec, qui doivent être ajoutés à la liste d'exemptions. En général, un hôte doit 
figurer dans la liste d'exemptions s'il répond à l'une des conditions suivantes :

• L'hôte est un ordinateur auquel des hôtes approuvés doivent accéder, mais qui ne possède pas 
d'implémentation IPSec compatible.

• L'hôte fournit des services pour des hôtes non approuvés et approuvés, mais ne répond pas aux 
critères d'appartenance du groupe d'isolation de limite.

• L'hôte est utilisé pour une application affectée par le délai de 3 secondes avant retour à la 
communication en clair ou par l'encapsulation IPSec du trafic de l'application.

• L'hôte prend en charge plusieurs milliers de clients simultanément et il a été déterminé qu'IPSec ne 
pouvait pas être utilisé en raison de l'impact sur les performances.

• L'hôte gère des hôtes approuvés de différents domaines d'isolation ne s'approuvant pas 
mutuellement.

• L'hôte est un contrôleur de domaine, car IPSec n'est actuellement pas pris en charge entre un 
contrôleur de domaine et un membre de domaine. Cependant, les contrôleurs de domaine satisfont 
d'autres critères de cette liste et offrent également la stratégie IPSec aux membres du domaine et 
l'authentification Kerberos sur laquelle est basé le concept d'isolation.

• L'hôte gère des hôtes approuvés et non approuvés, mais il n'utilisera jamais IPSec pour sécuriser 
des communications avec des hôtes approuvés.

L'implémentation IPSec de Windows gère uniquement le filtrage statique, et non dynamique (ou avec 
état). Par conséquent, une exemption statique pour le trafic sortant est également une exemption 
statique pour le trafic entrant. Les hôtes exemptés disposent par conséquent d'un accès entrant non 
authentifié sur chaque hôte, approuvé ou non. Ainsi, le nombre d'hôtes exemptés doit être aussi 
restreint que possible, et ces hôtes doivent être gérés de près et renforcés autant que possible contre 
les attaques et infections. Pour aider à atténuer le risque d'attaques entrantes provenant d'hôtes de la 
liste d'exemptions, un pare­feu de filtrage avec état basé sur l'hôte, tel que le Pare­feu Windows, peut 
être utilisé. Windows XP Service Pack (SP) 2 a fourni des contrôles de stratégie de groupe basée sur 
le domaine pour la configuration du pare­feu. Le Pare­feu Windows prend également en charge la 
possibilité d'autoriser uniquement certains ordinateurs via le pare­feu lors de la protection par IPSec, à 
l'aide du paramètre de stratégie « Pare­feu Windows : autoriser à ignorer la sécurité IPSec 

79
 authentifiée ». Woodgrove Bank a choisi de ne pas implémenter le Pare­feu Windows. Cependant, 
d'autres environnements peuvent trouver nécessaire d'atteindre des niveaux de sécurité élevés dans 
un domaine ou un groupe isolé. Pour plus d'informations, reportez­vous au livre blanc « Deploying 
 Windows Firewall Settings for Microsoft Windows    XP with Service Pack    2    » (Déploiement de 
paramètres du Pare­feu Windows pour Microsoft Windows XP avec Service Pack 2) depuis le centre 
de téléchargement de Microsoft à l'adresse http://go.microsoft.com/fwlink/?LinkId=23277.

Dans les organisations de taille importante, la liste d'exemptions peut s'allonger considérablement si 
toutes les exemptions sont implémentées par une stratégie IPSec pour l'ensemble du domaine ou 
pour toutes les forêts approuvées. Une longue liste produit un certain nombre d'effets indésirables sur 
chaque ordinateur recevant la stratégie, notamment :

• Elle réduit l'efficacité globale de l'isolation.
• Elle alourdit la charge de gestion (suite aux fréquentes mises à jour).
• Elle augmente la taille de la stratégie, ce qui signifie qu'elle consomme plus de mémoire et de 
ressources processeur, ralentit le débit du réseau, et allonge le délai de téléchargement et 
d'application de la stratégie.

Pour maintenir le nombre d'exemptions aussi bas que possible, vous avez plusieurs possibilités :

• N'utilisez pas d'exemption si les communications peuvent résister au délai de 3 secondes avant 
retour à la communication en clair. Cette option ne s'applique pas aux contrôleurs de domaine.

• Considérez avec soin les exigences de communications de chaque groupe d'isolation, en 
particulier des groupes serveur uniquement. Ils peuvent ne pas avoir à communiquer avec chaque 
exemption de la stratégie de niveau domaine des clients.

• Consolidez les fonctions de serveur. Si plusieurs services exempts peuvent résider sur la même 
adresse IP, le nombre de filtres sera réduit.

• Consolidez des hôtes exemptés sur le même sous­réseau. Lorsque le volume de trafic réseau 
l'autorise, les serveurs peuvent résider sur un sous­réseau exempté, au lieu d'utiliser des 
exemptions pour chaque adresse IP.

Comme pour la définition du groupe de limite, un processus formel est souhaitable pour approuver les 
hôtes ajoutés à la liste d'exemptions. Reportez­vous à l'organigramme décisionnel de l'illustration 
précédente comme modèle pour le traitement des demandes d'exemptions.

Planification des groupes d'accès aux ordinateurs et au réseau

Le domaine d'isolation et chaque groupe d'isolation doivent avoir des spécifications claires et 
complètes des exigences de sécurité réseau. La feuille de calcul Business_Requirements.xls du 
dossier Tools and Templates fournit un modèle de la manière dont les exigences peuvent être 
référencées. Une fois les exigences entrantes et sortantes décrites, vous pouvez concevoir les 
mécanismes d'implémentation des contrôles d'accès.

À ce stade du processus, il est conseillé de commencer à recenser les nouveaux groupes 
Active Directory qui seront requis pour répondre aux exigences de groupe d'isolation. Pour chaque 
groupe d'isolation, vous devrez créer jusqu'à trois groupes Active Directory spécialisés. La section 
suivante explique le rôle de chacun de ces groupes.

80
Groupes d'ordinateurs

Chaque groupe d'isolation nécessitera la création d'un groupe d'ordinateurs qui sera utilisé pour 
contenir les membres du groupe d'isolation. Ceci est requis car les exigences de sécurité d'un groupe 
d'isolation sont remplies par plusieurs types de paramètres de sécurité dans des objets Stratégie de 
groupe affectés dans le domaine. Par exemple, cette solution utilise un filtrage de groupe de sécurité 
sur les objets Stratégie de groupe pour fournir une stratégie IPSec aux ordinateurs d'un groupe 
d'isolation particulier. Les comptes d'ordinateurs membres du groupe d'ordinateurs se verront affecter 
la stratégie IPSec associée lors du traitement de l'objet Stratégie de groupe. Ceci évite d'avoir à 
changer ou créer une nouvelle structure d'unité d'organisation (UO) basée sur l'appartenance à un 
groupe d'isolation pour appliquer les objets Stratégie de groupe corrects. Si la structure d'UO peut être 
modifiée pour refléter l'appartenance au groupe d'isolation, ces groupes de sécurité d'ordinateurs ne 
sont pas requis pour contrôler l'application de la stratégie de groupe.

Tableau 4.1 : Groupes d'ordinateurs Woodgrove Bank

Nom du groupe d'ordinateurs Description
CG_IsolationDomain_Computers Ce groupe universel contiendra tous les 
ordinateurs faisant partie du domaine d'isolation.

CG_BoundaryIG_Computers Ce groupe contiendra tous les ordinateurs 
autorisés à accepter une communication de 
systèmes non approuvés.

Groupes d'accès au réseau

L'utilisation d'IPSec et de Kerberos seuls fournit une limite d'authentification approuvée et non 
approuvée. Pour aider à différencier ce groupe de tout autre, ce guide désigne ces groupes en tant 
que groupes d'accès réseau.

Vous pouvez créer deux types de groupes d'accès réseau : Autoriser et Refuser. Ces groupes 
contrôlent la capacité d'autres systèmes approuvés à autoriser ou refuser explicitement l'accès. Ce 
contrôle est obtenu en utilisant le droit d'utilisateur « Interdire l'accès à cet ordinateur à partir du 
réseau » (REFUSER) ou « Accéder à cet ordinateur à partir du réseau » (AUTORISER) dans la 
stratégie de groupe. 

Techniquement, ce contrôle d'accès par droit d'utilisateur s'applique uniquement aux services réseau 
recevant des informations d'identification de connexion pour authentifier le compte pour l'ouverture de 
session réseau. Le « compte » peut être un compte d'ordinateur, d'utilisateur ou de service. Lorsque la 
stratégie IPSec est configurée pour protéger tout le trafic, IKE confirmera que l'ordinateur distant 
possède un droit de connexion réseau. Par conséquent, le droit de connexion réseau contrôle 
désormais la possibilité pour un ordinateur distant d'établir des connexions protégées par IPSec. Une 
fois ce contrôle d'accès de niveau IP vérifié, les protocoles de niveau supérieur normaux (par 
exemple, le partage de fichiers) authentifient en général l'utilisateur, ce qui évalue à nouveau les droits 
de connexion réseau de l'identité d'utilisateur. Enfin, les autorisations spécifiques au service (telles 
que les listes de contrôle d'accès au partage de fichiers) sont évaluées à l'aide de l'identité de 
l'utilisateur. Pour plus d'informations, reportez­vous au diagramme Protection renforcée avec l'isolation 
logique dans le chapitre 2, « Présentation de l'isolation de serveurs et de domaines ».

Par défaut, le droit d'utilisateur AUTORISER contient le groupe Tout le monde, qui autorise tous les 
utilisateurs et ordinateurs authentifiés à accéder à l'ordinateur. Durant l'implémentation de cette 
solution, le groupe Tout le monde sera remplacé via l'affectation de droits d'utilisateur de stratégie de 
groupe par des groupes d'accès réseau contenant des ordinateurs ou utilisateurs et groupes 
spécifiques, selon les exigences de l'organisation. De même, le droit d'utilisateur REFUSER 

81
contiendra des ordinateurs non supposés disposer d'un accès entrant protégé par IPSec. Bien qu'il 
soit possible d'utiliser un seul groupe pour contenir les comptes d'utilisateurs et d'ordinateurs, 
Microsoft recommande l'utilisation de groupes distincts, un pour les utilisateurs et un pour les 
ordinateurs. Cette approche améliore la possibilité de gérer et prendre en charge ces stratégies et 
groupes en continu. La configuration de l'affectation des droits d'utilisateur AUTORISER et REFUSER 
complète les directives fournies par les guides de sécurité des plates­formes Windows antérieures, qui 
ne traitaient pas spécifiquement de l'authentification des ordinateurs exigée par IPSec.

Les groupes d'accès réseau peuvent implémenter les exigences suivantes :

• Bloquer l'accès réseau aux serveurs sensibles à partir d'hôtes limites ou d'hôtes approuvés situés 
dans des zones publiques.

• Limiter l'accès aux serveurs des cadres supérieurs aux seuls ordinateurs clients utilisés par ces 
cadres.

• Isoler les hôtes approuvés d'un projet de recherche et développement de tous les autres hôtes 
approuvés du domaine.

Dans le scénario Woodgrove Bank, une exigence commerciale limite la quantité de nouveau matériel 
informatique pouvant être acheté au cours d'une année. Un serveur d'impression était requis pour 
permettre à la fois aux hôtes approuvés et non approuvés d'imprimer. Bien que Woodgrove aurait 
préféré acheter un nouveau serveur que seuls les ordinateurs non approuvés utiliseraient pour 
l'impression, il a été décidé qu'un seul serveur pourrait satisfaire les besoins des deux types d'hôtes. 
La société a par conséquent créé un serveur limite comme serveur d'impression. Le serveur 
d'impression étant soumis à un risque plus élevé d'infections et d'attaques d'ordinateurs non 
approuvés, le reste des hôtes approuvés devaient bloquer l'accès entrant à partir de ce serveur. Les 
hôtes approuvés devaient toujours pouvoir établir des connexions sortantes avec le serveur 
d'impression au besoin. En conséquence, Woodgrove a déterminé la nécessité d'un groupe d'accès 
réseau REFUSER pour implémenter cette exigence.

À ce stade du processus de conception, l'affectation de membres au groupe d'accès réseau n'est pas 
requise. Il convient juste d'identifier et de documenter les groupes d'accès réseau requis par la 
conception. Les concepteurs de Woodgrove Bank ont identifié la nécessité de créer le groupe d'accès 
réseau suivant :

Tableau 4.2 : Groupes d'accès réseau de Woodgrove Bank

Nom du groupe d'accès réseau
DNAG_IsolationDomain_Computers
Description
Ce groupe comprend tout compte d'ordinateur de 
domaine non autorisé à établir des connexions 
entrantes protégées par IPSec avec tous les 
hôtes approuvés du domaine d'isolation.

Création de groupes d'isolation supplémentaires 

À ce stade du processus de conception, il existe deux groupes d'isolation : le groupe Domaine 
d'isolation et le groupe de limite.

Si les exigences commerciales de votre organisation peuvent être satisfaites par cette conception, 
vous pouvez passer à la section suivante de ce chapitre pour définir les modèles de trafic pour ces 
deux groupes d'isolation. Cependant, si votre organisation exige que certains hôtes approuvés 
disposent d'une protection du trafic ou de contrôles d'accès réseau entrant ou sortant différents, des 
groupes d'isolation seront requis pour chaque série d'exigences. 

82
L'objectif de cette section est de vous aider à comprendre quand des groupes supplémentaires seront 
requis. La première chose à faire consiste à identifier les ordinateurs ayant des exigences de 
protection du trafic ou d'isolation spécifiques qui ne sont pas satisfaites par les paramètres du 
domaine d'isolation. L'objectif doit être de maintenir le nombre de ces hôtes aussi réduit que possible, 
car chaque nouveau groupe augmente la complexité de la conception globale, et complique par 
conséquent sa prise en charge et sa gestion.

Citons parmi les exemples types d'exigences pouvant mener à la création d'un nouveau groupe :

• Exigences de chiffrement
• Accès hôte ou utilisateur limité requis au niveau du réseau
• Exigences de protection ou de flux de trafic réseau sortant ou entrant différentes du domaine 
d'isolation

Bien souvent, l'accès entrant aux serveurs contenant des données sensibles est limité à un sous­
ensemble d'hôtes approuvés du domaine. Dans d'autres cas, les hôtes approuvés peuvent ne pas 
être autorisés à établir des connexions sortantes vers des ordinateurs non approuvés pour réduire le 
risque de fuite d'informations ou pour garantir le respect des réglementations en matière de protection 
du trafic réseau. Par exemple, dans le scénario Woodgrove Bank, les concepteurs ont identifié des 
exigences pouvant uniquement être satisfaites par la création des deux groupes d'isolation 
supplémentaires suivants :

• Le groupe de chiffrement contenait un petit groupe de serveurs d'application contenant des 
données très sensibles et exigeant le niveau de protection maximal. Seul un sous­ensemble 
spécifique de clients approuvés seraient autorisés à effectuer une connexion entrante sur ces 
serveurs. Tout le trafic réseau avec ces serveurs exigeait un chiffrement de niveau 128 bits 
conforme aux réglementations fédérales américaines en matière de protection des données 
financières. Enfin, ces serveurs n'étaient pas autorisés à établir des connexions sortantes avec des 
hôtes non approuvés, ni à recevoir des connexions entrantes d'hôtes limites. 

• Le groupe Sans basculement était requis pour un certain nombre d'hôtes approuvés du domaine 
d'isolation dont les communications réseau avec des systèmes non approuvés devaient être 
restreintes. 

Bien que le second groupe n'exige aucun basculement, il ne possède pas l'ensemble d'exigences 
complet des serveurs d'applications. Ainsi, ces deux séries d'exigences différentes indiquaient que 
deux groupes d'isolation supplémentaires étaient requis. Le nombre total de groupes pour Woodgrove 
Bank passait donc à quatre. L'illustration suivante montre comment ces groupes se présentaient dans 
la conception finale des groupes d'isolation de Woodgrove Bank :

83
Figure 4.3 Conception finale des groupes de Woodgrove Bank

Les quatre groupes suivants exigent une stratégie pour atteindre les exigences de conception :

• Domaine d'isolation. Il s'agit du groupe par défaut pour tous les ordinateurs approuvés.
• Groupe d'isolation de limite. Ce groupe est affecté aux ordinateurs auxquels des hôtes non 
approuvés doivent pouvoir accéder.

• Groupe d'isolation de chiffrement. Ce groupe autorise uniquement les communications via un 
chemin chiffré approuvé.

• Groupe d'isolation sans basculement. Ce groupe contient des ordinateurs ayant une exigence 
de sécurité supérieure qui les empêche d'initier des communications avec des hôtes non 
approuvés directement.

Woodgrove Bank ayant identifié deux groupes supplémentaires exigeant des stratégies IPSec, elle a 
défini des groupes d'ordinateurs supplémentaires pour contrôler l'application de ces nouvelles 
stratégies.

Tableau 4.3 : Groupes d'ordinateurs Woodgrove Bank supplémentaires

Nom du groupe d'ordinateurs Description
CG_NoFallbackIG_Computers Ce groupe contient tous les ordinateurs non 
autorisés à communiquer en clair.

CG_EncryptionIG_Computers Ce groupe contient tous les ordinateurs devant 
utiliser un chiffrement.

En conséquence, Woodgrove a déterminé que des groupes d'accès réseau seraient requis pour 
autoriser l'accès entrant dans le sous­ensemble d'hôtes approuvés. Les concepteurs de Woodgrove 
Bank ont créé les groupes d'accès réseau suivants :

Tableau 4.4 : Groupes d'accès réseau de Woodgrove Bank

84
Nom du groupe d'accès réseau Description
ANAG_EncryptedResourceAccess_Users Ce groupe comprend tous les utilisateurs 
autorisés à accéder aux serveurs du groupe 
d'isolation de chiffrement.

ANAG_EncryptedResourceAccess_Computers Ce groupe contient tous les ordinateurs autorisés 
à avoir un accès réseau entrant sur les serveurs 
du groupe d'isolation de chiffrement.

DNAG_EncryptionIG_Computers Ce groupe comprend des groupes de comptes 
d'ordinateur dont l'accès doit être refusé sur les 
hôtes du groupe d'isolation de chiffrement.

Collecte des exigences de trafic réseau

À ce stade du processus de conception, vous devez documenter les exigences de trafic de 
communications qui seront autorisées à passer entre les groupes, ainsi que la forme que prendront 
les communications. Il existe de nombreuses manières de documenter les exigences de trafic des 
groupes. Cependant, l'équipe de support informatique de Microsoft a découvert, avec l'expérience, 
que la création d'un diagramme constituait la méthode la plus efficace pour communiquer des 
exigences précises.

L'illustration suivante décrit les chemins de communications généralement autorisés entre les groupes 
de base, les hôtes non approuvés et les listes d'exemptions. Pour simplifier ce modèle, les listes 
d'exemptions figurent sous la forme d'un seul regroupement. C'est généralement le cas pour les 
services d'infrastructure, tels que les contrôleurs de domaine ou les serveurs DNS. Cependant, les 
groupes d'isolation peuvent avoir comme exigence commerciale d'exempter des ordinateurs 
spécifiques juste pour les ordinateurs de ce groupe. Dans ce cas, le groupe d'isolation contiendrait 
alors une liste d'exemptions supplémentaire des ordinateurs devant être exemptés en plus des 
exemptions communes. Microsoft recommande de restreindre au maximum les entrées de la liste 
d'exemptions, car elles exemptent explicitement des systèmes de participer à l'infrastructure IPSec. 
Dans l'illustration, toutes les flèches noires continues utilisent IPSec pour leurs communications ; les 
lignes en pointillés indiquent des communications autorisées sans IPSec. Une ligne en tirets gras 
indique qu'une stratégie IPSec est affectée aux ordinateurs de ce groupe.

85
Figure 4.4 Chemins de communications généralement autorisés pour les groupes d'isolation de base

Le tableau suivant répertorie les chemins de communications autorisés pour le trafic parmi les 
groupes de base, les systèmes non sécurisés et les listes d'exemptions :

Tableau 4.5 : Options de communication autorisées pour les groupes d'isolation de base

Chemin  De À Bidirectionnel Essayer  Basculement Chiffrer

d'accès IKE/IPSec
1 DI EX Oui Non Non Non

2 DI LI Oui Oui Non Non

3 DI NA Non Oui Oui Non

4 LI EX Oui Non Non Non

5 LI NA Non Oui Oui Non

6 NA LI Non Non Non Non

7 NA EX Oui Non Non Non

Le tableau précédent enregistre les exigences de communications pour chaque chemin de 
communications autorisé dans la conception initiale de groupes d'isolation. La liste suivante décrit 
chaque colonne :

• Chemin. Numéro affecté au chemin de communications illustré dans le diagramme de groupe.
• De. Groupe contenant les initiateurs du trafic.
• À. Groupe contenant les répondeurs qui seront contactés via le chemin de communication 
autorisé.

86
• Bidirectionnel. Indique si le chemin autorise l'inversion des rôles de l'initiateur et du répondeur de 
sorte que le trafic peut partir du groupe De ou À.

• Essayer IKE/IPSec. Indique si ce chemin tente d'utiliser IPSec pour sécuriser les communications.
• Basculer. Indique si les communications peuvent renoncer à utiliser IPSec si la négociation IKE 
n'aboutit pas.

• Chiffrer. Indique si ce chemin exige le chiffrement des communications à l'aide d'un algorithme 
défini dans la stratégie IPSec.

Les formes abrégées des noms de groupe ont été utilisées pour garder les informations du tableau 
aussi concises que possible. En utilisant cette forme de documentation, il est possible de créer une 
représentation très concise des communications de la solution. En supposant que tout le trafic réseau 
est rejeté s'il n'est pas spécifiquement identifié dans ce tableau, le processus d'identification du trafic 
qui sera protégé dans le cadre de la solution devient bien plus clair. L'exemple de l'illustration 
précédente décrit chacun des chemins autorisés suivants :

• Les chemins de trafic 1, 4 et 7 illustrent les communications réseau spécifiquement autorisées pour 
tous les hôtes répertoriés par les listes d'exemptions de leur stratégie IPSec. Les exemptions 
spécifiques peuvent être différentes pour les groupes d'isolation.

• Le chemin de trafic 2 représente les communications entre le domaine d'isolation et les groupes 
Limite. Ce chemin tente d'utiliser IPSec pour protéger le trafic. Le trafic peut exiger un chiffrement, 
selon les exigences de sécurité. Si la négociation IKE échoue, les communications échoueront car 
il n'y a pas d'option de communication en texte clair dans ce cas.

• Le chemin 3 montre que les hôtes du domaine d'isolation sont en mesure d'initier des 
communications avec des hôtes non approuvés. Ceci est possible parce que la stratégie de ce 
groupe autorisera les hôtes du domaine d'isolation à communiquer en texte clair en l'absence de 
réponse à la demande de négociation IKE initiale. Les systèmes non approuvés qui tentent 
d'établir des connexions non IPSec avec des hôtes approuvés sont bloqués par les filtres entrants 
IPSec.

• Les chemins de trafic 5 et 6 décrivent les communications autorisées entre le groupe de limite et 
les systèmes non approuvés. Le chemin 4 montre que le groupe de limite est autorisé à établir des 
communications sortantes avec des hôtes non approuvés en clair. Si la négociation IKE ne reçoit 
pas de réponse, l'hôte revient à des communications en clair. Le chemin 5 couvre le trafic initié à 
partir des hôtes non approuvés vers le groupe de limite. Bien que cette flèche ressemble au 
chemin 4, les détails du tableau montrent que les hôtes non approuvés ne tentent pas de 
négociation IKE avec le groupe de limite. Ils utilisent des connexions TCP/IP en clair.

Une fois les communications de base documentées, des groupes supplémentaires peuvent être 
ajoutés au plan général et leurs exigences de communications enregistrées de la même manière. Par 
exemple, les deux groupes supplémentaires requis par le scénario Woodgrove Bank ont mené à un 
diagramme de communications plus complexe, comme le montre l'illustration suivante.

87
Figure 4.5 Chemins de communications autorisés par Woodgrove Bank pour les groupes d'isolation

Le tableau suivant répertorie les chemins de communications autorisés pour le trafic dans les groupes 
supplémentaires du scénario Woodgrove Bank.

Tableau 4.6 : Options de communication autorisées pour les groupes d'isolation 
supplémentaires

Chemin  De À Bidirectionnel Essayer  Basculement Chiffrer

d'accès IKE/IPSec
8 CR EX Oui Non Non Non

9 CR DI Oui Oui Non Oui

10 CR SB Oui Oui Non Oui

11 CR LI Non Oui Non Oui

12 SB DI Oui Oui Non Non

13 SB EX Oui Non Non Non

14 SB LI Oui Oui Non Non

L'exemple de l'illustration précédente décrit dans le tableau explique chacun des chemins 
supplémentaires autorisés suivants : 

• Les chemins 8 et 13 correspondent aux communications en clair pour tout le trafic exempté.
• Les chemins 9 et 10 montrent les communications IPSec chiffrées par ESP (Encapsulating 
Security Payload) requises entre les groupes Chiffrement, Sans basculement et Domaine 
d'isolation. Si la négociation IKE ne parvient pas à sécuriser la communication par chiffrement, la 
tentative de communication échoue.

88
• Le trafic du chemin 11 est légèrement différent car il autorise uniquement que des communications 
soient initiées à partir du groupe de chiffrement vers le groupe de limite, et non l'inverse. Ceci est 
dû au fait que Woodgrove Bank a placé des données sensibles dans le groupe de chiffrement et 
ne veut pas que ces données soient exposées à des ordinateurs auxquels accèdent directement 
des ressources non approuvées.

• Les chemins de trafic 12 et 14 pourraient être implémentés par le mode de transport IPSec AH ou 
IPSec ESP, qui est authentifié mais sans chiffrement (ESP­Null).

Comme le montre cet exemple, l'ajout de groupes peut avoir un impact exponentiel sur la complexité 
de la solution. C'est pourquoi il est recommandé de limiter autant que possible le nombre de groupes, 
en particulier durant les premières étapes d'un déploiement, lorsque la plupart des changements sont 
introduits.

Affectation de membres au groupe d'ordinateurs et au groupe d'accès 
réseau

Une fois les exigences de trafic détaillées et décrites dans la conception, la tâche suivante consiste à 
identifier les hôtes qui seront les membres des groupes d'ordinateurs ou des groupes d'accès réseau.

Comme mentionné précédemment, les groupes d'ordinateurs sont utilisés dans cette solution pour 
appliquer l'objet Stratégie de groupe contenant la stratégie IPSec associée. Une fois déterminé qu'un 
ordinateur doit appartenir à un groupe d'isolation donné, le compte de cet ordinateur est ajouté au 
groupe d'ordinateurs de ce groupe d'isolation. Pour le domaine d'isolation, cette étape n'est pas 
nécessaire, car tous les ordinateurs du domaine appartiennent implicitement au groupe d'ordinateurs 
du domaine d'isolation.

L'appartenance à un groupe d'accès réseau sera basée sur l'autorisation entrante que le groupe 
d'accès réseau implémente. Par exemple, s'il existe un groupe d'accès réseau pour limiter la 
communication d'un serveur donné vers un ensemble connu de clients, les comptes d'ordinateur client 
doivent être placés dans le groupe d'accès réseau approprié. Les groupes d'accès réseau ne sont 
créés qu'en fonction des besoins et ne possèdent par conséquent aucune configuration par défaut.

Appartenance au groupe d'ordinateurs

Il est important qu'un hôte ne soit pas représenté dans plusieurs groupes d'ordinateurs, car le groupe 
d'ordinateurs sert à définir les objets Stratégie de groupe applicables. Bien qu'il soit théoriquement 
possible de modifier les stratégies pour permettre à un hôte d'appartenir à plusieurs groupes 
d'ordinateurs, la complexité d'une telle approche rendrait rapidement la solution insoutenable.

La tâche de détermination des membres d'un groupe d'ordinateurs n'est généralement pas 
compliquée, mais elle peut être longue. Il est conseillé d'utiliser les informations générées à partir d'un 
audit tel que celui effectué dans le chapitre 3 de ce guide, « Détermination de l'état actuel de votre 
infrastructure informatique », pour placer chaque hôte dans un groupe d'ordinateurs en fonction du 
groupe d'isolation dont il est membre. Vous pouvez déterminer ce placement en ajoutant une colonne 
Groupe pour y noter l'appartenance à un groupe d'ordinateurs pour la conception finale, comme 
indiqué dans le tableau suivant :

Tableau 4.7 : Exemple de données collectées sur l'hôte

Nom de  Config.  Config.  Configuration  Détails Coût  Groupe 

l'hôte matérielle  logicielle  requise prévisionnel
conforme ? conforme ?

89
HOST­ Non Non Mises à niveau  Le système  $XXX. DI
NYC­001 matérielle et  d'exploitation 
logicielle actuel est 
Windows NT 
4.0. Ancien 
matériel non 
compatible 
avec 
Windows XP.

SERVER­ Oui Non Intégrer  Aucun logiciel  $XXX. CR

LON­001 domaine  antivirus 
approuvé,  présent.
mettre à niveau 
de NT 4 vers 
Windows 2000 
ou ultérieur

Appartenance au groupe d'accès réseau

La dernière étape de ce processus de conception consiste à définir les membres des groupes d'accès 
réseau identifiés précédemment dans ce chapitre. Bien qu'un hôte approuvé ne doive appartenir qu'à 
un seul groupe d'ordinateurs, il est possible qu'il soit membre de plusieurs groupes d'accès réseau. 
Essayez d'utiliser aussi peu de groupes d'accès réseau que possible pour limiter la complexité de la 
solution.

Lors de l'affectation de comptes d'utilisateurs à un groupe d'accès réseau, décidez du degré souhaité 
de contrôle d'accès. Pour qu'une ressource utilisant déjà des autorisations de fichiers et de partage 
standards assure le niveau correct de contrôle, le moyen le plus simple de définir l'appartenance 
serait d'attribuer l'appartenance du groupe d'accès réseau de l'utilisateur au groupe Utilisa. du 
domaine de chaque domaine approuvé de la forêt devant accéder à la ressource. Cette approche 
rétablit pratiquement le comportement de la valeur par défaut d'origine d'Utilisateurs authentifiés, sans 
inclure de comptes d'utilisateurs locaux. Si des comptes d'utilisateurs ou de services locaux sont 
requis, un objet Stratégie de groupe basé sur le domaine n'est peut­être pas la meilleure approche 
pour configurer des droits de connexion réseau AUTORISER et REFUSER. L'affectation de droits 
d'utilisateur AUTORISER et REFUSER ne fusionne pas les paramètres parmi plusieurs objets 
Stratégie de groupe. Par conséquent, cet ordinateur ne doit pas être autorisé à posséder le droit 
AUTORISER et REFUSER de l'objet Stratégie de groupe basé sur le domaine, et doit utiliser un objet 
Stratégie de groupe local personnalisé. Si l'objet Stratégie de groupe basé sur le domaine qui fournit 
l'affectation de stratégie IPSec est différent de l'objet Stratégie de groupe utilisé pour fournir les droits 
de connexion réseau, l'objet Stratégie de groupe basé sur le domaine pour l'affectation de stratégie 
IPSec peut encore être utilisé. 

De plus, décidez comment implémenter les exigences d'accès entrant à l'aide d'un groupe d'accès 
réseau AUTORISER ou REFUSER, voire les deux. Le choix du type de groupe d'accès réseau à créer 
est basé exclusivement sur le comportement attendu et sur ce qui minimise l'effort administratif. Il peut 
s'avérer utile d'avoir un groupe d'accès réseau REFUSER pré­existant mais vide pour les utilisateurs 
et un groupe d'accès réseau REFUSER pour les ordinateurs possédant déjà le droit « Interdire l'accès 
à cet ordinateur à partir du réseau » de l'objet Stratégie de groupe.

Dans les scénarios de sécurité élevée, l'appartenance des groupes d'accès réseau utilisateur peut 
être affectée à des utilisateurs ou groupes spécifiques. Si cette méthode est utilisée, il faut 
comprendre que les utilisateurs qui ne sont pas membres de ce groupe verront leur accès à 
l'ordinateur bloqué sur le réseau, même s'ils sont membres du groupe des administrateurs locaux et 
disposent d'un contrôle total sur toutes les autorisations de partage et de fichiers.

90
Pour le scénario Woodgrove Bank, l'appartenance à NAG_EncryptedResourceAccess_Users a été 
affectée à Utilisateurs du domaine et enregistrée comme le montre le tableau suivant :

Tableau 4.8 : Groupes d'accès réseau de Woodgrove Bank avec appartenance définie

Nom du groupe d'accès réseau Appartenance Description

ANAG_EncryptedResourceAcces User7 Ce groupe correspond à tous les 
s_Users utilisateurs autorisés à établir des 
connexions entrantes protégées 
par IPSec avec les ordinateurs du 
groupe d'isolation de chiffrement.

ANAG_EncryptedResourceAcces IPS­SQL­DFS­01  Ce groupe contient tous les 

s_Computers IPS­SQL­DFS­02 ordinateurs autorisés à établir des 
IPS­ST­XP­05 connexions entrantes protégées 
par IPSec avec les ordinateurs du 
groupe d'isolation de chiffrement.

DNAG_EncryptionIG_Computers CG_BoundaryIG_Computers Ce groupe contient tous les 

ordinateurs non autorisés à 
établir des connexions entrantes 
protégées par IPSec avec les 
ordinateurs du groupe d'isolation 
de chiffrement.

Remarque : l'appartenance à un groupe d'accès réseau ne détermine pas le niveau de protection du 
trafic IPSec. Les paramètres de stratégie IPSec commandent les méthodes de sécurité utilisées pour 
protéger le trafic et sont indépendants de l'identité authentifiée par IKE. La négociation IKE est 
uniquement consciente de la réussite ou de l'échec du processus d'authentification de l'identité de 
l'ordinateur Kerberos. Elle ne peut pas implémenter une stratégie « chiffrer si user3 se connecte » ou 
« chiffrer si hôte approuvé IPS­SQL­DFS­01 ou IPS­SQL­DFS­02 ». L'administrateur doit obtenir le 
comportement attendu en utilisant une stratégie IPSec pour les serveurs du groupe d'isolation de 
chiffrement exigeant un « chiffrement pour toute connexion entrante d'hôte approuvé » et de manière 
similaire un « chiffrement pour toute connexion sortante vers un hôte approuvé ». 

Jusqu'ici, ce processus de conception n'a pas revu les détails de la conception de stratégie IPSec. Le 
chapitre 5 fournira des détails relatifs à la conception de la stratégie IPSec pour Woodgrove.

À ce stade du processus de conception, vous avez terminé les tâches requises pour transformer vos 
exigences en conception préliminaire. Cette section vous a aidé à mettre au point la conception et la 
documentation requises pour la création des stratégies IPSec.

Limitations pouvant affecter votre conception

Les problèmes suivants peuvent affecter votre conception et doivent par conséquent être pris en 
compte avant que votre conception puisse être considérée comme terminée :

• Nombre maximal de connexions simultanées par des hôtes uniques sur des serveurs 
utilisant IPSec. Le nombre de connexions simultanées est un facteur crucial pour déterminer si 
une implémentation IPSec sur des serveurs d'usage élevé se déroulera sans problèmes ou 
surchargera le processeur avec le traitement IKE ou IPSec. Chaque négociation IKE réussie établit 
des associations de sécurité occupant environ 5 kilo­octets de mémoire de mode utilisateur. Des 
ressources processeur sont requises pour maintenir les états d'association de sécurité IKE 
courants avec tous les homologues connectés simultanément. Pour plus d'informations sur 

91
 l'évolutivité, consultez le livre blanc « Improving Security with Domain Isolation: Microsoft IT 
 implements IP Security (IPSec)     » (Amélioration de la sécurité avec l'isolation de domaines : 
Implémentation d'IPSec par Microsoft IT) à l'adresse 
www.microsoft.com/technet/itsolutions/msit/security/ipsecdomisolwp.mspx.

• Limitation de la taille de jeton Kerberos maximale pour les hôtes utilisant IPSec. Il existe une 
limite pratique d'environ 1 000 groupes par utilisateur, et si cette valeur est dépassée, l'application 
de l'objet Stratégie de groupe peut ne pas se produire. Pour plus d'informations à ce sujet, 
consultez les articles 327825 de la Base de connaissances Microsoft « New Resolution for 
Problems That Occur When Users Belong to Many Groups   » (Nouvelle résolution de problèmes 
se produisant lorsque des utilisateurs appartiennent à de nombreux groupes) à l'adresse 
http://support.microsoft.com/?kbid=327825 et 306259 « Members of an Extremely Large Number 
of Groups Cannot Log On to the Domain   » (Des membres d'un nombre très élevé de groupes 
ne peuvent pas se connecter au domaine) à l'adresse http://support.microsoft.com/?kbid=306259.
Bien que ces articles mentionnent des utilisateurs spécifiquement, le problème existe également pour 
les comptes d'ordinateurs, car le paramètre Kerberos MaxTokenSize s'applique aussi aux comptes 
d'ordinateurs. Bien que cette limite soit rarement atteinte dans la plupart des implémentations, vous 
devez être conscient de ce problème si vous décidez de placer un ordinateur (peut­être un client) 
dans un grand nombre de groupes d'accès réseau.

Si votre conception sera affectée par ces problèmes, vous devrez revisiter le processus de conception 
pour y répondre. Par exemple, vous pouvez répondre au problème du nombre maximal de connexions 
simultanées en déplaçant un serveur très lourdement chargé dans les listes d'exemptions. Vous 
pouvez répondre à la limitation de la taille de jeton Kerberos maximale en réduisant le nombre de 
groupes d'accès réseau que votre conception utilisera.

Si ces limitations n'affecteront pas votre conception, la tâche suivante consiste à considérer la 
manière dont la conception sera déployée dans l'organisation.

Méthodes d'implémentation de groupe
Une fois la conception initiale créée, vous devez considérer attentivement le processus de 
déploiement d'IPSec. Ce n'est que dans les environnements les plus petits qu'il est possible de 
déployer simplement les stratégies sur tous les ordinateurs et d'espérer un fonctionnement sans 
heurts d'IPSec avec un impact relativement faible sur les utilisateurs.

Dans les organisations étendues, la complexité et le risque nécessitent un déploiement progressif. En 
utilisant une telle approche, l'organisation peut aider à atténuer le risque associé à un tel changement 
fondamental de l'environnement. Sans planification soignée, les appels au support technique et la 
perte de productivité augmenteront rapidement le coût du déploiement.

Il existe différentes manières de déployer IPSec dans une organisation. Les facteurs suivants aident à 
déterminer la méthode de déploiement :

• les états de départ et de fin de l'environnement ;
• la complexité de configuration des groupes ;
• la complexité de la structure de domaines ;
• la tolérance de risque de l'organisation ;
• les exigences de sécurité. 

92
Les méthodes de déploiement suivantes ne comprennent pas tout, mais elles sont des exemples 
d'approches possibles. Vous pouvez également utiliser une combinaison de ces approches. En 
général, les organisations ne doivent pas déployer initialement des stratégies IPSec limitant ou 
bloquant la communication, afin de garantir qu'elles disposent de suffisamment de temps pour 
résoudre les problèmes et réduire la coordination de gestion dans les environnements complexes.

Quelle que soit l'approche choisie pour déployer IPSec, il est fortement recommandé de tester 
soigneusement le scénario de déploiement dans un environnement de laboratoire, y compris la 
séquence et le déroulement spécifiques des étapes de déploiement et des changements de stratégie. 
De plus, utilisez une action de filtre demandant une fonctionnalité IPSec, mais acceptant la 
communication en texte clair en utilisant la fonction Communiquer en texte clair. Cette approche 
aidera à minimiser l'impact du déploiement initial. Une fois le déploiement terminé, passez à des 
modes de fonctionnement plus sécurisés exigeant que le trafic soit protégé par IPSec.

Pour un déploiement dans un environnement de production, un pilote initial est fortement 
recommandé à chaque grande phase du déploiement. Il est particulièrement important d'analyser 
l'impact des changements de stratégie IPSec, car ils prendront effet dans l'environnement de 
production suite aux durées de vie des tickets Kerberos, et aux intervalles d'interrogation de stratégie 
de groupe et de stratégie IPSec. Il est conseillé de mettre en œuvre un processus formel de contrôle 
des modifications indiquant les stratégies et les critères d'annulation pour s'assurer que toutes les 
organisations informatiques concernées sont conscientes du changement et de son impact, et savent 
comment coordonner les commentaires vers les décideurs.

Déployer par groupe

La méthode Déployer par groupe utilise des stratégies IPSec entièrement définies, mais contrôle 
l'application des stratégies par l'utilisation de groupes et de listes de contrôle d'accès sur les objets 
Stratégie de groupe fournissant les stratégies.

Dans la méthode Déployer par groupe, les stratégies IPSec sont créées dans Active Directory dans 
leur configuration finale. Toutes les exemptions et tous les sous­réseaux sécurisés sont définis et les 
actions de filtre appropriées sont activées dans chaque stratégie IPSec.

Les administrateurs de stratégie IPSec créent alors des objets Stratégie de groupe pour chaque 
stratégie IPSec. De plus, des groupes d'ordinateurs sont créés dans le domaine pour gérer et 
appliquer ces nouveaux objets Stratégie de groupe. Les listes de contrôle d'accès des objets Stratégie 
de groupe sont modifiées pour que les membres du groupe Utilisateurs authentifiés n'aient plus le 
droit « Appliquer ». Les groupes d'utilisateurs de l'administrateur approprié pour la gestion et 
l'application de la stratégie reçoivent également des droits sur l'objet Stratégie de groupe.

Les stratégies IPSec appropriées sont ensuite affectées à l'objet Stratégie de groupe correspondant. 
De plus, l'objet Stratégie de groupe est lié à l'objet approprié dans Active Directory. À ce stade, aucun 
des ordinateurs de l'environnement ne doit recevoir la stratégie, car les listes de contrôle d'accès 
contrôlant l'affectation de l'objet Stratégie de groupe (possibilité de lire l'objet Stratégie de groupe) 
sont vides.

Enfin, les ordinateurs qui recevront les stratégies sont identifiés et leurs comptes d'ordinateurs sont 
placés dans les groupes d'ordinateurs appropriés avec accès en lecture à l'objet Stratégie de groupe. 
Une fois les tickets Kerberos de l'ordinateur mis à jour avec les informations d'appartenance de 
groupe, l'objet Stratégie de groupe, ainsi que la stratégie IPSec correspondante, s'appliquent à 
l'intervalle d'interrogation de stratégie de groupe suivant. 

93
Remarque : les listes de contrôle d'accès qui empêchent les ordinateurs du domaine de lire les objets 
de stratégie IPSec ou le conteneur de stratégie IPSec dans Active Directory ne sont pas 
recommandées.

Considérez une organisation ayant défini deux stratégies IPSec, IPSec standard et IPSec chiffrement. 
La stratégie IPSec standard est la stratégie par défaut ; elle exige que le trafic entrant utilise IPSec, 
mais permet aux systèmes de communiquer en clair s'ils initient une connexion vers un ordinateur non 
basé sur IPSec. La stratégie IPSec chiffrement exige la négociation IPSec chiffré à tous moments.

Dans cet exemple, l'administration de l'organisation crée deux objets Stratégie de groupe dans 
Active Directory : IPSec standard et IPSec chiffré. De plus, elle identifie les groupes dans le tableau 
suivant :

Tableau 4.9 : Groupes d'administration IPSec

Nom de groupe Type de groupe Description

IPSecSTD Universel Contrôle l'application de la stratégie IPSec standard

IPSecENC Universel Contrôle l'application de la stratégie IPSec chiffré

Les listes de contrôle d'accès des deux objets Stratégie de groupe nouvellement créés sont mises à 
jour de sorte qu'elles ne sont pas automatiquement appliquées au groupe Utilisateurs authentifiés et 
que les groupes d'application et de gestion appropriés reçoivent les droits corrects. L'administration a 
modifié les listes de contrôle d'accès pour les deux objets Stratégie de groupe en fonction des 
informations du tableau suivant :

Tableau 4.10 : Droits de groupes sur les objets Stratégie de groupe

Groupe Objet Stratégie de groupe IPSec  Objet Stratégie de groupe IPSec 

standard chiffré
Utilisateurs  Lecture Lecture
authentifiés

IPSecENC Aucun Lecture

Appliquer la stratégie de groupe

IPSecSTD Lecture Aucun

Appliquer la stratégie de groupe

Remarque : ce tableau montre uniquement les autorisations ajoutées ou modifiées. Il y aura 
également des groupes supplémentaires avec des autorisations.

Les administrateurs ont lié les deux objets Stratégie de groupe au domaine dans Active Directory. 
Cette approche garantit que la stratégie s'appliquera à tout ordinateur du domaine sans modifier son 
emplacement (à moins que l'ordinateur se situe dans une UO bloquant les stratégies).

À mesure que les ordinateurs sont identifiés, leurs comptes sont ajoutés au groupe IPSecSTD ou 
IPSecEnc. Passé un certain délai, la stratégie IPSec correspondante s'appliquera et sera effective.

Cette méthode exige une planification soignée pour s'assurer que les communications ne sont pas 
perturbées. Par exemple, si un serveur a été placé dans le groupe IPSecEnc, mais que plusieurs 
clients dépendant de ce serveur n'ont pas pu négocier IPSec, les communications entre ces clients et 
le serveur seraient perturbées.

94
Déployer par élaboration de stratégies

Cette méthode utilise une technique dans laquelle les stratégies IPSec peuvent être créées de toutes 
pièces durant le déploiement. L'avantage de cette méthode est qu'IPSec est négocié uniquement pour 
un petit pourcentage du trafic TCP/IP total, et non pour tous les sous­réseaux internes de la méthode 
de déploiement par groupe. Elle permet également de tester tous les chemins du réseau interne vers 
ce sous­réseau cible pour vérifier l'absence de problèmes avec la transmission réseau de la 
négociation IKE et du trafic protégé par IPSec. Un autre avantage est que l'intervalle d'interrogation 
pour IPSec peut fournir plus rapidement des mises à jour de stratégie IPSec (y compris d'annulation) 
au lieu de devoir dépendre des changements de membres de groupe dans le ticket d'octroi 
d'autorisations (TGT) Kerberos ou les tickets de service. L'inconvénient de cette méthode est qu'elle 
s'applique à tous les ordinateurs du groupe ou domaine d'isolation, et non à des ordinateurs 
spécifiques comme dans la méthode de déploiement par groupe. De plus, tous les ordinateurs 
disposeront d'un délai de 3 secondes avant retour à la communication en clair à un moment donné 
lors de la communication avec les sous­réseaux spécifiés.

Dans cette méthode de déploiement, les stratégies IPSec n'incluent que des exceptions initialement ; 
il n'existe aucune règle pour la négociation de la sécurité par les ordinateurs dans la stratégie IPSec. 
Cette méthode teste et vérifie d'abord que toutes les stratégies IPSec locales existant précédemment 
et pouvant être en cours d'utilisation sont supprimées. L'équipe d'administration doit pouvoir identifier 
les hôtes qui utilisaient des stratégies IPSec définies localement à l'avance pour gérer ces systèmes 
avec un processus spécial. Si une stratégie IPSec locale est remplacée par une stratégie de domaine, 
il peut se produire des interruptions dans les communications et une perte de sécurité pour les 
ordinateurs affectés. Contrairement aux stratégies locales remplacées par l'application de stratégie de 
domaine, les stratégies persistantes sous Windows Server 2003 fusionnent avec le résultat de 
l'application de la stratégie de domaine. Un système contenant une stratégie persistante peut sembler 
fonctionner, mais la configuration de la stratégie persistante peut changer le comportement ou 
diminuer en fait la sécurité fournie par la stratégie de domaine, ou peut perturber les communications 
une fois des règles de sous­réseau sécurisé ajoutées à la stratégie.

Vous pouvez ensuite créer une règle de sécurité avec un filtre affectant uniquement un seul sous­
réseau dans le réseau de l'organisation, par exemple « Tout le trafic à partir de n'importe quelle 
adresse IP vers Sous­réseau A, négocier ». Cette règle aurait une action de filtre pour accepter le 
texte clair entrant et déclencher des négociations pour tout le trafic sortant vers ce sous­réseau avec 
la communication en texte clair activée. À mesure que le déploiement dans tous les domaines de cette 
stratégie IPSec prend effet, les communications passeront peu à peu d'associations de sécurité 
logicielles à des associations de sécurité IPSec normales pour les hôtes approuvés juste sur ce sous­
réseau. Tout échec de négociation IKE est étudié et résolu. Toutes incompatibilité d'application est 
identifiée et corrigée. IPSec sécurisera la communication entre les hôtes approuvés dans ce sous­
réseau. La communication avec des hôtes approuvés en dehors de ce sous­réseau repassera en clair 
après le délai de trois secondes. Des sous­réseaux supplémentaires sont ajoutés à la règle sécurisée 
jusqu'à ce que la stratégie soit constituée à son état final.

Considérez une organisation ayant une seule stratégie IPSec définie, appelée stratégie IPSec 
standard, qui demande une négociation IPSec, mais accepte le retour à la communication en texte 
clair en cas d'échec. La stratégie est créée dans Active Directory et ne contient que des règles 
d'exemption.

L'objet Stratégie de groupe IPSec standard est créé et lié de sorte qu'il s'applique à tous les 
ordinateurs de l'environnement. De plus, la stratégie IPSec standard est affectée à ce nouvel objet 
Stratégie de groupe.

Tous les ordinateurs recevront finalement la stratégie IPSec. Tous problèmes avec des stratégies 
IPSec locales seront détectés car cette stratégie de domaine supplantera les stratégies locales 

95
existantes. Les problèmes sont continuellement résolus jusqu'à ce que tous les sous­réseaux 
apparaissent dans la liste de filtres de sous­réseaux sécurisés.

Implémentation des groupes pour Woodgrove Bank
Woodgrove Bank a choisi d'implémenter son déploiement de production en déplaçant d'abord tous les 
ordinateurs vers le groupe de limite à l'aide de la méthode d'élaboration. Cette approche a permis aux 
administrateurs d'avancer peu à peu et de résoudre tous les problèmes en suspens sans trop affecter 
les communications entre tous les systèmes. En déployant d'abord une stratégie sans sous­réseaux 
sécurisés, l'équipe d'administration a pu identifier les systèmes auxquels était affectée une stratégie 
IPSec locale et prendre également ces informations en considération. Alors que des sous­réseaux ont 
été ajoutés à la stratégie, tous les conflits supplémentaires détectés ont été résolus.

Une fois que les ordinateurs fonctionnaient selon la stratégie de groupe de limite, l'équipe a 
implémenté les groupes Domaine d'isolation, Sans basculement et Chiffrement. Le déploiement de 
ces groupes utilisait la méthode Déployer par groupe. Un ensemble d'ordinateurs a été sélectionné 
pour un pilote et ajouté aux groupes appropriés contrôlant les nouvelles stratégies. Les problèmes ont 
été résolus à mesure de leur découverte, et des ordinateurs supplémentaires ont été ajoutés aux 
groupes jusqu'à ce qu'ils soient totalement remplis.

Le tableau suivant répertorie les groupes d'ordinateurs et d'accès réseau ainsi que leurs membres une 
fois la solution totalement déployée :

Tableau 4.11 : Appartenance au groupe d'ordinateurs et au groupe d'accès réseau

Groupe d'ordinateurs ou d'accès réseau Membres
CG_IsolationDomain_Computers Ordinateurs du domaine

CG_BoundaryIG_Computers IPS­PRINTS­01

CG_NoFallbackIG_Computers IPS­LT­XP­01

CG_EncryptionIG_Computers IPS­SQL­DFS­01
IPS­SQL­DFS­02

ANAG_EncryptedResourceAccess_Users User7

ANAG_EncryptedResourceAccess_Computers IPS­SQL­DFS­01
IPS­SQL­DFS­02
IPS­ST­XP­05

DNAG_EncryptionIG_Computers CG_BoundaryIG_Computers

Notez que le groupe ANAG_EncryptedResourceAccess_Computers contient les serveurs se trouvant 
dans le groupe d'isolation de chiffrement. Ceci leur permettra de communiquer selon les besoins. Si 
cette communication n'est pas nécessaire pour ces serveurs, il est inutile de les ajouter dans ce 
groupe.

Résumé
Ce chapitre décrit le processus de conception d'une solution d'isolation de serveurs et de domaines. 
Les tâches comprenaient l'identification des groupes d'ordinateurs et des groupes d'accès réseau 
requis, la compréhension des groupes d'isolation de base, l'ajout de groupes d'isolation 

96
supplémentaires, l'élaboration d'un modèle de trafic, l'affectation de membres aux groupes, ainsi que 
la planification de la méthode de déploiement.

Ce chapitre utilisait également l'implémentation IPSec de Woodgrove Bank, une organisation fictive, 
pour aider à illustrer le processus de conception en action et éprouver la conception dans les 
laboratoires de test Microsoft.

La conception de groupes était basée sur les exigences commerciales et les informations de 
découverte obtenues à partir des deux chapitres précédents et documentées dans la feuille de calcul 
Business_Requirements.xls (disponible dans le dossier Tools and Templates). Une appréciation de 
l'impact d'IPSec sur un réseau était également une considération importante.

Après avoir lu ce chapitre, vous devez disposer de suffisamment d'informations pour commencer à 
planifier des groupes d'isolation, à documenter les exigences de communication entre ces groupes, et 
à planifier la stratégie IPSec de niveau supérieur. Ces tâches vous prépareront pour le chapitre 5, 
« Création de stratégies IPSec pour les groupes d'isolation ».

Informations complémentaires

Cette section fournit des liens vers des informations supplémentaires pouvant s'avérer utiles lors de 
l'implémentation de cette solution.

IPSec

Les liens suivants offrent une grande variété d'informations relatives à IPSec sous Windows :

• Le livre blanc « Using Microsoft Windows IPSec to Help Secure an Internal Corporate Network 
Server   » (Utilisation de Microsoft Windows IPSec pour aider à sécuriser un serveur de réseau 
d'entreprise interne) présente le premier modèle d'utilisation d'IPSec pour sécuriser l'accès réseau 
aux serveurs internes traitant ou stockant des informations sensibles. Ce livre blanc peut être 
téléchargé sur www.microsoft.com/downloads/
details.aspx?FamilyID=a774012a­ac25­4a1d­8851­b7a09e3f1dc9&displaylang=en.

• Le déploiement Microsoft d'IPSec pour protéger tous les membres du domaine est décrit dans 
l'étude de cas « Improving Security with Domain Isolation: Microsoft IT implements IP Security 
 (IPSec)     » (Amélioration de la sécurité avec l'isolation de domaines : Implémentation d'IPSec 
par Microsoft IT) sur www.microsoft.com/technet/itsolutions/msit/
security/ipsecdomisolwp.mspx.

• Page IPSec for Windows
      2000   (IPSec pour Windows 2000) à l'adresse 
www.microsoft.com/windows2000/technologies/communications/ipsec/.

• Page Microsoft Windows Server 2003 IPSec   à l'adresse 
www.microsoft.com/windowsserver2003/technologies/networking/ipsec/.

Sécurité

• L'approche d'évaluation des risques de sécurité informatique de Microsoft est documentée dans le 
livre blanc « IT Security at Microsoft Overview   » (Présentation de la sécurité informatique chez 
Microsoft) à l'adresse www.microsoft.com/technet/itsolutions/msit/security/mssecbp.mspx.

Windows Server 2003 Active Directory

Pour plus d'informations sur Active Directory, consultez :

97
• La page Windows
      Server    2003 Active    Directory  
 à l'adresse 
www.microsoft.com/windowsserver2003/technologies/directory/activedirectory/.

98
Chapitre  5 : Création de stratégies 
IPSec pour les groupes d'isolation
L'objectif de ce chapitre est de fournir des instructions relatives à l'implémentation de la conception 
d'isolation de serveurs et de domaines. Les chapitres précédents expliquent le processus de 
conception et les raisons qui justifient les instructions du présent chapitre. Si cela n'est déjà fait, nous 
vous conseillons vivement de lire ces chapitres avant de poursuivre.

Ce chapitre détaille l'implémentation des exigences de sécurité des groupes d'isolation de serveurs et 
de domaines conçus au chapitre 4, « Conception et planification de groupes d'isolation ». La 
combinaison des éléments suivants permettra la mise en place de ces exigences :

• Exigences d'accès entrant et sortant pour le domaine d'isolation et les groupes d'isolation :
• Stratégie IPSec (Internet Protocol security) conçue spécialement pour le groupe d'isolation 
nécessitant une négociation IKE (Internet Key Exchange) IPSec pour les connexions entrantes 
et sortantes.
• Groupes de sécurité basés sur les domaines, appelés groupes d'accès réseau, pour autoriser 
ou refuser l'accès réseau lors de l'utilisation d'un trafic protégé par IPSec.

• Exigences de protection du trafic réseau pour le domaine d'isolation et les groupes d'isolation :
• Filtres de stratégie IPSec conçus pour identifier correctement le trafic à sécuriser.
• Actions de filtrage IPSec chargées de négocier le niveau d'authentification et de chiffrement 
requis pour le trafic identifié par les filtres.
• Paramètres des actions de filtrage IPSec afin de contrôler si les communications en texte clair 
sont autorisées lorsque des hôtes approuvés établissent des connexions sortantes.

Ce guide aborde la préparation de la solution à l'aide de la stratégie de groupe et des stratégies IPSec 
dans le service d'annuaire Active Directory® sous Microsoft® Windows Server™ 2003, ainsi que la 
configuration des membres des domaines avec Windows Server 2003 et Microsoft Windows® XP. Ce 
chapitre décrit aussi les solutions conceptuelles alternatives et les options de déploiement. Des listes 
de vérification finales sont proposées afin de s'assurer que le processus de conception respecte 
toutes les exigences commerciales et de sécurité.

Connaissances préalables requises pour ce chapitre
Cette section renferme des informations qui vous permettront de vérifier que votre organisation est 
prête à implémenter la solution IPSec (« Prête » s'entend au sens logistique et non au sens 
commercial – la motivation de l'entreprise pour l'implémentation de cette solution est traitée au 
chapitre 1, « Introduction à l'isolation de serveurs et de domaines », du présent guide).

Connaissances requises

Il est préférable de connaître les principes généraux d'IPSec et, plus particulièrement, les techniques 
Microsoft d'implémentation d'IPSec. Une connaissance de base de Windows Server 2003 est 
également requise dans les domaines suivants :

99
• Concepts relatifs à Active Directory, notamment la structure et les outils Active Directory, la 
manipulation des utilisateurs, des groupes et autres objets Active Directory, et l'utilisation de la 
stratégie de groupe.

• Sécurité du système Windows : concepts de sécurité tels que les utilisateurs, les groupes, l'audit et 
les listes de contrôle d'accès, l'utilisation des modèles de sécurité et l'application des modèles de 
sécurité à l'aide de la stratégie de groupe ou des outils de ligne de commande.

• Maîtrise des principes réseau et IPSec fondamentaux

Avant de poursuivre la lecture de ce chapitre, vous devez avoir lu les instructions de planification 
fournies dans les chapitres précédents du guide et bien comprendre l'architecture et la conception de 
la solution. Vous devez aussi avoir défini et documenté les besoins commerciaux de la solution dans 
le cadre de la définition des exigences de la solution.

Conditions requises pour l'organisation

Vous devez consulter les membres de votre organisation qui peuvent être impliqués dans 
l'implémentation de cette solution, notamment 

• les dirigeants ;
• les personnes chargées de l'audit et de la sécurité ;
• les ingénieurs, les administrateurs et les équipes opérationnelles Active Directory ;
• les ingénieurs et les personnes chargées de l'administration et de l'exploitation du réseau, du 
serveur Web et du DNS (Domain Name System).

Remarque : selon la structure de votre organisation informatique, ces rôles peuvent être remplis par 
plusieurs personnes, ou une même personne peut remplir plusieurs rôles.

Configuration requise pour l'infrastructure informatique

Ce chapitre part également du principe que l'infrastructure informatique suivante est disponible :

• Un domaine Active Directory Microsoft Windows Server 2003 fonctionnant en mode mixte ou natif. 
Cette solution fait appel à des groupes universels pour l'application des objets Stratégie de groupe. 
Si l'organisation ne fonctionne pas en mode mixte ou natif, il reste possible d'appliquer l'objet 
Stratégie de groupe à l'aide de configurations de groupes locaux et globaux standards. Cependant, 
cette option étant plus complexe à gérer, cette solution ne l'utilise pas.
Remarque : Windows Server 2003 a introduit un certain nombre d'améliorations qui affectent les 
stratégies IPSec. Aucune spécificité de cette solution ne l'empêche de fonctionner avec 
Windows 2000. Cependant, la solution n'a été testée qu'avec Windows Server 2003 Active Directory.
Pour plus d'informations sur les améliorations apportées à IPSec dans Windows Server 2003, 
reportez­vous à la page New features for IPSec   (Nouvelles fonctionnalités d'IPSec) sur le site Web 
de Microsoft à l'adresse www.microsoft.com/resources/documentation/
WindowsServ/2003/standard/proddocs/en­us/ipsec_whatsnew.asp.

• Licences, clés de produit et CD d'installation de Windows 2000 Server, Windows Server 2003 
Standard Edition et Windows Server 2003 Enterprise Edition.

Ce chapitre exige aussi une maîtrise complète de l'infrastructure informatique existante pour garantir 
que les stratégies appropriées sont déployées sur les hôtes concernés de l'environnement. Le 
chapitre 3 (« Détermination de l'état actuel de votre infrastructure informatique ») décrit les 

100
informations requises et comment vous les procurer. N'entamez pas la procédure décrite dans ce 
chapitre tant que vous ne disposez pas des informations suivantes :

• La définition des groupes d'isolation de la conception. Chacun des groupes d'isolation requis doit 
bénéficier d'une instruction claire signalant les exigences de sécurité et identifiant les ressources 
auxquelles ces exigences s'appliquent (soit l'appartenance à un groupe d'isolation).

• Une description détaillée de la manière dont les stratégies IPSec sont utilisées pour implémenter 
les groupes d'isolation, avec la liste des différentes stratégies IPSec requises et leur mode 
d'attribution.

• Un résumé général de l'impact d'IPSec pour l'application des groupes d'isolation. Ce résumé peut 
être accompagné d'une liste de problèmes et de solutions pour les éviter.

• Une description détaillée de l'évolution des stratégies IPSec dans le temps et une liste des 
procédures nécessitant des modifications de ces stratégies. Cette liste peut inclure des procédures 
telles que le traitement des incidents de sécurité, l'ajout de composants réseau et l'ajout de clients 
ou de serveurs à un groupe d'isolation quelconque.

• Une bonne connaissance de la topologie du réseau et des schémas d'adressage IP de 
l'organisation.

Création de stratégies IPSec dans Active Directory
Le processus visant à créer les stratégies nécessaires à la prise en charge des groupes d'isolation 
requis implique les tâches principales suivantes :

• Création des listes de filtres.
• Création des actions de filtrage.
• Création des stratégies IPSec pour l'implémentation des groupes d'isolation.

Avant d'entreprendre le processus de création de ces composants, il est primordial que vous vous 
procuriez les schémas et les tableaux des modèles de trafic du chapitre 4 (« Conception et 
planification de groupes d'isolation »), tout comme les tableaux de correspondance réseau et hôtes. 
Ces tableaux fournissent les informations nécessaires pour garantir que les stratégies offrent les 
fonctionnalités requises et sont attribuées aux groupes d'isolation appropriés.

La figure suivante décrit la configuration réseau utilisée pour simuler le scénario de la Woodgrove 
Bank.

101
Figure 5.1 Configuration réseau de la Woodgrove Bank

La configuration du laboratoire de test de la Woodgrove Bank fait apparaître les fonctions clés 
suivantes de la solution :

• Isolation des domaines à l'aide de groupes d'accès réseau afin de contenir certains hôtes à haut 
risque mais approuvés dans le domaine lorsque vous utilisez IPSec.

• Isolation des serveurs à l'aide de groupes d'accès réseau afin de définir et limiter les clients hôtes 
approuvés autorisés à se connecter via IPSec.

De plus, cet environnement de laboratoire permet de dégager les fonctionnalités Windows IPSec 
requises suivantes et d'évaluer la compatibilité avec d'autres technologies de sécurité susceptibles 
d'être employées dans des environnements réels :

• Compatibilité des ordinateurs dotés de Windows 2000 Service Pack (SP) 4 (avec mise à jour de la 
traduction d'adresses réseau NAT­Traversal (NAT­T), Windows XP SP2 et Windows Server 2003 
en tant que membres de domaines.

• Compatibilité de ces plates­formes lorsque vous les sécurisez à partir des techniques de 
renforcement préconisées dans les guides de sécurité Microsoft Windows. Les cartes de trafic 
utilisées pour autoriser et bloquer le trafic à l'aide de filtres IPSec n'ont pas été intégrées à cette 
solution puisque l'isolation ne présente pas les mêmes exigences de protection. D'autres raisons 
ont abouti à la décision de ne pas intégrer les cartes de trafic, notamment le besoin de minimiser la 
complexité des stratégies IPSec d'isolation de serveurs et le fait que le pare­feu Windows est 
souvent mieux adapté au filtrage d'autorisation/blocage (indépendamment de la capacité d'IPSec à 
fournir une sécurité de bout en bout pour chaque paquet).

• Capacité de l'application IPSec à sécuriser le service Web (HTTP), SQL Server, le système de 
fichiers distribués (DFS), le partage de fichiers et d'imprimantes, Microsoft Operations Manager 
(MOM) et les serveurs et le trafic SMS (Microsoft Systems Management Server).

102
• Compatibilité d'IPSec ESP (Encapsulated Security Payload) NAT­T par encapsulation UDP (User 
Datagram Protocol)­ESP pour les deux conditions suivantes :
• Accès sortant depuis des membres de domaine derrière NAT par authentification IKE Kerberos
• Accès entrant à un membre de domaine derrière NAT par authentification IKE Kerberos

Le scénario du laboratoire illustré dans la figure 5.1 a été utilisé pour vérifier que les fonctionnalités 
recherchées étaient obtenues dans tous les groupes d'isolation de la solution. Au total, quatre 
stratégies IPSec ont été créées et attribuées aux groupes d'isolation entourés de tirets gras dans la 
figure (soit le domaine d'isolation, le groupe d'isolation de chiffrement, le groupe d'isolation sans 
basculement et le groupe d'isolation de limite). Les sections suivantes expliquent comment ces 
stratégies ont été créées.

Présentation des composants de la stratégie IPSec

Une stratégie IPSec désigne un nombre de composants utilisés pour appliquer les exigences de 
sécurité IPSec de l'organisation. La figure suivante décrit les divers composants d'une stratégie IPSec 
et expliquent comment ils sont associés entre eux.

Figure 5.2 Composants de la stratégie IPSec

La stratégie IPSec joue le rôle d'un conteneur identifiant l'ensemble des règles qui déterminent quel 
trafic de communication réseau est autorisé et sous quelle forme. Chaque règle se compose d'une 
liste de filtres et d'une action associée. La liste de filtres désigne un groupe de filtres. Chaque trafic 
mis en correspondance avec un filtre spécifique déclenche une action de filtrage associée. Les règles 
permettent également de définir les méthodes d'authentification à appliquer entre les hôtes.

Ce schéma présente la structure descendante des composants de la stratégie. Néanmoins, la 
méthode la plus efficace pour créer des stratégies est de débuter avec des filtres et des listes de 
filtres car ils constituent le bloc fondamental qui permet de contrôler et déterminer quel trafic est 
sécurisé.

103
Listes de filtres IPSec

Les listes de filtres IPSec sont des ensembles d'un ou plusieurs filtres utilisés pour structurer le trafic 
réseau selon des critères définis pour chaque filtre. Chaque filtre répertorié dans la liste des filtres 
définit les éléments suivants :

• Réseaux ou adresses source et de destination
• Protocole(s)
• Ports TCP (Transmission Control Protocol) ou UDP source et de destination

Les listes de filtres et les actions de filtrage ont été conçues pour être partagées entre les stratégies 
IPSec. Cette approche permet de conserver une liste de filtres pour un type d'exemption donné et de 
l'utiliser dans une stratégie IPSec indépendante pour chaque groupe d'isolation. En revanche, les 
filtres qui composent les listes de filtres ne peuvent être partagés d'une liste à l'autre. Si deux listes de 
filtres contiennent des filtres identiques, les filtres devront être créés deux fois, soit un pour chaque 
liste de filtres.

L'administrateur IPSec devra être particulièrement vigilant pour éviter les filtres en double dans une 
stratégie IPSec car les filtres peuvent correspondre à des actions distinctes. Le service IPSec peut 
modifier l'ordre des filtres en double en traitement par paquets et produire des résultats incohérents. 
Vous pouvez recourir aux filtres en double lorsqu'ils impliquent exactement la même action (par 
exemple, action d'autorisation ou de blocage) et que les performances restent inchangées.

Les informations de réseau recueillies précédemment sont utilisées pour identifier les divers modèles 
de trafic que l'administrateur souhaite sécuriser. Elles permettent aussi d'identifier toutes les données 
en circulation pouvant bénéficier d'une exemption pour les restrictions IPSec.

Le tableau ci­dessous décrit certaines listes de filtres élémentaires susceptibles d'être utilisées dans 
une organisation classique. Selon les besoins commerciaux et la conception du réseau de 
l'organisation, d'autres listes de filtres peuvent être nécessaires.

Tableau 5.1 : Listes de filtres de la solution

Liste de filtres Description
Secure Subnets List (Liste des sous­ Contient tous les sous­réseaux de l'organisation à sécuriser 
réseaux sécurisés) avec IPSec.

DNS Exemption List (Liste  Contient les adresses IP des serveurs DNS qui seront 
d'exemptions DNS) autorisés à communiquer sans IPSec.

Domain Controllers Exemption List  Contient les adresses IP des contrôleurs de domaine qui 
(Liste d'exemptions de contrôleurs de  seront autorisés à communiquer sans IPSec.
domaine)

WINS Exemption List (Liste  Contient les adresses IP des serveurs WINS (Windows 
d'exemptions WINS) Internet Naming Service) qui seront autorisés à communiquer 
sans IPSec.

DHCP, Negotiation Traffic (DHCP,  Contient le filtre permettant au trafic de négociation DHCP 
trafic de négociation) (Dynamic Host Configuration Protocol) d'avoir lieu sur le port 
UDP 68.

ICMP, All Traffic (ICMP, tout le trafic) Contient le filtre qui permet au protocole ICMP (Internet 
Control Message Protocol) d'être utilisé au sein de 

104
 l'organisation à des fins de dépannage.

La liste des sous­réseaux sécurisés répertorie tous les sous­réseaux disponibles sur le réseau interne 
de l'organisation. Cette liste de filtres est associée à une action de filtrage chargée d'implémenter les 
actions requises pour un groupe d'isolation spécifique. Cette action constitue l'action de sécurité la 
plus étendue pour l'ensemble du trafic réseau de ce sous­réseau (par exemple, négociation IPSec) ; 
les autres filtres, notamment le filtre ICMP, seront plus spécifiques et nécessiteront une action 
différente (par exemple, autorisation). Un point primordial à retenir est que cette approche signifie 
qu'aucun hôte non approuvé ou non­IPSec ne doit figurer sur ces sous­réseaux.

Les filtres doivent implémenter à la fois des exigences de sécurité en entrée et en sortie. Au moment 
de les définir, vous devez les configurer en miroir. La mise en miroir garantit que le filtre est appliqué 
au trafic dont les adresses source et de destination sont exactement inverses. Lorsque vous 
définissez des filtres, le symbole « <­> » est employé pour signaler que le filtre est mis en miroir. Vous 
devez utiliser des filtres en miroir chaque fois que l'action de filtrage négocie les méthodes de sécurité 
pour l'encapsulation IPSec.

Adresses source et de destination

Chaque filtre dispose d'un paramètre désignant à la fois les adresses source et de destination. 
Windows XP et Windows Server 2003 offrent plus d'options que Windows 2000 pour les adresses. 
Utilisez donc les paramètres Windows 2000 uniquement si cette plate­forme est membre du domaine. 
Les paramètres Windows 2000 se présentent comme suit :

• Mon adresse IP. Cette option a été conçue afin d'appliquer une stratégie IPSec commune dans 
Active Directory à plusieurs ou à l'ensemble des ordinateurs, qu'ils disposent d'une adresse IP 
statique ou d'une adresse attribuée par le serveur DHCP. Pour permettre la gestion centralisée des 
stratégies à partir du domaine, IPSec ne prend pas en charge la configuration des filtres pour les 
interfaces de réseau physique mais uniquement des interfaces réseau de type réseau local ou 
étendu ou des interfaces d'accès réseau à distance ou de réseau privé virtuel (VPN). Lorsque vous 
sélectionnez l'option Mon adresse IP, les filtres génériques de la stratégie IPSec sont copiés dans 
un filtre spécifique contenant chaque adresse IP utilisée par l'ordinateur au moment où le 
service IPSec s'apprête à appliquer la stratégie. Elle permet aussi au service IPSec de détecter 
toutes les modifications apportées aux adresses ou toute nouvelle interface réseau afin de 
conserver le nombre approprié de filtres. Si un ordinateur dispose d'une carte réseau pour laquelle 
deux adresses IP ont été configurées, deux filtres IPSec spécifiques différents sont créés à partir 
des deux adresses IP distinctes.

• N'importe quelle adresse IP. Cette option permet d'appliquer les filtres IPSec à n'importe quelle 
adresse IP.

• Un nom DNS spécifique. Grâce à cette option, IPSec peut évaluer l'adresse IP du nom DNS 
spécifié, puis créer les filtres à partir de cette ou ces adresses IP. Le résultat obtenu est le même 
que si l'administrateur avait entré les adresses IP dans les filtres. Lors de la création du premier 
filtre, le nom DNS est résolu et les adresses IP correspondantes sont placées dans le filtre. Si le 
serveur DNS dispose d'un enregistrement de ressource incorrect pour le nom DNS spécifié dans le 
filtre, l'adresse IP erronée est ajoutée au filtre. 
Remarque : le nom DNS n'est jamais évalué après la création initiale des filtres au sein de la 
stratégie. 
L'option de nom DNS est utile lorsque vous avez besoin de créer un grand nombre de filtres, car le 
nom DNS correspond à de nombreuses adresses IP, notamment pour chaque contrôleur de domaine 
appartenant au domaine. Il n'existe aucune méthode de création automatique de filtres dont la liste 
d'adresses IP peut être actualisée pour un nom DNS donné.

105
• Une adresse IP spécifique. Cette option compare le trafic avec l'adresse IP spécifiée dans le 
filtre.

• Un sous­réseau IP spécifique. Cette option permet à l'administrateur de configurer un sous­
réseau spécifique. N'importe quelle adresse IP au sein du sous­réseau spécifié correspondra au 
filtre. Manipulez cette option avec soin, surtout si vous avez défini une exemption pour un sous­
réseau (tout utilisateur malveillant s'emparant d'une adresse IP de ce sous­réseau sera, lui aussi, 
exempté).
Remarque : Windows XP et Windows Server 2003 ont été améliorés en vue de fournir des options 
d'adresse supplémentaires et d'autres options prises en charge dans ces versions. Si la même 
stratégie IPSec est appliquée à plusieurs plates­formes, l'administrateur doit s'assurer que seules les 
options de Windows 2000 sont utilisées dans l'élaboration de la stratégie.

Protocoles

Outre les adresses source et de destination, chaque filtre peut être configuré pour rechercher un 
protocole ou un port spécifique. Par défaut, le filtre s'appliquera au trafic sur tous les protocoles et 
tous les ports. Si un protocole spécifique prenant en charge les ports est sélectionné en tant que 
critère de filtrage, l'administrateur a également la possibilité de configurer les ports source et de 
destination.

Ports source et de destination

Bien que les filtres puissent être configurés afin d'être adaptés aux ports TCP ou UDP, cette solution 
ne recommande pas la création de filtres spécifiques aux ports. Le filtrage par port augmente 
considérablement la charge administrative et la complexité de la configuration des filtres IPSec et peut 
exiger un effort de coordination complexe entre les stratégies client et serveur pour permettre une 
négociation correcte de la sécurité par IKE. Puisque cette solution part du principe que la 
communication entre les ordinateurs approuvés est en fait approuvée, les filtres autorisent IPSec à 
sécuriser tout le trafic (sauf le trafic ICMP). Si le filtrage par port s'avère nécessaire sur l'hôte 
approuvé, reportez­vous à la feuille de calcul Business_Requirements.xls pour connaître les 
conditions de sécurité liées à l'utilisation combinée d'IPSec et d'un pare­feu basé sur un hôte (par 
exemple, le pare­feu Windows) superposé sur la couche IPSec.

Pour éviter certains des problèmes mentionnés dans l'annexe A et inhérents au comportement des 
filtres avec l'option « Mon adresse IP », cette solution utilise des filtres N'importe quelle adresse IP <­> 
sous­réseaux pour le scénario de la Woodgrove Bank. Une liste composée de plusieurs filtres 
N'importe quelle adresse IP <­> Un sous­réseau IP spécifique est créée, répertoriant de manière 
explicite tous les sous­réseaux de l'organisation. Cette approche permet à l'administrateur de définir 
les sous­réseaux spécifiques à sécuriser. Tout le trafic circulant en dehors des sous­réseaux spécifiés 
ne correspond à aucun filtre IPSec et est envoyé en clair à l'hôte de destination.

Pour connaître d'autres méthodes conseillées pour la création de filtres, reportez­vous à la section 
« Best Practices » (Meilleures pratiques) du livre blanc « Improving Security with Domain Isolation: 
Microsoft IT implements IP Security (IPSec)   » (Amélioration de la sécurité avec l'isolation de 
domaines : Implémentation d'IPSec par Microsoft IT) sur Microsoft TechNet à l'adresse 
www.microsoft.com/technet/itsolutions/msit/
security/ipsecdomisolwp.mspx.

Considérations relatives aux listes d'exemptions

Pour des raisons de support, techniques ou commerciales, certains types de trafic ne peuvent pas 
être protégés par IPSec. De même, la prise en charge d'IPSec n'est pas garantie sur les ordinateurs 
non dotés du système d'exploitation Windows et son déploiement peut s'y avérer délicat. Les 

106
ordinateurs munis d'anciennes versions de Windows, notamment Microsoft Windows NT® version 4.0, 
Windows 95 et Windows 98, ne peuvent pas gérer une structure IPSec fondée sur la stratégie de 
groupe. Enfin, les ordinateurs non gérés équipés de Windows 2000 (ou ultérieur) peuvent uniquement 
participer à la négociation IPSec si la stratégie est déployée manuellement sur chaque ordinateur et 
qu'une forme d'authentification autre que le protocole Kerberos version 5 (par exemple, une clé pré­
partagée ou un certificat) est utilisée.

Qui plus est, un ordinateur équipé de Windows 2000 (ou ultérieur) nécessite une connectivité réseau 
et doit être en mesure de se procurer une stratégie IPSec à partir du domaine avant d'implémenter 
IPSec. À l'heure actuelle, la connexion au réseau, l'identification d'un contrôleur de domaine et 
l'obtention de la stratégie exigent que les services de l'infrastructure de soutien soient exemptés de la 
sécurité IPSec. Il peut s'agir de services d'attribution de noms, tels que les services DNS et WINS, et 
des contrôleurs de domaine eux­mêmes.

Outre ces services d'infrastructure, d'autres services ne prenant pas en charge IPSec peuvent être 
présents dans l'organisation. Par exemple, les clients légers ou d'autres clients d'amorçage (BOOTP) 
cherchant à télécharger une image depuis des services ADS (Advanced Deployment Services) ou des 
services d'installation à distance (RIS) ne prennent pas en charge IPSec. Si des serveurs fournissant 
ces services existent sur votre réseau, vous devez les examiner et envisager de les intégrer dans une 
liste d'exemptions ou bien les affecter en tant que membres du groupe d'isolation de limite afin qu'ils 
puissent accepter les communications réseau provenant des hôtes inaptes à utiliser IPSec.

Remarque : la décision d'inclure ou non les serveurs dotés de services ADS, RIS ou d'autres services 
répertoriés dans les listes d'exemptions, ou celle de les définir en tant que membres du groupe 
d'isolation de limite, dépend de critères de risque et de facilité de gestion. Dans un cas comme dans 
l'autre, vous devez tester avec soin l'approche choisie.

Si un client est inapte à participer à l'infrastructure IPSec mais doit, pour des besoins commerciaux, 
accéder à un serveur qui utilise IPSec, vous devez implémenter une méthode permettant d'établir un 
chemin de communication. La solution de ce guide fait appel à des listes d'exemptions pour contrôler 
ces exigences de trafic par le biais d'autorisations. Les listes d'exemptions sont créées dans 
l'infrastructure IPSec pour s'assurer que toutes les communications requises avec les hôtes ont lieu, 
même si l'utilisation de négociations IPSec est impossible.

Leur but est d'empêcher le trafic (de manière sélective) de participer à l'infrastructure IPSec en 
autorisant seulement le trafic correspondant aux filtres des listes d'exemptions. Ces listes doivent être 
établies avec soin puisqu'elles ne sont pas soumises aux mécanismes de sécurité mis en place par 
IPSec. Par exemple, si vous placez un serveur généralement sécurisé par chiffrement (protection des 
informations propriétaires) dans un filtre d'exemption, les ordinateurs invités pourront communiquer 
directement avec le serveur sans l'aide d'IPSec.

Les listes d'exemptions sont implémentées en tant que listes de filtres afin de réduire la taille des 
listes et faciliter la configuration de l'interface utilisateur. Par exemple, vous devez disposer d'une liste 
de filtres contenant les filtres de tous les contrôleurs de domaine ou des contrôleurs de domaine 
figurant dans chaque domaine. Un autre avantage à disposer de plusieurs listes de filtres réside dans 
le fait que vous pouvez aisément désactiver/activer la règle d'autorisation dans la stratégie IPSec.

Lorsque vous concevez une règle pour définir une exemption dans la stratégie IPSec, il est préférable 
d'autoriser la quantité de trafic la plus infime possible à ne plus être protégé par IPSec. Néanmoins, la 
complexité et la taille de la stratégie IPSec, face aux gains de sécurité que représente l'emploi des 
filtres les plus spécifiques, implique des compromis. Notez que toutes les adresses IP des contrôleurs 
de domaine dans toutes les forêts approuvées doivent être exemptées afin que les clients d'un 
domaine ou d'une forêt puissent se procurer des tickets Kerberos pour les serveurs d'une autre forêt 
ou d'un autre domaine approuvé. Pour ses propres contrôleurs de domaine et ceux d'autres 
domaines, le client Windows Kerberos doit disposer des éléments suivants : ICMP, LDAP (Lightweight 

107
Directory Access Protocol) sur port UDP 389 et le trafic Kerberos sur les ports UDP 88 et TCP 88. Les 
membres des domaines exigent d'autres types de trafic pour les contrôleurs de domaine de leur 
propre domaine, notamment SMB (Server Message Block) sur TCP 445, l'appel de procédure distante 
(RPC) et LDAP sur TCP 389. Lorsque les exigences de sécurité ne sont pas trop importantes, 
l'exemption est définie pour « tout le trafic » avec les adresses IP des contrôleurs de domaine pour 
simplifier les choses et réduire le nombre de filtres.

Il peut être tentant d'exempter une application particulière par port, plutôt que par adresse de 
destination, pour éviter d'avoir à entretenir une liste d'adresses (par exemple, un trafic Telnet sortant 
utilisant le port TCP 23 pour accéder à des systèmes UNIX). Par exemple, imaginons l'exemption 
sortante suivante :

Mon adresse IP à N'importe quelle adresse IP, TCP, src port N'importe lequel, dst port 23, miroir

Le filtre entrant correspondant se présente comme suit :

N'importe quelle adresse IP à Mon adresse IP, TCP, src port 23, dst port N'importe lequel

Ce filtre entrant permettrait d'obtenir des réponses aux demandes de connexion Telnet, mais un 
attaquant pourrait également contourner les exigences d'authentification IPSec et accéder à n'importe 
quel port ouvert sur l'hôte. Les organisations devront évaluer avec soin les risques de sécurité d'une 
éventuelle attaque de ce type avant d'utiliser un tel filtre. Les risques sont sans doute réduits si vous 
spécifiez l'adresse IP de destination. Cette même situation peut se produire si l'exemption par défaut 
du protocole d'authentification Kerberos n'est pas désactivée. Reportez­vous aux articles 811832   
(http://support.microsoft.com/?kbid=811832) et 810207   (http://support.microsoft.com/?
kbid=810207) de la Base de connaissances Microsoft pour obtenir des informations détaillées sur 
l'impact des exemptions par défaut en termes de conception et de sécurité. Vous devez concevoir les 
stratégies IPSec en partant du principe qu'aucune exemption par défaut n'est activée.

L'insertion d'adresses système dans une liste d'exemptions exempte bel et bien ces systèmes de 
participer en tant qu'hôtes IPSec dans toutes les stratégies IPSec qui mettent en œuvre la liste 
d'exemptions. Du fait que la plupart des clients de l'organisation (y compris les clients invités) 
nécessitent habituellement un accès aux services d'infrastructure, notamment DHCP, DNS ou WINS, 
les serveurs fournissant ces services sont, en règle générale, implémentés de cette manière.

Listes de filtres de la Woodgrove Bank

Après avoir analysé les exigences de trafic décrites au chapitre 4, les administrateurs de la 
Woodgrove Bank ont élaboré les listes de filtres dans le tableau ci­dessous.

Tableau 5.2 : Exemples de listes de filtres de la Woodgrove Bank

Liste de filtres Filtres définis Protocole ou 

port
Secure Subnets (Sous­réseaux sécurisés) N'importe lequel <­> 
192.168.1.0/24
N'importe lequel <­> 172.10.1.0/24 Toutes
DNS Exemption List (Liste d'exemptions DNS) N'importe lequel <­> 
192.168.1.21
N'importe lequel <­> 192.168.1.22 Toutes
Domain Controllers Exemption List (Liste d'exemptions  N'importe lequel <­> 
de contrôleurs de domaine) 192.168.1.21

108
N'importe lequel <­> 192.168.1.22 Toutes

LOB Application Servers Exemption List (Liste  N'importe lequel <­>  Tous

d'exemptions de serveurs d'application commerciales) 192.168.1.10

WINS Exemption List (Liste d'exemptions WINS) N'importe lequel <­>  Tous

192.168.1.22

DHCP, Negotiation Traffic (DHCP, trafic de  Mon adresse IP <­>  UDP source 68, 

négociation) N'importe lequel dest 67

ICMP, All Traffic (ICMP, tout le trafic) Mon adresse IP <­>  ICMP 

N'importe lequel uniquement

Les concepteurs de la Woodgrove Bank ont suivi les instructions fournies dans ce chapitre pour créer 
les listes de filtres. La première liste, celle des sous­réseaux sécurisés, comporte deux filtres :

• N'importe lequel <­> 192.168.1.0/24
• N'importe lequel <­> 172.10.1.0/24

Ces filtres de sous­réseaux sont mis en miroir pour correspondre à la fois au trafic entrant et sortant et 
sont configurés pour être déclenchés sur n'importe quel protocole. Cette liste de filtres, une fois 
associée à l'action de filtrage appropriée, procèdera à l'implémentation des groupes d'isolation.

Les concepteurs de la Woodgrove Bank ont choisi d'implémenter ensuite une liste d'exemptions pour 
le trafic réseau ICMP. Cette liste de filtres comprend un filtre miroir unique (Mon adresse IP <­> 
N'importe lequel) configuré exclusivement pour le trafic réseau ICMP. Cette approche permet aux 
administrateurs d'utiliser l'utilitaire Ping en tant qu'outil de dépannage au sein de l'environnement, 
sans se soucier de savoir si une association de sécurité IPSec a été négociée ou non. Cette approche 
s'avérait également nécessaire du fait que la solution exige la découverte du PMTU (Path MTU) pour 
fonctionner correctement. Pour le trafic DHCP, les concepteurs de la Woodgrove Bank ont créé un 
nouveau filtre pour le port UDP 68 afin de permettre aux clients DHCP de recevoir le trafic provenant 
du serveur DHCP.

De plus, la Woodgrove Bank dispose de quelques applications commerciales sur des serveurs inaptes 
à participer à l'infrastructure IPSec. Pour adapter ces services, ils ont créé une nouvelle liste de filtres 
d'exemption (LOB Application Servers Exemption List) et ajouté un filtre N'importe lequel <­> 
192.168.1.10 pour le système hébergeant l'application commerciale.

Pour finir, l'équipe de conception de la Woodgrove Bank a identifié ses services d'infrastructure et 
créé les listes de filtres d'exemption correspondantes pour permettre à tous les clients de 
communiquer directement avec les serveurs fournissant ces services, quels que soient les paramètres 
IPSec des groupes d'isolation. Des listes d'exemptions spécifiques ont été créées pour les services 
suivants :

• DNS. Cette liste exempte les serveurs DNS afin que tous les clients du réseau puissent procéder à 
des recherches de noms de domaines.

• Contrôleurs de domaine. Cette liste permet aux systèmes associés à des domaines de 
s'authentifier avec un contrôleur de domaine.

• WINS. Cette liste permet surtout aux périphériques hôtes de rechercher des noms NetBIOS sur un 
serveur WINS.

109
Ces listes de filtres sont composées de filtres mis en miroir (de type N'importe lequel <­> Une adresse 
IP spécifique) configurés pour se déclencher sur n'importe quel protocole. Le nombre d'ordinateurs 
inscrits dans les listes de filtres d'exemption doit rester aussi réduit que possible puisque tout le trafic 
est exempté sur ces ordinateurs et que tous les ordinateurs de la liste d'exemptions bénéficient d'un 
accès TCP/IP intégral à tous les hôtes approuvés du domaine d'isolation. Cette approche peut, par 
conséquent, élargir la surface d'attaque potentielle. Consultez la feuille de calcul 
Business_Requirements.xls (dossier Tools and Templates) pour obtenir des détails sur les 
exigences d'atténuation des risques liés au trafic entrant depuis les adresses IP exemptées.

La Woodgrove Bank a choisi de gérer deux listes séparées pour les serveurs DNS et les contrôleurs 
de domaine, même si les adresses IP sont identiques. La Woodgrove Bank a opté pour cette 
approche parce que les deux listes de filtres présenteront exactement la même action (autoriser). De 
plus, le réseau de production Woodgrove utilise les serveurs DNS dans certains domaines où ils ne 
sont pas également des contrôleurs de domaine.

Au lieu d'utiliser des adresses IP de destination spécifiques, le filtre DHCP a été conçu pour 
s'appliquer à l'ensemble du trafic sortant des clients DHCP. La copie miroir de ce filtre autorise les 
réponses des serveurs DHCP. Comme nous l'avons déjà indiqué, il peut également autoriser des 
attaques entrantes depuis n'importe quelle adresse IP utilisant le port source 67. En revanche, 
l'attaque entrante est limitée au port de destination 68 sur le client, ce que le client DHCP utilise. La 
Woodgrove Bank a utilisé cette conception pour éviter de créer des filtres pour chaque serveur DHCP 
et parce que son évaluation des risques a conclu que les risques d'attaques entrantes sur le port du 
client DHCP ou les risques de serveurs DHCP non autorisés n'étaient pas très élevés.

Cette section ne fournit pas une description complète de chaque filtre. Néanmoins, nous vous 
conseillons d'utiliser le champ de description du filtre pour définir avec soin chaque filtre puisque le 
moniteur IPSec et les outils de ligne de commande affichent la description de chaque filtre, pas les 
informations dans la liste de filtres.

Actions de filtrage IPSec

Les actions de filtrage définissent la manière dont les paquets IP sont gérés après qu'ils aient été 
reconnus par un filtre de la liste des filtres. Les actions de filtrage sont à la base de l'implémentation 
des divers groupes d'isolation. Bien que le système d'exploitation Windows propose trois actions de 
filtrage par défaut, nous vous conseillons de les retirer et de créer d'autres actions de filtrage 
conformes à cette approche pour veiller à ce que seules les actions que vous créez dans le cadre de 
votre solution soient utilisées. Chaque action de filtrage est composée d'un nom, d'une description et 
d'une méthode de sécurité.

Nom

Donnez un nom significatif à l'action de filtrage, qui reflète ce qu'elle fait.

Description

Tapez une description détaillée de l'action de filtrage dans le champ de description.

Méthodes de sécurité

Les méthodes de sécurité implémentées dans l'action de filtrage sont déterminées par les exigences 
de traitement des paquets correspondant aux filtres associés dans la liste de filtres. Les trois options 
disponibles sont les suivantes :

110
• Bloquer. Les paquets IP correspondant au filtre associé sont bloqués, ce qui signifie qu'ils sont 
ignorés.

• Autoriser. Les paquets IP correspondant au filtre associé sont autorisés à traverser la couche 
IPSec sans traitement supplémentaire dans IPSec.

• Négocier. Si les paquets sortants répondent aux critères du filtre, IPSec tente de négocier l'une 
des méthodes de sécurité inscrites dans l'action de filtrage selon leur ordre relatif. Plus la méthode 
de sécurité est haut dans la liste, plus la priorité qui lui est accordée est grande. Chaque méthode 
de sécurité peut déterminer s'il faut utiliser l'outil d'intégrité, activer le chiffrement et quels 
algorithmes de cryptographie sont implémentés. Le traitement des paquets entrants correspondant 
à un filtre doté d'une action de négociation (négocier) est fonction du paramètre défini pour l'option 
Accepter les communications non sécurisées mais toujours répondre en utilisant IPSec.

Le tableau ci­après répertorie les options cryptographiques possibles pour chaque méthode de 
sécurité :

Tableau 5.3 : Options cryptographiques et de sécurité

Méthode de  Options  Description

sécurité cryptographiques
Authentification de  MD5 Garantit à la fois l'authenticité et l'intégrité de la charge 
l'en­tête (AH) SHA­1 utile IP (données) et de l'en­tête IP (adresse) sans 
chiffrement. AH ne peut pas traverser les périphériques 
utilisant la traduction d'adresses réseau (NAT).
ESP – Intégrité <Aucune> Garantit l'intégrité et l'authenticité des données de la 
MD5 charge utile IP (données) uniquement. Elle peut être 
SHA­1 utilisée avec ou sans chiffrement. L'utilisation d'ESP sans 
authentification est déconseillée.
ESP – chiffrement <Aucune> Avec DES ou 3DES, fournit le chiffrement de la charge 
3DES utile IP (données). Peut être utilisée avec un algorithme 
DES de chiffrement nul lorsque le chiffrement n'est pas 
nécessaire. 

Les implémentations IPSec dans Windows 2000 SP4, Windows XP SP2 et Windows Server 2003 
prennent désormais en charge les techniques NAT­T pour ESP en mode de transport IPSec, en plus 
de la prise en charge de NAT­T pour les tunnels clients VPN L2TP/IPSec. La mise à jour NAT­T est 
requise pour Windows 2000 SP4. La prise en charge de NAT­T en mode de transport IPSec dans 
Windows 2000 et Windows XP est limitée aux versions Windows 2000 et Windows XP antérieures au 
SP2 puisque la fonctionnalité de détection PMTU (Path­MTU) TCP n'est pas prise en charge pour le 
trafic TCP protégé par IPSec. Windows Server 2003 offre cette prise en charge. Les techniques NAT­
T utilisent un en­tête UDP après l'en­tête IP pour encapsuler ESP. IKE détecte automatiquement 
l'existence de NAT dans le chemin et utilise UDP­ESP si ESP est autorisé dans la liste des méthodes 
de sécurité. Un point également à noter est que les implémentations IPSec Windows actuelles ne 
prennent pas en charge la norme AES (Advanced Encryption Standard) du gouvernement fédéral 
américain. Cela sera corrigé dans les versions prochaines de Windows.

Les options cryptographiques disponibles pour AH et ESP sont les suivantes :

• MD5. Cet algorithme de hachage utilise une clé de chiffrement de 128 bits pour générer un résumé 
du contenu du paquet. MD5 n'est pas un algorithme adapté à des scénarios de sécurité du 
gouvernement fédéral américain.

• SHA­1. Cet algorithme de hachage utilise une clé de chiffrement de 160 bits pour générer un 
résumé du contenu du paquet. Plus la clé de SHA­1 est longue, plus la sécurité est élevée mais la 

111
 charge requise pour le traitement est, elle aussi, plus importante. SHA­1 est un algorithme adapté 
aux réglementations de sécurité du gouvernement fédéral américain.

Vous pouvez configurer ESP afin qu'il n'utilise aucun algorithme de chiffrement, auquel cas seules 
l'authenticité et l'intégrité des données sont appliquées. Cette configuration, couramment appelée 
ESP­Null, offre la possibilité d'authentifier les hôtes avant d'établir une connexion et d'effectuer une 
vérification de l'intégrité de la section des données du paquet IP transporté au sein du paquet ESP.

ESP peut également chiffrer la section des données du paquet IP. Les deux options cryptographiques 
disponibles sont les suivantes :

• DES. Cette option utilise une clé 56 bits et traite chaque bloc une seule fois. DES offre une 
conformité RFC (Request for Comment). Les attaquants étant de plus en plus capables de 
compromettre le chiffrement DES, l'utilisation de l'option DES n'est pas conseillée.

• 3DES. Cette option traite chaque bloc trois fois à l'aide de trois clés 56 bits uniques. Bien que 
l'option DES soit prise en charge, il est vivement recommandé d'utiliser l'option plus sécurisée 
3DES. En revanche, 3DES est un peu plus lent et exige une capacité de traitement plus élevée 
que DES.

Vous pouvez combiner les protocoles AH et ESP s'ils doivent répondre à des exigences de sécurité 
optimales. Par exemple, si votre infrastructure exige clairement l'intégrité de l'en­tête IP en plus du 
chiffrement des données, vous pouvez configurer la méthode de sécurité afin qu'elle utilise le 
protocole AH avec une intégrité SHA­1 et un chiffrement ESP–3DES. Si seule l'intégrité des données 
est requise, vous pouvez alors utiliser ESP­Null avec SHA­1. 

Bien que vous puissiez choisir une combinaison quelconque d'options de sécurité, il faut savoir que le 
protocole AH garantit à la fois l'intégrité des données et de l'en­tête d'adresse. L'utilisation combinée 
des protocoles AH et ESP ne renforce pas la protection de l'intégrité des données des paquets. Elle 
augmente simplement la charge de travail associée au traitement du paquet. Qui plus est, ESP 
associé à AH ne résout pas les problèmes de barrière NAT auxquels le protocole AH est confronté. 
L'utilisation du protocole AH avec ESP ne convient donc qu'aux environnements de haute sécurité.

Une planification minutieuse est nécessaire pour définir les méthodes de sécurité des actions de 
filtrage. Pour mener à bien la négociation de deux ordinateurs, ces derniers doivent disposer au moins 
d'une méthode de sécurité en commun dans leurs actions de filtrage respectives. Chaque action de 
filtrage peut contenir plusieurs méthodes de négociation en vue de s'adapter à différents types de 
négociation. Par exemple, un système négocie souvent uniquement ESP­Null, mais l'action de filtrage 
peut contenir également une méthode de négociation pour ESP­3DES. Cette approche permet au 
système de négocier une connexion de chiffrement 3DES si celle­ci est nécessaire.

Outre le choix des méthodes de sécurité, vous pouvez au besoin définir les paramètres de la clé de 
session pour chaque méthode de sécurité. Dans le paramètre par défaut, la durée de vie des 
associations de sécurité IPSec est fixée au moment où 100 méga­octets (Mo) de données sont 
transmises ou au bout d'une heure de temps passé. Ces paramètres détectent chaque nouvelle paire 
d'associations de sécurité IPSec renégociée en mode rapide IKE. Bien que le processus du mode 
rapide IKE soit appelé « régénération des clés », il ne se contente pas d'actualiser les clés d'une paire 
d'associations de sécurité IPSec. IPSec doit ignorer les paquets si la durée de vie expire ; il s'efforce 
donc de renégocier comme il se doit avant que la durée de vie en octets ou en secondes n'expire. Si 
la durée de vie définie est trop faible, les paquets risquent d'être perdus. De même, vous pouvez 
augmenter le taux d'utilisation du processeur pour les serveurs chargés d'entretenir les associations 
de sécurité IPSec avec un grand nombre de clients. Le renouvellement des associations de sécurité 
IPSec garantit qu'aucun attaquant ne peut déchiffrer l'ensemble de la communication même s'il 
parvient à déterminer l'une des clés de la session. À mesure que la durée de vie augmente, l'attaquant 
obtient davantage d'informations sur la clé de la session. Par conséquent, il est préférable que vous 

112
ne changiez pas la durée de vie sauf si des besoins opérationnels l'exigent. Vous pouvez également 
rédiger des exigences de sécurité spécifiques qui définissent un niveau approprié de protection contre 
des attaques cryptographiques élaborées.

Options de négociation de sécurité

Vous pouvez définir les options de négociation de sécurité suivantes pour les stratégies IPSec :

• Relais entrant
• Communiquer en texte clair
• Utiliser la session de clé principale PFS (Perfect Forward Secrecy)

Relais entrant

L'option Relais entrant a été conçue pour être utilisée dans une stratégie serveur interne afin que la 
stratégie client puisse adopter la règle de « réponse par défaut » non intrusive. Une fois cette option 
activée, toute demande de connexion soumise en texte clair et correspondant à un filtre entrant sera 
acceptée. La réponse de connexion du serveur correspond au filtre sortant pour déclencher une 
demande de négociation IKE en mode principal au client.

Il est préférable de ne pas activer cette option sur des ordinateurs reliés à Internet en raison des 
attaques entrantes qu'elle laisse circuler à travers la couche IPSec. Elle force également le serveur à 
tenter une négociation d'association de sécurité IPSec sur l'adresse IP source de tout paquet entrant. 
En prenant le contrôle des adresses IP source, l'attaquant peut provoquer un refus de service sur le 
serveur tandis qu'IKE tente de négocier avec des centaines ou des milliers d'adresses IP non valides.

Pour activer l'option Relais entrant, activez la case à cocher Accepter les communications non 
sécurisées mais toujours répondre en utilisant IPSec dans la boîte de dialogue Gérer les actions 
de filtrage.

Remarque : si les stratégies attribuées aux clients n'activent pas la règle de réponse par défaut, vous 
devez désactiver cette option puisqu'il n'y aura aucune réponse pour la communication IPSec. De 
plus, elle peut être utilisée comme vecteur d'attaque de refus de service.

Communiquer en texte clair

L'option Communiquer en texte clair avec les ordinateurs qui ne prennent pas en charge IPSec 
contrôle la capacité de l'ordinateur (source) à transmettre le trafic sans protection IPSec si la 
négociation IKE initiale en mode normal n'obtient aucune réponse d'un ordinateur de destination cible. 
Les hôtes qui ne prennent pas en charge IPSec ne seront pas en mesure de répondre (via IKE) à la 
demande de négociation IKE. Dans le cas de ces hôtes, on parle d'ordinateurs qui n'utilisent pas 
IPSec. Néanmoins, l'absence de réponse IKE en mode principal ne signifie pas nécessairement que 
l'ordinateur n'est pas compatible avec IPSec. Il peut s'agir d'un ordinateur IPSec qui ne dispose pas 
d'une stratégie IPSec active. La stratégie IPSec active peut aussi n'effectuer que des actions autoriser 
et bloquer. Elle peut également ne pas avoir été conçue pour négocier avec l'adresse IP de 
l'ordinateur source. En terminologie IPSec, le trafic réseau qui n'utilise pas IPSec est appelé trafic en 
texte clair. Si l'ordinateur cible ne répond pas sous trois secondes, une association de sécurité 
logicielle (SA logicielle) est créée et la communication est entamée en texte clair. Pour vos premiers 
déploiements, nous vous conseillons d'activer cette option afin que les clients puissent communiquer 
avec les hôtes sur lesquels IPSec n'est pas activé. De même, le recours à cette option permet aussi 
d'établir à nouveau une connectivité provisoire en texte clair lorsque vous arrêtez le service IPSec à 
des fins de dépannage. Si l'ordinateur cible fournit une réponse IKE et qu'un échec de la 

113
négociation IKE survient pour une raison quelconque, IPSec ignore les paquets sortants sur 
l'ordinateur source et bloque véritablement la communication.

Pour activer l'option Communiquer en texte clair, activez la case à cocher Autoriser une 
communication non sécurisée avec des ordinateurs n'utilisant pas IPSec dans la boîte de 
dialogue Gérer les actions de filtrage.

Remarque : le mode de fonctionnement de cette option a évolué sur les ordinateurs fonctionnant 
sous Windows 2000 SP3 (ou ultérieur), Windows XP SP1 ou Windows Server 2003. Si vous activez 
uniquement cette option, le système pourra lancer une communication sécurisée mais n'acceptera 
aucune demande de communication de systèmes n'utilisant pas IPSec. Si le système doit répondre à 
des demandes en provenance de systèmes qui n'utilisent pas IPSec et établir une communication 
avec ces systèmes, vous devez activer à la fois les cases à cocher Accepter les communications 
non sécurisées mais toujours répondre en utilisant IPSec et Autoriser une communication non 
sécurisée avec des ordinateurs n'utilisant pas IPSec.
Si le système fonctionne sous Windows 2000 ou Windows XP sans les service packs appropriés, le 
client accepte les demandes de communication non sécurisée dès que vous sélectionnez l'option 
Autoriser une communication non sécurisée avec des ordinateurs n'utilisant pas IPSec, même 
si la case à cocher Accepter les communications non sécurisées mais toujours répondre en 
utilisant IPSec est désactivée. Ce comportement se produit parce que lorsque vous activez la case 
à cocher Autoriser une communication non sécurisée avec des ordinateurs n'utilisant pas 
IPSec, IPSec traite le filtre entrant associé en tant que filtre relais entrant (le même comportement que 
lorsque vous activez la case à cocher Accepter les communications non sécurisées mais 
toujours répondre en utilisant IPSec).

Utiliser la session de clé principale PFS (Perfect Forward Secrecy)

L'option Utiliser la session de clé principale PFS (Perfect Forward Secrecy) permet de déterminer si la 
clé principale peut générer toutes les clés de session ou seulement la première. En activant cette 
option, vous ne pourrez utiliser la clé principale qu'une seule fois et chaque renégociation de clé de 
session supplémentaire exigera un nouvel échange de clés pour générer une nouvelle clé principale 
avant de générer la clé de session. Cette exigence garantit qu'en cas de clé principale compromise, 
l'attaquant ne peut générer aucune clé de session supplémentaire lui permettant de déchiffrer le flux 
de trafic. Nous vous déconseillons d'activer cette option en raison de la charge supplémentaire 
qu'implique un échange de clés à chaque intervalle de renouvellement de clé de session.

Pour plus d'informations sur les options Relais entrant, Communiquer en texte clair et les options de 
clé de session et de clé principale PFS, reportez­vous à la section « Security Negotiation Options » 
(Options de négociation de sécurité) du document Using Microsoft Windows IPSec to Help Secure an 
Internal Corporate Network Server   (Utilisation de Microsoft Windows IPSec pour aider à sécuriser 
un serveur de réseau d'entreprise interne) disponible depuis le Centre de téléchargement Microsoft à 
l'adresse www.microsoft.com/downloads/details.aspx?familyid=a774012a­ac25­4a1d­8851­
b7a09e3f1dc9&displaylang=en.

Actions de filtrage IPSec de la Woodgrove Bank

Le tableau ci­après fournit les noms et les descriptions des actions de filtrage utilisées pour 
l'implémentation des divers groupes d'isolation intervenant dans le scénario de la Woodgrove Bank.

Tableau 5.4 : Actions de filtrage IPSec et descriptions

Action de filtrage Description
IPSec – Block (Bloquer) Bloque le trafic correspondant au filtre.

114
IPSec – Permit (Autoriser) Autorise le trafic correspondant au filtre.
IPSec – Request Mode 
(Accept Inbound, Allow  Un hôte accepte les paquets entrants qui sont soit de type IPSec, 
Outbound) (Mode de requête ­  soit en texte clair. Pour le trafic sortant, il déclenche une 
Accepter le trafic entrant,  négociation IKE et autorise l'option Communiquer en texte clair s'il 
Autoriser le trafic sortant) ne reçoit aucune réponse. Cette action de filtrage est utilisée pour 
la configuration du groupe d'isolation de limite.

IPSec – Secure Request Mode  Un hôte autorise l'accès TCP/IP entrant uniquement lorsque les 
(Ignore Inbound, Allow  paquets sont sécurisés par IPSec et ignore les paquets entrants 
Outbound) (Mode de requête  non­IPSec. Pour le trafic sortant, il déclenche une négociation IKE 
sécurisée ­ Ignorer le trafic  et autorise l'option Communiquer en texte clair s'il ne reçoit 
entrant, Autoriser le trafic  aucune réponse. Ce filtre sert à l'implémentation du domaine 
sortant) d'isolation dans lequel les connexions sortantes vers les hôtes 
approuvés sont autorisées.

IPSec – Full Require Mode  Un hôte exige des communications sécurisées IPSec pour les 
(Ignore Inbound, Disallow  paquets entrants comme pour les paquets sortants. Cette action 
Outbound) (Mode requis complet  de filtrage permet d'implémenter le groupe d'isolation sans 
­ Ignorer le trafic entrant, Ne pas  basculement dans lequel toutes les communications sont 
autoriser le trafic sortant) protégées par IPSec.

IPSec – Require Encryption  Un hôte autorise l'accès TCP/IP entrant uniquement lorsque les 
Mode (Ignore Inbound, Disallow  paquets sont sécurisés par chiffrement ESP 3DES IPSec et ignore 
Outbound) (Mode de chiffrement  les paquets entrants non­IPSec. Pour le trafic sortant, il déclenche 
requis ­ Ignorer le trafic entrant,  une négociation IKE exigeant un chiffrement ESP 3DES IPSec. 
Ne pas autoriser le trafic sortant) Cette action de filtrage est utilisée pour la configuration du groupe 
d'isolation de chiffrement.

Les deux premières actions de filtrage sont simples à réaliser. L'action de filtrage Bloquer ignore tout 
le trafic correspondant au filtre d'une liste de filtres associée à l'action. L'action de filtrage Autoriser 
autorise le trafic pour n'importe quelle liste de filtres associée contenant le filtre correspondant. Les 
quatre dernières actions de filtrage présentées dans le tableau 5.4 sont utilisées pour l'implémentation 
des groupes d'isolation dans le scénario de la Woodgrove Bank. 

Les administrateurs de la Woodgrove Bank ont quatre groupes d'isolation de sécurité à implémenter. 
Pour déployer cette configuration, vous devez définir au minimum trois actions de filtrage dotées de 
méthodes de négociation de sécurité personnalisées en plus des actions de filtrage Autoriser et 
Bloquer.

La Woodgrove Bank n'impose aucune exigence supplémentaire pour l'isolation mutuelle des 
ordinateurs au sein d'un groupe d'isolation de sécurité spécifique. La Woodgrove Bank a établi que les 
quatre actions de filtrage négociées dans le tableau ci­dessous suffisent à la mise en place de son 
environnement :

Tableau 5.5 : Méthodes de sécurité prises en charge

Action de filtrage Méthodes de sécurité prises 
en charge
IPSec – Request Mode (Accept Inbound, Allow Outbound) (Mode  ESP – SHA­1, <Aucune> 
de requête ­ Accepter le trafic entrant, Autoriser le trafic sortant) ESP – SHA­1, 3DES
IPSec – Secure Request Mode (Ignore Inbound, Allow Outbound)  ESP – SHA­1, <Aucune>
(Mode de requête sécurisée ­ Ignorer le trafic entrant, Autoriser le  ESP – SHA­1, 3DES
trafic sortant)
IPSec – Full Require Mode (Ignore Inbound, Disallow Outbound)  ESP – SHA­1, <Aucune>

115
(Mode requis complet ­ Ignorer le trafic entrant, Ne pas autoriser le  ESP – SHA­1, 3DES
trafic sortant)
IPSec – Require Encryption Mode (Ignore Inbound, Disallow  ESP – SHA­1, 3DES
Outbound) (Mode de chiffrement requis ­ Ignorer le trafic entrant, 
Ne pas autoriser le trafic sortant)

La Woodgrove Bank utilise IPSec ESP au lieu du protocole AH en raison de la présence de 
périphériques réseau utilisant la traduction d'adresses réseau (NAT) dans l'organisation.

La Woodgrove Bank exige également le chiffrement de certains serveurs de l'organisation. Par 
conséquent, toutes les stratégies nécessitent la possibilité de recourir au chiffrement. C'est pourquoi 
la Woodgrove Bank a choisi de développer sa sécurité uniquement sur la base du protocole IPSec 
ESP.

Pour l'intégrité ESP, Woodgrove Bank a opté pour l'algorithme SHA­1 (au lieu de MD5) parce qu'il 
offre une meilleure sécurité mais aussi parce qu'elle doit respecter les réglementations du 
gouvernement américain relatives au traitement de données financières, impliquant l'usage 
d'algorithmes approuvés. 

La Woodgrove Bank a décidé de ne pas implémenter le service PFS (Perfect Forward Secrecy) dans 
toutes les actions de filtrage car aucune menace de sécurité spécifique n'exigeait l'utilisation de ce 
service. Woodgrove cherche également à éviter l'impact de la renégociation des clés sur les 
performances des ordinateurs.

Action de filtrage du domaine d'isolation

Pour implémenter le domaine d'isolation, les administrateurs de la Woodgrove Bank ont créé l'action 
de filtrage « IPSEC – Secure Request Mode (Ignore Inbound, Allow Outbound) ».

Pour diverses raisons commerciales, les hôtes du domaine d'isolation et d'autres groupes d'isolation 
doivent pouvoir communiquer entre eux. Les clients du domaine d'isolation doivent donc effectuer les 
actions suivantes décrites dans les tableaux 4.5 et 4.6 du chapitre 4 du présent guide :

• Établir des communications avec les hôtes du groupe d'isolation sans basculement.
• Accepter les communications provenant des hôtes du groupe d'isolation sans basculement.
• Établir des communications avec les hôtes du groupe d'isolation de chiffrement.
• Accepter des communications avec les hôtes du groupe d'isolation de chiffrement.
• Établir des communications avec les hôtes du groupe d'isolation de limite.
• Accepter les communications provenant des hôtes du groupe d'isolation de limite.
• Établir une communication avec des systèmes non approuvés

Les clients du domaine d'isolation ne peuvent pas accepter des communications provenant de 
systèmes non approuvés.

Souvenez­vous que la stratégie IPSec utilise des filtres et des actions de filtrage pour intercepter et 
contrôler les paquets IP entrants et sortants. Bien qu'IKE authentifie les deux ordinateurs, 
l'appartenance à un groupe d'un ordinateur utilisant une adresse IP donnée n'est pas connue au 
moment de l'envoi de la demande initiale de connexion. Par conséquent, IPSec et IKE ne peuvent pas 
être spécifiquement configurés pour établir des communications d'une manière précise avec une 
identité ou un groupe d'isolation particulier. De même, les ordinateurs membres de ces groupes 

116
d'isolation peuvent résider n'importe où sur le réseau interne. Vous ne pouvez donc pas utiliser des 
adresses IP pour définir de manière précise ou approximative les groupes d'isolation.

Pour implémenter ces exigences dans une stratégie IPSec, vous devez créer l'action de filtrage qui 
fonctionnera avec la liste de filtres spécifiant tous les sous­réseaux internes. Vous pouvez regrouper 
les exigences décrites ci­dessus en deux comportements de base :

• Sortant, pour les paquets adaptés aux filtres correspondants (tous les sous­réseaux internes) ; 
déclencher des demandes de négociation IKE pour tenter de sécuriser le trafic avec IPSec ESP, 
utiliser de préférence ESP­Null et inclure ESP–SHA­1–3DES. Autoriser la communication en texte 
clair si un hôte de destination cible ne répond pas avec IKE.

• Entrant, pour les paquets adaptés aux filtres correspondants (tous les sous­réseaux internes) ; 
ignorer le trafic s'il n'est pas déjà sécurisé dans des paquets IPSec ESP valides.

Pour activer des communications avec le groupe d'isolation de chiffrement, les méthodes de sécurité 
incluent les méthodes de sécurité (algorithmes ESP–SHA­1–3DES) définies pour ce groupe. Pour 
plus d'informations sur les méthodes de négociation de sécurité par chiffrement, reportez­vous à la 
section « Action de filtrage du groupe d'isolation de chiffrement » plus loin dans ce chapitre.

Pour le trafic au sein du domaine d'isolation et avec les groupes d'isolation de limite et sans 
basculement, la Woodgrove Bank utilise ESP­Null avec l'algorithme SHA­1.

Vous devez désactiver la case à cocher Accepter les communications non sécurisées mais 
toujours répondre en utilisant IPSecdans l'action de filtrage afin que les communications entrantes 
en texte clair soit ignorées. Cette approche garantit que les hôtes du domaine d'isolation n'accepteront 
pas le trafic d'un ordinateur qui ne participe pas à l'environnement IPSec.

L'action de filtrage IPSEC – Secure Request Security (Ignore Inbound, Allow Outbound) est 
configurée afin de permettre aux membres du domaine d'isolation d'établir des communications avec 
des systèmes non approuvés. Vous pouvez opter pour ce comportement en activant la case à cocher 
Autoriser une communication non sécurisée avec des ordinateurs n'utilisant pas IPSec dans 
l'action de filtrage. Si un hôte approuvé du domaine d'isolation établit une connexion sortante avec un 
hôte non approuvé (ou un autre système n'utilisant pas IPSec), l'association de sécurité logicielle 
IPSec est établie et demeure active pendant cinq minutes après l'arrêt du trafic. Pendant ce laps de 
temps, le système non approuvé est donc capable d'établir de nouvelles connexions en texte clair 
dans l'hôte approuvé. Une fois le délai de l'association de sécurité logicielle expiré, l'hôte approuvé ne 
pourra plus accepter aucun trafic en texte clair provenant de ce système. La prise en charge du 
filtrage IPSec et des associations de sécurité logicielles n'a pas été conçue en vue de fournir des 
mesures de protection spécifiques aux connexions (par exemple, le filtrage avec état), comme c'est le 
cas avec un grand nombre de pare­feu. Les associations de sécurité logicielles autorisent tout le trafic 
correspondant au filtre associé. Pour plus d'informations sur ce processus, reportez­vous à la section 
« SA de mode principal IKE et SA  IPSec» de l'annexe A (« Présentation des concepts relatifs à la 
stratégie IPSec »).

Action de filtrage du groupe d'isolation de limite

Pour implémenter le groupe d'isolation de limite, les administrateurs de la Woodgrove Bank ont créé 
l'action de filtrage IPSEC – Request Mode (Accept Inbound, Allow Outbound).

Pour diverses raisons commerciales, les hôtes du groupe d'isolation de limite et d'autres groupes 
d'isolation doivent pouvoir communiquer entre eux. Les clients du groupe d'isolation de limite doivent 
donc effectuer les actions suivantes décrites dans les tableaux 4.5 et 4.6 du chapitre 4 :

• Établir des communications avec les hôtes du groupe d'isolation sans basculement.

117
• Accepter les communications provenant des hôtes du groupe d'isolation sans basculement.
• Établir des communications avec les hôtes du domaine d'isolation.
• Accepter les communications provenant des hôtes du domaine d'isolation.
• Accepter des communications avec les hôtes du groupe d'isolation de chiffrement.
• Établir des communications avec des systèmes non approuvés.
• Accepter des communications provenant de systèmes non approuvés.

Pour implémenter ces exigences dans une stratégie IPSec, vous devez créer l'action de filtrage qui 
fonctionnera avec la liste de filtres spécifiant tous les sous­réseaux internes. Vous pouvez regrouper 
les exigences décrites en deux comportements de base :

• Sortant, pour les paquets adaptés aux filtres correspondants (tous les sous­réseaux internes) ; 
déclencher des demandes de négociation IKE pour tenter de sécuriser le trafic avec IPSec ESP, 
utiliser de préférence ESP­Null et inclure ESP–SHA­1–3DES. Autoriser la communication en texte 
clair si un hôte de destination cible ne répond pas avec IKE.

• Entrant, accepter les paquets en texte clair adaptés aux filtres correspondants (tous les sous­
réseaux internes).

Pour répondre aux exigences d'établissement et d'acceptation du trafic vers et depuis le domaine 
d'isolation et le groupe d'isolation sans basculement, la Woodgrove Bank s'est assurée que les 
méthodes de négociation de sécurité pour le domaine d'isolation et le groupe d'isolation sans 
basculement étaient présentes dans l'action de filtrage. La méthode de négociation de sécurité 
commune retenue par la Woodgrove Bank est ESP avec l'algorithme SHA­1 pour la vérification de 
l'intégrité.

Les hôtes du groupe d'isolation de limite sont autorisés à communiquer avec des systèmes non 
approuvés. Pour faciliter cette fonction, l'équipe administrative de la Woodgrove Bank a activé à la fois 
les cases à cocher Autoriser une communication non sécurisée avec des ordinateurs n'utilisant 
pas IPSec et Accepter les communications non sécurisées mais toujours répondre en utilisant 
IPSec pour cette action de filtrage. En activant ces deux options, la Woodgrove Bank a la garantie 
que les hôtes accepteront le trafic entrant non sécurisé et pourront communiquer en texte clair pour le 
trafic sortant non sécurisé.

Action de filtrage du groupe d'isolation sans basculement

Pour l'implémentation du groupe d'isolation sans basculement, les administrateurs de la Woodgrove 
Bank ont créé l'action de filtrage IPSEC – Full Require Mode (Ignore Inbound, Disallow Outbound).

Pour diverses raisons commerciales, les hôtes du groupe d'isolation sans basculement et d'autres 
groupes d'isolation doivent pouvoir communiquer entre eux. Les clients du groupe d'isolation sans 
basculement peuvent donc effectuer les actions suivantes :

• Établir des communications avec les hôtes du domaine d'isolation.
• Accepter les communications provenant des hôtes du domaine d'isolation.
• Établir des communications avec les hôtes du groupe d'isolation de chiffrement.
• Accepter des communications avec les hôtes du groupe d'isolation de chiffrement.
• Établir des communications avec les hôtes du groupe d'isolation de limite.

118
• Accepter les communications provenant des hôtes du groupe d'isolation de limite.

Les clients du groupe d'isolation sans basculement ne peuvent ni établir, ni accepter des 
communications provenant de systèmes non approuvés.

Pour implémenter ces exigences dans une stratégie IPSec, vous devez créer l'action de filtrage qui 
fonctionnera avec la liste de filtres spécifiant tous les sous­réseaux internes. Vous pouvez regrouper 
les exigences décrites en deux comportements de base :

• Sortant, pour les paquets adaptés aux filtres correspondants (tous les sous­réseaux internes) ; 
déclencher des demandes de négociation IKE pour tenter de sécuriser le trafic avec IPSec ESP, 
utiliser de préférence ESP­Null et inclure ESP–SHA­1–3DES. Ne pas autoriser la communication 
en texte clair si un hôte de destination cible ne répond pas avec IKE.

• Entrant, pour les paquets en texte clair adaptés aux filtres correspondants (tous les sous­réseaux 
internes) ; les ignorer.

Pour activer des communications avec le groupe d'isolation de chiffrement, les méthodes de 
négociation de sécurité incluent les méthodes de négociation de chiffrement (algorithmes ESP–SHA­
1–3DES) définies pour ce groupe. Pour plus d'informations sur les méthodes de négociation de 
sécurité par chiffrement, reportez­vous à la section « Action de filtrage du groupe d'isolation de 
chiffrement » plus loin dans ce chapitre.

Pour le trafic vers les groupes d'isolation de limite et sans basculement, la Woodgrove Bank utilise 
ESP avec l'algorithme SHA­1 comme méthode de négociation de sécurité pour vérifier l'intégrité.

La case à cocher Accepter les communications non sécurisées mais toujours répondre en 
utilisant IPSec dans l'action de filtrage est désactivée pour créer le groupe d'isolation sans 
basculement. Cette approche garantit que les hôtes du groupe d'isolation sans basculement 
sécurisent tout le trafic entrant et sortant avec IPSec. Tout trafic provenant d'un ordinateur qui ne 
participe pas à l'environnement IPSec est ainsi refusé.

L'action de filtrage IPSEC – Full Require Mode (Ignore Inbound, Disallow Outbound) ne permet pas à 
un ordinateur qui utilise cette action d'établir une communication avec un ordinateur qui ne participe 
pas à l'infrastructure IPSec. La case à cocher Autoriser une communication non sécurisée avec 
des ordinateurs n'utilisant pas IPSec a été désactivée pour appliquer cette exigence.

Action de filtrage du groupe d'isolation de chiffrement

La Woodgrove Bank a choisi ESP en tant que protocole d'intégrité de base et l'algorithme SHA­1 en 
tant qu'option cryptographique. De plus, les hôtes du groupe d'isolation de chiffrement ont besoin de 
communiquer avec ceux du domaine d'isolation et du groupe d'isolation sans basculement. L'action de 
filtrage a été configurée afin d'inclure les méthodes de négociation de sécurité chargées de chiffrer les 
informations.

Pour diverses raisons commerciales, les hôtes du groupe d'isolation de chiffrement et d'autres 
groupes d'isolation doivent pouvoir communiquer entre eux. Les clients du groupe d'isolation de 
chiffrement peuvent donc effectuer les actions suivantes du tableau 4.6 :

• Établir des communications avec les hôtes du domaine d'isolation.
• Accepter les communications provenant des hôtes du domaine d'isolation.
• Établir des communications avec les hôtes du groupe d'isolation sans basculement.

119
• Accepter les communications provenant des hôtes du groupe d'isolation sans basculement.
• Établir des communications avec les hôtes du groupe d'isolation de limite.

Les ordinateurs du groupe d'isolation de chiffrement ne sont pas autorisés à accepter des 
communications en provenance d'hôtes du groupe d'isolation de limite.

Pour implémenter ces exigences dans une stratégie IPSec, vous devez créer l'action de filtrage qui 
fonctionnera avec la liste de filtres spécifiant tous les sous­réseaux internes. Vous pouvez regrouper 
les exigences décrites en deux comportements de base :

• Sortant, pour les paquets adaptés aux filtres correspondants (tous les sous­réseaux internes) ; 
déclencher des demandes de négociation IKE pour tenter de sécuriser le trafic avec ESP–SHA­1–
3DES uniquement. Ne pas autoriser la communication en texte clair si un hôte de destination cible 
ne répond pas avec IKE.

• Entrant, pour les paquets en texte clair adaptés aux filtres correspondants (tous les sous­réseaux 
internes) ; les ignorer. Accepter uniquement les demandes de négociation IKE issues d'hôtes 
approuvés autorisant IPSec ESP–SHA­1–3DES.

Les clients du groupe d'isolation de chiffrement ne peuvent pas accepter de communications en 
provenance du groupe d'isolation de limite, ni accepter ou établir de communications issues de 
systèmes non approuvés.

Pour permettre les communications avec le domaine d'isolation, les méthodes de négociation de 
sécurité de chiffrement adoptées pour l'action de chiffrement IPSEC – Require Encryption Mode 
(Ignore Inbound, Disallow Outbound) sont également disponibles dans les actions de filtrage IPSEC – 
Secure Request (Ignore Inbound, Allow Outbound) et IPSEC – Full Require Mode (Ignore Inbound, 
Disallow Outbound). Woodgrove Bank utilise la méthode de chiffrement 3DES qui offre une meilleure 
sécurité que la méthode DES, mais représente une charge plus élevée.

Pour répondre à la nécessité de ne pas accepter ou établir de communications avec des systèmes 
non approuvés, la Woodgrove Bank n'a pas activé la case à cocher Accepter les communications 
non sécurisées mais toujours répondre en utilisant IPSec. Cette configuration garantit que les 
hôtes du groupe d'isolation de chiffrement n'accepteront pas le trafic d'un ordinateur qui ne participe 
pas à l'environnement IPSec. De plus, l'option Autoriser une communication non sécurisée avec 
des ordinateurs n'utilisant pas IPSec a elle aussi été désactivée pour empêcher des ordinateurs de 
chercher à établir des communications avec un autre ordinateur ne participant pas à 
l'environnement IPSec.

Le blocage des communications IPSec à partir des ordinateurs du groupe d'isolation de limite 
impliquait d'autres tâches de configuration. Les administrateurs de la Woodgrove Bank ont attribué le 
droit « Refuser l'accès à cet ordinateur à partir du réseau » à l'objet Stratégie de groupe chargé de 
fournir la stratégie IPSec aux ordinateurs du groupe d'isolation de chiffrement. Ce droit a été appliqué 
à un groupe comprenant tous les comptes d'ordinateurs des systèmes participant au groupe 
d'isolation de limite. Si l'un de ces ordinateurs tentait d'établir des communications avec un système 
du groupe d'isolation de chiffrement, l'authentification IKE aboutirait à un refus d'autorisation et la 
communication serait bloquée.

Stratégies IPSec 

Les stratégies IPSec permettent de configurer des ordinateurs Windows pour qu'ils fonctionnent dans 
un environnement IPSec. Une stratégie IPSec désigne un ensemble de règles appliquées au trafic. Il 
existe trois types de stratégies IPSec pour Windows 2000 :

120
• Stratégie locale
• Stratégie de domaine Active Directory
• Stratégie dynamique

Windows XP et Windows Server 2003 prennent en charge les types de stratégies supplémentaires 
suivants :

• Stratégie IPSec de démarrage. Stockée et gérée dans le Registre local. Prise en charge 
uniquement sous Windows XP SP2 ou ultérieur. Elle est appliquée dès que l'ordinateur obtient une 
adresse IP, ce qui peut survenir avant le démarrage du service IPSec. Elle est remplacée lorsque 
le service applique une stratégie persistante.

• Stratégie IPSec persistante. Stockée et gérée dans le Registre de l'ordinateur local. Configurée à 
l'aide de l'outil de ligne de commande. Elle est appliquée en premier au démarrage du service 
IPSec. Elle remplace la stratégie de démarrage.

• Stratégie IPSec locale. Stockée et gérée dans l'ordinateur local. Configurée à l'aide du composant 
logiciel enfichable MMC (Microsoft Management Console) Gestion de stratégie IPSec ou de l'outil 
de ligne de commande. Elle est appliquée en plus de la stratégie persistante si aucune stratégie de 
domaine n'est définie.

• Stratégie IPSec de domaine Active Directory. Stockée dans Active Directory. Gérée par le 
composant logiciel enfichable MMC Gestion de stratégie IPSec ou l'outil de ligne de commande. 
Elle remplace toutes les stratégies locales susceptibles d'être attribuées. Les stratégies IPSec 
Active Directory sont affectées à un objet Stratégie de groupe par l'intermédiaire du composant 
logiciel enfichable MMC Éditeur de stratégies de groupe ou la console de gestion des stratégies de 
groupe (GPMC) disponible sous Paramètres Windows, Paramètres de sécurité et Stratégies 
IPSec.

• Stratégie IPSec dynamique. Stockée uniquement en mémoire. Configurée à l'aide de l'outil de 
ligne de commande. Elle permet d'ajouter de manière dynamique des éléments à la stratégie 
existante. La stratégie dynamique est ignorée dès l'arrêt du service IPSec.

Pour des raisons de simplicité, le présent guide s'intéresse uniquement à l'utilisation de la stratégie 
IPSec dans le domaine Active Directory.

Lorsque vous définissez des stratégies IPSec, il est préférable d'essayer de créer une stratégie 
générique qui sera la base de l'infrastructure IPSec pour tous les ordinateurs. Vous pouvez ensuite 
créer des stratégies supplémentaires pour appliquer des paramètres plus stricts aux systèmes 
exigeant une configuration de sécurité supplémentaire. Chaque stratégie supplémentaire doit cibler le 
plus grand nombre possible d'ordinateurs devant répondre à des exigences commerciales ou 
techniques particulières. En limitant le nombre total des stratégies, vous faciliterez la gestion des 
stratégies et la résolution des problèmes qui en découlent.

Les stratégies IPSec sont composées d'un nom, d'une description, d'un ensemble de règles, de 
paramètres de configuration pour les fréquences d'interrogation, ainsi que de paramètres et de 
méthodes d'échange de clés. La section qui suit aborde tous ces éléments en détail.

Nom

Tout comme pour les actions de filtrage, vous devez attribuer des noms significatifs aux stratégies afin 
de faciliter la gestion et la résolution des problèmes liés à la solution pendant les phases 
d'implémentation et d'exploitation du projet.

121
Description

Une description détaillée de la stratégie permettra aux administrateurs d'identifier l'objectif de la 
stratégie sans avoir à l'ouvrir et étudier les règles qui la définissent.

Règles

Une règle IPSec se compose d'une liste de filtres unique, d'une action de filtrage associée, des 
méthodes d'authentification employées pour établir le niveau d'approbation entre les ordinateurs, d'un 
type de connexion et du type de tunnel (le cas échéant).

Chaque règle définit une ou plusieurs méthodes d'authentification à utiliser pour établir le niveau 
d'approbation entre les hôtes. Les options proposées sont le protocole Kerberos version 5, des 
certificats provenant d'une autorité de certification précise et des clés pré­partagées.

Le type de connexion définit les connexions auxquelles la stratégie IPSec s'applique. Vous pouvez 
configurer la stratégie pour l'appliquer à l'ensemble des connexions, à des connexions au réseau local 
ou à des connexions d'accès à distance.

Le type de tunnel détermine si la stratégie IPSec définit un tunnel IPSec. Si le type de tunnel est 
désactivé, IPSec utilise le mode de transport.

Pour prendre en charge les groupes d'isolation de sécurité identifiés plus haut dans ce guide, la 
Woodgrove Bank a mis en place quatre stratégies IPSec. Elle a les toutes configurées afin qu'elles 
utilisent le protocole d'authentification Kerberos  version 5, soient appliquées à l'ensemble des 
connexions et ne définissent pas un tunnel IPSec.

Le tableau ci­dessous décrit les stratégies adoptées dans le scénario de la Woodgrove Bank :

Tableau 5.6 : Stratégies IPSec de la Woodgrove Bank

Nom de stratégie Description
IPSEC – Isolation Domain  Cette stratégie définit le domaine d'isolation. Les hôtes de ce groupe 
IPSec Policy  d'isolation ont la capacité de communiquer en texte clair lorsqu'ils 
(1.0.041001.1600) (Stratégie  établissent des communications avec des hôtes non­IPSec. Elle 
IPSec de domaine  configure les hôtes pour qu'ils exigent une communication IPSec. Si 
d'isolation) la négociation échoue entre les clients utilisant IPSec, la 
communication échoue elle aussi.

IPSEC – Boundary Isolation  Cette stratégie définit le groupe d'isolation de limite. Elle configure les 
Group IPSec Policy  hôtes pour qu'ils demandent des communications IPSec mais leur 
(1.0.041001.1600) (Stratégie  permet de communiq uer en t exte cla ir si le s commun ications 
IPSec de groupe d'isolation  doivent être établies avec un hôte n'utilisant pas IPSec.
de limite)

IPSEC – No Fallback  Cette stratégie définit le groupe d'isolation sans basculement. Elle 
Isolation Group IPSec Policy  configure les hôtes pour qu'ils exigent une communication IPSec. Si 
(1.0.041001.1600) (Stratégie  la négociation échoue ou en cas de tentative de communication avec 
IPSec de groupe d'isolation  un client qui n'utilise pas IPSec, la communication échoue.
sans basculement)

IPSEC – Encryption Isolation  Cette stratégie définit le groupe d'isolation de chiffrement. Elle 
Group IPSec Policy  configure les hôtes pour qu'ils exigent une communication et un 
(1.0.041001.1600) (Stratégie  chiffrement IPSec. Si la négociation échoue ou en cas de tentative de 
IPSec de groupe d'isolation  communication avec un client qui n'utilise pas IPSec, la 

122
de chiffrement) communication échoue.

Le nombre associé à chaque nom de stratégie correspond à un numéro de version, comme expliqué 
plus loin dans la section « Versions des stratégies ».

Chacune des stratégies de la Woodgrove Bank renferme les mêmes listes d'exemptions puisqu'il 
n'existe aucune exigence d'exemption d'un ensemble spécial d'ordinateurs pour un groupe d'isolation 
particulier. Le tableau ci­après présente les règles activées et communes aux quatre stratégies 
identifiées dans le tableau précédent :

Tableau 5.7 : Règles communes définies dans les stratégies IPSec de la Woodgrove Bank

Liste de filtres Action de  Méthodes  Point de  Type de 

filtrage d'authentification sortie du  connexion
tunnel
DNS Exemption List (Liste  IPSEC –  Aucun Aucun Tous
d'exemptions DNS) Permit 
(Autoriser)

Domain Controllers Exemption  IPSEC –  Aucun Aucun Tous

List (Liste d'exemptions de  Permit 
contrôleurs de domaine) (Autoriser)

Liste d'exemptions WINS  IPSEC –  Aucun Aucun Tous

(WINS Exemptions List) Permit 
(Autoriser)

DHCP, Negotiation Traffic  IPSEC –  Aucun Aucun Tous

(DHCP, trafic de négociation) Permit 
(Autoriser)

ICMP, All Traffic (ICMP, tout le  IPSEC –  Aucun Aucun Tous

trafic) Permit 
(Autoriser)

En plus des règles énumérées dans ce tableau, la règle de réponse client par défaut est désactivée 
dans chaque stratégie.

Les quatre stratégies définies par la Woodgrove Bank diffèrent uniquement dans leur manière de 
gérer le trafic qui n'est traité par aucune des listes de filtres d'exemption. Pour chacune de ces règles, 
la méthode d'authentification employée est le protocole Kerberos version 5, le point de sortie du tunnel 
est défini à None (Aucun) et le type de connexion est All (Toutes).

Le tableau ci­après affiche les règles d'implémentation des quatre groupes d'isolation de la 
Woodgrove Bank :

Table 5.8: Règles d'implémentation de base des groupes d'isolation de la Woodgrove Bank

Nom de stratégie Liste de filtres Action de filtrage

IPSEC – Isolation Domain IPSec Policy  Sous­réseaux  IPSec – Secure Request Mode (Ignore 
(1.0.041001.1600) (Stratégie IPSec de  sécurisés de  Inbound, Allow Outbound) (Mode de 
domaine d'isolation) Woodgrove Bank requête sécurisée ­ Ignorer le trafic 
entrant, Autoriser le trafic sortant)

123
IPSEC – Boundary Isolation Group  Sous­réseaux  IPSec – Request Mode (Accept 
IPSec Policy (1.0.041001.1600)  sécurisés de  Inbound, Allow Outbound) (Mode de 
(Stratégie IPSec de groupe d'isolation  Woodgrove Bank requête ­ Accepter le trafic entrant, 
de limite) Autoriser le trafic sortant)

IPSEC – No Fallback Isolation Group  Sous­réseaux  IPSec – Full Require Mode (Ignore 

IPSec Policy (1.0.041001.1600)  sécurisés de  Inbound, Disallow Outbound) (Mode 
(Stratégie IPSec de groupe d'isolation  Woodgrove Bank requis complet ­ Ignorer le trafic 
sans basculement) entrant, Ne pas autoriser le trafic 
sortant)

IPSEC – Encryption Isolation Group  Sous­réseaux  IPSec – Require Encryption Mode 

IPSec Policy (1.0.041001.1600)  sécurisés de  (Ignore Inbound, Disallow Outbound) 
(Stratégie IPSec de groupe d'isolation  Woodgrove Bank (Mode de chiffrement requis ­ Ignorer le 
de chiffrement) trafic entrant, Ne pas autoriser le trafic 
sortant)

La Woodgrove Bank a choisi d'utiliser le protocole Kerberos version 5 comme unique protocole 
d'authentification. Elle n'utilise pas de clés pré­partagées puisque la valeur de clé d'authentification 
peut être lue par des administrateurs locaux du Registre et par n'importe quels utilisateur authentifié et 
ordinateur sur le domaine. Elle n'a pas choisi non plus de certificats puisqu'elle ne dispose pas d'une 
infrastructure de clés publiques (PKI) déployée.

Grâce au protocole Kerberos version 5, tous les ordinateurs associés à des domaines peuvent 
participer à l'infrastructure IPSec puisqu'ils peuvent authentifier et se procurer une stratégie. Les 
ordinateurs qui ne sont pas associés à des domaines ne peuvent pas facilement participer à 
l'environnement IPSec en raison de l'absence d'un mécanisme d'authentification et d'un système de 
distribution des stratégies. Si ces ordinateurs répondent aux critères des hôtes approuvés, vous 
pouvez configurer une stratégie IPSec locale à l'aide de l'authentification de certificats pour leur 
permettre de communiquer avec d'autres hôtes approuvés. Pour l'heure, la Woodgrove Bank traite les 
ordinateurs n'appartenant pas à des domaines en tant qu'ordinateurs non approuvés.

Remarque : l'utilisation du protocole Kerberos version 5 pour l'authentification IKE n'empêche pas les 
ordinateurs qui n'appartiennent pas à des domaines de participer à l'environnement IPSec. Par 
exemple, si un système UNIX est correctement configuré pour l'utilisation d'Active Directory comme 
domaine Kerberos et si la structure IKE mise en place prend en charge l'authentification Kerberos, il 
peut alors participer au domaine d'isolation. Néanmoins, une configuration de ce type va au­delà de la 
portée du présent document et n'a pas été testée par Microsoft.

Fréquences d'interrogation

Deux fréquences d'interrogation sont à prendre en compte : la fréquence d'interrogation de la stratégie 
de groupe et celle du service IPSec. Le paramètre par défaut de fréquence d'interrogation de 
modification de stratégie du service IPSec est de 180 minutes entre deux interrogations consécutives 
pour les changements des stratégies IPSec Active Directory. Ces interrogations vérifient uniquement 
les modifications apportées à la stratégie IPSec ; elles ne détectent pas les changements 
d'appartenance à un domaine ou une unité d'organisation ou bien l'affectation ou la suppression d'une 
stratégie IPSec dans un objet Stratégie de groupe. La détection des modifications d'appartenance à 
l'unité d'organisation d'un ordinateur et de l'affectation d'objets Stratégie de groupe s'effectue par 
interrogation du service Stratégie de groupe toutes les 90 minutes par défaut.

La Woodgrove Bank a choisi de définir ces deux fréquences d'interrogation à 60 minutes afin que, si 
la nécessité d'une réponse de sécurité se présente, les stratégies puissent être mises à jour et 
déployées en une heure pour minimiser les risques. Cette fréquence d'interrogation accrue ajoute un 
trafic d'interrogation supplémentaire sous la forme de requêtes LDAP soumises par le client pour 

124
vérifier les valeurs d'horodatage dans les stratégies IPSec. Même si cette augmentation ne se traduit 
pas par une charge significative dans le scénario de la Woodgrove Bank, elle peut être considérable 
dans des déploiements impliquant un grand nombre de clients.

Paramètres d'échange de clés

Les paramètres d'échange de clés suivants définissent le mode d'obtention des nouvelles clés et leur 
fréquence de renouvellement. Le terme « clé principale » désigne la clé secrète partagée Diffie­
Hellman générée en mode principal IKE. Le terme « clé de session » se rapporte aux clés générées 
en mode rapide IKE en vue d'être utilisées dans les algorithmes de chiffrement et d'intégrité IPSec. 
Les clés de session sont dérivées de la clé principale.

• PFS (Perfect Forward Secrecy). Il existe deux types de composants PFS dans IKE : la clé 
principale PFS (soit le mode principal PFS) et la clé de session PFS (mode rapide PFS). Le mode 
principal PFS n'est pas conseillé car les fonctionnalités sont dupliquées par d'autres paramètres 
d'échange de clés pris en charge. Le mode principal PFS exige qu'IKE ré­authentifie et négocie 
une nouvelle clé principale chaque fois qu'un mode rapide est exécuté pour actualiser les clés de 
session. Cette condition garantit à chaque fois qu'une clé de chiffrement doit être actualisée, les 
deux ordinateurs repartent de zéro avec une nouvelle négociation en mode rapide et en mode 
principal IKE. Cette protection supplémentaire implique une charge supplémentaire. La clé de 
session PFS génère une nouvelle clé principale en mode rapide (sans authentification en mode 
principal), puis extrait les nouvelles clés de session à partir de la nouvelle clé principale. Cette 
fonctionnalité garantit qu'un grand nombre de données (voire la totalité des données) de la 
communication ne sont pas uniquement protégées par une seule valeur de clé principale et qu'une 
quantité infime de données chiffrées serait dévoilée si un attaquant parvenait à découvrir la clé 
principale. La clé de session PFS est disponible sous la forme d'une case à cocher dans les 
méthodes de sécurité d'une action de filtrage. Utilisez­la uniquement là où le trafic protégé IPSec 
est exposé à des risques d'attaques cryptographiques complexes dans la clé principale Diffie­
Hellman.

• Authentifier et générer une nouvelle clé toutes les <nombre> minutes. Cette valeur définit la 
durée de vie de l'association de sécurité en mode principal IKE (fixée à 480 minutes par défaut). 
Elle contrôle la durée d'utilisation de la clé principale et de la relation d'approbation avant leur 
renégociation. La première connexion TCP/IP entre un client unique et l'hôte entraîne la création 
d'une nouvelle association de sécurité en mode principal IKE. Contrairement aux associations de 
sécurité logicielles, les associations de sécurité en mode principal ne sont pas supprimées de 
l'hôte après cinq minutes d'inactivité. Les associations de sécurité en mode principal exigent 
environ 5 kilo­octets de mémoire chacune. En ajustant cette valeur, l'administrateur peut optimiser 
la charge processeur et la capacité mémoire requises par IKE. En réduisant la durée de vie, vous 
réduisez le nombre d'associations de sécurité en mode principal actives sur le serveur. Cela 
permet d'économiser de la mémoire et du temps de traitement IKE, en maintenant moins 
d'associations de sécurité. Néanmoins, vous pouvez augmenter la charge processeur requise pour 
renégocier les associations de sécurité en mode principal pour les clients qui communiquent 
fréquemment.

• Authentifier et générer une nouvelle clé toutes les <nombre> sessions. Ce paramètre contrôle 
le nombre maximal d'opérations en mode rapide IKE autorisées pendant la durée de vie d'une 
association de sécurité en mode principal, limitant ainsi le nombre de clés de session qu'il est 
possible de générer à partir de la même clé principale. Une fois cette limite atteinte, une nouvelle 
association de sécurité en mode principal IKE est négociée pour la création d'une nouvelle clé 
principale. Le paramètre par défaut est 0, ce qui signifie l'absence de limite. La clé principale est 
donc uniquement actualisée lorsque la durée de vie de l'association de sécurité en mode principal 
IKE arrive à expiration, à moins que vous n'utilisiez le mode rapide PFS. Pour obtenir le même 
comportement que le paramètre de la clé principale PFS, cette option est définie à 1.

125
La Woodgrove Bank a choisi de ne pas recourir à la clé principale PFS puisque aucune exigence de 
sécurité spécifique ne le justifie. De même, le service PFS en mode rapide IKE n'a pas été utilisé dans 
les actions de filtrage. La durée de vie des associations de sécurité en mode principal IKE est passée 
de 480 minutes à 180 minutes pour supprimer plus rapidement les associations de sécurité en mode 
principal sur les serveurs occupés dans tous les groupes d'isolation, à l'exception du groupe 
d'isolation de limite. Pour ce dernier, les administrateurs de la Woodgrove Bank ont réduit la durée de 
vie des associations de sécurité en mode principal IKE à 20 minutes pour diminuer la surface 
d'attaque exposée par les associations de sécurité en mode principal résidentes qui ont été négociées 
avec le groupe d'isolation de chiffrement. Bien que les hôtes du groupe d'isolation de limite ne 
puissent pas entamer de nouvelles négociations IKE avec les hôtes du groupe d'isolation de 
chiffrement, l'inverse peut se produire. Une fois l'association de sécurité en mode principal établie, un 
hôte du groupe d'isolation de limite peut l'utiliser pour négocier des associations de sécurité en mode 
rapide pour la protection du trafic entrant sur le système correspondant dans le groupe d'isolation de 
chiffrement jusqu'à ce que l'association de sécurité en mode principal soit supprimée. Vous pouvez 
minimiser les risques en forçant la suppression à intervalles plus réguliers des associations de 
sécurité en mode principal sur les serveurs du groupe de limite. Le nombre de sessions pour 
lesquelles vous pouvez utiliser la clé principale pour la création d'une clé de session est resté à 0 
(paramètre par défaut).

Méthodes d'échange de clés

Les méthodes d'échange de clés permettent de contrôler les méthodes de sécurité employées lors de 
la négociation IKE en mode principal. Les options de configuration concernent l'intégrité (SHA­1 et 
MD5), la confidentialité ou le chiffrement (3DES et DES) et la longueur des nombres premiers de base 
adoptés lors du processus d'échange de clés.

Remarque : pour utiliser 3DES, les ordinateurs équipés de Windows 2000 doivent disposer du pack 
de chiffrement élevé ou de SP2 (ou ultérieur).

La puissance de chiffrement des clés utilisées pour l'intégrité et le chiffrement de la négociation IKE 
elle­même et la protection des données IPSec dépend de la puissance du groupe Diffie­Hellman sur 
lequel les nombres premiers sont fondés. Trois options sont proposées pour le groupe Diffie­Hellman :

• Haute (3) – puissance de clé 2048 bits. Cette option correspond à la norme IETF RFC 3526 du 
groupe Diffie­Hellman 14. Cette puissance de clé est indispensable pour que 3DES bénéficie d'un 
niveau de chiffrement maximal. Reportez­vous à la norme IETF RFC 3526 pour plus 
d'informations.

• Moyenne (2) – puissance de clé 1024 bits.
• Faible (1) – puissance de clé 768 bits.

La configuration Haute concerne exclusivement les systèmes dotés de Windows XP SP2 et 
Windows Server 2003. La configuration Moyenne offre une interopérabilité avec Windows 2000 et 
Windows XP SP1. La configuration Faible est fournie pour une compatibilité descendante. Du fait de 
sa faiblesse relative, il est préférable d'éviter de l'utiliser.

Le tableau ci­dessous répertorie par ordre de préférence les méthodes de sécurité d'échange de clés 
que la Woodgrove Bank a choisi d'implémenter :

Tableau 5.9 : Méthodes de sécurité d'échange de clés par défaut

Chiffrement Intégrité Groupe Diffie­Hellman

3DES SHA­1 Haute (3) 2048 bits

126
3DES SHA­1 Moyenne (2) 1024 bits

3DES MD5 Moyenne (2) 1024 bits

Remarque : l'utilisation du groupe 2048 bits dans la stratégie IPSec exige que vous configuriez cette 
dernière à l'aide des outils de gestion de Windows Server 2003, notamment le composant logiciel 
enfichable MMC Gestion de stratégie IPSec ou l'utilitaire de ligne de commande Netsh IPSec. Vous 
pouvez affecter cette stratégie au domaine sur les plates­formes Windows 2000, ce qui exclut 
l'utilisation de l'option 2048 bits.

Versions des stratégies

Il est probable que la conception des stratégies IPSec change plusieurs fois au cours de la 
planification initiale, des tests en laboratoire, des déploiements pilote et pendant l'utilisation 
opérationnelle. Si vous utilisez des scripts, des feuilles de calcul ou d'autres documents pour créer 
des stratégies IPSec, vous devez gérer ces fichiers à l'aide d'un système de contrôle des versions 
semblable à Microsoft Visual SourceSafe®.

Il est difficile d'identifier les versions des stratégies IPSec dans Active Directory en examinant les 
attributs de la stratégie. Lors du dépannage, vous devrez être en mesure de déterminer la version de 
la stratégie IPSec active sur l'ordinateur. C'est pourquoi nous vous conseillons de stocker les 
informations sur les versions sous une forme quelconque à la fois dans le nom et dans les règles de la 
stratégie.

Une méthode simple consiste à créer un ID de version fondé sur la formule suivante :

<Major Change>.<Minor Change>.<Date:yymmdd>.<Time:24 Hour>

Par exemple, 1.0.041001.1600 correspond à la version 1.0 créée le 10/01/04 à 16 heures.

Vous devez ensuite placer cet ID de version à la fin du nom créé pour la stratégie. Par exemple, 
IPSEC – Boundary IPSec Policy (1.0.041001.1600). Vous pouvez également l'ajouter au nom ou à la 
description des listes de filtres fréquemment sujettes à modifications.

La stratégie de groupe extrait le nom de la stratégie IPSec et la place dans le Registre local sous 
HKEY_LOCAL_MACHINE \SOFTWARE\Policies\Microsoft\Windows\IPSec\GPTIPSECPolicy où 
elle est stockée sous forme de valeur de chaîne sous la clé DSIPSECPolicyName.

Bien que le processus d'interrogation du service IPSec vérifie les changements intervenus dans tous 
les objets Stratégie affectés, il ne met pas à jour le nom de la stratégie affectée stockée par la 
stratégie de groupe. La stratégie de groupe ne met pas à jour le nom dans le Registre local tant que 
l'objet Stratégie de groupe n'a pas été modifié. L'équipe de recherche informatique de Microsoft a 
établi qu'une règle inutilisée au sein de la stratégie IPSec était un moyen efficace pour stocker les 
informations de version des stratégies. Par exemple, vous pouvez créer une liste de filtres contenant 
des adresses non valides et associée à une action de filtrage Autoriser, comme dans l'exemple 
suivant :

Nom de la liste de filtres : stratégie IPSec ver 1.0.041001.1600

Description de la liste de filtres : stratégie IPSec ver 1.0.041001.1600

1.1.1.1 <­> 1.1.1.2, ICMP, description = "stratégie IPSec ver ID 1.0.041001.1600"

127
Après avoir créé cette liste de filtres dans Active Directory, vous pouvez identifier le nom unique de 
l'objet de version de la liste de filtres à l'aide du composant logiciel enfichable MMC Utilisateurs et 
ordinateurs Active Directory fonctionnant en mode avancé. Vous pouvez rechercher l'objet liste de 
filtres dans l'arborescence <DomainName>\System\IP Security et l'identifier grâce à sa description.

Dès que vous connaissez le nom unique de l'objet de version, vous pouvez le comparer par 
programmation avec les objets IPSec stockés dans le Registre sous HKEY_LOCAL_MACHINE 
\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Cache pour déterminer s'il se trouve dans 
le cache. En recherchant le nom unique de l'objet de version dans le cache, vous pouvez comparer 
les noms des stratégies de l'objet stocké dans Active Directory et de l'objet stocké dans l'ordinateur 
local. Si les noms sont identiques, les stratégies de domaine et les stratégies locales sont 
synchronisées. Les noms et les descriptions de chaque liste de filtres sont également stockés dans le 
cache des stratégies IPSec, ce qui permet d'identifier et de savoir quelles versions de ces objets sont 
actuellement attribuées. Le service IPSec conserve en mémoire le texte descriptif de chaque filtre (et 
non la liste de filtres) afin que le composant logiciel enfichable MMC Moniteur IPSec et les outils de 
ligne de commande puissent accéder à ces informations.

Un script peut permettre d'automatiser la vérification des versions des stratégies, notamment le script 
Detect_IPSec_Policy.vbs fourni à titre d'exemple dans le dossier Tools and Templates (outils et 
modèles) de cette solution.

À mesure que vous modifiez les stratégies sur une période donnée, vous devez mettre à jour les 
noms de filtres correspondants afin qu'ils tiennent compte des modifications apportées.

Procédure d'application des stratégies IPSec à des ordinateurs 
individuels

L'étape finale de l'activation d'IPSec consiste à déployer les stratégies sur les hôtes. Il existe deux 
méthodes de déploiement des stratégies. L'une consiste à appliquer directement les stratégies sur les 
ordinateurs hôtes individuels ; l'autre passe par l'utilisation des objets Stratégie de groupe et 
d'Active Directory. L'application des stratégies via Active Directory est abordée dans la section 
« Application des stratégies IPSec à l'aide d'objets Stratégie de groupe » plus loin dans ce chapitre.

Deux méthodes vous permettent d'appliquer des stratégies IPSec sur des ordinateurs individuels : via 
le composant logiciel enfichable MMC Gestion de la stratégie de sécurité IPSec ou par le biais de la 
ligne de commande en exécutant l'outil Netsh (pour Windows Server 2003), Ipseccmd.exe (pour 
Windows XP) ou Ipsecpol.exe (pour Windows 2000).

Le composant logiciel enfichable MMC fournit une interface utilisateur graphique qui permet à 
l'administrateur d'appliquer manuellement la stratégie ou d'importer une stratégie IPSec définie au 
préalable et exportée depuis un autre ordinateur. Outre la manipulation de la stratégie sur l'ordinateur 
local, le composant logiciel enfichable permet aux administrateurs de gérer une stratégie sur un 
ordinateur distant.

Des informations détaillées sur les outils de ligne de commande sont disponibles à partir des 
ressources suivantes :

• Aide et support Windows Server 2003 pour Netsh
• Documentation des outils de support Windows XP pour Ipseccmd.exe
• Kit de ressources Windows 2000 Server pour Ipsecpol.exe

128
Vous pouvez vous procurer la dernière version du kit de ressources et des outils de support à partir du 
Centre de téléchargement Microsoft à l'adresse www.microsoft.com/downloads/search.aspx?

Microsoft fournit un outil IPSeccmd mis à jour et d'autres outils de support pour Windows XP SP2. 
Reportez­vous à l'article 838079 de la Base de connaissances Microsoft, « Windows
      XP Service Pack  
2 Support Tools   » (Outils de support du Service Pack 2 Windows XP), à l'adresse 
http://support.microsoft.com/?kbid=838079.

Les informations détaillées sur l'utilisation de ces outils dépassent le cadre du présent guide. Les 
exemples donnés dans ce dernier concernent l'utilisation de l'outil Netsh sur des serveurs fonctionnant 
sous Windows Server 2003.

Application des stratégies IPSec à l'aide d'objets Stratégie de groupe

La stratégie de groupe Active Directory sert de mécanisme de distribution et d'attribution des 
stratégies IPSec aux ordinateurs associés à des domaines. Pour répartir les stratégies via les 
mécanismes de distribution de la stratégie de groupe dans Active Directory, vous devez avant toute 
chose configurer les objets Stratégie de groupe qui seront utilisés pour appliquer les stratégies IPSec 
sur les ordinateurs hôtes.

Remarque : bien que la section suivante aborde le chargement des stratégies IPSec directement 
dans Active Directory, vous devez partir du principe que les stratégies ont été créées et testées sur un 
système local, dans un laboratoire de test et dans le cadre de projets pilote à petite échelle avant 
d'être déployées au sein d'un environnement de production.

Procédure de chargement des stratégies IPSec dans Active Directory

La première tâche à effectuer pour l'implémentation des stratégies IPSec via Active Directory est de 
créer les listes de filtres, les actions de filtrage et les stratégies IPSec dans le service d'annuaire. Vous 
pouvez le faire à l'aide du composant logiciel enfichable MMC Gestion de la stratégie de sécurité 
IPSec ou par le biais d'un outil de ligne de commande tel que Netsh. Quel que soit l'outil que vous 
choisissez, vous devez effectuer les trois sous­tâches suivantes pour implémenter les stratégies 
IPSec :

1. Créer les listes de filtres et les filtres identifiés dans la section « Listes de filtres IPSec » de ce 
chapitre.
2. Créer les actions de filtrage identifiées dans la section « Actions de filtrage IPSec » de ce 
chapitre.
3. Créer les stratégies IPSec identifiées dans la section « Stratégies IPSec » de ce chapitre.

Utilisation du composant logiciel enfichable MMC Gestion de la stratégie de sécurité IPSec

Le composant logiciel enfichable MMC Gestion de la stratégie de sécurité IPSec est un outil 
d'interface graphique utilisateur à l'aide duquel les administrateurs peuvent créer, configurer et 
modifier des stratégies IPSec sur des ordinateurs locaux, des ordinateurs distants ou des domaines. 
La configuration des composants IPSec est un processus manuel qui implique de modifier directement 
les objets créés, dirigé par des assistants.

Après avoir défini les stratégies IPSec localement ou dans Active Directory, l'administrateur peut les 
exporter (avec toutes les listes de filtres et les actions de filtrage) dans un fichier dont le nom se 
termine par une extension .ipsec. Vous pouvez copier ce fichier sur un autre support à titre de 
sauvegarde.

129
Si une sauvegarde des stratégies IPSec est déjà disponible, vous pouvez utiliser l'outil pour importer 
les stratégies sauvegardées dans Active Directory. Vous pouvez opter pour cette approche à des fins 
de récupération ou pour déplacer les fichiers de stratégies IPSec d'une forêt de test vers une forêt de 
production sans avoir à recréer chaque liste de filtres, action de filtrage et stratégie manuellement. 
Examinez avec soin la conception des stratégies récupérées à partir des copies de sauvegarde. Il est 
conseillé d'effectuer des tests afin d'évaluer l'impact de l'application des anciens paramètres dans 
l'environnement actuel. Un ancien fichier de sauvegarde peut contenir des paramètres de stratégie 
(notamment des listes de filtres ou des actions de filtrage) non valides et susceptibles de faire échouer 
toute communication s'ils ont été affectés aux membres actuels du domaine.

Pour plus d'informations sur l'utilisation du composant logiciel enfichable MMC Gestion de la stratégie 
de sécurité IPSec, reportez­vous à la rubrique « Définition des stratégies IPSec » du Centre d'aide et 
de support de Windows Server 2003.

Utilisation de l'outil Netsh

Vous pouvez faire appel à l'outil Netsh au lieu du composant logiciel enfichable MMC Gestion de la 
stratégie de sécurité IPSec pour configurer des stratégies IPSec dans un domaine Active Directory 
Windows Server 2003. L'exécution de cet outil de ligne de commande peut avoir lieu en mode 
interactif ou en mode de traitement par lot. Lorsqu'il fonctionne en mode interactif, Netsh exige que 
l'administrateur tape chaque commande dans l'invite de commandes Netsh. Avant créer les listes de 
filtres, les actions de filtrage et les stratégies IPSec, vous devez configurer l'outil pour qu'il pointe sur 
Active Directory. 

Pour que Netsh pointe sur Active Directory, tapez la commande suivante à l'invite Netsh :

ipsec static set store location=domain

L'administrateur peut ensuite entrer les listes de filtres, les filtres, les actions de filtrage et les 
stratégies IPSec manuellement via l'invite de commandes Netsh. Tout comme l'outil GUI, Netsh prend 
en charge l'exportation et l'importation des fichiers de stratégies IPSec pour les scénarios de 
sauvegarde et de récupération.

L'exécution de Netsh en mode de traitement par lot nécessite la création d'un fichier script contenant 
les commandes Netsh. Ce fichier script doit contenir la commande permettant de cibler le domaine 
ainsi que toutes les commandes de configuration des listes de filtres, des filtres, des actions de filtrage 
et des stratégies IPSec.

Vous pouvez ensuite créer les informations des stratégies IPSec dans Active Directory en démarrant 
l'outil Netsh, puis en exécutant le fichier script. La syntaxe de la ligne de commande pour le lancement 
de Netsh et l'exécution d'un fichier script se présente comme suit :

netsh –f <scriptfile>

Pour plus d'informations sur l'utilisation de Netsh, reportez­vous à la rubrique « Netsh » de la section 
« Outils d'administration et de script » du Centre d'aide et de support de Windows Server 2003.

Remarque : Netsh fonctionne uniquement avec des stratégies IPSec sur des ordinateurs exécutant 
Windows Server 2003. La manipulation depuis la ligne de commande des stratégies IPSec sur des 
ordinateurs exécutant Windows 2000 ou Windows XP exige respectivement l'outil Ipsecpol.exe ou 
Ipseccmd.exe. De plus, Netsh consigne une commande dump dans le contexte IPSec de l'outil. Bien 
qu'elle soit répertoriée dans l'aide, cette fonction n'a pas été implémentée. De plus, contrairement à 
l'outil GUI, Netsh ne prend pas en charge les connexions à distance.

130
Création d'objets Stratégie de groupe pour la distribution des stratégies IPSec

Les objets Stratégie de groupe (GPO) sont stockés dans Active Directory et définissent un ensemble 
de paramètres à appliquer à un ordinateur. Les stratégies IPSec ne sont pas stockées directement 
dans les objets Stratégie de groupe. À la place, les objets Stratégie de groupe maintiennent une 
liaison DN LDAP avec la stratégie IPSec. Les stratégies IPSec sont stockées à l'emplacement cn=IP 
Security, cn=System, dc=<domain> dans Active Directory.

Les objets Stratégie de groupe sont attribués aux sites, aux domaines ou aux unités d'organisation 
dans Active Directory. Les ordinateurs situés à ces emplacements ou dans ces conteneurs reçoivent 
la stratégie définie par l'objet Stratégie de groupe, sauf si d'autres paramètres l'empêchent. L'équipe 
de conception IPSec doit consulter l'équipe Active Directory afin de discuter de la possibilité d'utiliser 
les objets Stratégie de groupe existants pour fournir leurs stratégies IPSec. Si cette approche s'avère 
impossible ou exige une modification à grande échelle des méthodes de gestion, vous pouvez définir 
de nouveaux objets Stratégie de groupe pour chaque ensemble de stratégies IPSec à déployer. La 
solution décrite dans ce guide fait appel à de nouveaux objets Stratégie de groupe pour le 
déploiement des stratégies IPSec.

Bien que vous puissiez créer les objets Stratégie de groupe via l'outil Utilisateurs et ordinateurs 
Active Directory ou l'outil Sites et services Active Directory, nous vous conseillons de les créer à l'aide 
de la console de gestion des stratégies de groupe (GPMC). La création d'une stratégie avec les outils 
Active Directory permet de lier automatiquement l'objet Stratégie de groupe à l'objet en cours 
d'exploration. En faisant appel à la console GPMC pour créer les objets Stratégie de groupe, 
l'administrateur peut s'assurer que les objets Stratégie de groupe sont créés dans Active Directory 
mais ne sont pas appliqués aux ordinateurs tant que chaque objet Stratégie de groupe n'est pas 
explicitement lié à un site, un domaine ou une unité d'organisation.

La console GPMC est un utilitaire complémentaire destiné aux ordinateurs sous Windows XP Service 
Pack 1 (ou ultérieur) ou Windows Server 2003. Elle permet aux administrateurs de gérer la stratégie 
de groupe pour plusieurs domaines et sites dans une ou plusieurs forêts via une interface utilisateur 
simplifiée prenant en charge la fonctionnalité « glisser­déplacer ». Ses fonctions clés couvrent 
notamment la sauvegarde, la restauration, l'importation, la copie des objets Stratégie de groupe et la 
création de rapports les concernant. Ces opérations sont entièrement scriptables, ce qui permet aux 
administrateurs de personnaliser et d'automatiser la gestion. Notez que ces techniques de gestion des 
objets Stratégie de groupe s'appliquent à la gestion des objets de stratégie IPSec eux­mêmes. Vous 
devez développer une stratégie de gestion afin de gérer la stratégie IPSec en coordination avec les 
objets Stratégie de groupe chargés d'attribuer les stratégies IPSec.

Pour plus d'informations sur l'utilisation de la console GPMC, reportez­vous au livre blanc 
« Administering Group Policy with the GPMC   » (Administration de la stratégie de groupe à l'aide 
de la console GPMC) disponible sur le site Web de Microsoft à l'adresse 
www.microsoft.com/windowsserver2003/gpmc/gpmcwp.mspx.

Vous pouvez télécharger la console de gestion des stratégies de groupe avec Service Pack
      1    à 
partir de www.microsoft.com/downloads/details.aspx?FamilyId=0A6D4C24­8CBD­4B35­9272­
DD3CBFC81887&displaylang=en.

Grâce à la console GPMC, l'administrateur peut créer un objet Stratégie de groupe pour chaque 
stratégie IPSec en procédant comme suit :

Pour créer un nouvel objet Stratégie de groupe

1. Développez l'arborescence du domaine, cliquez avec le bouton droit sur le conteneur Objets 
de stratégie de groupe, puis sélectionnez Nouveau.

131
 2. Tapez le nom d'un nouvel objet Stratégie de groupe, puis cliquez sur OK.

Tout comme pour les actions de filtrage et les stratégies IPSec, vous devez développer une norme 
d'attribution de noms pour les objets Stratégie de groupe en incluant le numéro de version de la 
stratégie car les informations de version des objets Active Directory ne sont pas faciles à obtenir. 
L'ajout d'un numéro de version dans le nom de la stratégie permet aux administrateurs d'identifier 
rapidement la stratégie actuellement en vigueur. Microsoft recommande l'utilisation de la même 
convention d'attribution de noms que celle décrite plus haut dans ce chapitre pour les actions de 
filtrage et les stratégies IPSec. Par exemple, un objet Stratégie de groupe intitulé « GPO IPSec de 
domaine d'isolation ver 1.0.040601.1600 » désigne la version 1.0 créée le 06/01/04 à 16 heures.

Une fois l'objet Stratégie de groupe créé, l'administrateur doit le configurer pour qu'il utilise la stratégie 
IPSec appropriée.

Pour attribuer une stratégie IPSec à un objet Stratégie de groupe

1. Cliquez avec le bouton droit sur le nom de l'objet Stratégie de groupe, puis sélectionnez 
Modifier pour lancer l'Éditeur de stratégies de groupe.
2. Les stratégies IPSec qu'il est possible d'attribuer sont disponibles sous Configuration 
ordinateur\Paramètres Windows\Paramètres de sécurité\Stratégies de sécurité IP dans 
Active Directory.
3. Pour attribuer une stratégie IPSec, cliquez avec le bouton droit sur le nom de la stratégie dans 
le volet droit, puis sélectionnez Attribuer.
• Une seule stratégie IPSec peut être attribuée à un objet Stratégie de groupe.
4. Pour enregistrer les modifications de l'objet Stratégie de groupe, fermez l'Éditeur de stratégies 
de groupe.

La stratégie IPSec est appliquée aux ordinateurs hôtes via les paramètres de configuration ordinateur 
de l'objet Stratégie de groupe. Si vous utilisez l'objet Stratégie de groupe uniquement en vue 
d'appliquer des stratégies IPSec, nous vous conseillons de le configurer en désactivant les 
paramètres de configuration utilisateur. En désactivant ces paramètres, vous pourrez passer outre 
l'évaluation des options de configuration utilisateur et raccourcirez ainsi le temps de traitement de 
l'objet Stratégie de groupe.

Pour désactiver la configuration utilisateur dans l'objet Stratégie de groupe

1. Ouvrez l'outil GPMC.
2. Cliquez avec le bouton droit sur le nom de l'objet Stratégie de groupe dans la console GPMC.
3. Sélectionnez État GPO, puis Paramètres de configuration utilisateurs désactivés.

Si les paramètres de configuration utilisateur sont modifiés dans l'objet Stratégie de groupe par la 
suite, l'administrateur devra réactiver le traitement de ces paramètres afin qu'ils s'appliquent.

Groupes de sécurité de domaine

Les groupes de sécurité de domaine remplissent deux fonctions. La première est d'identifier les 
comptes d'ordinateurs de domaine membres d'un groupe d'isolation ; la deuxième est d'identifier les 
comptes d'ordinateurs de domaine membres d'un groupe d'accès réseau.

Tous les membres d'un groupe d'isolation doivent recevoir la même stratégie IPSec. Par conséquent, 
vous pouvez créer des groupes de sécurité de domaine pour l'application et la gestion des stratégies 

132
IPSec au lieu d'utiliser des conteneurs d'unités d'organisation pour contrôler l'attribution des 
stratégies. Les groupes universels constituent la meilleure option de contrôle de l'attribution des 
stratégies puisque vous pouvez les appliquer à la forêt tout entière et réduire ainsi le nombre de 
groupes à gérer. En revanche, si ces groupes universels ne sont pas disponibles, vous pouvez utiliser 
les groupes globaux de domaine à la place. Les groupes locaux de domaine sont utilisés pour les 
groupes d'accès réseau abordés plus loin dans ce guide.

Le tableau ci­après répertorie les groupes qui ont été créés pour le scénario de la Woodgrove Bank 
afin de gérer l'environnement IPSec et contrôler l'application des stratégies.

Tableau 5.10 : Noms des groupes IPSec

Nom de groupe Description
No IPSec Groupe universel de comptes d'ordinateurs ne participant pas à 
l'environnement IPSec Il s'agit généralement de comptes 
d'ordinateurs issus de l'infrastructure.

CG_IsolationDomain_computers  Groupe universel de comptes d'ordinateurs membres du domaine 
d'isolation.

CG_BoundaryIG_computers  Groupe universel de comptes d'ordinateurs membres du groupe 
d'isolation de limite et, par conséquent, autorisés à communiquer 
avec des systèmes non approuvés.

CG_NoFallbackIG_computers Groupe universel de comptes d'ordinateurs membres du groupe 
d'isolation sans basculement non autorisés à établir des 
communications non authentifiées sortantes.

CG_EncryptionIG_computers Groupe universel de comptes d'ordinateurs membres du groupe 
d'isolation de chiffrement et qui, par conséquent, exigent le 
chiffrement de leurs communications.

Outre les groupes énumérés, d'autres groupes ont peut­être été créés et exploités en vue de 
restreindre l'application des stratégies lors de la phase de déploiement initiale. Au moment de 
déployer IPSec, il n'est pas recommandé de se contenter de créer les objets Stratégie de groupe et 
les stratégies IPSec et de les attribuer en même temps à tous les ordinateurs du domaine. Vous 
pouvez utiliser un groupe de sécurité de domaine pour contrôler avec précision les ordinateurs 
capables de lire les objets Stratégie de groupe et, donc, de recevoir la stratégie IPSec 
correspondante. Les objets Stratégie de groupe offrant la stratégie IPSec peuvent tous être attribués à 
l'ensemble du domaine. Le processus de déploiement doit soigneusement examiner si la stratégie 
IPSec a été correctement conçue, attribuée et récupérée sur tous les nœuds sensés négocier IPSec. 
La conception de la stratégie du groupe de limite est généralement employée pour autoriser les 
communications non­IPSec entrantes et sortantes sur des ordinateurs qui n'ont pas encore reçu leur 
stratégie IPSec.

Distribution des stratégies IPSec via Active Directory

Trois méthodes, seules ou combinées, vous permettent de contrôler les objets Stratégie de groupe 
que vous pouvez appliquer à des ordinateurs dans Active Directory.

• Utilisation d'unités d'organisation avec des objets Stratégie de groupe liés.
• Intégration de comptes d'ordinateurs dans des groupes de sécurité référencés dans des listes de 
contrôle d'accès appliquées aux objets Stratégie de groupe.

133
• Utilisation de filtres WMI (Windows Management Instrumentation) dans les objets Stratégie de 
groupe.

Le contrôle de l'application des objets Stratégie de groupe par le biais d'unités d'organisation avec 
objets Stratégie de groupe liés est la méthode d'application de stratégies la plus répandue dans 
Active Directory. Elle vous permet de créer des unités d'organisation dans Active Directory et de lier 
des objets Stratégie de groupe à des sites, des domaines ou des unités d'organisation. La stratégie 
est attribuée aux ordinateurs en fonction de leur emplacement dans Active Directory. Si vous déplacez 
un ordinateur d'une unité d'organisation vers une autre, la stratégie liée à la deuxième unité 
d'organisation entre effectivement en vigueur lorsque la stratégie de groupe détecte des modifications 
lors de l'interrogation.

La deuxième méthode utilise les paramètres de sécurité des objets Stratégie de groupe eux­mêmes. 
Un groupe est ajouté à la liste de contrôle d'accès de l'objet Stratégie de groupe dans 
Active Directory. Des autorisations de lecture et d'application sont attribuées au groupe dans la 
stratégie à appliquer aux ordinateurs du groupe. De plus, d'autres autorisations spécifiques sont 
refusées au groupe dans les stratégies non applicables aux ordinateurs de ce groupe. La stratégie est 
ensuite liée au niveau du domaine.

La troisième méthode fait appel aux filtres WMI de la stratégie pour contrôler de manière dynamique 
l'étendue d'application de la stratégie. Un filtre SQL WMI est créé et lié à la stratégie. Si la condition 
interrogée est vraie (true), la stratégie est appliquée ; sinon, elle est ignorée. Les ordinateurs dotés de 
Windows 2000 ignorent le filtrage WMI et appliquent la stratégie. Les requêtes WMI peuvent ralentir le 
traitement des objets Stratégie de groupe et doivent être utilisées uniquement si elles sont 
nécessaires.

La Woodgrove Bank a opté pour l'utilisation des groupes de sécurité pour contrôler l'application des 
stratégies plutôt que de les lier directement à une unité d'organisation. Si elle a choisi cette approche, 
c'est pour faciliter l'intégration des stratégies IPSec dans l'environnement et éviter de les imposer à 
plusieurs emplacements ou de forcer le déplacement d'ordinateurs d'une unité d'organisation vers une 
autre pour obtenir la stratégie appropriée. À moins que les listes de contrôle d'accès de l'objet 
Stratégie de groupe soient extrêmement longues, cette méthode n'ajoute aucune charge par rapport à 
la première méthode puisque, dans les deux cas, les listes de contrôle d'accès doivent faire l'objet 
d'une évaluation. La Woodgrove Bank n'a pas opté pour le filtrage WMI en raison des systèmes 
Windows 2000 qu'abrite l'environnement.

Le tableau ci­dessous indique la configuration finale des listes de contrôle d'accès de la stratégie de 
groupe. Notez que les listes de contrôle d'accès dans les objets de stratégie IPSec eux­mêmes ne 
sont pas utilisées et sont déconseillées.

Tableau 5.11 : Autorisations GPO de la Woodgrove Bank

Nom de l’objet Stratégie de groupe Nom du groupe de sécurité Autorisations 

attribuées
IPSEC – Isolation Domain Policy  No IPSec Refuser Appliquer la 
(Stratégie de domaine d'isolation) stratégie de groupe

IPSEC – Isolation Domain Policy  CG_IsolationDomain_computers Autoriser Lecture et 

(Stratégie de domaine d'isolation) Appliquer la stratégie de 
groupe

IPSEC – Boundary  Group Policy  No IPSec Refuser Appliquer la 

(Stratégie de groupe de limite) stratégie de groupe

IPSEC – Boundary  Group Policy  CG_BoundaryIG_computers Autoriser Lecture et 

134
(Stratégie de groupe de limite) Appliquer la stratégie de 
groupe

IPSEC – No Fallback Isolation Group  No IPSec Refuser Appliquer la 

Policy (Stratégie de groupe d'isolation  stratégie de groupe
sans basculement)

IPSEC – No Fallback Isolation Group  CG_NoFallbackIG_computers Autoriser Lecture et 

Policy (Stratégie de groupe d'isolation  Appliquer la stratégie de 
sans basculement) groupe

IPSEC – Encryption Isolation Group  No IPSec Refuser Appliquer la 

Policy (Stratégie de groupe d'isolation  stratégie de groupe
de chiffrement)

IPSEC – Encryption Isolation Group  CG_EncryptionIG_computers Autoriser Lecture et 

Policy (Stratégie de groupe d'isolation  Appliquer la stratégie de 
de chiffrement) groupe

Domaine d'isolation 

La Woodgrove Bank a choisi de lier la stratégie Domaine d'isolation au niveau du domaine dans 
chaque domaine de l'organisation. La stratégie utilise une liste de contrôle d'accès qui empêche 
quiconque n'étant pas membre du groupe CG_IsolationDomain_computers d'appliquer la stratégie. 
Les autorisations Appliquer la stratégie de groupe du groupe Utilisateurs authentifiés ont été 
supprimées de la liste de contrôle d'accès de la stratégie.

La stratégie Domaine d'isolation Domain est la stratégie que tous les ordinateurs de l'organisation 
utilisent en tant que stratégie de sécurité IPSec par défaut. Par conséquent, le groupe Ordinateurs du 
domaine se voit accorder un droit d'accès en lecture à la stratégie. Les autorisations Appliquer la 
stratégie de groupe du groupe Utilisateurs authentifiés ont été supprimées de la liste de contrôle 
d'accès de la stratégie. Lors de la phase de déploiement initiale, le groupe Ordinateurs du domaine a 
été supprimé de la liste de contrôle d'accès et un autre groupe de sécurité provisoire a été utilisé pour 
contrôler et déterminer les destinataires de cette stratégie. Cette approche a permis un déploiement 
par étapes de cette stratégie.

Groupe d'isolation de limite

La Woodgrove Bank a choisi de lier la stratégie du groupe d'isolation de limite au niveau du domaine 
dans chaque domaine de l'organisation. La stratégie utilise une liste de contrôle d'accès qui empêche 
quiconque n'étant pas membre du groupe CG_BoundaryIG_computers d'appliquer la stratégie. Les 
autorisations Appliquer la stratégie de groupe du groupe Utilisateurs authentifiés ont été supprimées 
de la liste de contrôle d'accès de la stratégie.

Si, pour des besoins commerciaux, un système doit accepter des communications provenant de 
systèmes non approuvés, vous pouvez ajouter le compte d'ordinateur du système au groupe de 
sécurité CG_BoundaryIG_computers.

Groupe d'isolation sans basculement

La Woodgrove Bank a choisi de lier la stratégie du groupe d'isolation sans basculement au niveau du 
domaine dans chaque domaine de l'organisation. La stratégie utilise une liste de contrôle d'accès qui 
empêche quiconque n'étant pas membre du groupe CG_NoFallbackIG_computers d'appliquer la 
stratégie. Les autorisations Appliquer la stratégie de groupe du groupe Utilisateurs authentifiés ont été 
supprimées de la liste de contrôle d'accès de la stratégie.

135
Si, pour des besoins commerciaux, un système ne doit pas être en mesure d'établir des 
communications avec des systèmes non approuvés, vous pouvez ajouter le compte d'ordinateur du 
système au groupe CG_NoFallbackIG_computers.

Groupe d'isolation de chiffrement

La Woodgrove Bank a choisi de lier la stratégie du groupe d'isolation de chiffrement au niveau du 
domaine dans chaque domaine de l'organisation. La stratégie utilise une liste de contrôle d'accès qui 
empêche quiconque n'étant pas membre du groupe CG_EncryptionIG_computers d'appliquer la 
stratégie. Les autorisations Appliquer la stratégie de groupe du groupe Utilisateurs authentifiés ont été 
supprimées de la liste de contrôle d'accès de la stratégie.

Si, pour des besoins commerciaux, un système doit communiquer uniquement avec du trafic chiffré, 
vous pouvez ajouter le compte d'ordinateur du système au groupe CG_EncryptionIG_computers.

Autorisation de l'accès en entrée à un groupe 
d'isolation
Selon les exigences de la Woodgrove Bank, l'accès réseau en entrée aux serveurs du groupe 
d'isolation de chiffrement peut uniquement être autorisé à un sous­ensemble d'hôtes approuvés. Pour 
respecter ces exigences, les groupes d'accès réseau suivants ont été définis (voir le tableau 4.8 du 
chapitre 4) :

• ANAG_EncryptedResourceAccess_Users
• ANAG_EncryptedResourceAccess_Computers
• DNAG_EncryptedResourceAccess_Computers

Lorsqu'un client démarre IKE sur un serveur de chiffrement, IKE doit se procurer un ticket de service 
Kerberos dans lequel figure l'identificateur du groupe de sécurité du domaine indiquant si l'ordinateur 
client est membre du groupe ANAG et/ou peut­être du groupe DNAG. Si tous les ordinateurs du 
groupe d'isolation de chiffrement sont membres du même domaine, vous pouvez alors créer ces 
groupes d'accès réseau en tant que groupes de sécurité locaux du domaine. Si les ordinateurs du 
groupe d'isolation de chiffrement sont membres de domaines approuvés séparés, vous pouvez alors 
utiliser un ensemble de groupes globaux de domaine pour les groupes d'accès réseau ou bien créer 
des groupes locaux dans chaque domaine. Le scénario imaginé pour la Woodgrove Bank fait 
intervenir un seul et unique domaine ; il fait donc appel à des groupes locaux du domaine pour ces 
groupes d'accès réseau.

L'objet Stratégie de groupe supplémentaire suivant a été créé afin de définir des droits de type 
Accéder à cet ordinateur à partir du réseau permettant d'implémenter l'autorisation entrante :

• EncryptionIG GPO d'autorisation d'entrée sur le réseau

Le groupe CG_EncryptionIG_Computers se voit accorder les droits Lecture et Appliquer pour cet objet 
Stratégie de groupe. Le droit d'accès en lecture est retiré au groupe Utilisateurs authentifiés ; cet objet 
Stratégie de groupe est alors uniquement appliqué aux ordinateurs membres du groupe d'isolation de 
chiffrement.

Comme l'illustre le tableau 4.8 du chapitre 4, le compte d'ordinateur IPS­ST­XP­05 du domaine client 
autorisé est ajouté au groupe d'accès réseau ANAG_EncryptedResourceAccess_Computers. Les 
comptes IPS­SQL­DFS­01 et IPS­SQL­DFS­02 des serveurs de chiffrement sont également ajoutés. 

136
Néanmoins, le même résultat aurait été obtenu plus aisément en faisant appel au groupe 
CG_EncryptionIG_computers pour gérer une liste plus volumineuse. Les comptes doivent, d'une 
manière ou d'une autre, bénéficier du droit Accéder à cet ordinateur à partir du réseau, que ce soit 
du fait de l'appartenance au groupe ANAG, par intégration directe de leur groupe 
CG_EncryptionIG_computers ou par une liste explicite des comptes d'ordinateurs ajoutée au droit. 
Dans le cas contraire, les comptes ne seront pas en mesure d'établir des connexions protégées par 
IPSec entre eux, condition qu'exigent leurs applications. Pour simuler un environnement de domaine à 
grande échelle, les groupes ANAG sont les seuls groupes qui autorisent l'accès en entrée dans le 
scénario de la Woodgrove Bank.

Du fait que le groupe Utilisateurs authentifiés inclut tous les ordinateurs du domaine, le droit Accéder 
à cet ordinateur à partir du réseau doit lui être retiré. Les utilisateurs autorisés du domaine doivent 
désormais bénéficier d'une autorisation explicite qu'il est possible de définir à l'aide du groupe intégré 
Utilisateurs du domaine. Cependant, la Woodgrove Bank cherchait à tirer parti de la possibilité de 
définir des restrictions d'accès réseau entrant pour les utilisateurs et les ordinateurs. Elle a donc créé 
un groupe de sécurité local de domaine intitulé « ANAG_EncryptedResourceAccess_Users » en y 
intégrant les comptes des utilisateurs d'applications autorisés (par exemple, User7) ainsi que le 
groupe des administrateurs locaux et les groupes des administrateurs de domaine. Ces restrictions 
d'accès réseau définies au niveau de l'utilisateur interviennent lors des demandes d'authentification 
des protocoles de niveau supérieur (notamment RPC, SMB et SQL) après qu'une connectivité IPSec 
ESP 3DES a été établie avec succès.

Les groupes de sécurité de domaine suivants ont été créés en vue de définir des droits de connexion 
réseau pour les serveurs de chiffrement. Ils résident dans l'objet Stratégie de groupe sous 
Configuration ordinateur, Paramètres Windows, Paramètres de sécurité, Stratégies locales, Attribution 
des droits utilisateur, autorisation Accéder à cet ordinateur à partir du réseau :

• ANAG_EncryptedResourceAccess_Computers
• ANAG_EncryptedResourceAccess_Users

Le groupe suivant est configuré pour le même objet Stratégie de groupe, Interdire l'accès à cet 
ordinateur à partir du réseau :

• DNAG_EncryptedResourceAccess_Computers

En supposant qu'il ne parvienne pas à ouvrir directement une session sur les serveurs de chiffrement, 
l'utilisateur User7 doit utiliser l'ordinateur client IPS­ST­XP­05 pour accéder au serveur IPS­SQL­DFS­
01 ou au serveur IPS­SQL­DFS­02. L'ordinateur IPS­ST­XP­05 doit disposer d'un compte d'ordinateur 
de domaine valide et d'une stratégie IPSec active capable de soumettre une négociation IKE sur les 
adresses IP des serveurs de chiffrement.

Notez que les utilisateurs et les ordinateurs restants du domaine sont exclus de tout accès puisque 
l'autorisation Accéder à cet ordinateur à partir du réseau leur est intentionnellement retirée. Seuls 
les ordinateurs du groupe d'isolation de limite se voient explicitement refuser l'accès, par le biais du 
groupe DNAG. C'est une mesure de défense renforcée contre toutes les modifications d'appartenance 
à un groupe susceptibles d'être apportées à l'avenir et d'inclure un compte d'ordinateur de limite dans 
un groupe ANAG. Un paramètre de refus explicite remplace toutes les formes d'autorisation.

Autres considérations relatives à IPSec
Outre la définition des stratégies IPSec, d'autres éléments indispensables à une implémentation 
réussie d'IPSec sont à prendre en compte. La feuille de calcul Business_Requirements.xls (dossier 
Tools and Templates) fournit des informations détaillées sur les contraintes liées à l'utilisation d'IPSec.

137
Exemptions par défaut

Dans Windows 2000 et Windows XP, les types de trafic suivants sont, par défaut, exemptés du 
filtrage :

• Diffusion
• Multidiffusion
• Protocole d'authentification Kerberos
• IKE (Internet Key Exchange)
• RSVP (Resource Reservation Protocol)

Dans les systèmes d'exploitation de la famille Windows Server 2003, le trafic de diffusion, 
multidiffusion, RVSP et d'authentification Kerberos n'est, par défaut, pas exempt du filtrage (seul le 
trafic IKE l'est). Les paquets de diffusion et de multidiffusion sont ignorés s'ils correspondent à un filtre 
muni d'une action de filtrage visant à négocier la sécurité. Par défaut, Windows Server 2003 offre une 
prise en charge limitée pour le filtrage du trafic de diffusion et de multidiffusion. Un filtre doté d'une 
adresse source de type N'importe quelle adresse IP s'appliquera aux adresses de diffusion et de 
multidiffusion. Un filtre doté d'une adresse source de type N'importe quelle adresse IP et d'une 
adresse de destination N'importe quelle adresse IP s'appliquera à des adresses de multidiffusion 
entrantes et sortantes. Vous pouvez utiliser ce type de filtre pour bloquer l'ensemble du trafic. En 
revanche, les filtres unidirectionnels à utiliser pour bloquer ou autoriser un trafic de diffusion ou de 
multidiffusion spécifique ne sont pas pris en charge.

La modification du comportement d'exemption par défaut de l'implémentation d'IPSec dans la famille 
Windows Server 2003 doit vous inciter à vérifier le comportement des stratégies IPSec élaborées pour 
Windows 2000 ou Windows XP et à déterminer si des filtres explicites doivent être configurés pour 
autoriser des types de trafic spécifiques. Pour rétablir le comportement par défaut de Windows 2000 
et Windows XP pour les stratégies IPSec, vous pouvez utiliser la commande Netsh ou modifier le 
Registre.

Pour rétablir le comportement de filtrage par défaut de Windows 2000 et Windows XP dans le 
pilote IPSec à l'aide de la commande Netsh

1. Tapez la commande suivante à l'invite Netsh, puis appuyez sur Entrée :
netsh ipsec dynamic set config ipsecexempt 0
2. Redémarrez l’ordinateur.

Pour exempter tout le trafic de diffusion, multidiffusion et IKE du filtrage IPSec en modifiant le 
Registre

1. Donnez au paramètre HKEY_LOCAL_MACHINE\System\CurrentControlSet\
Services\IPSEC\NoDefaultExempt DWORD du Registre la valeur 1. La clé 
NoDefaultExempt n'existe pas par défaut et doit être créée.
2. Redémarrez l’ordinateur.

NAT­Traversal (NAT­T)

En raison du mode de fonctionnement des traducteurs d'adresses réseau, les clients peuvent être 
confrontés à des résultats inattendus avec des serveurs Windows 2000 Server ou 

138
Windows Server 2003 placés derrière un traducteur d'adresses réseau utilisant la technologie NAT­T 
IPSec. Par défaut, Windows XP SP2 ne prend plus en charge les associations de sécurité NAT­T 
IPSec avec ces serveurs.

L'objectif de cette modification est d'éviter un risque de sécurité prévisible dans une situation où les 
événements consécutifs suivants se produisent :

1. Un traducteur d'adresses réseau est configuré afin de faire correspondre le trafic IKE et le 
trafic NAT­T IPSec sur un serveur placé sur un réseau configuré NAT (Serveur 1).
2. Un client étranger au réseau NAT (Client 1) utilise NAT­T avec IPSec pour établir des 
associations de sécurité bidirectionnelles avec le Serveur 1.
3. Un client appartenant au réseau NAT (Client 2) utilise NAT­T avec IPSec pour établir des 
associations de sécurité bidirectionnelles avec le Client 1.
4. Une condition contraint le Client 1 à rétablir les associations de sécurité avec le Client 2 en 
raison des paramètres du traducteur d'adresses réseau qui fait correspondre le trafic IKE et le 
trafic IPSec NAT­T sur le Serveur 1. Cette condition peut provoquer un routage incorrect du 
trafic de négociation des associations de sécurité IPSec (transmis par le Client 1et destiné au 
Client 2) vers le Serveur 1.

Bien que cette situation soit peu probable, le comportement par défaut sur des ordinateurs 
Windows XP SP2 empêche toute association de sécurité IPSec NAT­T avec des serveurs situés 
derrière un traducteur d'adresses réseau afin de garantir que cette situation ne se produise jamais.

Si des communications IPSec sur NAT sont requises, nous vous conseillons d'utiliser des adresses IP 
publiques pour tous les serveurs qu'il est possible de connecter directement depuis Internet. Si cette 
configuration n'est pas possible, vous pouvez alors modifier le comportement par défaut de 
Windows XP SP2 pour activer les associations de sécurité IPSec NAT­T avec les serveurs situés 
derrière un traducteur d'adresses réseau.

Pour créer et configurer la valeur de Registre AssumeUDPEncapsulationContextOnSendRule

1. Cliquez sur Démarrer, Exécuter, tapez regedit, puis cliquez sur OK.
2. Recherchez, puis cliquez sur la sous­clé suivante du Registre :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec
3. Dans le menu Edition, pointez sur Nouveau, puis cliquez sur Valeur DWORD.
4. Dans la zone Nouvelle valeur #1, tapez ce qui suit, puis appuyez sur Entrée : 
AssumeUDPEncapsulationContextOnSendRule

Remarque : le nom de cette valeur tient compte de la casse.

5. Cliquez avec le bouton droit sur AssumeUDPEncapsulationContextOnSendRule, puis 
cliquez sur Modifier.
6. Dans la zone Données de la valeur, tapez l'une des valeurs suivantes :
• 0 (par défaut). Une valeur 0 (zéro) configure Windows de sorte qu'il ne puisse pas établir 
d'associations de sécurité avec des serveurs situés derrière des traducteurs d'adresses réseau.
• 1. Une valeur 1 configure Windows de sorte qu'il puisse établir des associations de sécurité 
avec des serveurs situés derrière des traducteurs d'adresses réseau.

139
 • 2. Une valeur 2 configure Windows de sorte qu'il puisse établir des associations de sécurité 
lorsque le serveur et l'ordinateur client Windows XP SP2 sont situés derrière des traducteurs 
d'adresses réseau.
Remarque : la configuration que représente la valeur 2 existe dans la version d'origine de 
Windows XP et dans Windows XP Service Pack 1 (SP1).
7. Cliquez sur OK, puis fermez l'Éditeur du Registre.
8. Redémarrez l’ordinateur.

Une fois AssumeUDPEncapsulationContextOnSendRule défini à une valeur 1 ou 2, Windows XP 
SP2 peut se connecter à un serveur situé derrière un traducteur d'adresses réseau.

Les serveurs Windows Server 2003 doivent également être mis à jour pour fonctionner comme il se 
doit avec IPSec lorsqu'ils sont placés derrière un dispositif NAT. Consultez l'URL ci­dessous pour 
savoir comment vous procurer Windows Server 2003 Service Pack
      1    : 
http://go.microsoft.com/fwlink/?LinkId=41652

Remarque : pour plus d'informations, reportez­vous à l'article 885348 de la Base de connaissances 
Microsoft, « IPSec NAT­T is not recommended for Windows Server 2003 computers that are behind 
network address translators   », (IPSec NAT­T est déconseillé pour les ordinateurs Windows 
Server 2003 situés derrière des traducteurs d'adresses réseau) disponible à l'adresse 
http://support.microsoft.com/default.aspx?scid=kb;en­us;885348. Cet article présente les risques de 
sécurité liés à l'utilisation de ce scénario. Chaque client doit comparer les avantages de l'utilisation 
d'IPSec dans ce scénario avec les risques de sécurité que cela implique. Bien que Microsoft ne 
recommande pas le scénario en raison des risques de sécurité qui y sont associés, ce scénario est 
pris en charge avec la configuration décrite dans cette solution.

Pour que les connexions NAT entrantes fonctionnent correctement, la découverte PMTU doit être 
activée et elle­même fonctionner. Certaines sources, notamment le Windows XP Hardening Guide et 
le Windows Server 2003 Hardening Guide (Guides de renforcement de la sécurité de Windows XP et 
de Windows Server 2003) recommandent de désactiver la découverte PMTU et fournissent, dans 
certains cas, des modèles de stratégies permettant de désactiver cette fonctionnalité.

Pour activer la découverte du PMTU (Path MTU)

1. Cliquez sur Démarrer, Exécuter, tapez regedit, puis cliquez sur OK.
2. Recherchez, puis cliquez sur la sous­clé suivante du Registre :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Services\tcpip\parameters
3. Dans le menu Edition, pointez sur Nouveau, puis cliquez sur Valeur DWORD.
4. Dans la zone Nouvelle valeur #1, tapez EnablePMTUDiscovery, puis appuyez sur Entrée.
5. Cliquez avec le bouton droit sur EnablePMTUDiscovery, puis cliquez sur Modifier.
6. Dans la zone Données de la valeur, tapez 1.
7. Cliquez sur OK, puis fermez l'Éditeur du Registre.
8. Redémarrez l’ordinateur.

De plus, les hôtes équipés de Windows 2000 et intervenant dans un scénario NAT­T nécessitent 
l'installation du correctif fourni avec l'article 818043 de la Base de connaissances Microsoft, 
« L2TP/IPSec NAT­T update for Windows
      XP and Windows    2000    » (Mise à jour NAT­T 
L2TP/IPSec pour Windows XP et Windows 2000) pour fonctionner correctement.

140
Pour plus d'informations, reportez­vous aux articles suivants de la Base de connaissances :

• 885407, « The default behavior of IPSec NAT traversal (NAT­T) is changed in Windows
      XP Service  
Pack 2   » (Le comportement par défaut d'IPSec NAT­T (NAT­Traversal) est modifié dans 
Service Pack 2 Windows XP), sur le site Web du support Microsoft à l'adresse 
http://support.microsoft.com/kb/885407.

• 818043, « L2TP/IPSec NAT­T update for Windows
      XP and Windows    2000   » (Mise à jour NAT­
T L2TP/IPSec pour Windows XP et Windows 2000), sur le site Web du support Microsoft à 
l'adresse http://support.microsoft.com/kb/818043.

IPSec et Pare­feu Windows

Le Pare­feu Windows sur des ordinateurs Windows XP SP2 offre une protection supplémentaire 
contre les attaques en bloquant le trafic entrant non sollicité. Sous Windows XP SP2, IPSec utilise le 
pare­feu Windows. Lorsqu'une stratégie IPSec est active, les composants IPSec de Windows XP SP2 
sollicitent le Pare­feu Windows afin qu'il ouvre les ports UDP 500 et 4500 pour autoriser le trafic IKE.

Une autre fonctionnalité prise en charge avec IPSec est la possibilité de préciser via la stratégie de 
groupe que tout le trafic protégé par IPSec ignore le traitement du Pare­feu Windows. Pour plus 
d'informations, reportez­vous à l'annexe A du livre blanc, « Deploying Windows Firewall Settings for 
 Microsoft Windows    XP with Service Pack 2    » (Déploiement des paramètres du Pare­feu Windows 
pour Microsoft Windows XP Service Pack 2) disponible à l'adresse 
http://download.microsoft.com/download/
6/8/a/68a81446­cd73­4a61­8665­8a67781ac4e8/wf_xpsp2.doc.

IPSec et Pare­feu de connexion Internet (ICF)

Pour les ordinateurs Windows XP non équipés du SP2, le Pare­feu de connexion Internet (ICF) 
répondra mieux aux exigences de sécurité qu'impose le filtrage du trafic. Le Pare­feu de connexion 
Internet offre en effet une fonction de filtrage et permet de bloquer le trafic de diffusion et de 
multidiffusion entrant dans Windows XP SP1. En revanche, il ne reconnaît pas le trafic protégé par 
IPSec au format AH ou ESP en mode transport ou en mode tunnel. Du fait qu'IPSec opère dans la 
couche réseau sous le Pare­feu de connexion Internet et qu'IKE intervient au­dessus du Pare­feu de 
connexion Internet, vous devez définir une autorisation statique (port UDP 500) pour le trafic entrant. 
Si IPSec bloque le trafic, le journal des paquets ignorés par le Pare­feu de connexion Internet ne 
contiendra pas les paquets ignorés par IPSec.

Résumé
Ce chapitre contient les informations requises pour créer et déployer des stratégies IPSec à partir de 
la conception des groupes d'isolation créée au chapitre 4. Ces informations ont été divisées en sept 
tâches élémentaires :

• Identification et création de listes de filtres
• Identification et création d'actions de filtrage
• Identification et création de règles
• Identification et création de stratégies IPSec
• Définition d'un mécanisme de distribution des stratégies IPSec
• Définition d'une méthode de déploiement des stratégies IPSec

141
• Définition d'autorisations pour le contrôle de l'accès entrant par configuration des droits de 
connexion réseau de la stratégie de groupe

Ces tâches complètent les phases de conception et de planification de la solution d'isolation de 
serveurs et de domaines. La prochaine phase du projet consiste à déployer un environnement test ou 
pilote afin de valider la conception. Microsoft a procédé à cette vérification dans ses laboratoires de 
test et utilisé le scénario de la Woodgrove Bank en tant que pilote. Si vous souhaitez recréer cet 
environnement ou étudier les phases de déploiement, l'annexe C du présent guide contient des 
instructions détaillées relatives au processus de déploiement adopté dans les laboratoires de 
Microsoft pour valider la conception du scénario.

Informations complémentaires

Cette section propose des liens vers d'autres informations relatives aux technologies mentionnées 
dans ce chapitre.

Informations générales sur IPSec

• La page d'accueil IPSec sur le site Web de Microsoft : www.microsoft.com/ipsec
• La page Page IPSec for Windows
      2000    (IPSec pour Windows 2000) sur le site Web de 
Microsoft fournit une grande variété d'informations relatives à IPSec sous Windows 2000 : 
www.microsoft.com/windows2000/technologies/communications/ipsec/default.asp.

• La page IPSec   de la section Windows Server 2003 du site Web de Microsoft fournit une grande 
variété d'informations relatives à IPSec sous Windows Server 2003 : 
www.microsoft.com/windowsserver2003/technologies/networking/ipsec/default.mspx.

• Le chapitre Deploying IPSec   (Déploiement d'IPSec) du Windows Server 2003 Deployment Kit 
(Kit de déploiement de Windows Server 2003) : www.microsoft.com/resources/documentation/
WindowsServ/2003/all/deployguide/en­us/DNSBJ_IPS_OVERVIEW.asp.

Informations complémentaires

• La page Windows
      Server    2003 Group Policy    (Stratégie de groupe dans Windows Server 2003) 
sur le site Web de Microsoft offre une grande variété d'informations sur la gestion des systèmes 
Windows à l'aide de la stratégie de groupe dans Active Directory : 
www.microsoft.com/windowsserver2003/technologies/management/grouppolicy/default.mspx.

• L'article paru en octobre 2004 dans The Cable Guy, « Problems with Using Network Address 
Translators   » (Problèmes liés à l'utilisation de traducteurs d'adresses réseau), apporte des 
informations supplémentaires sur les problèmes spécifiques liés à NAT et IPSec. Cet article est 
disponible sur le site Web de Microsoft à l'adresse suivante : 
www.microsoft.com/technet/community/columns/cableguy/cg1004.mspx.

142
Chapitre 6 : Gestion d'un 
environnement d'isolation de 
serveurs et de domaines
Dernière mise à jour le 16­02­2005

Ce chapitre fournit des conseils destinés à faciliter la gestion d'une solution d'isolation de serveurs et 
de domaines déployée efficacement dans un environnement de production.

Il est important que l'équipe du support technique comprenne que la solution d'isolation apporte une 
couche de sécurité supplémentaire, et qu'il faut plus qu'une simple connexion réseau et une 
adresse IP pour qu'un hôte réussisse à se connecter à une ressource. De même, les personnes 
chargées des stratégies IPSec et de la stratégie de groupe doivent avoir conscience qu'une seule 
option mal définie peut nuire aux performances des hôtes auxquels s'appliquent ces stratégies. C'est 
pourquoi il convient de mettre en place un ensemble de procédures et de processus de gestion 
correctement documentés et communiqués, qui seront utilisés par les équipes du support après la 
mise en service de la solution.

Les informations fournies dans ce chapitre sont destinées à faciliter l'élaboration de ces processus de 
gestion de la solution. Il est conseillé de personnaliser autant que possible ces informations afin de 
refléter les besoins de votre propre environnement. La réussite de la gestion d'une solution d'isolation 
de serveurs et de domaines repose sur vos capacités à anticiper.

Connaissances préalables requises pour ce chapitre
Avant d'utiliser les informations fournies dans ce chapitre, vous devez être familiarisé avec les 
concepts utilisés dans Microsoft® Operations Framework (MOF) et les concepts IPSec. Vous devez 
également posséder des connaissances sur les éléments suivants de Windows® 2000 Server (ou 
version ultérieure) :

• opérations et maintenance de base sur Microsoft Windows Server™ 2003, y compris l'utilisation 
d'outils tels que l'Observateur d'événements, la Gestion de l'ordinateur et NTBackup ;

• service d'annuaire Active Directory®, y compris la structure et les outils Active Directory, la 
manipulation des utilisateurs, des groupes et autres objets Active Directory, et utilisation de la 
stratégie de groupe ;

• concepts de sécurité du système Windows (utilisateurs, groupes, audit, listes de contrôle d'accès), 
utilisation des modèles de sécurité, application des modèles de sécurité à l'aide d'une stratégie de 
groupe ou d'un outil de ligne de commande ;

• concepts clés de la mise en réseau, notamment ceux relatifs à IPSec et au protocole TCP/IP ;
• environnement Windows Scripting Host et langage Microsoft Visual Basic® Scripting Edition 
(VBScript) afin d'exploiter au mieux les scripts fournis (toutefois, ces connaissances ne sont pas 
essentielles).

Avant de poursuivre la lecture de ce chapitre, vous devez lire le reste de ce guide et bien comprendre 
l'architecture et la conception de la solution.

143
Gestion des modifications
L'un des objectifs clés du processus de gestion des modifications est de garantir que toutes les parties 
concernées par une modification imminente ont conscience de l'impact de cette dernière et le 
comprennent. Dans la mesure où la plupart des systèmes sont étroitement liés, toute modification 
apportée à un composant d'un système est susceptible d'avoir un impact important sur un autre. Pour 
réduire ou éliminer les effets négatifs potentiels, la fonction de gestion des modifications tente 
d'identifier tous les systèmes et processus affectés avant le déploiement de la modification. En règle 
générale, l'environnement cible (ou géré) est l'environnement de production, mais il convient 
également d'inclure les environnements clés d'intégration, de test et intermédiaires.

Toutes les modifications apportées à un environnement IPSec doivent suivre le processus de gestion 
des modifications MOF standard suivant :

1. Demande de modification. Initiation formelle d'une modification par la soumission d'une 
requête de modification (RFC).
2. Classification de la modification. Affectation d'une priorité et d'une catégorie à la 
modification, en utilisant comme critères son urgence et son impact sur l'infrastructure ou les 
utilisateurs. Cette classification conditionne la vitesse et la voie de mise en œuvre de la 
modification.
3. Autorisation de la modification. Prise en considération de la modification, ainsi que son 
approbation ou sa désapprobation par le responsable des modifications et le comité 
d'approbation des modifications (CAB), qui comprend des représentants commerciaux et 
informatiques.
4. Développement de la modification. Planification et développement de la modification, 
processus dont la portée peut varier énormément et qui inclut des révisions à des étapes clés 
intermédiaires.
5. Diffusion de la modification. Diffusion et déploiement de la modification dans 
l'environnement de production.
6. Révision de la modification. Processus post­implémentation qui analyse si la modification a 
répondu aux objectifs fixés et qui détermine s'il convient de conserver la modification ou de 
l'annuler.

La section suivante décrit les procédures de développement de modification adaptées à certaines 
modifications clés que vous serez probablement amené à effectuer régulièrement dans votre 
environnement IPSec. Chaque procédure de développement de modification est accompagnée d'une 
procédure de diffusion, expliquant comment la modification doit être déployée en production.

Modification de la stratégie IPSec

Il est important de comprendre dans quelle mesure les modifications apportées à la stratégie IPSec 
affecteront les communications. Comme pour le déploiement initial, la première préoccupation 
concerne la chronologie des modifications, car cette dernière a des conséquences sur la capacité à 
implémenter une modification et sur le délai d'annulation de la modification.

Délais d'application de la stratégie

Lorsque l'attribution d'une stratégie IPSec dans un objet Stratégie de groupe est remplacée par une 
nouvelle stratégie IPSec, certains délais peuvent se produire. Il s'agit notamment du délai de 
réplication Active Directory de l'attribut Stratégie de groupe contenant l'attribution dans le domaine, et 
du délai d'interrogation des clients de la Stratégie de groupe membres du domaine requis pour 

144
détecter la modification au niveau de l'objet Stratégie de groupe. Ces délais peuvent durer moins 
d'une minute pour un petit site, et plusieurs heures pour l'ensemble d'une entreprise. Microsoft vous 
recommande de tester et de documenter ces délais (minimum, maximum et moyen) pour votre propre 
environnement afin que, lorsqu'une modification est introduite, le temps requis pour le premier impact 
et la durée totale du déploiement puissent être prévus.

Lorsque le contenu d'une stratégie IPSec déjà attribuée est modifié, les mêmes délais se produisent. Il 
faut s'attendre notamment à un délai de réplication Active Directory des objets de la stratégie IPSec, 
ainsi qu'à un délai d'interrogation du service de stratégie IPSec sur les ordinateurs membres. Il est 
possible de créer une condition dans laquelle la réplication de l'attribution de la stratégie dans l'objet 
Stratégie de groupe se produit avant la réplication de la stratégie IPSec ; cela induirait chez les clients 
un comportement identique à celui engendré par l'attribution d'une stratégie IPSec basée sur un 
domaine (sans possibilité de récupérer cette stratégie). Dans ce cas, les hôtes Windows 2000 et 
Windows XP ne parviendraient tout simplement pas à appliquer la stratégie basée sur un domaine. De 
même, ils n'appliqueraient aucune stratégie locale éventuellement attribuée.

Pour prendre en charge les délais de réplication Active Directory de manière appropriée, veillez 
d'abord à créer tous les objets (objet Stratégie de groupe, stratégie IPSec, etc.), puis procédez à 
l'attribution de la stratégie IPSec dans l'objet Stratégie de groupe.

Modifications affectant la connectivité IPSec

Plusieurs éléments peuvent affecter la connectivité au sein des stratégies et des groupes qui 
constituent une solution IPSec. Cette section fournit des informations sur la manière dont des 
modifications courantes peuvent affecter la connectivité IPSec dans le cadre de la modification d'une 
stratégie de serveur avec des clients ne possédant pas toujours la dernière mise à jour. Si une 
modification provoque un échec du mode IKE (Internet Key Exchange) principal ou rapide, le trafic est 
interrompu dès le début de l'inactivité des associations de sécurité IPSec ou à la fin de leur durée de 
vie en octets ou en secondes.

Cette présentation traite de l'impact qu'ont la plupart des modifications sur les fonctionnalités client­
serveur IPSec. Elle n'est pas uniquement basée sur les modèles de stratégie IPSec de 
Woodgrove Bank. Ici, les clients peuvent avoir une stratégie proche de celle du modèle de 
Woodgrove Bank (impliquant des filtres côté clients pour initier IKE sur le serveur), ou ils peuvent 
utiliser uniquement la règle de réponse par défaut (non utilisée dans le modèle de Woodgrove Bank).

Modifications en mode principal 

La modification d'une méthode d'authentification ou d'une méthode de sécurité de mode principal 
entraîne la suppression des modes principaux existants par l'IKE, sans affecter les associations de 
sécurité IPSec de mode rapide établies. Les nouvelles associations de sécurité de mode principal sont 
générées lorsque la régénération de clé de mode rapide suivante se produit.

En règle générale, la modification de la stratégie de serveur n'affecte pas la capacité des clients 
existants à générer une nouvelle clé de mode principal. Néanmoins, certaines modifications côté 
serveur peuvent provoquer l'échec de la négociation en mode principal IKE avec les clients, 
notamment :

• Mise en place d'une nouvelle méthode d'authentification (certificats uniquement) sans inclure les 
anciennes méthodes d'authentification que le client peut utiliser.

• Passage à 3DES/SHA1/DH1 ou DH2 comme méthode de sécurité de mode principal alors que les 
clients ont été configurés uniquement pour utiliser DES/SHA1/DH1.

145
• Activation de la confidentialité de transmission parfaite (PFS) de mode principal sans mettre à jour 
la stratégie du client et du serveur afin que les deux utilisent la PFS de mode principal.

• Activation de la confidentialité de transmission parfaite (PFS) de mode rapide sans mettre à jour la 
stratégie du client et du serveur afin que les deux utilisent la PFS de mode rapide.

Les modifications de stratégie de serveur suivantes n'affectent pas la capacité d'un client à générer 
une nouvelle clé pour les associations de sécurité de mode principal :

• Intervalle d'interrogation pour les modifications de stratégie (car il ne s'agit pas d'un paramètre IKE 
de mode principal)

• Clés de session utilisant la même clé principale (par exemple, nombre de modes rapides IKE par 
mode principal)

• Ajout d'une nouvelle méthode de sécurité non connue des clients
• Modification des paramètres avancés d'échange de clés de la stratégie IPSec pour les paramètres 
de durée de vie Authentifier et générer une nouvelle clé pour l'association de sécurité de mode 
principal IKE

Modifications en mode rapide

Toute modification d'une action de filtrage étant utilisée pour une association de sécurité IPSec 
provoque la suppression des associations de sécurité IPSec existantes établies avec ces paramètres 
de stratégie. Ainsi, en présence de trafic, le système tente d'établir un nouveau mode rapide. Une 
partie du trafic peut être perdue au cours de ce processus de modification, mais les connexions TCP 
doivent être rétablies. Cependant, pour les transferts de données à haute vitesse, la suppression 
immédiate des associations de sécurité IPSec provoque le rejet du trafic sortant jusqu'à 
l'établissement du nouveau mode rapide. Par exemple, une salve de paquets d'un flux de données 
vidéo, suite à laquelle TCP n'a pu être rétabli, provoquera une réinitialisation de la connexion pour 
l'application vidéo.

Les modifications de stratégie de serveur affectant la capacité des clients IPSec actifs à générer une 
nouvelle clé de mode rapide sont les suivantes :

• Passage d'un filtre plus général à un filtre plus spécifique. Par exemple, lorsqu'un serveur 
démarre avec un filtre de type tout le trafic, puis le supprime, en laissant un filtre TCP uniquement. 
Pour éviter les problèmes, laissez le filtre plus générique en place lorsque vous ajoutez le filtre plus 
spécifique. Par exemple, si les clients ont une stratégie de réponse par défaut et qu'un serveur a 
une stratégie passant de « tout le trafic » à « TCP uniquement », le filtre plus spécifique sera 
soumis au trafic sortant sur le serveur, qui établira une nouvelle association de sécurité IPSec pour 
TCP uniquement lorsque les clients auront une réponse par défaut. Le filtre « tout le trafic » 
appliqué à tous les clients finira par être supprimé (après deux heures) et pourra ensuite être retiré 
en toute sécurité de la stratégie du serveur.
Si le serveur ajoute un filtre plus spécifique avec une action d'autorisation, ce trafic sera 
immédiatement autorisé et pourra être rejeté par le client ayant un filtre plus général de réponse par 
défaut IPSec. Exemple : un filtre d'exemption ICMP (Internet Control Message Protocol) est ajouté à 
un serveur, mais les clients sont déjà sécurisés pour tout le trafic vers le serveur. Dans ce cas, le 
client va sécuriser son trafic ICMP sortant, recevoir une réponse ICMP en texte clair en retour et 
rejeter le paquet, car le filtre de réponse par défaut IPSec indique que tout le trafic doit être sécurisé. 
Cet exemple n'affecterait pas le trafic autre que le trafic ICMP entre le serveur et le client, et il 
représente un comportement attendu qui provoque toujours une perte de trafic ICMP après la 
demande de sécurisation de l'ensemble du trafic avec le client par le serveur. Cela peut, ou non, 
affecter considérablement les performances du service.

146
• Modifications de méthodes de sécurité ou de types d'encapsulation incompatibles. Par 
exemple, passage du mode de transport 3DES/SHA1 pour ESP uniquement au mode de transport 
3DES/MD5 pour ESP uniquement. Vous pouvez éviter les échecs de négociation en mode rapide 
IKE provoqués par ce type de modification en incluant les anciennes méthodes de sécurité ou les 
anciens types d'encapsulation en tant que dernier choix dans la nouvelle méthode de sécurité. Une 
fois que toutes les associations de sécurité IPSec utilisent la nouvelle méthode d'encapsulation, 
vous pouvez supprimer l'ancienne méthode au bas de la liste des méthodes de sécurité.

• Désactivation totale d'une règle dont les clients avaient besoin pour établir le mode 
principal ou le mode rapide IKE. En mode rapide, le filtre est supprimé afin qu'un filtre différent 
(ou aucun) contrôle la négociation en mode principal ou en mode rapide IKE.

• Modification totale d'une action de filtrage du type Négocier la sécurité au type Autoriser ou 
Bloquer. Le trafic étant explicitement autorisé ou bloqué ne nécessite pas la régénération de clé 
dans la mesure où ce trafic ne transitera plus sur une voie de communication protégée par IPSec.

• Désactivation de la case à cocher Communiquer en texte clair. Cette action conserve la 
connectivité des clients connectés pour toute la durée de l'association de sécurité logicielle. Une 
fois l'association de sécurité arrivée à expiration ou inactive, une augmentation du trafic sortant du 
serveur conduit l'IKE à tenter une nouvelle négociation en mode principal et à reconnaître les 
nouveaux paramètres afin d'éviter toute redirection. Les clients qui ne peuvent pas répondre 
positivement à la négociation IKE ne parviendront pas à se connecter. Cela peut être le but 
recherché.

• Désactivation de la case à cocher Autoriser une connexion non sécurisée. Cette action 
provoque la déconnexion des clients s'ils ne disposent pas de filtres IPSec pour déclencher une 
initiation en mode principal IKE sortant. Les clients disposant d'une règle de réponse par défaut 
restent connectés jusqu'à ce que leur filtre dynamique de réponse par défaut devienne inactif 
après deux heures d'absence de trafic vers le serveur, après quoi ils ne sont plus à même de se 
reconnecter.

Les modifications de stratégie de serveur suivantes n'affectent pas la capacité d'un client à générer 
une nouvelle clé de mode rapide :

• L'ajout d'un filtre ne correspondant pas au trafic se trouvant déjà dans les associations de sécurité 
IPSec actuelles n'affecte pas ce trafic. Par exemple, si des filtres de type autorisation sont ajoutés 
à la stratégie d'un serveur pour l'adresse IP d'un nouveau contrôleur de domaine.

• Modification de la durée de vie de l'association de sécurité IPSec de l'action de filtrage, en octets 
ou en temps.

• Modification de l'action de filtrage du type Autoriser à Négocier la sécurité. Si les clients peuvent 
répondre, ils seront toujours en mesure de négocier une connexion sécurisée pour ce trafic.

Procédures de modification de stratégie IPSec

Les sections suivantes décrivent les procédures permettant de modifier les stratégies IPSec délivrées 
à l'aide des objets Stratégie de groupe. Bien que les étapes présentées pour chaque tâche utilisent le 
composant logiciel enfichable de la console MMC (Microsoft Management Console) Stratégie de 
sécurité IP, chacune de ces tâches peut également être accomplie à l'aide de l'outil de ligne de 
commande Netsh sur un système Windows Server 2003.

Microsoft recommande la plate­forme Windows Server 2003 comme station de gestion des stratégies 
car elle offre les meilleures fonctionnalités pour les scripts et la surveillance.

L'importation et l'exportation des stratégies IPSec Windows sont destinées à la sauvegarde et à la 
restauration. La fonction d'exportation copie tous les objets de stratégie IPSec à l'emplacement de 

147
stockage pour garantir que tous les objets associés sont capturés dans la sauvegarde. L'exportation 
est la méthode recommandée pour déplacer l'ensemble de la stratégie de domaine actuelle sur un 
support de stockage local à des fins de test. En raison du risque d'erreur, veillez à bien supprimer tous 
les objets inutiles (y compris les stratégies, les listes de filtres et les actions de filtrage) contenus sur le 
support de stockage local avant d'utiliser la fonction d'exportation. Microsoft déconseille l'utilisation 
d'un magasin local exporté pour l'importation dans le domaine car des anciennes versions d'objet 
peuvent écraser des versions de domaine plus récentes et rompre ainsi les liens entre les objets.

Les scripts de lignes de commande sont la méthode recommandée pour créer une stratégie IPSec et 
pour réaliser des ajouts importants aux objets existants, comme l'ajout de filtres à une liste de filtres 
existants, par exemple. En règle générale, ces modifications importantes dans une stratégie IPSec 
doivent être effectuées via la création d'une nouvelle version de stratégie IPSec.

Une fois la stratégie créée, vous pouvez utiliser des scripts ou le composant logiciel enfichable MMC 
Gestion des stratégies IPSec pour apporter des modifications. Après la création et la mise en service 
de la stratégie IPSec, le composant logiciel enfichable MMC Gestion des stratégies IPSec est 
recommandé pour effectuer des modifications mineures.

Dans la mesure où l'outil de ligne de commande Ipsecpol.exe de Windows 2000 prend uniquement 
en charge la création d'une stratégie, le composant logiciel enfichable MMC peut être utilisé pour 
gérer les modifications dans Windows 2000 Active Directory. L'ajout d'un nouvel objet du même nom 
n'est pas autorisé dans les commandes d'ajout de Netsh. Pour cette raison, et parce que les scripts 
sont souvent exécutés de trop nombreuses fois, les scripts Netsh doivent inclure les étapes initiales 
permettant de supprimer les objets de stratégie existant déjà avant que de nouveaux objets soient 
ajoutés. La suppression d'un objet qui n'existe pas a pour effet de renvoyer un message d'erreur 
inattendue, qui n'interrompt pas l'exécution du script.

La suppression d'une stratégie de domaine IPSec déjà attribuée à un objet Stratégie de groupe rendra 
le lien de l'objet en question non valide. L'objet Stratégie de groupe doit être édité pour réattribuer la 
dernière version de la stratégie IPSec.

Remarque : bien que la section suivante explique comment modifier des stratégies IPSec directement 
dans Active Directory, nous partons du principe que toutes les modifications ont été testées sur un 
système local ou un environnement de test avant d'être déployées dans un environnement de 
production.

Modification de l'attribution de la stratégie IPSec pour un groupe d'isolation

Pour modifier la stratégie IPSec attribuée à un groupe d'isolation, vous pouvez remplacer la stratégie 
IPSec actuelle par une nouvelle.

La console GPMC (Group Policy Management Console) permet de modifier la stratégie IPSec qu'un 
objet Stratégie de groupe particulier distribue. Après avoir identifié la nouvelle stratégie IPSec et l'objet 
Stratégie de groupe qui distribue la stratégie actuelle, procédez comme suit.

Pour modifier la stratégie IPSec attribuée à un groupe d'isolation

1. Connectez­vous à un contrôleur de domaine en tant qu'administrateur de domaine.
2. Lancez la console GPMC.
3. Développez Forêt : <nom_domaine>, développez Domaines, puis développez 
<nom_domaine>.
4. Cliquez avec le bouton droit de la souris sur Nom d'objet de stratégie de groupe, puis 
cliquez sur Modifier.

148
 5. Développez Configuration ordinateur, développez Paramètres Windows, développez 
Paramètres de sécurité, puis cliquez sur Stratégies de sécurité IP sur Active Directory 
(nom du domaine).
6. Dans le volet de droite, cliquez avec le bouton droit de la souris sur <Nom de la stratégie  
IPSec>, puis cliquez sur Attribuer.
7. Vérifiez que la stratégie <Nom de la stratégie IPSec> est attribuée, puis fermez l'éditeur 
d'objets GPO, puis la console GPMC.

Modification d'une stratégie IPSec existante dans le domaine

Compte tenu que les fonctionnalités IPSec ont été étendues dans Windows XP, puis à nouveau dans 
Windows Server 2003, le format de stockage des stratégies IPSec a été modifié pour inclure les 
paramètres correspondants à ces améliorations. Veillez à ne pas utiliser un composant logiciel 
enfichable MMC Gestion des stratégies IPSec d'une version antérieure pour afficher ou modifier une 
stratégie intégrant ces fonctionnalités ajoutées. Si vous cliquez sur OK lors de l'affichage d'un 
composant de stratégie, les paramètres existants sont écrasés par les paramètres enregistrés dans la 
mémoire actuelle, même si vous n'avez effectué aucune modification. Des mises à jour ont été 
ajoutées aux Service Packs de Windows XP et à Windows 2000 Service Pack 4 (SP4) pour détecter 
les nouvelles versions de stratégie afin d'éviter ce problème potentiel. Néanmoins, le composant 
logiciel enfichable MMC ne parvient pas à enregistrer les modifications, comme si l'accès en 
modification était refusé ; il utilise les messages d'erreur qui existaient à la sortie du produit. De 
même, si l'utilisateur exécutant le composant logiciel enfichable MMC ne dispose que de droits de 
lecture sur les objets de stratégie IPSec, les modifications sont perdues lorsqu'une erreur d'accès 
refusé apparaît. Utilisez le mode lecture seule du composant logiciel enfichable MMC Gestion des 
stratégies IPSec dans Windows Server 2003 chaque fois que vous ne souhaitez pas effectuer de 
modification. Enfin, le composant logiciel enfichable MMC ne permet pas d'entrer un ID d'utilisateur et 
un mot de passe différents lors de la connexion à un ordinateur ou domaine distant. L'utilisateur doit 
être connecté sur le Bureau en tant qu'utilisateur disposant d'autorisations appropriées pour effectuer 
les modifications souhaitées.

Modification de la liste de filtres d'une règle existante

Il est parfois nécessaire de modifier la liste de filtres d'une règle existante pour ajouter, supprimer ou 
modifier un élément de filtre. Vous pouvez utiliser le composant logiciel enfichable MMC Gestion de 
stratégie de sécurité IP pour effectuer cette modification. N'oubliez pas que l'ordre d'un filtre dans une 
liste de filtres n'a aucune incidence sur l'ordre dans lequel le pilote IPSec traitera les paquets. Les 
filtres de toutes les listes de filtres dans toutes les règles d'une stratégie IPSec sont ordonnés à l'aide 
d'un algorithme interne de pondération. Pour effectuer une modification, vous devez vérifier 
manuellement que vous n'êtes pas en train de créer un filtre dupliqué pour un autre filtre utilisé dans la 
stratégie IPSec. Dans le cadre du processus de test de la modification, la stratégie doit être attribuée 
localement sur un ordinateur afin que la sortie du composant logiciel enfichable MMC Moniteur IPSec 
ou de la ligne de commande puisse être utilisée pour afficher l'ordre exact des filtres et détecter les 
filtres dupliqués.

Pour ajouter un ordinateur à une liste de filtres

1. Connectez­vous à un contrôleur de domaine en tant qu'administrateur de domaine.
2. Lancez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP et centrez­le 
sur le domaine.
3. Cliquez avec le bouton droit de la souris sur Stratégies de sécurité IP sur Active Directory, 
puis cliquez sur Gérer les listes de filtres IP et les actions de filtrage.

149
 4. Sous l'onglet Gestion de listes de filtres IP, dans la fenêtre Gérer les listes de filtres IP et 
les actions de filtrage, cliquez sur la liste de filtres Exemptions, puis cliquez sur Modifier.
5. Vérifiez que la case à cocher Utiliser l'Assistant Ajout est désactivée.
6. Dans la boîte de dialogue Liste de filtres IP, cliquez sur Ajouter.
7. Dans la liste déroulante Adresse source, cliquez sur Toute adresse IP.
8. Dans la liste déroulante Adresse de destination, cliquez sur Une adresse IP spécifique.
9. Dans la zone de texte Adresse IP, tapez l'adresse IP spécifique.
10. Vérifiez que la case à cocher Miroir est activée.
11. Sous l'onglet Description, tapez une description appropriée pour l'élément de filtre.
12. Cliquez sur OK, puis     de nouveau sur OK.
13. Fermez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP.

Remarque : une fois le nouveau système ajouté à une liste de filtres d'exemptions, le compte 
d'ordinateur doit être ajouté au groupe de sécurité Sans IPSec.

Pour modifier une entrée d'ordinateur dans une liste de filtres

1. Connectez­vous à un contrôleur de domaine en tant qu'administrateur de domaine.
2. Lancez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP et centrez­le 
sur le domaine.
3. Cliquez avec le bouton droit de la souris sur Stratégies de sécurité IP sur Active Directory, 
puis cliquez sur Gérer les listes de filtres IP et les actions de filtrage.
4. Sous l'onglet Gestion de listes de filtres IP, dans la fenêtre Gérer les listes de filtres IP et 
les actions de filtrage, cliquez sur la liste de filtres Exemptions, puis cliquez sur Modifier.
5. Vérifiez que la case à cocher Utiliser l'Assistant Ajout est désactivée.
6. Dans la liste Filtres IP, cliquez sur le filtre correspondant au système <nom_ordinateur>, 
puis cliquez sur Modifier.
7. Dans la zone de texte Adresse IP, remplacez l'entrée par la nouvelle adresse IP.
8. Cliquez sur OK, puis de nouveau sur OK dans la fenêtre suivante.
9. Fermez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP.

Pour supprimer une entrée dans une liste de filtres

1. Connectez­vous à un contrôleur de domaine en tant qu'administrateur de domaine.
2. Lancez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP et centrez­le 
sur le domaine.
3. Cliquez avec le bouton droit de la souris sur Stratégies de sécurité IP sur Active Directory, 
puis cliquez sur Gérer les listes de filtres IP et les actions de filtrage.
4. Sous l'onglet Gestion de listes de filtres IP, dans la fenêtre Gérer les listes de filtres IP et 
les actions de filtrage, cliquez sur la liste de filtres Exemptions, puis cliquez sur Modifier.
5. Dans la liste Filtres IP, cliquez sur le filtre correspondant au système <nom_ordinateur>.
6. Dans la boîte de dialogue Liste de filtres IP, cliquez sur Supprimer.

150
 7. Cliquez sur Oui pour supprimer l'élément de filtre.
8. Cliquez sur OK, puis de nouveau sur OK dans la fenêtre suivante.
9. Fermez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP.

Remarque : une fois le système supprimé de la liste de filtres d'exemptions, le compte d'ordinateur 
doit être retiré du groupe de sécurité Sans IPSec.

Modification de l'action de filtrage d'une règle existante

Chaque règle d'une stratégie IPSec dispose d'une action de filtrage correspondante qui est exécutée 
lorsque les conditions de la règle sont satisfaites. Bien qu'il soit possible d'attribuer une nouvelle 
stratégie IPSec aux ordinateurs qui présentent la nouvelle combinaison de règle et d'action de filtrage, 
il est plus judicieux de modifier l'action de filtrage associée à une règle de stratégie IPSec qui existe 
déjà. Par exemple, si une stratégie IPSec personnalisée existe pour un ensemble d'ordinateurs, il est 
plus logique de modifier l'action de filtrage attribuée à la règle plutôt que de générer une nouvelle 
stratégie IPSec.

Vous pouvez utiliser le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP pour 
configurer une règle dans une stratégie IPSec pour utiliser une nouvelle action de filtrage.

Pour modifier l'action de filtrage d'une règle existante

1. Connectez­vous à un contrôleur de domaine en tant qu'administrateur de domaine.
2. Lancez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP et centrez­le 
sur le domaine.
3. Dans le volet de droite, cliquez avec le bouton droit de la souris sur <Nom de la stratégie  
IPSec>,  puis cliquez sur Propriétés.
4. Dans la liste Règles de sécurité IP, cliquez sur <nom_règle>, puis cliquez sur Modifier.
5. Sous l'onglet Action de filtrage, dans la liste Actions de filtrage, cliquez sur <nouvelle  
action de filtrage> pour sélectionner le bouton adjacent.
6. Cliquez sur OK, puis de nouveau sur OK dans la fenêtre suivante.
7. Fermez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP.

Modification de la méthode d'authentification d'une règle existante

La méthode d'authentification par défaut des stratégies IPSec utilise le protocole Kerberos, version 5. 
Avec le temps, il peut s'avérer nécessaire de modifier une méthode d'authentification associée à une 
règle existante. Par exemple, une infrastructure de clés publiques (PKI) peut être déployée pour 
permettre l'utilisation de certificats pour authentifier les ordinateurs.

Bien que des informations différentes soient requises pour chaque méthode d'authentification pouvant 
être choisie, les étapes générales pour l'ajout d'une méthode d'authentification sont semblables. Par 
exemple, pour utiliser une clé pré­partagée, vous devez identifier la clé, et, pour utiliser les certificats, 
l'autorité de certification doit être connue. Pour ajouter une nouvelle option d'authentification à une 
règle IPSec existante, procédez comme suit.

Pour ajouter une option à une règle existante

1. Connectez­vous à un contrôleur de domaine en tant qu'administrateur de domaine.

151
 2. Lancez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP et centrez­le 
sur le domaine.
3. Dans le volet de droite, cliquez avec le bouton droit de la souris sur <Nom de la stratégie 
IPSec>, puis cliquez sur Propriétés.
4. Dans la liste Règles de sécurité IP, cliquez sur <nom_règle>, puis cliquez sur Modifier.
5. Sous l'onglet Méthodes d'authentification, cliquez sur Ajouter.
6. Cliquez sur le bouton correspondant à la nouvelle option d'authentification souhaitée, puis 
configurez les options requises.
7. Cliquez sur OK.
8. Dans la liste Ordre de préférence des méthodes d'authentification, utilisez les boutons Monter 
et Descendre pour créer l'ordre de préférence des méthodes d'authentification.

Remarque : pour supprimer une méthode d'authentification, cliquez dessus dans la liste Ordre de 
préférence des méthodes d'authentification, puis cliquez sur Supprimer.

9. Cliquez sur OK, puis de nouveau sur OK dans la fenêtre suivante.
10. Fermez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP.

Ajout d'une nouvelle règle à une stratégie IPSec existante

L'ajout de nouvelles règles à des stratégies IPSec existantes permet de restreindre ou d'élargir 
davantage les communications entre les ordinateurs de l'environnement. Par exemple, si un système 
prenant en charge IPSec doit communiquer avec des systèmes placés dans un groupe d'isolation 
particulier mais ne reçoit pas sa stratégie de l'infrastructure IPSec, vous pouvez effectuer des 
modifications sur le groupe d'isolation afin d'autoriser les communications.

Dans cet exemple, il faut appliquer à l'hôte IPSec non géré une stratégie autorisant les 
communications. En outre, il faut choisir une méthode d'authentification partagée (soit des certificats, 
soit une clé pré­partagée). Une nouvelle règle peut alors être créée dans la stratégie IPSec existante 
afin de permettre au groupe d'isolation d'autoriser le trafic une fois que la méthode d'authentification a 
été acceptée.

Les étapes nécessaires sont les suivantes : créer une nouvelle liste de filtres dans le répertoire, 
associer la nouvelle liste de filtres à la stratégie existante, puis configurer les mécanismes 
d'authentification afin qu'ils incluent la nouvelle méthode d'authentification choisie.

Pour créer une nouvelle liste de filtres afin de permettre tout le trafic vers un ordinateur 
spécifique

1. Connectez­vous à un contrôleur de domaine en tant qu'administrateur de domaine.
2. Lancez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP et centrez­le 
sur le domaine.
3. Cliquez avec le bouton droit de la souris sur Stratégies de sécurité IP sur Active Directory, 
puis cliquez sur Gérer les listes de filtres IP et les actions de filtrage.
4. Sous l'onglet Gestion de listes de filtres IP, cliquez sur Ajouter.
5. Dans la zone de texte Nom, tapez un nom de liste de filtres approprié.
6. Dans la zone de texte Description, tapez une description appropriée pour la liste de filtres.

152
 7. Vérifiez que la case à cocher Utiliser l'Assistant Ajout est désactivée.
8. Dans la boîte de dialogue Liste de filtres IP, cliquez sur Ajouter.
9. Dans la liste déroulante Adresse source, cliquez sur Toute adresse IP.
10. Dans la liste déroulante Adresse de destination, cliquez sur Une adresse IP spécifique.
11. Dans la zone de texte Adresse IP, tapez l'adresse IP de l'ordinateur spécifique.
12. Vérifiez que la case à cocher Miroir est activée.

Remarque : par défaut, cette procédure crée une règle examinant tout le trafic provenant d'une 
adresse IP quelconque sur une adresse IP spécifique. Si la correspondance doit être effectuée sur un 
port ou une base de protocole spécifique, des opérations de configuration supplémentaires doivent 
être effectuées sous l'onglet Protocole.

13. Sous l'onglet Description, tapez une description appropriée pour l'élément de filtre.
14. Cliquez sur OK, puis de nouveau sur OK dans la fenêtre suivante.

Pour modifier une stratégie IPSec afin d'utiliser une nouvelle liste de filtres et une action de 
filtrage

1. Cliquez avec le bouton droit de la souris sur <Nom de la stratégie IPSec>, puis cliquez sur 
Propriétés.
2. Vérifiez que la case à cocher Utiliser l'Assistant Ajout est désactivée.
3. Cliquez sur Ajouter.
4. Sous l'onglet Liste de filtres IP, dans la liste Filtres IP, cliquez sur la case d'option Nouvelle 
liste de filtres IP.
5. Sous l'onglet Action de filtrage, dans la liste Actions de filtrage, cliquez sur la case d'option 
Action de filtrage.
6. Sous l'onglet Méthodes d'authentification, cliquez sur Ajouter.
7. Cliquez sur le bouton correspondant à la méthode d'authentification souhaitée, puis configurez 
les options requises.

Remarque : la méthode d'authentification choisie doit être négociable par l'initiateur et le répondeur 
(clé pré­partagée ou certificats, par exemple). Si nécessaire, supprimez le protocole de la liste en le 
sélectionnant, puis en cliquant sur le bouton Supprimer.

8. Cliquez sur OK.
9. Dans la liste Ordre de préférence des méthodes d'authentification, utilisez les boutons 
Monter et Descendre pour sélectionner l'ordre de préférence des méthodes d'authentification 
si la liste en contient plusieurs.
10. Cliquez sur OK, puis de nouveau sur OK dans la fenêtre suivante.
11. Fermez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP.

Déplacement d'hôtes entre différents groupes d'isolation

Pour plusieurs raisons, les hôtes doivent régulièrement être déplacés d'un groupe à un autre. Il est 
important de comprendre les implications des modifications apportées aux appartenances de groupe 

153
sur les communications. Les sections suivantes décrivent les étapes requises pour ajouter ou 
supprimer des hôtes dans les groupes.

Ajout ou suppression d'un hôte dans une liste d'exemptions

Vous pouvez ajouter ou supprimer un hôte dans la liste d'exemptions en modifiant les listes de filtres 
d'exemptions IPSec et le groupe de sécurité Sans IPSec. Pour ce faire, suivez les étapes décrites 
dans la section « Modification de la liste de filtres d'une règle existante », plus haut dans ce chapitre.

La liste de filtres d'exemption, le nom de l'hôte, ainsi que son adresse IP doivent être connus pour 
réaliser cette tâche.

Ajout ou suppression d'hôtes et d'utilisateurs dans des groupes 
existants

Lorsque vous ajoutez ou supprimez un hôte dans un groupe d'accès réseau (NAG), les étapes sont 
spécifiques au rôle joué par l'hôte dans le groupe. Si l'hôte fait office d'initiateur, son ajout ou sa 
suppression dans le groupe d'accès réseau associé suffit. En revanche, s'il fait office de répondeur, la 
stratégie qui contrôle la mise à jour du droit « Accéder à cet ordinateur à partir du réseau » doit être 
appliquée ou supprimée. Si le système fait office d'initiateur et de répondeur, les deux étapes doivent 
être exécutées.

Ajout ou suppression d'initiateurs dans un groupe d'accès réseau existant

Vous pouvez ajouter ou supprimer un initiateur dans un groupe d'accès réseau en utilisant les outils 
standards de gestion de groupes pour modifier le groupe de sécurité associé. 

Pour modifier un groupe d'accès réseau lié à un ordinateur spécifique

1. Connectez­vous à un contrôleur de domaine en tant qu'administrateur de domaine, puis 
lancez le composant MMC Utilisateurs et ordinateurs Active Directory.
2. Développez le domaine, puis cliquez sur Utilisateurs.
3. Dans le volet de droite, cliquez avec le bouton droit de la souris sur <Groupe d'accès  
réseau>, puis cliquez sur Propriétés.
4. Pour ajouter un ordinateur au groupe :
• Cliquez sur l'onglet Membres, puis cliquez sur Ajouter.
• Cliquez sur le bouton Types d'objet, activez la case à cocher Ordinateurs, puis cliquez 
sur OK.
• Dans la zone de texte Entrer les noms des objets à sélectionner, tapez 
<nom_ordinateur>, puis cliquez sur OK.
• Cliquez sur OK.
5. Pour supprimer un ordinateur du groupe :
• Cliquez sur l’onglet Membres.
• Dans la liste Membres, cliquez sur <nom_ordinateur>, puis cliquez sur Supprimer.
• Cliquez sur Oui pour supprimer le compte <nom_ordinateur>.
• Cliquez sur OK.

Remarque : il y aura un délai entre le moment où le compte de l'hôte sera ajouté au groupe et le 
moment où l'hôte pourra accéder à la ressource restreinte. Ce délai est dû aux délais de réplication et 

154
au temps requis entre les mises à jour du ticket de session sur le serveur qui héberge la ressource 
restreinte (si le ticket est mis en cache).

Ajout ou suppression d'utilisateurs dans un groupe d'accès réseau existant

Bien que les groupes d'isolation aient été créés pour limiter l'initiation par des hôtes de 
communications vers la ressource restreinte, ils peuvent également être utilisés pour permettre de 
restreindre l'accès à cette ressource par des utilisateurs. Si aucune exigence n'est spécifiée pour 
restreindre l'accès à une ressource d'une manière similaire à un groupe d'accès réseau, le groupe 
Utilisateurs du domaine se voit accorder le droit « Accéder à cet ordinateur à partir du réseau » sur les 
répondeurs. Si une exigence est spécifiée pour restreindre l'accès à une ressource, un groupe 
Utilisateurs NAG est créé.

Vous pouvez ajouter ou supprimer un utilisateur avec accès restreint dans un groupe Utilisateurs NAG 
en recourant aux outils standards de gestion de groupes pour modifier le groupe de sécurité associé. 
Cette procédure est uniquement requise si un groupe Utilisateurs NAG a été créé et attribué au 
groupe d'accès réseau ; si le groupe Utilisateurs du domaine est en cours d'utilisation, cette procédure 
n'est pas nécessaire.

Pour modifier un groupe Utilisateurs NAG lié à un utilisateur spécifique

1. Connectez­vous à un contrôleur de domaine en tant qu'administrateur de domaine, puis 
lancez le composant MMC Utilisateurs et ordinateurs Active Directory.
2. Développez le domaine, puis cliquez sur Utilisateurs.
3. Dans le volet de droite, cliquez avec le bouton droit de la souris sur <Utilisateurs NAG>, puis 
cliquez sur Propriétés.
4. Pour ajouter un utilisateur au groupe d'accès réseau :
• Cliquez sur l'onglet Membres, puis cliquez sur Ajouter.
• Dans la zone de texte Entrer les noms des objets à sélectionner, tapez <nom de  
l'utilisateur>, puis cliquez sur OK.
• Cliquez sur OK.
5. Pour supprimer un utilisateur du groupe d'accès réseau :
• Cliquez sur l’onglet Membres.
• Dans la liste Membres, cliquez sur le <nom de l'utilisateur> spécifique, puis cliquez sur 
Supprimer.
• Cliquez sur Oui pour supprimer le compte <nom de l'utilisateur>.
• Cliquez sur OK.

Remarque : il y aura un délai entre le moment où le compte de l'utilisateur sera ajouté au groupe et le 
moment où l'utilisateur pourra accéder à la ressource restreinte. Ce délai est dû aux délais de 
réplication et au temps requis entre les mises à jour du ticket de session sur le serveur qui héberge la 
ressource restreinte (si le ticket est mis en cache).

155
Ajout ou suppression de répondeurs dans un groupe d'accès réseau existant

Pour supprimer un hôte répondeur d'un groupe d'accès réseau, vous pouvez supprimer l'attribution de 
l'objet Stratégie de groupe qui configure le droit « Accéder à cet ordinateur à partir du réseau » sur le 
répondeur. L'application de l'objet Stratégie de groupe peut être contrôlée par n'importe quel moyen 
standard permettant de garantir l'application des stratégies avec Active Directory. Néanmoins, 
l'approche utilisée dans ce guide a attribué l'objet Stratégie de groupe à une unité d'organisation qui a 
été créée pour contenir les comptes d'ordinateurs de domaine des répondeurs. Le simple 
déplacement du compte d'ordinateur en dehors de l'unité d'organisation des répondeurs l'empêchera 
de recevoir l'objet Stratégie de groupe attribué, et l'accès ne sera plus restreint. L'ordinateur reviendra 
ainsi à la stratégie de domaine d'isolation. (Si le compte d'ordinateur appartenait aussi à un groupe de 
sécurité de domaine local composé de groupes d'accès réseau, il doit également être supprimé de ce 
groupe.)

Vous devez vous assurer que les hôtes appartenant à plusieurs groupes d'accès réseau sont toujours 
capables de communiquer avec les autres groupes d'accès réseau après avoir été supprimés de l'un 
de ces groupes.

Ajout de nouveaux groupes d'accès réseau

La création d'un groupe d'accès réseau est un processus relativement simple. Vous devez tout 
d'abord créer un groupe de domaine local pour contrôler l'accès à la ressource, ainsi qu'un objet 
Stratégie de groupe pour mettre à jour le droit « Accéder à cet ordinateur à partir du réseau » sur les 
hôtes qui agissent en tant que serveurs dans le groupe d'accès réseau. Vous devez ensuite appliquer 
cet objet Stratégie de groupe aux serveurs, et identifier les hôtes qui appartiennent au groupe.

Seuls les initiateurs doivent être membres du groupe d'accès réseau. En d'autres termes, si deux 
serveurs se trouvent dans le même groupe d'isolation et ne communiqueront jamais ensemble, ils 
n'ont pas besoin d'être ajoutés au groupe d'accès réseau pour leur groupe d'isolation. En revanche, si 
ces deux serveurs sont amenés à communiquer, ils doivent être ajoutés au groupe d'accès réseau 
comme le sont tous les autres initiateurs.

Si un serveur agit en tant que répondeur au sein de plusieurs groupes d'accès réseau, vous devez 
vous assurer que tous les groupes de sécurité des groupes d'accès réseau auxquels le serveur 
appartient sont présents sur le droit « Accéder à cet ordinateur à partir du réseau » de ce système 
après que l'objet Stratégie de groupe a été appliqué. Si nécessaire, des objets Stratégie de groupe 
supplémentaires peuvent être requis afin que les ordinateurs remplissent cette exigence.

Création d'un nouveau groupe d'accès réseau pour les ordinateurs initiateurs

Procédez comme indiqué ci­après pour créer un nouveau groupe d'accès réseau.

Pour créer un nouveau groupe d'accès réseau pour les ordinateurs initiateurs

1. Connectez­vous à un contrôleur de domaine en tant qu'administrateur de domaine, puis 
lancez le composant MMC Utilisateurs et ordinateurs Active Directory.
2. Cliquez sur le conteneur Utilisateurs avec le bouton droit de la souris, cliquez sur Nouveau, 
puis sur Groupe.
3. Dans la zone de texte Nom du groupe, tapez un nom approprié pour le groupe.
4. Cliquez sur le groupe de sécurité Domaine local, puis cliquez sur OK.
5. Cliquez avec le bouton droit de la souris sur le groupe que vous venez de créer, puis cliquez 
sur Propriétés.

156
 6. Dans la zone de texte Description, tapez une description appropriée pour le groupe.
7. Cliquez sur OK.

Ajout de comptes d'ordinateurs initiateurs à un groupe d'accès réseau

Procédez comme indiqué ci­après pour constituer un nouveau groupe d'accès réseau avec des 
comptes d'initiateurs.

Pour constituer le nouveau groupe d'accès réseau des initiateurs avec des comptes 
d'initiateurs

1. Connectez­vous à un contrôleur de domaine en tant qu'administrateur de domaine, puis 
lancez le composant MMC Utilisateurs et ordinateurs Active Directory.
2. Développez le domaine, puis cliquez sur Utilisateurs.
3. Dans le volet de droite, cliquez avec le bouton droit de la souris sur le groupe Initiateurs  
NAG, puis cliquez sur Propriétés.
4. Cliquez sur l'onglet Membres, puis cliquez sur Ajouter.
5. Cliquez sur le bouton Types d'objet, activez la case à cocher Ordinateurs, puis cliquez sur 
OK.
6. Dans la zone de texte Entrer les noms des objets à sélectionner, tapez le <nom de 
l'initiateur>, puis cliquez sur OK.
7. Cliquez sur OK.

Si vous avez besoin de restreindre encore les utilisateurs du domaine autorisés à accéder à la 
ressource restreinte, un groupe doit être créé pour les utilisateurs NAG avec accès restreint. À défaut, 
le groupe Utilisateurs du domaine peut être utilisé à la place.

Création d'un nouveau groupe d'accès réseau pour les utilisateurs avec accès restreint

Procédez comme indiqué ci­après pour créer un groupe d'accès réseau pour les utilisateurs avec 
accès restreint.

Pour créer un groupe d'accès réseau pour des comptes d'utilisateurs

1. Connectez­vous à un contrôleur de domaine en tant qu'administrateur de domaine, puis 
lancez le composant MMC Utilisateurs et ordinateurs Active Directory.
2. Cliquez sur le conteneur Utilisateurs avec le bouton droit de la souris, cliquez sur Nouveau, 
puis sur Groupe.
3. Dans la zone de texte Nom du groupe, tapez un nom approprié pour le groupe.
4. Cliquez sur le groupe de sécurité Domaine local, puis cliquez sur OK.
5. Cliquez avec le bouton droit de la souris sur le groupe que vous venez de créer, puis cliquez 
sur Propriétés.
6. Dans la zone de texte Description, tapez une description appropriée pour le groupe.
7. Cliquez sur OK.

157
Ajout de comptes d'utilisateurs avec accès restreint à un groupe d'accès réseau

Procédez comme indiqué ci­après pour constituer un nouveau groupe d'accès réseau avec des 
utilisateurs avec accès restreint.

Pour constituer le nouveau groupe d'accès réseau avec des comptes d'utilisateurs

1. Connectez­vous à un contrôleur de domaine en tant qu'administrateur de domaine, puis 
lancez le composant MMC Utilisateurs et ordinateurs Active Directory.
2. Développez le domaine, puis cliquez sur Utilisateurs.
3. Dans le volet de droite, cliquez avec le bouton droit de la souris sur le groupe Utilisateurs  
NAG, puis cliquez sur Propriétés.
4. Cliquez sur l'onglet Membres, puis cliquez sur Ajouter.
5. Dans la zone de texte Entrer les noms des objets à sélectionner, tapez <nom de  
l'utilisateur>, puis cliquez sur OK.
6. Cliquez sur OK.

Création d'un objet Stratégie de groupe pour accorder le droit « Accéder à cet ordinateur à 
partir du réseau »

Un objet Stratégie de groupe permet d'attribuer le droit « Accéder à cet ordinateur à partir du réseau » 
aux groupes d'accès réseau appropriés.

Le tableau suivant fournit un exemple d'implémentation, par un objet Stratégie de groupe, d'un groupe 
d'accès réseau et des noms de groupe associés auxquels le droit « Accéder à cet ordinateur à partir 
du réseau » doit être accordé.

Tableau 6.1 : Exemple de définition de stratégie de groupe d'accès réseau

Nom de l’objet Stratégie de groupe Nom de groupe
<Nom de la stratégie d'implémentation du groupe d'accès   <Nom du groupe d'accès réseau>
réseau> Administrateurs
Opérateurs de sauvegarde
Utilisateurs NAG ou Utilisateurs du 
domaine

Remarque : les groupes répertoriés représentent les groupes minimaux à ajouter. L'administrateur 
devra déterminer s'il doit accorder ce droit à des groupes supplémentaires.
Le groupe Utilisateurs du domaine est ajouté en tant que groupe par défaut. Si l'administrateur 
souhaite également restreindre l'accès pour certains utilisateurs en plus des ordinateurs, un groupe 
Utilisateurs NAG devra être créé de la même manière que celui dédié aux comptes d'ordinateurs 
(contenant les comptes d'utilisateurs sélectionnés).

Pour créer un objet Stratégie de groupe pour accorder le droit « Accéder à cet ordinateur à 
partir du réseau »

1. Connectez­vous à un contrôleur de domaine en tant qu'administrateur de domaine.
2. Lancez la console GPMC.

158
 3. Développez Forêt : <nom_domaine>, développez Domaines, puis développez 
<nom_domaine>.
4. Cliquez avec le bouton droit de la souris sur Objets de stratégie de groupe, puis cliquez sur 
Nouveau.
5. Dans la zone de texte Nom, tapez <Nom d'objet de stratégie de groupe>, puis cliquez sur OK.
6. Cliquez avec le bouton droit de la souris sur <Nom d'objet de stratégie de groupe>, puis 
cliquez sur Modifier.
7. Développez Configuration ordinateur, développez Paramètres Windows, développez 
Paramètres de sécurité, développez Stratégies locales, puis cliquez sur Attribution des 
droits utilisateur.
8. Dans le volet de droite, cliquez avec le bouton droit de la souris sur « Accéder à cet ordinateur 
à partir du réseau », puis cliquez sur Propriétés.
9. Activez la case à cocher Définir ces paramètres de stratégie.
10. Cliquez sur le bouton Ajouter un utilisateur ou un groupe.
11. Cliquez sur le bouton Parcourir.
12. Dans la zone de texte Entrer les noms des objets à sélectionner, tapez le nom de tous les 
groupes répertoriés dans le tableau précédent, séparés par des points­virgules. Cliquez 
ensuite sur OK.
13. Cliquez sur OK.
14. Fermez l'éditeur d'objets GPO puis la console GPMC.

Déploiement d'objets Stratégie de groupe d'un groupe d'accès réseau

Pour déployer les objets Stratégie de groupe d'un groupe d'accès réseau, ces derniers doivent tout 
d'abord être liés à un emplacement dans l'environnement du domaine afin qu'ils puissent être 
appliqués aux répondeurs appropriés du groupe d'accès réseau. L'application de l'objet Stratégie de 
groupe peut être contrôlée par n'importe quelle méthode standard permettant de garantir l'application 
des stratégies avec Active Directory. L'explication détaillée des étapes correspondantes n'entre pas 
dans le cadre de ce guide et dépend de la structure des unités d'organisation et des méthodes de 
gestion utilisées au sein de l'organisation.

Désactivation d'IPSec dans un groupe d'isolation

Vous pouvez désactiver une stratégie IPSec en modifiant l'objet Stratégie de groupe qui la distribue. 
Pour désactiver la stratégie IPSec, l'objet Stratégie de groupe est configuré pour que les paramètres 
d'ordinateur soient désactivés.

Pour désactiver les paramètres d'ordinateur de l'objet Stratégie de groupe

1. Connectez­vous à un contrôleur de domaine en tant qu'administrateur de domaine.
2. Lancez la console GPMC.
3. Développez Forêt : <nom de domaine>, développez Domaines, développez <nom de  
domaine>, puis développez Objets de stratégie de groupe.
4. Cliquez avec le bouton droit de la souris sur <Nom d'objet de stratégie de groupe>, cliquez 
sur État GPO, puis cliquez sur Paramètres de configuration ordinateurs désactivés.

159
 5. Fermez la console GPMC.

Réactivation d'IPSec dans un groupe d'isolation

Vous pouvez réactiver des stratégies IPSec ayant été désactivées en modifiant l'objet Stratégie de 
groupe qui distribue la stratégie. Pour réactiver une stratégie IPSec désactivée, l'objet Stratégie de 
groupe est configuré de sorte que les paramètres d'ordinateur soient activés.

Pour activer les paramètres d'ordinateur de l'objet Stratégie de groupe

1. Connectez­vous à un contrôleur de domaine en tant qu'administrateur de domaine.
2. Lancez la console GPMC.
3. Développez Forêt : <nom de domaine>, développez Domaines, développez <nom de  
domaine>, puis développez Objets de stratégie de groupe.
4. Cliquez avec le bouton droit de la souris sur <Nom d'objet de stratégie de groupe>, cliquez 
sur État GPO, puis cliquez sur Activé.
5. Fermez la console GPMC.

Suppression d'IPSec dans un groupe d'isolation

Vous pouvez supprimer une stratégie IPSec en modifiant l'objet Stratégie de groupe qui la distribue. 
Pour supprimer la stratégie IPSec, l'objet Stratégie de groupe est configuré de sorte que la stratégie 
IPSec ne soit plus attribuée.

Pour supprimer l'attribution de la stratégie IPSec de l'objet Stratégie de groupe

1. Connectez­vous à un contrôleur de domaine en tant qu'administrateur de domaine.
2. Lancez la console GPMC.
3. Développez Forêt : <nom_domaine>, développez Domaines, puis développez 
<nom_domaine>.
4. Cliquez avec le bouton droit de la souris sur <Nom d'objet de stratégie de groupe>, puis 
cliquez sur Modifier.
5. Développez Configuration ordinateur, développez Paramètres Windows, développez 
Paramètres de sécurité, puis cliquez sur Stratégies de sécurité IP sur Active Directory 
(nom du domaine).
6. Dans le volet de droite, cliquez avec le bouton droit de la souris sur <Nom de la stratégie  
IPSec>, puis cliquez sur Supprimer l'attribution.
7. Vérifiez que la stratégie <Nom de la stratégie IPSec> n'est plus attribuée, puis fermez 
l'éditeur d'objets GPO, puis la console GPMC.

Considérations relatives à la sauvegarde et la 
récupération
Cette section fournit des informations sur l'évaluation des processus qui couvrent spécifiquement la 
sauvegarde et la restauration des composants de la solution d'isolation de serveurs et de domaines.

160
Sauvegarde Active Directory

Les stratégies IPSec ne sont pas stockées dans les objets Stratégie de groupe utilisés pour distribuer 
les stratégies. Les fonctions de sauvegarde et de restauration de la stratégie de groupe capturent 
uniquement les informations sur lesquelles est basée l'attribution des stratégies IPSec aux objets 
Stratégie de groupe, et non les informations réelles relatives aux stratégies IPSec.

Bien qu'une sauvegarde complète de l'état du système d'un contrôleur de domaine capture les 
informations relatives aux stratégies IPSec, il est également possible d'utiliser les commandes de 
menu Exporter des stratégies et Importer des stratégies du composant logiciel enfichable MMC 
Gestion de stratégie de sécurité IP pour sauvegarder et restaurer les stratégies IPSec.

Remarque : il est important de sécuriser les sauvegardes de vos stratégies IPSec. Néanmoins, la 
sauvegarde est un fichier qui hérite des autorisations du système de fichiers NTFS du répertoire dans 
lequel il est stocké, et les données du fichier ne sont ni chiffrées ni signées. Vous devez protéger les 
informations de configuration IPSec contenues dans ces fichiers en utilisant les autorisations ou 
procédures de sécurité appropriées. Seuls les administrateurs IPSec autorisés doivent avoir accès à 
ces fichiers de sauvegarde.

Pour plus d'informations sur la sauvegarde des données d'état du système sur un ordinateur 
exécutant Windows Server 2003, consultez la page To back up System State data   (Sauvegarde 
des données d'état du système) sur le site Microsoft.com, à l'adresse 
www.microsoft.com/resources/documentation/windowsserv/2003/standard/proddocs/en­
us/ntbackup_backup_sysstate.asp.

Restauration de systèmes hôtes

Sur les ordinateurs pour lesquels une stratégie IPSec a été restaurée à partir d'une sauvegarde 
(sauvegarde sur bande ou sauvegarde à partir d'une image), la stratégie IPSec appliquée peut être 
une copie mise en cache de la stratégie IPSec basée sur Active Directory ou une stratégie IPSec 
locale.

Si l'ordinateur se voit attribuer la stratégie IPSec basée sur Active Directory, le service IPSec tente de 
récupérer à partir d'Active Directory la copie la plus récente de la stratégie attribuée avant d'appliquer 
la copie mise en cache de la stratégie basée sur Active Directory. Au cours de cette opération, le 
service IPSec commence par interroger le système DNS (Domain Name System) pour obtenir la liste 
actuelle des adresses IP de tous les contrôleurs de domaine. Si les objets de stratégie IPSec ont été 
supprimés d'Active Directory, la copie mise en cache de la stratégie basée sur Active Directory est 
appliquée à la place.

La liste des adresses IP des contrôleurs de domaine de la copie mise en cache de la stratégie IPSec 
basée sur Active Directory peut avoir considérablement changé depuis la création de la sauvegarde 
de la stratégie IPSec (par exemple, de nouveaux contrôleurs de domaine peuvent avoir été ajoutés). 
Si tel est le cas, la communication peut être bloquée avec les contrôleurs de domaine actuels ; ainsi, 
les authentifications basées sur le protocole Kerberos échoueront lors des tentatives d'établissement 
de connexions sécurisées à l'aide d'IPSec à distance. En outre, l'ordinateur risque de ne pas être en 
mesure de recevoir les mises à jour de la stratégie de groupe. Ce problème peut être résolu à l'aide 
de la procédure suivante :

1. Accédez à l'ordinateur localement et arrêtez le service IPSec sur cet ordinateur.
2. Redémarrez l'ordinateur en Mode sans échec avec prise en charge réseau, et configurez le 
service IPSec pour un démarrage manuel ou désactivez le service IPSec pour permettre les 

161
 communications sécurisées à l'aide d'IPSec avec les adresses IP des nouveaux contrôleurs 
de domaine. 

Réduction des risques d'infection sur le réseau
Dans certains cas, il peut s'avérer nécessaire d'interrompre rapidement les communications afin 
d'assurer la sécurité de l'environnement, en cas d'attaques virales ou de violations de la sécurité, par 
exemple. Les sections suivantes présentent les différentes méthodes pouvant être appliquées pour 
isoler les hôtes prenant part à des communications authentifiées. Ces méthodes ont été conçues pour 
ne pas isoler l'infrastructure ni les serveurs exemptés. Il est en effet primordial de ne pas isoler les 
serveurs d'infrastructure afin d'éviter que les systèmes perdent leur capacité à mettre à jour leurs 
stratégies IPSec à partir du domaine.

Remarque : bien que ces méthodes d'isolation soient techniquement sûres, elles n'ont pas été 
testées dans un environnement de laboratoire. Il est fortement recommandé de les tester dans un 
environnement de laboratoire avant de les mettre en application.

Isolation du domaine d'isolation

Les hôtes du domaine d'isolation sont autorisés à initier des communications avec des hôtes non 
approuvés. S'il est nécessaire de bloquer rapidement ce type de trafic, l'action de filtrage IPSEC – 
Secure Request Mode (Ignore Inbound, Allow Outbound) (IPSEC – Mode de requête sécurisée 
(Ignorer le trafic entrant, Autoriser le trafic sortant) peut être modifiée pour que le droit « Autoriser une 
communication non sécurisée avec des ordinateurs n'utilisant pas IPSec » soit désactivé. Au terme de 
la période d'interrogation IPSec, tous les hôtes du domaine d'isolation doivent cesser de communiquer 
avec des systèmes non intégrés à l'environnement IPSec.

Pour modifier l'action de filtrage IPSEC – Secure Request Mode (Ignore Inbound, Allow 
Outbound) (IPSEC – Mode de requête sécurisé (Ignorer le trafic entrant, Autoriser le trafic 
sortant)

1. Connectez­vous à un contrôleur de domaine en tant qu'administrateur de domaine.
2. Lancez le composant logiciel enfichable MMC Gestion de stratégie de sécurité IP et centrez­le 
sur le domaine.
3. Cliquez avec le bouton droit de la souris sur Stratégies de sécurité IP sur Active Directory, 
puis cliquez sur Gérer les listes de filtres IP et les actions de filtrage.
4. Sous l'onglet Gérer les actions de filtrage, cliquez sur l'action de filtrage IPSEC – Secure 
Request Mode (Ignore Inbound, Allow Outbound) (IPSEC – Mode de requête sécurisé 
(Ignorer le trafic entrant, Autoriser le trafic sortant), puis cliquez sur Modifier.
5. Activez ou désactivez la case à cocher Autoriser une communication non sécurisée avec 
des ordinateurs n'utilisant pas IPSec.
6. Cliquez sur OK.
7. Cliquez sur OK.

Une fois cette option définie, la stratégie bloque tout le trafic réseau destiné à des hôtes non 
approuvés. Une fois le problème résolu, la communication peut être rétablie en réactivant l'option.

Blocage des ports

162
Les stratégies IPSec déployées sur les ordinateurs d'un réseau local interne à une organisation sont 
configurés pour autoriser toutes les communications sur l'ensemble des ports. Cette approche 
simplifie la configuration et la gestion de l'environnement. Cependant, si un hôte utilisant IPSec se 
trouve infecté par un logiciel malveillant (virus ou ver, par exemple), il va très probablement 
transmettre l'infection aux autres ordinateurs. En fonction des stratégies que l'ordinateur utilise, 
l'infection peut toucher les hôtes approuvés et non approuvés.

Les stratégies IPSec peuvent permettre de limiter la contamination par un blocage explicite des ports 
que le logiciel malveillant utilise. La limite principale que rencontre cette approche est le délai 
nécessaire aux ordinateurs pour détecter la modification apportée à la stratégie pour y intégrer des 
filtres de blocage. En outre, certains vers ont envahi le réseau et ont rendu difficile la récupération des 
modifications relatives à la stratégie IPSec. De plus, certains vers ont utilisé des ports également 
utilisés par des services vitaux, tels que le système DNS, ce qui rendrait difficile la mise à jour de la 
stratégie après l'application des filtres de blocage sur l'hôte. Le blocage peut être effectué en créant 
une règle qui bloque le trafic provenant d'adresses IP quelconques, destiné au port spécifique utilisé 
par un certain type de logiciels malveillants. Cette règle est ajoutée à toutes les stratégies appliquées 
à l'environnement. Une fois le logiciel malveillant éliminé, la règle peut être retirée des stratégies.

Après avoir identifié les ports et les protocoles utilisés par un certain type de logiciels malveillants, 
créez une liste de filtres correspondant aux critères relatifs à la communication des logiciels 
malveillants en suivant les étapes de la procédure « Ajout d'une nouvelle règle à une stratégie IPSec 
existante », dans la section « Modification de la stratégie IPSec » plus haut dans ce chapitre. 
L'intervalle d'interrogation de la stratégie IPSec doit être réduit immédiatement après la décision 
d'utiliser le blocage de ports dans la stratégie de domaine. L'intervalle d'interrogation peut être 
augmenté à nouveau, une fois la menace écartée.

Néanmoins, au lieu de créer un filtre qui utilise une adresse IP en direction d'une adresse IP 
spécifique, créez un filtre qui utilise « Mon adresse IP » vers n'importe quelle adresse IP. En principe, 
les filtres en miroir ne sont pas utilisés. Il faut utiliser une liste de filtres contenant deux filtres 
unidirectionnels (un pour le trafic entrant à destination d'un port connu, et un autre pour le trafic 
sortant à destination d'un port connu). Par exemple, les filtres suivants bloquent le port SQL 1433 
exploité par le ver SQLSlammer :

De toute adresse IP ­> Mon adresse IP, TCP, src *, dst 1433, sans miroir

De Mon adresse IP ­> Toute adresse IP, TCP, src *, dst 1433, sans miroir

Naturellement, ces filtres bloquent également les connexions de l'application SQL et doivent être 
retirés une fois que la menace de contamination par ver a disparu. Veillez à ne pas bloquer l'accès 
aux ports d'infrastructure essentiels comme DNS, sauf en cas de nécessité absolue. Ces filtres sont 
plus spécifiques que les filtres du sous­réseau Woodgrove qui négocient IPSec pour l'ensemble du 
trafic transitant sur le réseau interne car ils intègrent une adresse IP spécifique.

Une fois le filtre créé, ajoutez une règle à toutes les stratégies IPSec du domaine d'isolation et de 
groupe pour associer la liste de filtres à l'action de filtrage IPSec – Block (IPSec – Bloquer). Vous 
souhaiterez peut­être inclure dans la conception de votre stratégie une règle qui associe déjà une liste 
de filtres IPSec vierge utilisée pour les ports bloqués à l'aide de l'action de blocage. Cette liste de 
filtres vierge peut être utilisée par les règles présentes dans l'ensemble des stratégies IPSec et 
activée de sorte que tous les membres du domaine vérifient cette liste à chaque intervalle 
d'interrogation. La règle peut également être désactivée ; dans ce cas, l'interrogation du service IPSec 
détecte quand la règle est activée dans chaque stratégie de groupe d'isolation.

Si, pour quelque raison que ce soit, le blocage des ports empêche IPSec d'accéder à Active Directory 
pour obtenir une stratégie mise à jour, le service IPSec peut être arrêté et redémarré sur l'ordinateur 
par un administrateur, ou l'ordinateur peut être redémarré. Lorsque le service IPSec démarre, ce 

163
dernier tente de télécharger la version la plus récente de la stratégie IPSec attribuée avant d'appliquer 
l'ancienne version contenue dans la mémoire cache.

Isolation dans le domaine enfant uniquement

Si un domaine entier doit être isolé du reste des domaines de la forêt, la stratégie appliquée à ce 
domaine peut être configurée pour utiliser une clé pré­partagée plutôt que le protocole Kerberos. 
Cette approche permet aux ordinateurs situés dans le domaine enfant de maintenir des 
communications avec d'autres systèmes du même domaine, mais les communications avec les 
systèmes extérieurs au domaine auquel ils ont normalement accès sont bloquées.

Chaque stratégie du domaine enfant doit être modifiée afin d'utiliser uniquement une clé pré­partagée 
pour la règle IPSec – Secure Organization Subnets (IPSec – Sous­réseaux sécurisés de 
l'organisation). Toutes les méthodes d'authentification existantes, comme le protocole Kerberos, 
devront être supprimées. Pour configurer les méthodes d'authentification, suivez les étapes décrites 
dans la section « Modification de la méthode d'authentification d'une règle existante », plus haut dans 
ce chapitre.

Si d'autres règles intégrant l'authentification existent dans la stratégie, elles doivent également être 
configurées pour utiliser une clé pré­partagée. Toutes les stratégies du domaine enfant devant être 
isolé doivent être configurées de cette façon. Pour réduire les risques d'échec d'authentification de 
mode principal IKE lors du déploiement de la stratégie, la méthode d'authentification par clé pré­
partagée peut être placée au premier rang dans la liste des méthodes d'authentification, suivie par la 
méthode reposant sur le protocole Kerberos. Une fois que tous les ordinateurs disposent de la 
stratégie mise à jour, la méthode d'authentification Kerberos peut être supprimée. Un processus 
similaire est utilisé pour restaurer l'authentification pour le protocole Kerberos et supprimer la clé pré­
partagée une fois la menace écartée.

Isolation dans des groupes prédéfinis

Bien que les groupes d'accès réseau constituent une implémentation unique pouvant être utilisée pour 
isoler un groupe prédéfini d'ordinateurs, il est également possible d'utiliser des clés pré­partagées ou 
des certificats pour réaliser la même isolation. La principale différence par rapport aux groupes 
d'accès réseau est le fait que vous devrez créer des stratégies distinctes pour chaque groupe 
d'ordinateurs pour sécuriser le trafic entre les ordinateurs disposant d'une clé pré­partagée ou d'un 
certificat. Cette solution nécessite un processus de planification des communications supplémentaire, 
notamment si un système appartient à plusieurs groupes.

L'inconvénient majeur des clés pré­partagées est le fait qu'elles sont stockées en clair dans la 
stratégie, ce qui les rend facilement détectables (la confidentialité est alors compromise) depuis un 
client du domaine. Cet inconvénient peut ne pas être gênant si la valeur de la clé pré­partagée est 
uniquement utilisée pour une isolation temporaire lors d'une infection par ver.

En raison d'une restriction, IKE vérifie les contraintes de certificat au niveau de l'autorité de 
certification racine et non de l'autorité émettrice ; il faudrait alors déployer une autorité de certification 
racine unique pour chaque groupe.

Résumé
Ce chapitre fournit des informations, des processus et des procédures nécessaires à la gestion, la 
maintenance et la modification d'une solution d'isolation de serveurs et de domaines après le 
déploiement et la mise en service effectifs de cette dernière.

164
Les processus et procédures décrits ici doivent être correctement expliqués et communiqués au 
personnel susceptible d'être impliqué dans la gestion quotidienne des hôtes de l'environnement. Dans 
la mesure où la modification, même mineure, d'une stratégie IPSec peut désactiver une voie de 
communication protégée, ces processus et procédures doivent être conçus de manière à éviter tout 
risque d'erreur pouvant résulter d'une mauvaise compréhension des conséquences d'une telle 
modification. 

165
Chapitre 7 : Dépannage d'IPSec
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.

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.

166
• 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.

167
• 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.

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

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

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

171
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

172
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

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

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

175
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 

176
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 

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

178
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 :

179
• 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 
http://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 http://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 

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

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

Commande Description Windows2000  WindowsXP  Windows2003 ?

? ?
netdiag /test:ipsec Affiche la stratégie  Oui Oui Non**
IPSec attribuée

netdiag /test:ipsec  Affiche la stratégie  Oui Oui* Non**

/debug IPSec active, les 
filtres et les 
statistiques du mode 
rapide

netdiag /test:ipsec /v Affiche la stratégie  Oui Oui* Non**

IPSec active, les 
filtres et les 
statistiques du mode 
principal

* 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  Obtention Rôle Informations 

d'exploitation pris  complémentaires
en charge
Ipsecpol.exe Windows 2000  Kit de ressources  Configure les  Aide contenue dans 
uniquement de Windows 2000 stratégies IPSec  les outils du kit de 
dans l'annuaire ou  ressources de 
un registre Windows 2000

Gpresult Windows 2000,  Kit de ressources  Indique quand la  Aide contenue dans 

Windows  Windows 2000 ;  stratégie de groupe  les outils du kit de 
Server 2003,  pour Windows XP  a été appliquée  ressources de 
Windows XP et Windows  pour la dernière fois Windows 2000, 
Server 2003,  Aide de 
Gpresult fait partie  Windows XP et de 
du système  Windows Server 20
d'exploitation 03

Composant logiciel  Windows  Inclus dans le  Affiche la stratégie  Windows 

182
enfichable MMC  Server 2003,  système  IPSec d'un  Server 2003
Jeu de stratégie  Windows XP d'exploitation ordinateur ou des 
résultant (Resultant  membres d'un 
Set of Policy,  conteneur de 
RSoP) stratégie de groupe

Srvinfo Kits de ressources  Windows 2000 et  Fournit des  Aide contenue dans 

Windows 2000,  Windows  informations sur les  les outils du kit de 
Windows  Server 2003 services, pilotes de  ressources de 
Server 2003,  périphériques et  Windows 
Windows XP protocoles Server 2003

PortQry Kits de ressources  Windows  Génère des  http://support.micro

Windows 2000,  Server 2003 rapports sur l'état  soft.com/kb/310099 
Windows  des ports réseau
Server 2003, 
Windows XP

NLTest Kits de ressources  Outils de support  Teste les relations  Aide contenue dans 

Windows 2000,  d'approbation et les  les outils du kit de 
Windows  canaux Netlogon  ressources de 
Server 2003,  sécurisés Windows 
Windows XP Server 2003

Klist Kits de ressources  Windows 2000 et  Génère des  Aide contenue dans 

Windows 2000,  Windows  rapports sur les  les outils du kit de 
Windows  Server 2003 tickets Kerberos ressources de 
Server 2003,  Windows 
Windows XP Server 2003

Pathping Kits de ressources  Inclus dans le  Teste les chemins  Aide de Windows

Windows 2000,  système  d'accès et la 
Windows  d'exploitation connectivité réseau
Server 2003, 
Windows XP

LDP Kits de ressources  Outils de support  Teste le client  Aide contenue dans 

Windows 2000,  LDAP pour Active  les outils du kit de 
Windows  Directory ressources de 
Server 2003,  Windows 
Windows XP 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 

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

184
<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 

185
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 

186
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 ?

187
• 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/opsg
uide/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

188
• 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 http://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.)

189
 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 http://support.microsoft.com/?kbid=329194.

190
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 http://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.

191
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

192
• 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 

193
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 
http://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 http://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 http://support.microsoft.com/?kbid=811832

194
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

195
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 stats ou 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

196
    (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 

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

198
• 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.

199
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 http://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 ;

200
• 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 http://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

201
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 

202
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 

203
 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

204
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 :

205
• 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.  

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

207
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 

208
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 /debug pour 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:ipsec pour 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>" –o pour 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é.

209
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 130 pour 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 gpoassignedpolicy le 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 all pour 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 ipsec peut 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.

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

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

212
• 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.

213
• 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. 

214
 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 http://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 

215
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 

216
Authentication (Comment faire pour configurer une connexion L2TP/IPSec en utilisant 
l'authentification par clé pré­partagée)   à l'adresse http://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 
http://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. 

217
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 
http://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 

218
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>

219
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 

220
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

221
• 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é  Message de Windows 2000 indiquant que la modification d'une 
les SA formés avec l'ancienne  stratégie IPSec a entraîné la suppression des associations de 
stratégie 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  Cette condition peut être normale, causée par une surcharge de 
requêtes d'établissement  l'ordinateur, et/ou un grand nombre de tentatives de connexions 
d'association de sécurité en  client. Cela pourrait également être le résultat d'une attaque de 
attente, et démarre le mode de  refus de service contre IKE. Si tel est le cas, il y aura plusieurs 
prévention de refus de service. 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  IKE a récupéré après ce qu'il considérait comme une condition 
prévention de refus de service  d'attaque de refus de service, et a repris un fonctionnement 
et a repris un fonctionnement  normal.
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

222
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 

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

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

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

Haut de page

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

227
• 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.

Haut de page

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.

228
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 http://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
http://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 http://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

229
•  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

230