Réplication Active Directory via des pare-feu

Sur cette page

Réplication Active Directory via des pare-feu
Introduction
Appel RPC dynamique complet
Fonctionnement de l'appel RPC
Appel RPC limité
Encapsulage à l'intérieur du protocole IPSec
Promotion des contrôleurs de domaine grâce aux tunnels PPTP
Promotion des contrôleurs de domaine à l'aide du protocole IPSec et des certificats d'ordinateur
Comparaison des deux méthodes de promotion
Tunnels PPTP
Protocole IPSec avec certificats d'ordinateur
Configuration du mode de transport IPSec pour la communication CD à CD
Verrouillage supplémentaire des contrôleurs de domaine dans un réseau de type DMZ
Cette utilisation du protocole IPSec est-elle légitime ?

Réplication Active Directory via des pare-feu

Par Steve Riley

Consultant, Microsoft Telecommunications Practice

Mars 2001

Introduction

Les pare-feu présentent deux difficultés lors du déploiement d'une architecture distribuée du service d'annuaire Active Directory™ :

• La promotion initiale d'un serveur en tant que contrôleur de domaine.

• La réplication du trafic entre contrôleurs de domaine.

Active Directory utilise l'appel de procédure distante (RPC, Remote Procedure Call) pour la réplication entre contrôleurs de domaine. Le protocole SMTP (Simple Mail Transfer Protocol) peut être utilisé dans certaines situations, telles que la réplication d'un schéma, d'une configuration ou d'un catalogue global, mais pas dans un contexte d'attribution de noms de domaine, ce qui limite son utilité. Le défi est de parvenir à une réplication qui fonctionne correctement dans des environnements où une forêt d'annuaires est distribuée entre des réseaux internes, des réseaux de type DMZ (Demilitarized Zone) et des réseaux externes (c'est-à-dire vers Internet). Trois approches sont possibles :

• Ouvrir le pare-feu largement pour permettre le comportement dynamique natif de l'appel RPC.

• Limiter l'utilisation des ports TCP par l'appel RPC et ouvrir seulement un peu le pare-feu.

• Encapsuler le trafic entre contrôleurs de domaine (de CD à CD) à l'intérieur du protocole IPSec (IP Security Protocol) et ouvrir le pare-feu dans ce but.

Chaque approche présente des avantages et des inconvénients. Il y a en général plus d'inconvénients en haut de la liste et plus d'avantages en bas. Ainsi, bien que ce document décrive chacune des trois approches, il porte plus particulièrement sur celle qui implique le protocole IPSec, laquelle offre plus d'avantages que les deux autres.

Appel RPC dynamique complet

Bien qu'il soit possible de configurer votre environnement pour travailler de cette façon, il existe de nombreuses raisons de ne pas le faire, la plus importante étant que cela rend votre réseau non sécurisé. Cependant, cette approche demande moins de travail de configuration que les autres.

Pour permettre la réplication via un appel RPC dynamique, configurez votre pare-feu de la façon suivante :

C'est cette règle de "l'attribution dynamique des appels RPC" qui rend ce scénario non sécurisé. Parfois appelée "ports supérieurs TCP", cette règle doit autoriser le trafic entrant sur n'importe quel port au-delà de 1023. Si votre pare-feu autorise ce trafic, l'utilisation d'un pare-feu n'est pas réellement justifiée.

Si vous ne souhaitez pas activer les services DNS ou WINS, vous pouvez utiliser les fichiers HOSTS (pour DNS) et LMHOSTS (pour WINS) pour la résolution de nom. Ces fichiers sont stockés dans %SystemRoot%\system32\drivers\etc. Consultez-les pour en savoir plus sur leur utilisation.

Fonctionnement de l'appel RPC

Le service RPC se configure automatiquement dans le Registre avec un identificateur unique universel (UUID, Universally Unique Identifier). L'UUID est comparable à un identificateur global (GUID, Globally Unique Identifier). Les identificateurs UUID sont bien connus, uniques pour chaque service et communs à toutes les plates-formes. Lorsqu'un service RPC démarre, il obtient un port supérieur libre et inscrit ce port avec l'UUID. Certains services utilisent des ports supérieurs aléatoires ; d'autres tentent de toujours utiliser les mêmes ports supérieurs (si ceux-ci sont disponibles). L'attribution du port est statique durant toute la durée de vie du service.

Lorsqu'un client souhaite communiquer grâce à un service RPC particulier, il ne peut pas déterminer à l'avance sur quel port le service s'exécute. Il établit une connexion au service de mappage de port du serveur (sur 135) et demande le service désiré à l'aide de l'UUID du service. Le mappeur de port renvoie le numéro de port correspondant au client et ferme la connexion. Enfin, le client établit une nouvelle connexion avec le serveur grâce au numéro de port qu'il a reçu du mappeur de port.

Dans la mesure où il est impossible de connaître à l'avance le port qu'utilisera le service RPC, le pare-feu doit autoriser le trafic sur tous les ports supérieurs.

Appel RPC limité

Ce scénario offre une plus grande sécurité, mais il implique d'effectuer des modifications du Registre sur tous les contrôleurs de domaine. Les modifications du Registre peuvent être inscrites grâce à des outils du Kit de Ressources techniques de Microsoft® Windows® 2000, lesquels facilitent l'élimination des erreurs de configuration.

Vous devez décider d'un numéro de port fixe pour la réplication des appels RPC. L'IANA (Internet Assigned Numbers Authority) a réservé la plage de 49152 à 65535 pour l'utilisation par des attributions privées et dynamiques.

À l'aide de l'Éditeur du Registre, naviguez vers la clé de Registre suivante :

HKEY_LOCAL_MACHINE
SYSTEM\
CurrentControlSet\
Services\
NTDS\
Parameters\

Ajoutez une nouvelle valeur DWORD appelée Port TCP/IP (avec l'espace). Attribuez à la valeur le numéro de port que vous souhaitez utiliser (pensez à passer en mode décimal avant d'entrer les données). Effectuez cette opération sur tous les serveurs Active Directory. Vous devez les redémarrer pour valider les modifications.

À présent, configurez votre pare-feu de la façon suivante :

Remplacez <port-fixe> par le numéro de port que vous avez utilisé pour la valeur du Registre.

Comme précédemment, si vous ne souhaitez pas activer les services DNS ou WINS, vous pouvez utiliser les fichiers HOSTS (pour DNS) et LMHOSTS (pour WINS) pour la résolution de nom. Ces fichiers sont stockés dans %SystemRoot%\system32\drivers\etc. Consultez-les pour en savoir plus sur leur utilisation.

Vous avez toujours besoin du mappeur du point de sortie, car les clients ne savent pas que vous avez fixé le port. Le mappeur du point de sortie renvoie systématiquement votre port fixe lorsque les clients demandent le numéro de port associé à l'UUID RPC d'Active Directory.

Vous trouverez ci-dessous du texte que vous pouvez importer dans le Registre. Il définit le port à 49152. Copiez-le dans le Presse-papiers, collez-le dans un nouveau document Bloc-notes, enregistrez le fichier avec l'extension .REG, puis double-cliquez sur ce fichier à partir de l'Explorateur Windows. Si vous souhaitez utiliser un port différent, convertissez le numéro décimal en hexadécimal à l'aide de la Calculatrice de Windows (en mode scientifique). Pensez à faire précéder la valeur de quatre zéros, comme présenté dans l'exemple ci-dessous.

     Windows Registry Editor Version 5.00
     [HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NTDS \Parameters]
     "TCP/IP Port"=dword:0000c000

Encapsulage à l'intérieur du protocole IPSec

Le protocole IPSec permet d'encapsuler et d'acheminer facilement le trafic RPC via un pare-feu. En plus de simplifier le transport des appels RPC, le protocole IPSec améliore également la sécurité entre les contrôleurs de domaine grâce à sa fonctionnalité d'authentification mutuelle : grâce à Kerberos ou à des certificats d'ordinateur, les contrôleurs de domaine pourront "savoir" avec qui ils communiquent avant tout échange réel d'informations.

Ce document vous explique comment créer une stratégie IPSec appropriée grâce à l'interface de la console MMC (Microsoft Management Console). Vous pouvez écrire une nouvelle stratégie grâce à IPSECPOL.EXE, outil disponible dans le Kit de Ressources techniques de Windows 2000. Prenez soin de lire attentivement la documentation de l'outil IPSECPOL.EXE et assurez-vous de bien l'avoir comprise avant de l'utiliser (contrairement à l'interface utilisateur graphique, la ligne de commande n'offre qu'une vérification très élémentaire de la cohérence).

Avant de commencer, vous devez faire le choix suivant : utiliser des certificats pour l'authentification IPSec ou utiliser l'authentification Kerberos2 intégrée à Windows 2000. Pour l'authentification Kerberos, les deux ordinateurs doivent déjà se trouver dans le même domaine ; ainsi, si vous préférez Kerberos, vous devrez utiliser autre chose que le protocole IPSec pour la phase de promotion du contrôleur de domaine (DCPROMO), car le serveur cible n'est pas encore membre du domaine. Les tunnels PPTP (Point-to-Point Tunneling Protocol) fonctionnent bien pour cela ; ils sont documentés ici. Si vous préférez utiliser des certificats pour l'authentification, vous devez obtenir un certificat pour chaque contrôleur de domaine qui participera à la réplication IPSec. Veuillez consultez la page d'informations techniques de Windows 2000 Server pour consulter des documents qui expliquent comment construire une autorité de certification Windows 2000 et comment configurer votre domaine pour l'inscription automatique des certificats d'ordinateur.

Pour la réplication IPSec et la promotion IPSec ou PPTP, configurez votre pare-feu de la façon suivante :

Notez que le protocole IPSec ne fonctionne pas avec les périphériques de traduction d'adresses réseau (NAT, Network Address Translation). Dans la mesure où le protocole IPSec utilise des adresses IP lors du calcul du total de contrôle des paquets, les paquets IPSec dont les adresses source ont été modifiées par la NAT sont ignorés lorsqu'ils arrivent à destination.

Promotion des contrôleurs de domaine grâce aux tunnels PPTP

Si vous choisissez d'utiliser des tunnels PPTP pour la phase de promotion, vous devez configurer le service Routage et accès distant (RRAS, Routing and Remote Access) dans le réseau interne. Le service RRAS peut être exécuté sur un contrôleur de domaine interne ou sur un serveur distinct. Pour plus de simplicité, il est préférable que le serveur RRAS existe sur le même sous-réseau que le contrôleur de domaine racine (aucune maintenance des itinéraires statiques n'est alors nécessaire).

Pour configurer le service RRAS :

• Sélectionnez Démarrer | Programmes | Outils d'administration | Routage et accès distant.

• Cliquez à l'aide du bouton droit sur votre serveur dans le volet gauche, puis cliquez sur Configurer et activer le routage et l'accès distant. L'Assistant Installation du serveur de routage et d'accès distant démarre.

• Cliquez sur Serveur configuré manuellement.

  

  Figure 1 Assistant Installation du serveur de routage et d'accès distant.

• Terminez l'Assistant et démarrez le service lorsque celui-ci vous y invite.

La console MMC doit alors se présenter de la façon suivante, après que vous avez cliqué sur le + situé à côté du nom du serveur.

Figure 2 Le service RRAS après configuration et activation.

Après avoir configuré et activé le service RRAS, procédez aux modifications suivantes :

• Cliquez à l'aide du bouton droit sur le serveur, puis cliquez sur Propriétés. Sélectionnez l'onglet IP. Cliquez sur Pool d'adresses statique. Saisissez une plage d'adresses IP dans le même sous-réseau que le contrôleur de domaine interne. Quelques adresses (peut-être 9) suffisent. Fermez toutes les boîtes de dialogue.

  

  Figure 3 Propriétés du serveur, attribution des adresses IP.

• Cliquez à l'aide du bouton droit sur Ports (dans le volet gauche de la console MMC), puis cliquez sur Propriétés. Configurez Parallèle direct de façon à interdire les accès distants et les connexions de numérotation à la demande ; si vous avez des modems sur le serveur (comme dans l'exemple ci-dessous), configurez-les de la même façon. Configurez Numérotation à la demande (L2TP) de façon à ce qu'il n'y ait aucun port et que les accès distants et les connexions de numérotation à la demande soient interdits. Il n'est pas nécessaire d'effectuer des modifications dans Numérotation à la demande (PPTP) à moins que vous n'ayez besoin de plus de cinq ports. Fermez toutes les boîtes de dialogue.

  

  Figure 4 Propriétés des ports.

À présent, le service RRAS accepte les connexions PPTP entrantes pour la promotion des contrôleurs de domaine.

Avant de promouvoir un réseau de type DMZ ou un serveur externe en tant que contrôleur de domaine, établissez un tunnel PPTP vers le serveur RRAS interne. Ouvrez la page Propriétés de Favoris réseau et cliquez sur Établir une nouvelle connexion. Dans l'Assistant :

• Cliquez sur Connexion à un réseau privé via Internet.

• N'établissez aucune connexion initiale.

• Saisissez l'adresse IP du serveur RRAS interne comme destination.

• Définissez la disponibilité de connexion sur Pour tous les utilisateurs.

• Ne partagez pas la connexion.

• Donnez un nom quelconque à la connexion.

La boîte de dialogue Connexion à s'ouvre alors. Avant de vous connecter, cliquez sur le bouton Propriétés. Cliquez sur l'onglet Options, puis cliquez sur Inclure le domaine d'ouverture de session Windows. Fermez la boîte de dialogue.

À présent, ouvrez une session sur le serveur RRAS à l'aide des informations d'identification d'administrateur de l'entreprise (l'administrateur du domaine racine). Lorsque le serveur est connecté, vous pouvez lancer DCPROMO. Vous devez redémarrer DCPROMO à la fin du processus ; cela déconnectera également le tunnel PPTP. Dans la mesure où vous n'avez plus besoin du tunnel, vous pouvez supprimer le connectoid.

Promotion des contrôleurs de domaine à l'aide du protocole IPSec et des certificats d'ordinateur

Considérez cette approche si aucun des cas suivants ne vous concerne :

• Vous ne souhaitez pas utiliser le protocole PPTP pour la promotion.

• Vous préférez interdire Kerberos via le pare-feu.

• Vous cherchez des raisons de commencer le déploiement d'une infrastructure PKI.

Vous devez installer des certificats sur les contrôleurs de domaine pour qu'ils puissent effectuer une authentification IPSec. Tous les certificats doivent être signés par la même autorité de certification. Windows 2000 inclut une autorité de certification compatible RFC (Request for Comments) qui fonctionne très bien dans ce cas. À l'aide des stratégies de groupe, vous pouvez configurer le domaine de façon à inscrire automatiquement des ordinateurs membre avec les certificats d'ordinateur. Alors que le protocole IPSec travaille avec des certificats provenant de n'importe quelle autorité de certification, l'inscription automatique nécessite une autorité de certification Windows 2000. Si vous disposez déjà d'une infrastructure PKI, l'autorité de certification Windows 2000 peut être configurée comme une autorité secondaire par l'autorité émettrice. Pour plus de détails, veuillez consulter la documentation, notamment les documents d'aide mentionnés plus haut.

Si vous décidez de suivre cette solution, vous avez alors la possibilité d'inclure le trafic Kerberos dans le protocole IPSec. Normalement, certains types de trafic sont exempts de traitement du mode de transport IPSec :

• Diffusion : ne peut pas être classifiée par les filtres IPSec parce que l'expéditeur ne connaît pas tous les destinataires ;

• Multidiffusion : voir diffusion ;

• RSVP (Resource Reservation Protocol), protocole IP 46 : doit être exempt pour permettre la qualité du marquage de service ; cependant, les paquets IPSec peuvent être transportés par les paquets RSVP ;

• IKE (Internet Key Exchange) : le protocole IPSec utilise IKE pour établir les paramètres de sécurité et procéder à l'échange de clés. Les négociations IKE sont déjà cryptées lorsque cela est nécessaire.

• Kerberos : le protocole d'authentification natif de Windows 2000, utilisé également par le protocole IPSec pour l'authentification des ordinateurs. Le protocole Kerberos lui-même est déjà sécurisé.

Même si un filtre IPSec spécifie que tout le trafic entre deux ordinateurs doit être encapsulé, les types de trafic précédents sont exempts de traitement IPSec.

Windows 2000 Service Pack 1 a introduit une clé de Registre qui modifie quelque peu ce comportement. À l'aide de l'Éditeur du Registre, naviguez vers la clé de Registre suivante :

HKEY_LOCAL_MACHINE
SYSTEM\
CurrentControlSet\
Services\
IPSEC\

Ajoutez une nouvelle valeur DWORD appelée NoDefaultExempt et définissez la valeur à 1. Les valeurs suivantes sont autorisées :

0 : les exemptions par défaut s'appliquent
1 : Les protocoles Kerberos et RSVP sont inclus dans le traitement IPSec

Il est intéressant d'inclure le protocole Kerberos à l'intérieur du protocole IPSec après la promotion de l'ordinateur en tant que contrôleur de domaine (il est donc membre du domaine). Cependant, pour un ordinateur qui n'est pas encore membre d'un domaine et que vous souhaitez promouvoir comme contrôleur de domaine, vous ne pouvez pas établir le protocole IPSec à l'aide du protocole Kerberos. Vous devez utiliser une autre forme d'authentification. C'est pour cela que vous utilisez les certificats d'ordinateur.

Vous trouverez ci-dessous du texte que vous pouvez importer dans le Registre. Il définit la valeur de NoDefaultExempt à 1. Copiez-le dans le Presse-papiers, collez-le dans un nouveau document Bloc-notes, enregistrez le fichier avec l'extension .REG, puis double-cliquez sur ce fichier à partir de l'Explorateur Windows.

     Windows Registry Editor Version 5.00

     [HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \IPSEC]
     "NoDefaultExempt"=dword:00000001

Comprenez bien ce qui suit avant de poursuivre. Si vous décidez de suivre cette approche, vous devrez alors effectuer toutes les étapes de la section suivante "Configuration du mode de transport IPSec pour la communication CD à CD", avant d'exécuter DCPROMO. Voici la démarche :

1. Si vous souhaitez inclure le protocole Kerberos dans le traitement IPSec, ajoutez la clé de Registre précédente.

2. Installez une autorité de certification.

3. Procurez-vous des certificats d'ordinateur pour tous les contrôleurs de domaine, existants ou candidats.

4. Suivez les étapes décrites dans la section "Configuration du mode de transport IPSec pour la communication CD à CD".

5. Exécutez DCPROMO sur les contrôleurs de domaine candidats.

6. C'est terminé, laissez tout en l'état ; la configuration IPSec existante est en cours de réplication.

Comparaison des deux méthodes de promotion

Voici les différences entre les deux méthodes présentées plus haut.

Tunnels PPTP

• Facile et rapide.

• Nécessite le pare-feu pour autoriser le protocole Kerberos.

• Nécessite le pare-feu pour autoriser le protocole PPTP.

• Sépare les fonctions de promotion et de réplication (configure le protocole PPTP pour la promotion, puis configure le protocole IPSec pour la réplication en cours.

Protocole IPSec avec certificats d'ordinateur

• Constitue une bonne raison de déployer une infrastructure PKI.

• Permet au protocole Kerberos d'être inclus dans le traitement IPSec.

• Moins de protocoles via le pare-feu (pas PPTP, éventuellement pas Kerberos).

• Une seule étape pour la promotion et la réplication en cours.

Bien qu'aucune méthode ne soit préférable, l'utilisation du protocole IPSec avec des certificats d'ordinateur semble être une approche plus "avant-gardiste", en particulier parce que la plupart des organisations prévoient de déployer des infrastructures PKI.

Configuration du mode de transport IPSec pour la communication CD à CD

Il faut à présent configurer les stratégies sur tous les contrôleurs de domaine pour qu'ils puissent utiliser le mode de transport IPSec pour communiquer entre eux. Avec cette configuration, vous ne devez autoriser que le protocole IPSec et les protocoles associés via le pare-feu, ce qui est plus simple et plus tolérable. Notez que vous ne créez pas de tunnels IPSec. Au lieu de cela, vous utilisez le mode de transport IPSec (IPSec de bout en bout) pour sécuriser les sessions de communication entre les serveurs.

Sur chaque contrôleur de domaine, vous devez créer une stratégie IPSec pour la réplication, avec une liste de filtres IP et une action de filtrage correspondantes. Sélectionnez Démarrer | Programmes | Outils d'administration | Stratégie de sécurité locale.

Figure 5 Paramètres de sécurité locale.

Ensuite, cliquez sur Stratégies de sécurité IP (dans le volet gauche de la console MMC). Cela affiche les stratégies par défaut, auxquelles vous pouvez en ajouter une nouvelle pour la réplication. Cependant, vous devez tout d'abord créer la liste de filtres et l'action de filtrage.

La liste de filtres indique quels ports, protocoles et adresses IP déclenchent l'application du protocole IPSec. Vous souhaitez sécuriser tout le trafic entre les contrôleurs de domaine uniquement, et non pas n'importe quel trafic entre un contrôleur de domaine et un autre ordinateur. Cliquez à l'aide du bouton droit dans le volet droit de la console MMC et cliquez sur Gérer les listes de filtres IP et les actions de filtrage. Vous accédez à l'onglet Gestion de listes de filtres IP. Une liste de filtres est composée de plusieurs filtres ; vous devez créer un filtre pour chacun des serveurs avec lequel celui-ci va se répliquer. Ainsi, une seule liste de filtres suffit et cette liste contient les filtres pour tous les contrôleurs de domaine.

Figure 6 Listes de filtres IP et actions de filtrage, onglet listes de filtres.

Cliquez sur le bouton Ajouter pour créer une nouvelle liste de filtres. Nommez la liste de filtres Réplication CD. Cliquez sur le bouton Ajouter pour créer un nouveau filtre, puis effectuez les étapes suivantes pour terminer l'Assistant :

• Sélectionnez Mon adresse IP comme adresse source.

• Sélectionnez Une adresse IP spécifique comme adresse de destination, puis saisissez l'adresse IP de l'autre serveur.

• Sélectionnez N'importe quelle adresse IP comme type de protocole. Cela configure le filtre de façon à ce que tout le trafic entre les deux ordinateurs soit acheminé par le protocole IPSec4.

Figure 7 Liste de filtres pour la réplication des contrôleurs de domaine.

Ajoutez des filtres supplémentaires pour les autres contrôleurs de domaine. Lorsque vous avez terminé, fermez la boîte de dialogue.

Ensuite, vous souhaitez définir une action de filtrage. Sélectionnez l'onglet Gérer les actions du filtre, puis cliquez sur le bouton Ajouter pour créer une nouvelle action. Dans l'Assistant :

• Nommez l'action Réplication CD.

• Cliquez sur Négocier la sécurité.

• Cliquez sur Ne pas communiquer avec des ordinateurs qui ne prennent pas en charge IPSec.

• Cliquez sur Élevée (transport de données sécurisé encapsulé).

• Activez la case à cocher Modifier les propriétés (vous devrez apporter des modifications plus tard).

• Cliquez sur le bouton Terminer.

Dans la boîte de dialogue Propriétés, désactivez la case à cocher Accepter les communications non sécurisées mais toujours répondre en utilisant IPSec. Vous ne souhaitez pas que le serveur réponde à toutes les communications non sécurisées. Ceci ne s'applique bien évidemment qu'aux ordinateurs qui font partie de la liste de filtres IP correspondante ; vous associerez la liste de filtres et l'action de filtrage à une stratégie dans un instant. Fermez toutes les boîtes de dialogue.

Figure 8 Action de filtrage pour la réplication des contrôleurs de domaine.

Vous pouvez à présent créer la stratégie IPSec. Cliquez à l'aide du bouton droit dans le volet droit de la console MMC et cliquez sur Créer une stratégie de sécurité IP. Dans l'Assistant :

• Nommez la stratégie Réplication du contrôleur de domaine.

• Désactivez la case à cocher Activer la règle de réponse par défaut.

• Assurez-vous que la case à cocher Modifier les propriétés est activée et fermez l'Assistant.

La stratégie existe, mais ne contient aucune règle.

Figure 9 Stratégie IPSec pour la réplication des contrôleurs de domaine.

Vous créez une règle en associant la liste de filtres et l'action de filtrage que vous avez créées précédemment. Cliquez sur le bouton Ajouter pour définir une nouvelle règle. Dans l'Assistant :

• Sélectionnez l'option Cette règle ne spécifie aucun tunnel.

• Sélectionnez Réseau local pour le type de réseau.

  Choisissez une méthode d'authentification :

  • Sélectionnez Valeurs par défaut de Windows 2000 (protocole Kerberos V5) si vous avez utilisé des tunnels PPTP pour DCPROMO, ou

  • Sélectionnez Utiliser un certificat émis par cette Autorité de certification si vous utilisez des certificats. Cliquez ensuite sur Parcourir et sélectionnez l'autorité de certification qui a émis le certificat d'ordinateur installé sur l'ordinateur.

• Une liste de filtres IP vous est présentée. Dans la liste, sélectionnez la liste de filtres que vous avez créée précédemment, à savoir Réplication CD.

• Une liste d'actions de filtrage vous est présentée. Sélectionnez, dans la liste d'actions de filtrage, celle que vous avez créée précédemment, à savoir Réplication CD.

• Ne modifiez pas les propriétés. Terminez l'Assistant.

Votre stratégie doit alors se présenter de la façon suivante (la colonne d'authentification indique "Certificat" si c'est la méthode que vous avez sélectionnée).

Figure 10 Stratégie pour la réplication des contrôleurs de domaine terminée.

Enfin, vous devez activer (c'est-à-dire attribuer) cette stratégie.

• Cliquez à l'aide du bouton droit sur la stratégie Réplication du contrôleur de domaine.

• Cliquez sur Attribuer.

Figure 11 Stratégie de contrôleur de domaine attribuée.

Le traitement IPSec s'exécute immédiatement. Il n'est pas nécessaire de redémarrer le serveur.

Chaque contrôleur de domaine a besoin d'une stratégie IPSec similaire. Que le contrôleur se trouve dans le réseau interne, dans le réseau de type DMZ ou dans le réseau externe, vous devez configurer sa stratégie IPSec de façon à ce que toutes les communications avec tous les autres contrôleurs de domaine passent par le protocole IPSec. Cela permet non seulement au vérificateur de cohérence de la connaissance d'offrir une topologie de réplication qui ignore le pare-feu, mais cela permet également de sécuriser toute réplication IPSec entre tous les serveurs.

Vérification de la stratégie IPSec. Assurez-vous de tester les stratégies que vous avez créées. Après avoir créé et attribué une stratégie sur deux ordinateurs au moins, vous pouvez utiliser l'utilitaire IPSECMON.EXE pour observer le moment où les ordinateurs établissent l'association de sécurité IPSec :

• Ouvrez une fenêtre de commande.

• Entrez la commande ipsecmon. Un utilitaire graphique démarre, établissant une liste des associations de sécurité en cours et mentionnant la quantité de trafic authentifié et/ou crypté qui est passée par le serveur. Il n'y aura probablement pas d'administrateurs système instantanément, à moins que les contrôleurs de domaine n'aient commencé à échanger des informations.

• Cliquez sur le bouton Options et passez le taux de rafraîchissement à une seconde.

• Revenez à l'invite de commande et exécutez la commande "ping" sur un autre contrôleur de domaine auquel une stratégie IPSec a également été attribuée. Utilisez l'indicateur -t pour exécuter la commande "ping" de façon continue jusqu'à son arrêt (ping -t adresse_ip ).

• Cherchez des réponses "Négociation de la sécurité IP" (les ordinateurs échangent des clés de cryptage et établissent leurs associations de sécurité). Vous trouverez enfin des réponses normales. L'établissement des associations de sécurité dans les deux sens nécessite 10 à 12 secondes.

• Appuyez sur CTRL +C pour arrêter.

Verrouillage supplémentaire des contrôleurs de domaine dans un réseau de type DMZ

Les réseaux qui prennent en charge le commerce électronique et les connexions extranet peuvent nécessiter un contrôleur de domaine dans le réseau DMZ. Même si au premier abord vous pensez que cela peut créer des problèmes de sécurité, le protocole IPSec peut être utile ici aussi. Il est possible de créer des filtres de paquets sélectifs grâce aux fonctionnalités de type autorisation/blocage des règles IPSec. Veuillez consulter le document "Using IPSec to Lock Down a Server" . Vous pouvez associer telle approche avec telle information pour créer une stratégie IPSec qui permet uniquement de sécuriser la communication entre contrôleurs de domaine et qui empêche tout autre trafic de parvenir au contrôleur de domaine dans le réseau DMZ.

Cette utilisation du protocole IPSec est-elle légitime ?

Les concepteurs du protocole IPSec n'avaient probablement pas prévu que ce protocole deviendrait un excellent moyen d'encapsuler le trafic complexe pour l'acheminer en toute sécurité de réseau en réseau. Le moteur de stratégie IPSec de Windows 2000 peut être utilisé pour créer des règles très sélectives qui spécifient le trafic autorisé, le trafic bloqué ou le trafic sécurisé entre les hôtes. Dans ce scénario, nous l'utilisons pour sécuriser tout le trafic entre les hôtes connus (contrôleurs de domaine spécifiques) tout en autorisant le trafic de et vers ces hôtes.

1 Le protocole TCP est utilisé pour les transferts de zone et dès que les réponses aux questions excèdent 512 octets.

2 Ce document ne traite pas de l'utilisation des clés pré-partagées. L'authentification des clés pré-partagées est incluse dans Windows 2000 uniquement pour la compatibilité avec les autres implémentations du protocole IPSec et pour la conformité aux RFC IPSec. Nous ne recommandons en aucun cas l'utilisation de clés pré-partagées dans un environnement de production du fait des risques de sécurité associés à l'authentification de type secret partagé.

3 Si vous décidez d'utiliser des certificats plutôt que le protocole Kerberos pour l'authentification IPSec, vous pouvez configurer les serveurs pour qu'ils acheminent le trafic Kerberos via le protocole IPSec. Cela sera traité plus en détail plus loin. Quel que soit le mode d'authentification, le protocole Kerberos reste nécessaire entre les contrôleurs de domaine.

4 C'est-à-dire, tout le trafic à l'exception de celui qui est exempté de traitement IPSec, comme cela a été étudié plus haut.

Dernière mise à jour le mardi 15 mai 2001

Pour en savoir plus

• Les informations de TechNet concernant la sécurité

• Le dossier Active Directory