Configuration de points d'accès sans fil sécurisés

Paru le 29 août 2006

Sur cette page

Introduction
Définition
Enjeux
Solutions
Résumé

Introduction

Bienvenue dans ce document de la collection Guides de sécurité pour les entreprises de taille moyenne. Microsoft espère que les informations suivantes vous aideront à mettre en place un environnement informatique à la fois plus sûr et plus productif.

Synthèse

Dans le monde de l'entreprise, la technologie de réseau sans fil (WLAN) fait l'objet de nombreuses controverses. La plupart des entreprises ont d'ores et déjà déployé un WLAN ou équivalent, ou au moins débattu des avantages et des inconvénients de la technologie sans fil. Dans tous les cas, les entreprises qui ont déployé des réseaux sans fil sont préoccupées par la sécurité de leur réseau et celles qui ont évité cette technologie s'interrogent quant aux gains de productivité et aux économies d'infrastructure qu'elles auraient pu réaliser.

La sécurité des technologies sans fil inquiète de façon légitime les décideurs technologiques. En effet, suite aux défauts très médiatisés découverts dans la première génération de protocoles de sécurité WLAN IEEE 802.11, la technologie sans fil est toujours considérée comme une technologie non sécurisée. Au cours des dernières années, de nombreuses solutions ont été mises au point. Toutefois, la plupart des solutions conçues pour résoudre les problèmes de sécurité des technologies sans fil étaient trop onéreuses ou possédaient leurs propres imperfections.

De nombreux développements ont vu le jour car les réseaux sans fil d'hier, comme la technologie, ont été améliorés pour permettre des vitesses supérieures et une plus grande fiabilité, tout comme les normes de sécurisation des transmissions sans fil. Les protocoles de sécurité sans fil les plus récents, WPA et WPA2, basés sur la norme IEEE 802.11i, offrent une protection renforcée du trafic sans fil même dans des environnements de sécurité rigoureux. Ces nouvelles normes, lorsqu'elles sont configurées correctement, sont beaucoup plus sûres et peuvent être utilisées en toute fiabilité dans un environnement d'entreprise de taille moyenne.

Présentation

Cet article est divisé en quatre sections principales qui présentent les informations nécessaires à la conception et à l'implémentation d'une solution efficace de sécurisation des réseaux sans fil d'entreprises de taille moyenne. Ces sections sont les suivantes :

Introduction. Cette section comprend un résumé du document, une présentation de sa structure, ainsi que des informations relatives au public concerné.
Définition. Cette section donne des informations et des définitions utiles à la compréhension de la terminologie utilisée dans ce document.
Enjeux. Cette section présente les problèmes courants auxquels sont confrontées les entreprises de taille moyenne désireuses d'implémenter un réseau sans fil et introduit la solution qui fait l'objet de ce document.
Solutions. Cette section fournit des instructions pas-à-pas spécifiques et détaillées permettant de planifier, de développer, de déployer et de prendre en charge une infrastructure sans fil sécurisée. La section Solutions est divisée en trois sous-sections principales :
- Évaluation de la sécurité WLAN. Cette section étudie les prérequis et les options éventuelles afin de constituer une base pour le développement d'un projet de solution.
- Développer une solution WLAN sécurisée. Cette section exploite les informations obtenues lors de la phase d'évaluation afin de définir et de créer un plan, et de développer la base de la solution.
- Déploiement et gestion. Cette section présente la solution pas-à-pas de façon détaillée et fournit des informations afin d'aider à la gestion et à la validation de la solution de réseau sans fil sécurisé présentée dans ce document.

Personnes concernées par ce guide

Ce document s'adresse à l'équipe technique, aux implémenteurs de technologie et aux responsables techniques des entreprises de taille moyenne souhaitant utiliser l'accès WPA (Wi-Fi Protected Access) ou WPA2 (Wi-Fi Protected Access 2) pour sécuriser leur infrastructure sans fil. Dans ce document, nous partons du principe que le lecteur possède des connaissances techniques générales sur les périphériques sans fil, les concepts réseau de base, Microsoft® Windows Server™ 2003, le service d'authentification Internet (IAS), les services de certificat, le service d'annuaire Active Directory®, ainsi que sur la configuration et l'application de Stratégie de groupe.

Haut de page

Définition

Le lecteur doit comprendre et connaître les termes et concepts suivants, utilisés dans ce document.

AES. Le protocole AES (Advanced Encryption Standard) utilise une technique de chiffrement de données par bloc et fait partie intégrante de WPA2.

EAP. Le protocole EAP (Extensible Authentication Protocol) est une norme 802.1X qui permet aux développeurs de faire circuler des données d'authentification entre les serveurs RADIUS et les points d'accès sans fil. Le protocole EAP inclut plusieurs variantes et notamment les suivantes : EAP MD5, EAP-TLS, EAP-TTLS, LEAP et PEAP.

EAP-TLS. La norme EAP-TLS (Transport Layer Security) a été développée sous la norme 802.1X par Microsoft afin de pouvoir utiliser des certificats numériques pour l'authentification. C'est aujourd'hui la norme utilisée pour l'authentification 802.11i.

IEEE 802.1X. La norme IEEE 802.1X gère le processus d'encapsulation EAP qui se produit entre les suppliants (clients), les authentificateurs (points d'accès sans fil) et les serveurs d'authentification (RADIUS).

IEEE 802.11. La norme IEEE 802.11 gère les communications réseau sans fil (« aériennes »). Elle comprend plusieurs spécifications : de la norme 802.11g, qui fournit un trafic à plus de 20 Mbits/s dans la bande 2,4 GHz, à la norme 802.11i, qui gère l'authentification et le chiffrement WPA2.

IEEE 802.11i. L'amendement IEEE 802.11i à la norme 802.11 spécifie des méthodes de sécurité (WPA2) qui utilisent le chiffrement par bloc AES pour sécuriser les processus d'authentification d'origine (EAP) afin de résoudre les problèmes d'inadéquation précédents des normes et spécifications sur la sécurité des réseaux sans fil.

MS-CHAP v2. Le protocole MS-CHAP v2 (Microsoft Challenge Handshake Authentication Protocol version 2) est un protocole basé sur les mots de passe, la stimulation/réponse et l'authentification mutuelle. Il utilise le chiffrement MD4 et DES. Pour sécuriser les communications sans fil, il est utilisé avec PEAP (PEAP-MS-CHAP v2).

PEAP. Le protocole PEAP (Protected Extensible Authentication Protocol) est un type de communication EAP qui résout les problèmes de sécurité associés aux transmissions EAP en texte clair, en créant un canal sécurisé chiffré et protégé par TLS.

SSID. L'identificateur SSID (Service set Identifier) correspond au nom attribué à un WLAN et utilisé par le client pour identifier l'exactitude des paramètres et des informations d'identification nécessaires pour accéder à un WLAN.

TKIP. Le protocole TKIP (Temporal Key Integrity Protocol) fait partie intégrante de la norme de chiffrement WPA pour les réseaux sans fil. Le protocole TKIP représente la nouvelle génération du protocole WEP. Il fournit un mélange de clés par paquet pour résoudre les problèmes rencontrés dans la norme WEP.

WEP. Le protocole WEP (Wired Equivalent Privacy) fait partie intégrante de la norme IEEE 802.11. Il utilise le chiffrement RC4 64 ou 128 bits. En 2001, d'importantes failles ont été découvertes dans cette norme. Elles étaient dues, pour l'essentiel, à la longueur du vecteur d'initialisation du chiffrement du flux RC4, autorisant un décodage passif de la clé RC4.

WLAN. Réseau local sans fil.

WPA. Afin de résoudre les problèmes découverts dans la norme WEP, la norme WPA (Wi-Fi Protected Access) a été introduite en 2003 en tant que sous-ensemble interopérable de spécifications de sécurité des réseaux sans fil de la norme IEEE 802.11. Cette norme possède des fonctions d'authentification et utilise TKIP pour le chiffrement des données.

WPA2. En septembre 2004, la Wi-Fi Alliance a créé la norme WPA2. Il s'agit d'une version certifiée interopérable de la spécification IEEE 802.11i complète ratifiée en juin 2004. Comme son prédécesseur, la norme WPA2 prend en charge l'authentification IEEE 802.1X/EAP ou la technologie PSK mais inclut AES (Advanced Encryption Standard), un nouveau mécanisme de chiffrement avancé qui utilise le protocole CCMP (Counter-Mode/CBC-MAC Protocol).

Haut de page

Enjeux

Bon nombre d'entreprises reconnaissent que la technologie sans fil présente de nombreux avantages et qu'elle permet notamment d'améliorer la productivité et la collaboration, mais hésitent à implémenter cette technologie en raison des imperfections qu'elle semble présenter dans un environnement d'entreprise. La grande variété de méthodes proposées pour résoudre les problèmes de sécurité des communications sans fil et les différents rapports relatifs à leur efficacité peuvent être encore plus déroutants.

La technologie sans fil suscite bien des interrogations aux entreprises de taille moyenne, qui remettent en cause la sécurisation du déploiement, mais également l'intérêt de ce déploiement. Les questions les plus courantes soulevées par les réseaux sans fil et abordées dans ce document sont les suivantes :

Choisir d'implémenter un WLAN
Connaître les risques et palliatifs
Apprendre à sécuriser un environnement WLAN
Définir des options de sécurité WLAN appropriées
Valider le niveau de sécurité d'un réseau sans fil
Intégrer des ressources existantes à une solution de sécurité sans fil
Détecter et empêcher les connexions de périphériques sans fil non autorisés

Haut de page

Solutions

Cette section présente la conception, le développement, l'implémentation et la prise en charge de solutions sans fil sécurisées pouvant être déployées dans des environnements d'entreprise de taille moyenne. Comme nous l'avons évoqué précédemment, la technologie sans fil suscite bien des interrogations. Chacune de ces interrogations sera étudiée afin d'exploiter les avantages des réseaux sans fil de la façon la plus sûre et la plus efficace possible.

Évaluation de la sécurité WLAN

Bien que la technologie sans fil ait acquis une maturité qui permet désormais de mettre au point des réseaux suffisamment rapides et sécurisés pour être déployés dans un environnement d'entreprise de taille moyenne, il existe un grand nombre de facteurs à prendre en compte et de méthodes disponibles pour sécuriser un réseau sans fil. Cette section étudie les méthodes les plus courantes de sécurisation des réseaux sans fil, donne des conseils permettant de déterminer la meilleure solution en fonction d'un environnement donné et propose des arguments en faveur et contre chaque approche.

Avantages du réseau sans fil

Les avantages qu'il est possible de retirer de l'implémentation de la technologie WLAN entrent dans les deux catégories suivantes : avantages commerciaux et avantages opérationnels. Les avantages opérationnels incluent une diminution du coût de gestion et des investissements, alors que les avantages commerciaux incluent une augmentation de la productivité, une efficacité accrue des processus commerciaux et de plus grandes opportunités de création de nouvelles fonctions commerciales.

Avantages commerciaux

Les principaux avantages commerciaux qui découlent de l'utilisation de la technologie WLAN sont dûs à une amélioration de la flexibilité et de la mobilité des employés. Avec un réseau sans fil, les employés ne sont plus cantonnés à leur poste de travail. Ils peuvent se déplacer en toute liberté dans l'ensemble du bureau. Ce type de « liberté » peut créer les avantages suivants :

Les membres de la force de travail mobile d'une entreprise (les vendeurs, par exemple) peuvent facilement passer d'un bureau à un autre ou revenir du terrain et se connecter en toute transparence au réseau de l'entreprise. La connectivité est quasi instantanée. Il n'est plus nécessaire de partir à la recherche d'un port réseau disponible ou de démêler des câbles. Le gain de temps est considérable et les problèmes associés aux réseaux câblés disparaissent.
Les techniciens peuvent rester en contact permanent avec leurs systèmes, quel que soit l'endroit du bureau où ils se trouvent, en réunion ou loin de leurs postes de travail. Grâce à la technologie mobile (ordinateurs portables, Tablet PC ou ordinateurs de poche), le personnel informatique de l'entreprise peut répondre instantanément à tout besoin.
L'information est toujours à portée de main. Les réunions ne sont plus retardées par des personnes qui ont à faire des copies ou à récupérer des rapports depuis leur poste de travail. Les présentations sont exposées sur l'ordinateur plutôt que sur un rétroprojecteur flou. Il est également possible lors des réunions d'avoir recours aux technologies interactives pour collaborer avec des bureaux et des travailleurs distants.
La flexibilité de l'entreprise est considérablement accrue dans la mesure où des modifications structurelles peuvent être rapidement et facilement implémentées. Il est même possible de restructurer l'ensemble des bureaux car le câblage réseau ne constitue plus un problème.
La technologie sans fil ouvre un nouvel éventail d'applications et de solutions technologiques aux entreprises. Des périphériques comme les assistants numériques personnels (PDA) et les Tablet PC peuvent être intégrés en toute transparence à un environnement réseau. Les employés et fonctions commerciales autrefois privés d'informatique peuvent désormais profiter de la connectivité réseau. Les coins repas et cantines, points de rassemblement, chambres d'hôpitaux, points de vente, restaurants et terminaux industriels peuvent permettre d'atteindre de nouveaux gains de productivité grâce à des solutions technologiques simples d'accès.

Avantages opérationnels

Les avantages opérationnels de la technologie sans fil sont également variés et dépendent du type d'activité et des locaux de l'entreprise. Parmi les bénéfices figurent notamment les suivants :

Les coûts de mise en place du réseau sont considérablement réduits car la dépendance aux infrastructures réseau câblées est réduite. Des endroits où la connectivité réseau était impossible sont désormais accessibles à moindre coût via la technologie WLAN, notamment des zones extérieures ou des zones de bureau séparées.
L'évolutivité du réseau permet une adaptation plus réactive et efficace aux différents besoins. Pour résoudre des problèmes de congestion par exemple, il est bien plus simple de déployer ou de déplacer des points d'accès sans fil à différents endroits que d'étendre le nombre de ports du réseau.
Le capital lié à l'infrastructure du bâtiment est réduit car les équipements réseau sans fil ne sont pas fixes comme dans le cadre d'une infrastructure réseau câblée. Ainsi, la flexibilité en matière d'expansion est accrue et il est bien plus simple de modifier l'emplacement de ses bureaux quelle qu'en soit la raison. Les réseaux sans fil haute vitesse (802.11a/g/n) constituent également une alternative rentable aux anciens câblages lents (Ethernet ou Token Ring).

Vulnérabilités des réseaux sans fil

Pour comprendre le niveau de sécurité des solutions de sécurité pour réseaux sans fil, il est indispensable de bien cerner les menaces courantes auxquelles ils sont susceptibles d'être confrontés. Les vulnérabilités et types d'attaque auxquels doivent faire face les réseaux classiques sont bien connus, mais les réseaux sans fil souffrent quant à eux de vulnérabilités qui s'étendent bien au-delà de ces risques « classiques ».

Tableau 1. Menaces de sécurité WLAN classiques

Menace	Description
Divulgation de données par écoute électronique	Les attaques par écoute d'un trafic sans fil non sécurisé peuvent conduire à la divulgation de données confidentielles, à la découverte d'informations d'identification et peuvent aller jusqu'à l'usurpation d'identité. Les attaquants expérimentés peuvent utiliser les informations obtenues par écoute pour attaquer des systèmes qui pourraient ne pas être vulnérables.
Interception et modification de données transmises	Un attaquant qui peut accéder aux ressources réseau peut également insérer des systèmes non autorisés sur le réseau, capables d'intercepter et de modifier des données en transit entre deux systèmes légitimes.
Usurpation de contenu	Un attaquant qui accède à un réseau interne a la possibilité de créer des données qui apparaîtront comme légitimes sur le réseau. Ce type d'attaque peut notamment inclure des courriers électroniques usurpés. Les utilisateurs internes accorderont plus facilement leur confiance à ce type de courrier qu'aux communications en provenance de sources externes, créant ainsi une véritable plate-forme de lancement d'attaques par ingénierie sociale et d'insertion de chevaux de Troie.
Déni de service	Quelle que soit la solution de sécurité implémentée, un WLAN est sujet aux attaques par déni de service volontaires ou accidentelles. Ces perturbations peuvent être dues à un four à micro-ondes comme à un périphérique réglé pour saturer un réseau avec un trafic intempestif.
Freeloading (vol de ressources)	Un intrus peut avoir comme seul objectif d'utiliser votre réseau pour accéder gratuitement à Internet. Bien que ce type d'attaque ne crée pas de dommages ou de dégâts directs, il risque de ralentir la connectivité réseau des utilisateurs légitimes et peut être un facteur de risque non géré concernant les logiciels malveillants.
Menaces accidentelles et connexions non gérées	Dans des environnements WLAN non sécurisés, un visiteur peut accéder au réseau interne en démarrant tout simplement un périphérique capable d'accéder aux réseaux sans fil. Ces périphériques non gérés peuvent être déjà compromis ou fournir un point d'attaque à votre réseau à un utilisateur malveillant.
Points d'accès WLAN non autorisés	L'entreprise qui ne possède pas de réseau sans fil ne reste pas moins vulnérable aux menaces de sécurité des réseaux sans fil non gérés. Le matériel sans fil est en général assez abordable. Par conséquent, un employé peut tout à fait configurer un réseau non géré et non protégé au sein d'un environnement existant.

Aujourd'hui, dans des environnements où la sécurité est devenue la principale préoccupation, la plupart des risques de sécurité liés à la transmission de données sans fil semblent assez bien compris, mais ces problèmes n'étaient pas aussi évidents lorsque la première génération de technologie de sécurité sans fil a vu le jour. Lorsque le WEP a été créé pour sécuriser la diffusion de données sans fil, il ne semblait pas nécessaire de compenser les failles de sécurité inhérentes du système contrairement à celles liées à la transmission de données câblée. En effet, la technologie était tellement récente que très peu de personnes avaient imaginé les menaces potentielles auxquelles devraient faire face de tels réseaux. À mesure que les méthodes d'attaque évoluaient, la transmission de données sans fil était clairement exposée à des environnements potentiellement dangereux et se devait d'être sécurisée afin de devenir aussi fiable que les communications LAN câblées. Quand les failles de la sécurité WEP ont commencé à être largement médiatisées, l'environnement de sécurité réseau connaissait une mutation rapide. Les histoires sur le wardriving étaient courantes dans les principaux médias et les gouvernements légiféraient afin de contrôler les industriels en matière de sécurité des données et des identités. Suite à cela, bon nombre d'entreprises ont considéré que la technologie sans fil ne pouvait pas être implémentée et qu'elle n'était pas suffisamment fiable, ou ont développé des solutions de contournement complexes afin de combler les failles de la norme WEP. Certaines de ces solutions de contournement sont encore utilisées et même commercialisées aujourd'hui. Toutefois, comme le démontrent les sections suivantes, ces solutions complexes ne sont plus nécessaires pour protéger les réseaux sans fil de ces menaces. Elles devraient même être réévaluées, car la technologie sans fil s'est développée afin de s'adapter aux changements perpétuels en matière de sécurité. ##### Définir des solutions de sécurité WLAN appropriées Depuis la découverte des faiblesses technologiques des réseaux locaux sans fil, de nombreux efforts ont été accomplis pour résoudre leurs vulnérabilités. Tandis que l'industrie des technologies sans fil, Microsoft et d'autres fournisseurs se concentraient sur l'amélioration de la norme sans fil, de nombreux analystes, fournisseurs de sécurité réseau et bien d'autres encore trouvaient des moyens de contourner les faiblesses de l'ancienne norme sans fil. Ces travaux permettent de proposer différentes approches de résolution des problèmes de sécurité WLAN. Outre l'approche la plus fréquente, qui est la décision de ne pas implémenter la technologie WLAN, les alternatives sont comparées dans le tableau ci-dessous. **Tableau 2. Comparaison des approches sur la sécurité WLAN**

Composant	WPA et WPA2	WEP statique	VPN	IPsec
Authentification renforcée (voir Remarque)	Oui	Non	Oui, uniquement lorsque l'authentification par clé partagée n'est pas utilisée	Oui, si l'authentification par certificat ou Kerberos est utilisée
Chiffrement renforcé des données	Oui	Non	Oui	Oui
Connexions et reconnexions transparentes	Oui	Oui	Non	Oui
Authentification utilisateur (voir Remarque)	Oui	Non	Oui	Non
Authentification ordinateur (voir Remarque)	Oui	Oui	Non	Oui
Protège le trafic de diffusion et de multidiffusion	Oui	Oui	Oui	Non
Périphériques réseau supplémentaires requis	Oui, serveurs RADIUS	Non	Oui, VPN et serveurs RADIUS	Non
Sécurise l'accès au WLAN et pas uniquement aux paquets	Oui	Oui	Non	Non

**Remarque** En ce qui concerne l'authentification renforcée, bon nombre d'implémentations VPN qui utilisent le mode tunnel IPsec utilisent un schéma d'authentification de clé partagée faible, appelé XAuth. Les versions actuelles de Windows ne prennent pas en charge l'authentification utilisateur d'associations IPsec, mais cette fonctionnalité sera disponible dans Windows Vista et Server. L'authentification ordinateur signifie que l'ordinateur restera connecté au WLAN et au LAN même si aucun utilisateur n'a ouvert de session sur l'ordinateur. Cette fonctionnalité est nécessaire au bon fonctionnement de certaines fonctionnalités basées sur les domaines, comme les profils d'itinérance par exemple. Comme le montre ce tableau, les facteurs à prendre en compte lors de l'étude des différentes solutions de sécurisation des réseaux sans fil sont très nombreux. Ce type d'évaluation englobe tout : des coûts liés à l'implémentation et à la gestion à la sécurité générale de la solution concernée. Chaque approche présente des avantages et des inconvénients, c'est pourquoi chaque solution requiert un examen plus approfondi permettant une prise de décision réfléchie. Pour une meilleure connaissance des options de sécurisation des implémentations WLAN, les points suivants sont étudiés en détail et répertoriés selon le degré de sécurité fourni. - Ne pas déployer la technologie WLAN - Utiliser WPA avec EAP-TLS - Utiliser WPA avec PEAP-MS-CHAP v2 - Utiliser WPA avec PEAP-MS-CHAP v2 et les services de certificat - Utiliser un VPN - Utiliser IPsec - Utiliser WEP - Pas de sécurité WLAN ###### Ne pas déployer la technologie WLAN Selon la fameuse formule des professionnels de la sécurité : « Le système le plus sûr est celui qui n'est jamais sous tension. ». Ainsi, la façon la plus sûre de déployer une technologie, notamment la technologie de réseau sans fil, est de ne jamais la déployer. Bien entendu, avec cette approche, le problème est que l'entreprise qui n'utilise aucune technologie risque de ne pas être compétitive dans le monde d'aujourd'hui, dans lequel tout avantage, notamment en matière de technologie, est primordial. Comme mentionné précédemment, il est essentiel que chaque entreprise évalue ses propres besoins, sa tolérance aux risques, les risques liés à l'adoption de la technologie concernée, et cela vaut également pour l'implémentation de la technologie sans fil. Les réseaux sans fil peuvent offrir bon nombre d'avantages, mais ces avantages peuvent être sous-évalués et risquent même de ne pas être applicables à certaines entreprises. Lors de l'évaluation de la solution de sécurité sans fil appropriée, l'entreprise doit prendre en considération toutes les options possibles, y compris celle de ne pas déployer de solution sans fil. Toutefois, si une entreprise détermine qu'elle n'est pas prête à déployer un WLAN, sa décision doit s'inscrire dans une stratégie d'entreprise appliquée à la lettre, visant à éviter que des utilisateurs finaux ne déploient des WLAN non autorisés, compromettant ainsi la sécurité du réseau. ###### Utiliser WPA avec EAP-TLS WPA ou WPA2 avec EAP-TLS (Extensible Authentication Protocol Transport Layer Security) avec certificats utilisateur et ordinateur est la méthode d'authentification 802.1X la plus sûre prise en charge par les versions actuelles de clients sans fil Windows. EAP-TLS utilise des certificats numériques pour permettre l'authentification mutuelle. Le client sans fil s'authentifie auprès du serveur d'authentification et inversement. L'authentification EAP-TLS requiert une infrastructure de clé publique (PKI) pour émettre des certificats et les maintenir à jour. Pour garantir le plus haut niveau de sécurité, l'infrastructure PKI doit être configurée pour émettre les certificats utilisateur et ordinateur pour l'accès sans fil. En raison des coûts d'implémentation et de la surcharge administrative associés aux infrastructures PKI, seules les grandes entreprises ou les entreprises de taille moyenne utilisaient cette solution très sécurisée. Aujourd'hui, avec l'introduction de Microsoft Small Business Server, elle peut être implémentée dans des environnements d'entreprise de petite taille. En effet, Microsoft Small Business Server fournit les services de certificat sous-jacents requis dans le cadre de l'implémentation d'EAP-TLS. **Remarque** À l'heure actuelle, il n'existe aucune prise en charge d'objets de stratégie de groupe (GPO) pour la norme WPA2. Cela risque de desservir une implémentation efficace de cette norme dans des environnements plus étendus. Toutefois, des mises à jour de Windows Server 2003 et de Windows XP sont en cours de développement afin d'intégrer la prise en charge d'objets de stratégie de groupe pour WPA2. La nouvelle génération de systèmes d'exploitation Windows, Vista et Server, assurera une prise en charge native de la norme WPA2. ###### Utiliser WPA avec PEAP-MS-CHAP v2 WPA ou WPA2 avec PEAP (Protected EAP) et MS-CHAP v2 (Microsoft Challenge Handshake Authentication Protocol version 2) avec des exigences de mot de passe élevées constitue la deuxième solution d'implémentation de sécurité la plus efficace, prise en charge par les versions actuelles des clients Windows. Lorsque le déploiement de l'infrastructure PKI n'est pas possible, PEAP-MS-CHAP v2 constitue une solution viable et sûre permettant de déployer des réseaux sans fil fiables. PEAP est un schéma d'authentification unilatéral qui utilise TLS pour créer un canal chiffré depuis le serveur d'authentification, via lequel le client utilise un autre protocole pour s'authentifier. Conçu à l'origine pour les connexions distantes et l'accès à distance VPN, MS-CHAP v2 peut prendre en charge l'authentification renforcée par mot de passe des clients sans fil uniquement si des stratégies renforcées de mot de passe utilisateur sont utilisées sur le réseau. ###### Utiliser WPA avec PEAP-MS-CHAP v2 et les services de certificat Les entreprises qui doivent utiliser des éléments des deux approches pour concevoir leur solution peuvent combiner l'utilisation de services de certificat et une solution PEAP-MS-CHAP v2 basée sur mot de passe. Toutefois, à la date de rédaction de ce document, l'utilisation complémentaire de PEAP-MS-CHAP v2 ne confère aucun avantage de sécurité supplémentaire, notable et reconnu à la solution EAP-TLS qui est déjà suffisamment sécurisée. En réalité, l'utilisation de PEAP-MS-CHAP v2 avec EAP-TLS ralentit le processus d'authentification car il crée deux canaux TLS, l'un à l'intérieur de l'autre. Ce double chiffrement n'offre aucune valeur ajoutée. ###### Utiliser un VPN Lorsque les failles de sécurité WEP ont été découvertes, l'une des premières réponses proposées par les experts en sécurité et les leaders du marché a été d'utiliser les réseaux privés virtuels (VPN) pour sécuriser les réseaux sans fil. La technologie VPN est sans aucun doute une méthode sûre et éprouvée de protection des communications sur des réseaux hostiles, tels qu'Internet. D'ailleurs cette solution est toujours utilisée dans bon nombre d'environnements pour pallier les défauts du WEP. Cette solution semble très avantageuse pour ce qui est de la sécurité, mais elle souffre de défauts évidents qui ne la rendent pas si intéressante comparée à la flexibilité des solutions qui utilisent WPA, conçu spécifiquement pour traiter les menaces auxquelles doivent faire face les réseaux sans fil. Même s'il est possible de combiner des solutions WPA et la technologie VPN pour sécuriser les réseaux sans fil, cette solution ne présente aucun avantage comparée à une solution WPA « pure », surtout si l'on tient compte de la couche de complexité supplémentaire qui s'ajoute au réseau sans fil lors de l'utilisation de ce type de combinaison. Lorsque l'on s'interroge sur l'ajout d'un VPN dans une solution de sécurité WLAN, la convivialité doit également être prise en compte. Lorsqu'un utilisateur se connecte au réseau de l'entreprise via Internet, il s'attend aux processus d'authentification et aux limites de délai d'expiration supplémentaires associés aux VPN. Toutefois ces étapes supplémentaires pourront paraître fastidieuses à l'utilisateur habitué à se connecter facilement aux ressources de l'entreprise au sein d'un réseau local. Certaines entreprises souhaitent utiliser cette solution parce qu'elles ont déjà mis en place une solution VPN pour leurs utilisateurs distants et qu'elles pensent qu'il est indispensable de développer l'utilisation de ce système afin de pouvoir justifier son investissement. Dans ce cas, avant d'opter pour cette solution, il convient de se pencher sur les points suivants : - Comme une connexion VPN doit être établie avant que la communication via le tunnel soit autorisée, la stratégie de groupe de l'ordinateur ne s'applique pas si l'utilisateur se connecte au VPN après avoir ouvert une session sur l'ordinateur local. (Si l'utilisateur sélectionne **Ouvrir une session en utilisant une connexion réseau à distance**, lorsqu'il ouvre une session sur l'ordinateur, la connexion VPN s'établit, puis la stratégie de groupe s'applique.) - La plupart des serveurs VPN sont conçus pour sécuriser des connexions lentes (le trafic à distance par exemple) et peuvent devenir des goulets d'étranglement du réseau lorsqu'un grand nombre de connexions haut débit sont établies. - Selon la configuration VPN mise en place, les utilisateurs peuvent rencontrer des problèmes pour passer d'un point d'accès sans fil à un autre car les VPN annulent souvent les connexions, même après une très brève déconnexion. Dans ce cas, l'utilisateur est contraint de s'authentifier manuellement à chaque fois qu'il passe d'un point d'accès à un autre. Ce phénomène se produit également lorsque l'ordinateur de l'utilisateur passe en mode Veille. ###### Utiliser IPsec L'approche consistant à utiliser IPsec pour sécuriser les réseaux sans fil est née du besoin de contourner les failles du WEP, tout comme l'idée d'utiliser des VPN pour sécuriser les WLAN. Le protocole IPsec permet de sécuriser efficacement des trafics réseau spécifiques et présente même certains avantages lorsqu'il est utilisé avec des WLAN. Parmi ces avantages, citons notamment sa transparence, son indépendance vis-à-vis des contraintes matérielles des WLAN et sa faible surcharge, car il ne requiert aucun serveur ou logiciel supplémentaire pour fonctionner. Toutefois, utiliser IPsec pour sécuriser des réseaux sans fil pose un certain nombre de problèmes et notamment les suivants : - IPsec ne peut pas protéger le trafic de diffusion ou de multidiffusion car il gère uniquement les communications entre deux parties qui se sont mutuellement authentifiées et qui ont échangé des clés. - IPsec ne protège pas directement le réseau sans fil, mais uniquement les paquets réseau. - Bien que le protocole IPsec soit transparent pour les utilisateurs, il ne l'est pas complètement pour les périphériques réseau car il intervient au niveau de la couche réseau et non au niveau de la couche MAC. Cela entraîne des règles de pare-feu supplémentaires. - Les périphériques qui ne peuvent pas utiliser IPsec risquent d'être examinés ou attaqués par des personnes capables de surveiller le trafic WLAN. - La gestion de la stratégie IPsec dans des environnements plus étendus peut s'avérer compliquée si IPsec est utilisé pour protéger de bout en bout d'autres applications en plus du trafic réseau sans fil. ###### Utiliser WEP Le WEP statique est la forme la plus élémentaire de la norme de sécurité 802.11. Il utilise une clé partagée pour contrôler l'accès et utilise cette même clé comme base de chiffrement du trafic réseau. L'intérêt principal de cette méthode est sa simplicité et bien qu'elle augmente sensiblement le niveau de sécurité d'un réseau sans fil non protégé, elle souffre de graves problèmes en matière de gestion et de sécurité. En effet quelques minutes, voire quelques heures, suffisent à découvrir la clé partagée et l'identificateur SSID (s'il n'est pas diffusé) sur un WLAN WEP et à accéder ainsi au réseau à l'aide d'un ordinateur portable ordinaire et de quelques outils simples, disponibles sur Internet. Pour améliorer le WEP statique, il est possible de configurer des points d'accès de façon à ce que seul un groupe de clients prédéfini ait accès au réseau, en utilisant le filtrage MAC. Toutefois, cette méthode peut également être très facilement attaquée à l'aide d'outils permettant de découvrir et d'usurper les adresses MAC des ordinateurs connectés au WLAN. Pour améliorer quelque peu la sécurité des environnements qui ne prennent pas en charge les protocoles WPA ou WPA2, il est possible d'associer au WEP certaines technologies de sécurité. Toutefois ces configurations ne sont pas recommandées, sauf dans le cadre d'une phase de transition visant à passer d'un WLAN non sécurisé à une configuration WPA sécurisée. Ces méthodes sont les suivantes (de la plus sûre à la moins efficace) : - WEP avec authentification 802.1X en utilisant EAP-TLS avec des certificats utilisateur et ordinateur, et avec une réauthentification périodique forcée. - WEP avec authentification 802.1X en utilisant PEAP-MS-CHAP v2 avec des stratégies de mot de passe utilisateur renforcées et une réauthentification périodique forcée. ###### Pas de sécurité WLAN L'implémentation d'un réseau sans fil non sécurisé n'est pas recommandée dans les environnements d'entreprise de taille moyenne. Toutefois, dans certaines situations spécifiques, une configuration réseau sans fil non sécurisée peut être la meilleure des solutions. Par exemple, bon nombre de villes et de municipalités ont envisagé ou décidé d'implémenter des zones d'accès sans fil gratuites. Dans de tels cas, il peut être préférable d'utiliser un réseau dont les points d'accès sans fil ne sont pas sécurisés et autorisent uniquement des connexions directes à Internet. En fait, il est essentiel de bien comprendre que les réseaux sans fil non sécurisés sont particulièrement vulnérables à une grande variété d'attaques. ##### WPA ou WPA2 Les protocoles WPA (Wi-Fi Protected Access) et WPA2 (Wi-Fi Protected Access 2) ont tous deux été conçus pour répondre aux menaces auxquelles sont confrontés les réseaux sans fil IEEE 802.11. Il existe toutefois des différences entre ces deux protocoles. Le protocole WPA a été développé en 2003 pour pallier les défauts découverts dans la norme WEP. Il excelle dans sa tâche en implémentant la prise en charge de l'authentification mutuelle. Il utilise TKIP pour le chiffrement des données et intègre une vérification signée d'intégrité des messages pour déjouer les attaques par usurpation et les répétitions d'attaques. WPA2 améliore WPA en sécurisant le trafic réseau avec AES plutôt qu'avec TKIP. WPA2 doit donc toujours être privilégié par rapport à son prédécesseur. Les protocoles WPA et WPA2 sont beaucoup plus sûrs que le WEP et, lorsqu'ils sont correctement sécurisés, ne souffrent à ce jour d'aucune imperfection. Toutefois, WPA2 est considéré comme plus sûr que WPA. Lorsque cela est possible, il est donc recommandé d'utiliser WPA2, si l'infrastructure le prend en charge et que la surcharge de gestion supplémentaire peut être atténuée. La plupart des périphériques d'accès sans fil conçus aujourd'hui sont certifiés WPA2, tout comme les versions les plus récentes de Windows, notamment Windows XP avec Service Pack 2 (SP2) et Windows Server 2003 avec SP1. Les périphériques et clients sans fil qui prennent en charge WPA2 prennent également en charge WPA au cas où les points d'accès ou clients sans fil actuellement déployés dans un environnement ne prendraient pas en charge WPA2. **Remarque** Pour permettre la prise en charge de la certification WPA2, les clients Windows XP SP2 requièrent un package de mise à jour supplémentaire : la [mise à jour WPA2 (Wi-Fi Protected Access 2)/WPS IE (Wireless Provisioning Services Information Element)](http://support.microsoft.com/kb/893357/fr) (cette page peut être en anglais). Pour plus d'informations sur cette mise à jour, visitez le site http://support.microsoft.com/kb/893357/fr. Par ailleurs, les versions actuelles de Windows ne prennent pas en charge les objets de stratégie de groupe (GPO) pour WPA2. Cela constitue un inconvénient de gestion majeur et rend l'implémentation de WPA2 bien plus complexe que celle de WPA. Ce point peut faire la différence lorsqu'il s'agit de choisir entre WPA et WPA2, car ces normes sont toutes les deux relativement sûres. #### Développer une solution WLAN sécurisée La section précédente a permis de dresser un historique des différentes options de sécurité WLAN à envisager, d'expliquer les menaces courantes auxquelles sont confrontés les réseaux sans fil et de mettre en avant les vulnérabilités et palliatifs de chaque approche. Grâce à ces informations, il est possible de prendre des décisions réfléchies en évaluant notamment l'adéquation des différentes options aux différents environnements d'entreprise. Les dernières améliorations de sécurité des normes pour réseaux sans fil, avec l'implémentation de WPA et de WPA2, ont permis de pallier les importants défauts du WEP et ainsi de marginaliser les solutions de contournement telles que l'utilisation d'IPsec ou d'un VPN pour la sécurisation des connexions sans fil. L'utilisation d'un WEP statique ou dynamique n'est en aucun cas recommandée et ne pas utiliser d'option de sécurité n'est utile que dans très peu de cas. Compte tenu de ces hypothèses, il ne reste plus que quelques options disponibles lorsque vous envisagez d'implémenter une solution de sécurité complète et efficace pour votre WLAN. Cette section présente aux décideurs les approches recommandées pour la sécurisation des réseaux sans fil. Ces solutions recommandées par Microsoft sont considérées par les analystes du secteur, experts en sécurité et principaux vendeurs, comme les méthodes les plus sûres d'implémentation de réseaux sans fil sécurisés et efficaces. Ce guide met l'accent sur la méthode la plus adaptée à un environnement d'entreprise de taille moyenne. Toutefois, dans le cadre d'un processus de décision, il est primordial d'envisager toutes les options possibles car il existe toujours des exceptions à la règle. ##### Processus de décision Microsoft pour un WLAN sécurisé Il existe deux processus de sécurité WLAN et une troisième approche tirée de ces deux processus. Les deux solutions principales sont les suivantes (classées selon le niveau de sécurité fourni) : - WPA2 avec EAP-TLS en utilisant des services de certificat - WPA2 avec PEAP-MS-CHAPv2 Sans tenir compte du niveau de sécurité fourni, les ressources requises pour implémenter et prendre en charge ces solutions constituent en général un facteur de décision élémentaire permettant de choisir l'une ou l'autre de ces deux approches. La configuration WPA ou WPA2 avec PEAP-MS-CHAPv2 est moins exigeante en termes d'équipement et d'expertise technique car elle ne requiert pas d'infrastructure de certificat sous-jacente. Dans la mesure où tous les périphériques actuellement commercialisés sont certifiés WPA2 et abordables, il semble judicieux d'utiliser des périphériques qui prennent en charge WPA2 même si c'est finalement WPA qui sera utilisé en raison de ses avantages administratifs. La méthode de chiffrement AES de WPA2 est considérée comme beaucoup plus sûre que le chiffrement TKIP de WPA. En outre, la prise en charge d'objets de stratégie de groupe (GPO) pour WPA2 est prévue dans les prochaines versions. Il semble donc pertinent de mettre en place la base qui simplifiera l'implémentation ultérieure de WPA2. Utiliser WPA ou WPA2 avec EAP-TLS est l'option de sécurisation des réseaux sans fil la plus sûre, mais, dans la mesure où elle repose sur une infrastructure de certificat sous-jacente, elle nécessite des coûts d'implémentation et de gestion plus importants. Toutefois, bon nombre d'environnements d'entreprise de taille moyenne ont déjà mis en place des systèmes qui répondent aux exigences de WPA2 avec EAP-TLS. Par conséquent, cette option présentera un grand intérêt pour beaucoup d'entreprises. Même si la technologie requise n'est pas encore en place, bon nombre d'entreprises ont besoin de la technologie de cette solution pour d'autres raisons (certificats et RADIUS). Ainsi, même dans ce cas, d'excellentes raisons techniques et professionnelles justifient l'implémentation de cette solution. [![](images/Cc875845.SWCG1(fr-fr,TechNet.10).gif)](https://technet.microsoft.com/fr-fr/cc875845.swcg1_big(fr-fr,technet.10).gif) **Figure 1. Arborescence de décision WLAN de Microsoft** L'organigramme de la figure 1 a déjà été utilisé dans des guides précédents de Microsoft afin d'aider les entreprises à déterminer la configuration de sécurisation WLAN la mieux adaptée à leur environnement. Il présente également certaines hypothèses pour les grandes entreprises. Pour lire cet organigramme, il est entendu qu'une grande entreprise compte au moins 500 employés et une équipe informatique composée d'au moins cinq techniciens. Comme expliqué précédemment, cette arborescence de décision est légèrement faussée dans la mesure où bon nombre d'entreprises de taille moyenne, auxquelles est destiné ce guide, possèdent les ressources nécessaires et ont la possibilité d'implémenter facilement WPA2 EAP-TLS avec des services de certificat, si l'on considère que la plupart des entreprises de taille moyenne ont au moins cinq informaticiens et qu'elles sont en mesure de prendre en charge les exigences d'infrastructure supplémentaires requises dans le cadre d'une implémentation EAP-TLS élémentaire (quatre serveurs supplémentaires, dont un doit rester déconnecté du réseau). Compte tenu de ces éléments, il apparaît clairement que WPA2 EAP-TLS avec des services de certificat est la meilleure solution pour les entreprises de taille moyenne. Ce guide mettra donc l'accent sur cette approche. Il existe toutefois des exceptions à la règle. Par conséquent, si une entreprise s'oriente vers une approche différente, d'autres guides pourront répondre à ses besoins. Si elle opte pour WPA avec PEAP-MS-CHAP v2, des informations complémentaires sont disponibles dans le guide [Sécuriser les réseaux locaux avec PEAP et des mots de passe](http://go.microsoft.com/fwlink/?linkid=23459) (cette page peut être en anglais) à l'adresse suivante : http://go.microsoft.com/fwlink/?linkid=23459 ###### Configuration serveur EAP-TLS requise Comme indiqué précédemment, EAP-TLS requiert au moins quatre serveurs, (davantage, si nécessaire dans un environnement distribué ou plus étendu). Deux d'entre eux seront utilisés comme serveurs IAS (Internet Authentication Service) redondants (implémentation Microsoft d'un service RADIUS) et deux autres appartiendront à une infrastructure de certificat élémentaire (PKI). Sur les deux serveurs de certificat, l'autorité de certification (CA) racine sera autonome et hors réseau afin de protéger le certificat racine. **Tableau 3. Configuration matérielle requise pour le serveur CA racine**

Composant	Configuration requise
Unité centrale	1 processeur à 733 MHz ou supérieur
Mémoire	256 Mo de RAM
Interface réseau	Aucune (ou désactivée)
Stockage sur disque	Contrôleur RAID IDE ou SCSI. 2 x 18 Go configurés en tant que volume RAID 1 (lecteur C) Espace amovible local pour le transfert des données (certificat racine).

Comme le montre ce tableau, la configuration requise, basée sur les exigences standard de Windows Server 2003 Standard Edition, pour l'autorité de certification racine est minimale et peut même être installée sur une plate-forme plus ancienne dont il est prévu de se séparer, ou créée en tant que machine virtuelle. De nombreux clients trouvent que les ordinateurs portables sont très pratiques parce qu'ils peuvent être sécurisés physiquement dans le coffre d'une salle d'ordinateurs. Quelle que soit l'approche choisie pour créer l'autorité de certification racine, il est primordial de s'assurer que l'ordinateur en question peut être démarré ou restauré efficacement si besoin est.

La configuration matérielle requise pour l'autorité de certification émettrice est la même, si ce n'est que des exigences de stockage supplémentaires sont requises et que le serveur ne doit pas être nécessairement connecté au réseau. Comme ce serveur doit stocker tous les certificats émis, il doit être doté de préférence d'au moins 2 Go d'espace disque pour 1 000 utilisateurs.

La configuration des serveurs Radius est plus lourde car ces derniers sont indispensables au fonctionnement du WLAN. Ils doivent en outre gérer un grand nombre de tentatives d'authentification sur de courtes périodes. Par conséquent, une plate-forme matérielle plus robuste peut être nécessaire pour des environnements comptant des milliers de clients sans fil. Par ailleurs, les autorités de certification requièrent uniquement l'utilisation de Windows Server 2003 Standard Edition, alors que les serveurs IAS peuvent nécessiter l'utilisation de la version Enterprise Edition car la version Standard Edition ne peut prendre en charge que 50 clients RADIUS.

Pour ces différentes raisons, il est souvent recommandé d'installer les serveurs IAS sur des contrôleurs de domaine, car cela permet de réduire le besoin de serveurs supplémentaires en tirant parti des plates-formes serveur robustes existantes, requises par les contrôleurs de domaine. Cela permet également d'améliorer les performances des serveurs IAS en réduisant le trafic réseau entre les contrôleurs de domaine et les serveurs IAS lors de l'authentification utilisateur.

Lors de l'évaluation de la configuration requise pour les serveurs RADIUS, le basculement et la redondance sont aussi importants que le concept d'emplacement distant. Bien que la configuration minimum recommandée prévoie deux serveurs IAS, certaines entreprises peuvent compter un grand nombre de bureaux distants et avoir besoin de serveurs IAS dans certains de ces bureaux. Certaines entreprises peuvent également avoir des exigences plus élevées en matière d'équilibrage de charge ou de redondance des serveurs.

Bien que l'utilisation de serveurs multifonction tels que les serveurs RADIUS ne soit pas contre-indiquée, il est important de prendre en compte la charge supplémentaire que doivent gérer ces serveurs et la nature des demandes. Un serveur RADIUS doit être capable de s'adapter afin de pouvoir gérer la situation si tous les clients sans fil essaient de se connecter simultanément dans un laps de temps très court.

Certificats

Quelle que soit l'approche WPA choisie pour sécuriser un WLAN, les certificats sont nécessaires et font partie intégrante de la solution. PEAP requiert des certificats uniquement sur le serveur d'authentification. Il est donc possible d'utiliser un service de certificat tiers pour fournir les certificats requis. En d'autres termes, il n'est pas nécessaire d'implémenter une infrastructure PKI. C'est en grande partie pour cette raison que l'approche PEAP est particulièrement recommandée aux entreprises de petite taille, car elles pourraient ne pas avoir les ressources ou l'expertise nécessaires à l'implémentation et à la prise en charge d'une infrastructure de certificat.

L'implémentation EAP-TLS avec services de certificat prise en charge par Windows ne requiert pas nécessairement l'utilisation d'une infrastructure PKI sous-jacente pour assurer la prise en charge de l'émission des certificats, mais, comme chaque client doit avoir un certificat pour s'authentifier auprès du serveur RADIUS, l'utilisation de certificats tiers peut devenir rapidement onéreuse, sauf dans le cas des très petites entreprises. L'approche qui combine PEAP et des services de certificat est soumise aux mêmes considérations.

Si l'entreprise a déjà mis en place une infrastructure PKI, le processus de décision est plus simple. Si les composants sont déjà installés, elle peut les utiliser et implémenter l'option de sécurité la plus sûre pour sécuriser son WLAN. Si l'entreprise de taille moyenne n'a pas encore installé d'infrastructure PKI, elle peut estimer qu'il peut être judicieux d'opter pour une infrastructure de certificat compte tenu des applications connexes qui peuvent en découler. Citons notamment les applications suivantes :

Signature de code
Sécurisation de la messagerie électronique
Sécurisation des livraisons de contenus Web
Sécurité VPN
Services de fichiers chiffrés

Compte tenu de ces éléments, l'approche qui consiste à utiliser des services de certificat avec EAP-TLS ou PEAP est la plus adaptée aux entreprises de taille moyenne. Ce guide mettra donc l'accent sur cette approche.

Créer une déclaration CPS (Certificate Practices Statement)

La planification initiale d'une infrastructure PKI comprend la rédaction de documents décrivant l'utilisation des certificats dans l'environnement professionnel. Même si ces décisions peuvent être modifiées ultérieurement en fonction des besoins de l'entreprise, il est primordial de consigner ces décisions dans une déclaration de stratégie de certificat.

Une stratégie de certificat est un ensemble de règles qui régit l'infrastructure PKI. Elle enregistre les informations déterminant si les certificats peuvent s'appliquer aux groupes ou applications spécifiques de l'entreprise ayant des exigences de sécurité communes. Une déclaration CPS décrit les méthodes utilisées par l'entreprise pour gérer les certificats qu'elle émet. Elle décrit comment la stratégie de certificat est interprétée dans le contexte des stratégies de procédure de fonctionnement et de l'infrastructure du système de l'entreprise. Une stratégie de certificat est un document qui concerne l'ensemble de l'entreprise alors que la déclaration CPS est spécifique à l'autorité de certification. Notez toutefois que les autorités de certification qui effectuent les mêmes tâches peuvent avoir une déclaration CPS commune.

Pour certaines entreprises, ces déclarations sont des documents juridiques qui doivent être conçus en fonction des exigences réglementaires qui régissent leur secteur d'activité, et qui doivent être rédigés en étroite collaboration avec une assistance juridique. Cependant, même si l'entreprise n'est pas régie par ces exigences, il peut être judicieux d'élaborer ces documents.

Hiérarchie des autorités de certification

La conception spécifiée dans ce guide utilise un modèle d'approbation hiérarchique qui ne compte qu'une seule racine interne. Cette approche présente un certain nombre d'avantages et d'inconvénients, c'est pourquoi il sera nécessaire de l'approfondir afin de déterminer si elle convient à l'entreprise dans laquelle elle sera implémentée. Pour plus d'informations sur ce point, reportez-vous au chapitre sur la conception d'une infrastructure à clé publique (cette page peut être en anglais) dans le kit de déploiement Windows Server 2003 à l'adresse suivante : http://technet2.microsoft.com/WindowsServer/en/library/b1ee9920-d7ef-4ce5-b63c-3661c72e0f0b1033.mspx.

Figure 2. Hiérarchie des autorités de certification

Sécuriser l'autorité de certification racine

L'implémentation Microsoft d'EAP-TLS ne fonctionnera que si l'autorité de certification racine est sécurisée « hors ligne » (déconnectée du réseau). En matière de sécurité, il est plus judicieux d'utiliser une conception d'autorité de certification racine autonome plutôt qu'une conception d'autorité de certification racine d'entreprise. Pour cette raison, il est généralement recommandé d'utiliser cette approche dans le cadre de l'implémentation d'une infrastructure PKI.

Comme cette approche peut être perçue comme un gaspillage de ressources, certaines méthodes permettent à l'entreprise de redéployer au moins une partie du matériel utilisé afin de pouvoir créer une autorité de certification racine déconnectée du réseau. Parmi ces méthodes figurent notamment les suivantes :

Après avoir créé et distribué le certificat racine à une autorité de certification émettrice, les disques durs de l'autorité de certification peuvent être retirés et stockés de façon sécurisée jusqu'à leur prochaine utilisation. L'inconvénient de cette méthode est qu'en cas de besoin de l'autorité de certification racine, le matériel correspondant devra être récupéré.
Après avoir créé et distribué le certificat racine à une autorité de certification émettrice, il est possible de prendre une image du serveur via une sauvegarde et de l'enregistrer sur des bandes ou d'autres supports hors ligne. Le serveur est alors réutilisable. L'inconvénient de cette approche est le même que dans la méthode précédente, c'est-à-dire que si le matériel est de nouveau nécessaire, il devra être récupéré.
Créer l'autorité de certification racine en utilisant un serveur ou un PC virtuel, ou tout autre logiciel de machine virtuelle. Une fois le certificat racine créé et distribué, l'image de la machine virtuelle peut être enregistrée sur un dispositif de stockage hors ligne et archivée en cas de besoin ultérieur. Si une plate-forme générique standard (par exemple, le système de bureau standard de l'entreprise, lorsqu'il répond aux exigences matérielles requises) est utilisée dans le cadre de cette méthode, cela facilite la récupération du matériel lorsque l'autorité de certification est à nouveau nécessaire.
Créer l'autorité de certification racine hors ligne sur un ancien ordinateur portable, puis stocker ce dernier dans un coffre de la salle des ordinateurs. Cela permet d'utiliser une ressource matérielle qui, si elle n'était pas utilisée de la sorte, serait probablement mise au rebut.

Authentification Internet

Le service d'authentification Internet (IAS, Internet Authentication Service) est l'implémentation Microsoft d'un serveur RADIUS et d'un serveur proxy. Le service IAS peut effectuer une authentification, une autorisation et une gestion des comptes centralisées pour différentes connexions réseau. Le service IAS peut être utilisé avec d'autres serveurs RADIUS en tant que redirecteur d'authentification, d'autorisation et de gestion des comptes, avec d'autres serveurs VPN, tels que des serveurs de routage ou d'accès distant, ou avec d'autres infrastructures réseau, telles que des points d'accès sans fil.

Lors du développement d'un plan de déploiement d'une infrastructure IAS, il est essentiel de tirer parti des avantages de l'infrastructure RADIUS IAS. En effet, celle-ci n'est pas conçue pour fournir un accès à un seul réseau isolé. Ainsi, lors de la planification et du déploiement d'une infrastructure IAS, il convient de déterminer si un service centralisé sera utilisé pour la gestion de l'accès réseau, avec une base de données de comptes centralisée, telle qu'Active Directory, et de s'assurer qu'elle pourra répondre aux besoins actuels et futurs de l'entreprise. En d'autres termes, le déploiement d'une infrastructure IAS doit être stratégique et pas uniquement tactique.

Ce guide abordera uniquement la planification et le déploiement du service IAS dans le cadre d'une infrastructure sans fil sécurisée. Pour plus d'informations sur les autres possibilités et problèmes de planification et de déploiement d'IAS, reportez-vous à la section relative aux ressources de déploiement (cette page peut être en anglais), sur la page d'accueil du service IAS, à l'adresse suivante : technet.microsoft.com/fr-fr/network/bb643123.aspx.

Implémentations RADIUS préexistantes

Cette solution peut être intégrée à des implémentations RADIUS préexistantes. Ce guide ne donne toutefois pas d'information sur ce processus. Dans la plupart des cas, il est plus intéressant d'utiliser le service IAS pour les fonctionnalités présentées dans ce guide. Pour ce faire, il est possible de mettre à niveau d'anciennes plates-formes vers Windows 2003 Server de façon à ce qu'elles jouent le rôle de serveurs RADIUS de base ou de modifier des serveurs RADIUS afin de transmettre le trafic RADIUS vers de nouveaux serveurs RADIUS Windows Server 2003.

Pour obtenir des conseils de planification détaillés sur la migration d'une infrastructure RADIUS existante vers des serveurs RADIUS Windows Server 2003, consultez la page de références techniques IAS (cette page peut être en anglais) à l'adresse suivante : http://technet2.microsoft.com/WindowsServer/en/Library/8f5c89d5-fdaf-430c-9ef4-318f8c15baf11033.mspx ou contactez un représentant Microsoft ou le service MCS (Microsoft Consulting Services) approprié.

Basculement et équilibrage de la charge du serveur RADIUS

RADIUS est un composant essentiel de toute solution de sécurité sans fil basée sur 802.1X. Par conséquent, la disponibilité d'un réseau sans fil dépend de la disponibilité des serveurs RADIUS. Ainsi, une solution RADIUS prenant en charge des réseaux sans fil doit être fiable, réactive et redondante pour garantir une disponibilité et des performances équivalentes à celles d'un réseau câblé. Pour ces raisons, il est généralement recommandé d'installer le service IAS sur des contrôleurs de domaine existants.

Avant d'opter pour une stratégie d'équilibrage de la charge, il est essentiel de bien comprendre que 802.1X implémente EAP dans RADIUS (EAP-RADIUS) entre points d'accès sans fil et serveurs RADIUS. Bien que RADIUS utilise UDP, EAP est un protocole de session intégré dans RADIUS. Ceci signifie que plusieurs paquets EAP-RADIUS comprenant une seule authentification doivent retourner au même serveur RADIUS, sinon la tentative d'authentification échoue.

Dans le cadre des réseaux sans fil, l'équilibrage de la charge et le basculement sur serveurs IAS peuvent être présentés selon deux approches. La première consiste à utiliser des serveurs proxy IAS avec des groupes de serveurs RADIUS, et la seconde, à configurer les serveurs RADIUS principal et secondaire sur des points d'accès sans fil. Le tableau suivant répertorie les avantages et les inconvénients de ces deux approches.

Tableau 4. Basculement et équilibrage de la charge RADIUS pour EAP

Méthode	Avantages	Inconvénients
Proxies IAS avec groupes de serveurs RADIUS	Détection de rupture de service RADIUS avec basculement et restauration automatique Distribution de la charge réseau en fonction des propriétés du trafic Conserve l'état des sessions EAP lors de l'équilibrage de la charge. Distribution des demandes configurable en fonction des paramètres de priorité et de pondération	Serveurs IAS supplémentaires requis Requiert la configuration des adresses des serveurs RADIUS proxy principal et secondaire.
Paramètres des serveurs RADIUS principal et secondaire sur les points d'accès sans fil	Configuration plus simple pour les environnements de petite taille Le point d'accès sans fil détecte l'erreur de trafic et effectue le basculement. Exploite la fonctionnalité native du point d'accès sans fil.	Requiert une planification et un contrôle accrus de la distribution du trafic sur les serveurs RADIUS principal et secondaire. Certains points d'accès sans fil ne prennent toujours pas en charge la fonction de restauration automatique et peuvent donc générer des charges de trafic non équilibrées.

Les grandes entreprises doivent envisager de recourir à des proxies RADIUS configurés dans des groupes de serveurs RADIUS afin de distribuer les charges aux serveurs RADIUS. Autoriser la distribution du trafic en fonction d'un nombre d'éléments configurables, tels que le type de trafic RADIUS et les attributs RADIUS, ainsi que les valeurs de priorité et de pondération permet d'atteindre une certaine flexibilité. Ce type d'architecture offre également une souplesse et une évolutivité maximales en matière de gestion des demandes d'authentification, tout en étant moins exigeant d'un point de vue administratif.

La fonction de basculement la plus simple d'un serveur RADIUS intégrée à des points d'accès sans fil offre un niveau de résistance suffisant pour la plupart des entreprises. En revanche, cette solution est moins sophistiquée que celle qui consiste à utiliser des groupes de serveurs proxy. Migrer de cette architecture vers une solution de basculement et d'équilibrage de la charge basée sur des serveurs proxy RADIUS est un processus relativement simple, c'est pourquoi cette solution offre des possibilités d'évolution. Pour les entreprises qui n'envisagent qu'une couverture sans fil réduite, cette solution est efficace et facile à implémenter. Toutefois, les efforts à fournir en matière de gestion et d'implémentation augmentent avec la taille et la complexité du réseau sans fil. En effet, pour maintenir un équilibrage de la charge efficace sur l'ensemble des serveurs, chaque périphérique doit être attentivement configuré et surveillé.

Figure 3. Méthodes de basculement et d'équilibrage de la charge des serveurs WLAN RADIUS

L'équilibrage de la charge avec la fonction de points d'accès sans fil intégrée implique la configuration de la moitié des points d'accès sans fil sur chaque emplacement de façon à ce qu'ils utilisent le serveur RADIUS principal et un autre serveur défini comme secondaire. L'autre moitié des points d'accès sans fil utilise des affectations inverses dans les champs principal et secondaire, comme le montre la figure 3. La surcharge se produit lorsqu'il y a plus de charge sur certains points d'accès que sur d'autres. La mise en place et le maintien d'un équilibrage de la charge efficaces impliquent donc une surveillance constante.

Exigences relatives à la journalisation RADIUS

Les serveurs IAS peuvent consigner deux types d'événements facultatifs :

Tentatives d'authentification réussies et échecs de tentative d'authentification
Informations relatives au compte et à l'authentification RADIUS

Les événements d'authentification sont générés par les périphériques et les utilisateurs qui tentent d'accéder au WLAN. Ils sont enregistrés par le service IAS dans le journal des événements système de Windows Server 2003. Ces événements sont très utiles pour le dépannage et dans le cadre d'un système d'audit de sécurité et de détection des intrusions. Au début, il est nécessaire d'activer la journalisation des événements réussis et des échecs, mais il conviendra peut-être par la suite d'appliquer des filtres afin d'éviter de saturer le journal des événements système. Si la journalisation des demandes d'authentification RADIUS est activée, l'utilisation de ces événements ne présente aucun intérêt du point de vue de la sécurité.

Serveurs IAS centralisés ou distribués

La plupart des entreprises de taille moyenne devraient, pour commencer, envisager d'implémenter une architecture serveur IAS centralisée dans la mesure où la plupart des entreprises de cette taille disposent de connexions WAN haut débit robustes aux bâtiments distants et que le trafic RADIUS consomme peu de bande passante. Cette faible consommation est due au fait que le trafic RADIUS est conçu pour utiliser des liaisons WAN et des connexions d'accès distant. Une architecture centralisée est également plus rentable si une infrastructure WAN haut débit redondante sous-jacente existe déjà.

Toutefois, il convient d'analyser avec soin les possibilités des liaisons WAN existantes afin de déterminer s'il s'agit véritablement de l'option la plus adaptée car d'autres communications (le trafic DHCP par exemple) pourraient arriver à expiration en attendant que le processus d'authentification 802.1X s'achève alors que le réseau est saturé. La connectivité client n'est pas le seul facteur à prendre en compte lorsque l'entreprise envisage d'implémenter une architecture IAS centralisée. En effet, les communications entre les serveurs IAS et les contrôleurs de domaine requièrent des connexions réseau robustes afin d'éviter les dépassements de délai lors de l'évaluation des appartenances aux groupes et des droits d'accès réseau.

Certaines entreprises risquent de ne pas être en mesure de pouvoir tirer parti des avantages de l'architecture centralisée en raison des coûts liés aux connexions WAN à bande passante élevée et à l'équipement réseau sophistiqué. Ces entreprises doivent opter pour une conception d'infrastructure IAS distribuée, surtout si une infrastructure serveur décentralisée est déjà installée.

Une autre approche consiste à mélanger les deux précédentes. Cela permet d'installer de façon stratégique les serveurs IAS sur les sites capables de prendre en charge cette infrastructure et de les autoriser à fournir des services d'authentification aux agences non équipées d'une base serveur sous-jacente, comme le montre la figure ci-dessous.

Figure 4. Infrastructure WAN IAS mixte

Ce guide traite les trois approches. Il fournit des conseils permettant de fournir à de grandes entreprises une configuration avec deux serveurs RADIUS capables de gérer des demandes locales et distantes et des conseils pour la configuration des sièges de grande envergure avec des agences à serveur unique optionnel.

Remarque Une fois encore, l'accès WLAN des bureaux distants dépourvus d'infrastructure serveur dépend de la disponibilité WAN.

Considérations sur l'emplacement et la mutualisation des serveurs IAS

Pour maintenir l'accès aux services WLAN, au moins deux serveurs RADIUS sont requis pour chaque forêt Active Directory indépendante. Outre cette exigence élémentaire, certains facteurs permettent de déterminer le nombre de serveurs nécessaires et si ces derniers peuvent participer à la mutualisation avec d'autres fonctions serveur.

En général, l'emplacement des serveurs IAS doit correspondre à l'emplacement des contrôleurs de domaine, c'est-à-dire que si un bureau dépend déjà pour ses services de domaine d'une liaison WAN haut débit vers un autre bureau, il est probable qu'il ait également à utiliser un serveur RADIUS distant. Les grandes entreprises qui possèdent déjà leurs propres contrôleurs de domaine doivent au moins disposer d'un serveur RADIUS avec une possibilité de basculement située sur un autre emplacement selon la disponibilité des liaisons WAN. En raison du trafic supplémentaire que cela génère, il conviendra d'évaluer précisément, lors de la planification de l'emplacement des serveurs RADIUS, la capacité des liaisons WAN pour la fiabilité de l'authentification de l'utilisateur local aussi bien que pour l'emplacement des contrôleurs de domaine. Pour obtenir de meilleures performances, les serveurs RADIUS doivent être placés dans le domaine racine d'une forêt afin d'optimiser les opérations Kerberos.

Il conviendra également de définir s'il est possible de placer des serveurs supplémentaires dans les bureaux distants qui semblent en avoir besoin car les bureaux plus petits n'ont peut être pas l'espace ou l'infrastructure nécessaire à la prise en charge de serveurs supplémentaires. Pour résoudre ces problèmes, il est possible de mutualiser un serveur IAS avec un contrôleur de domaine Active Directory. Le tableau suivant présente les avantages et les inconvénients de cette approche.

Tableau 5. Considérations sur la mutualisation d'IAS et des contrôleurs de domaine

Emplacement d'IAS	Avantages	Inconvénients
Mutualisé sur le contrôleur de domaine	Les performances augmentent pour l'authentification et l'autorisation des ordinateurs et des utilisateurs. Requiert des ressources matérielles moins importantes.	Aucune séparation entre administrateurs IAS et administrateurs de domaine Aucune séparation inhérente des problèmes de panne ou de performances associés aux services mutualisés.
Serveurs IAS indépendants	Séparation des administrateurs IAS des administrateurs de domaine La charge et le comportement d'IAS n'ont aucune influence sur le contrôleur de domaine.	Requiert des ressources matérielles supplémentaires.

Comme le montre ce tableau, si les entreprises ont mis en place des stratégies visant à limiter les fonctionnalités de contrôleur de domaine à leurs serveurs, c'est parce qu'ils sont indispensables à l'environnement réseau. Placer des services IAS sur un contrôleur de domaine peut également poser des problèmes de sécurité lorsqu'il y a une séparation de tâches entre les deux groupes administratifs dans la mesure où il n'y a pas de séparation entre l'administration IAS et les fonctions du groupe d'administration Windows local. Ces problèmes doivent être pris en compte avant d'opter pour la mutualisation des services IAS. Cette approche présente néanmoins des avantages en termes de performances, sans parler des avantages financiers, notamment pour les bureaux distants.

Pour compenser les coûts qu'implique l'ajout de serveurs aux bureaux distants, il est possible d'utiliser les contrôleurs de domaine existants (qui sont peut-être déjà présents dans les bureaux distants) en tant que serveurs IAS, soit directement, soit en ajoutant un ordinateur virtuel au contrôleur de domaine existant.

Estimation de la charge du serveur et de la configuration matérielle requise

L'évaluation et la planification des charges serveur potentielles doivent être envisagées en se basant sur les pires scénarios. Que se passerait-il si les utilisateurs WLAN avaient besoin de s'authentifier dans un laps de temps très court lors d'un basculement ? Bien sûr, la conception la plus efficace consiste à déployer le minimum de serveurs requis pour la récupération tout en laissant l'espace nécessaire aux futurs développements.

Lors de la planification des charges du serveur et de la configuration matérielle requise, il est recommandé de tenir compte des informations suivantes :

Le nombre d'utilisateurs et de périphériques nécessitant authentification et comptabilisation.
Les options d'authentification telles que le type EAP et la fréquence des réauthentifications.
Les options RADIUS telles que la journalisation et le suivi des logiciels IAS.

Concernant cette solution, il est important de noter que, contrairement au WEP, l'utilisation de WPA ou de WPA2 avec des services de certificat EAP-TLS permet d'éviter le recours à la réauthentification forcée pour actualiser les clés de session. Par ailleurs, cette solution requiert une surcharge moins importante. Il est également important de noter que le protocole EAP-TLS requiert une clé publique gourmande en ressources processeur pour chaque authentification initiale. Il utilise ensuite les informations d'identification mises en cache pour permettre des reconnexions rapides lors des connexions ultérieures et ce jusqu'à ce que les informations d'identification en cache arrivent à expiration (par défaut, toutes les huit heures). Par ailleurs, la réauthentification a lieu lorsqu'un client passe d'un point d'accès sans fil qui s'authentifie auprès d'un serveur RADIUS à un point d'accès sans fil qui s'authentifie auprès d'un autre serveur d'authentification. Ce phénomène est transparent pour l'utilisateur et ne se produit qu'une seule fois pour chaque serveur d'authentification.

Lors de l'estimation de la capacité du serveur IAS, il peut être utile de considérer le nombre d'authentifications par seconde comme une estimation des charges potentielles du serveur. Le tableau suivant présente des estimations du nombre d'authentifications par seconde d'un serveur IAS avec Active Directory sur une plate-forme Intel Pentium 4 2 GHz.

Tableau 6. Authentifications par seconde

Type d'authentification	Authentifications par seconde
Nouvelles authentifications EAP-TLS	36
Nouvelles authentifications EAP-TLS avec prise en charge de cartes de déchargement	50
Authentifications avec reconnexion rapide	166

**Remarque** Les données de ce tableau ne sont que des estimations que vous pouvez utiliser pour vous aider à planifier la capacité du serveur. Ce tableau indique que le serveur serait capable de traiter 36 nouvelles authentifications par seconde en cas de basculement ou de période de pointe. Ainsi, 100 utilisateurs pourraient être authentifiés en 3 secondes (environ). L'impact de la journalisation sur disque sur la durée de l'authentification est également un facteur à prendre en compte. Un sous-système de disque lent peut avoir un effet négatif sur la durée de l'authentification lorsque le suivi de l'authentification s'effectue via une journalisation détaillée. Veillez à utiliser un sous-système de disque rapide afin de maintenir un temps de réponse raisonnable sur chaque serveur IAS. ##### Authentification WPA 802.11 Nous avons déjà étudié l'approche consistant à utiliser une infrastructure de certificat et RADIUS pour sécuriser les communications sans fil en autorisant l'authentification utilisateur et périphérique. Nous allons à présent examiner comment les données transmises entre les périphériques sans fil sont protégées des recherches tierces et autres risques. Les transmissions radio ont toujours eu la réputation d'être moins sûres que les communications câblées car il est beaucoup plus facile d'intercepter des données transmises par « voie aérienne » que de se connecter à un câble ou à un tableau de connexions, notamment lorsque les ports sont sécurisés. Pour compenser l'insécurité des communications sans fil, il est essentiel de chiffrer les données. Ainsi en cas d'interception, celles-ci ne sont pas directement exploitables par les éventuels intrus. Les caractéristiques WEP initiales du chiffrement sans fil n'étaient pas appropriées pour cette tâche. La norme WPA a alors été créée en tant que sous-ensemble de la norme 802.11i (non encore ratifiée à l'époque) afin de résoudre les failles de la norme WEP. Enfin, la norme WPA2 a été créée en tant qu'implémentation complète de la norme 802.11i désormais officielle. La première différence entre WPA et WPA2 réside dans la méthode de chiffrement. En effet, WPA utilise TKIP alors que WPA2 utilise AES-CCMP (norme plus sécurisée). Bien que la solution fournie dans ce guide permette de sécuriser aussi bien WEP que WPA, il est recommandé d'utiliser WPA2 afin d'utiliser la méthode de sécurisation de réseaux sans fil la plus fiable et la plus efficace, bien entendu, lorsque cela est possible d'un point de vue logistique. Dans le cas contraire, il est également possible d'atteindre un niveau de sécurité adéquat en utilisant WPA avec la solution proposée dans ce guide. ###### Configuration client requise La solution mise en avant dans ce guide a été conçue pour les ordinateurs clients sans fil exécutant Windows XP Professionnel avec SP2 ou Windows XP Édition Tablet PC. Ces versions du système d'exploitation Windows offrent une prise en charge 802.1X et WLAN intégrée. En outre, les clients Windows XP disposent de la fonction d'inscription et de renouvellement automatique des certificats qui rendent ainsi une solution comme celle-ci (basée sur les certificats) particulièrement rentable lorsqu'elle est associée à une infrastructure de certificat. Bien que Windows XP SP2 offre une prise en charge intégrée de WPA, il est indispensable d'installer une mise à jour supplémentaire pour activer la prise en charge de WPA2 IEEE 802.11i sur les clients Windows XP SP2. Pour plus d'informations sur cette mise à jour supplémentaire ainsi que pour obtenir des instructions de téléchargement, reportez-vous à la page sur la [mise à jour WPA2/WPS IE pour Windows XP avec Service Pack 2](http://support.microsoft.com/kb/893357/fr) (cette page peut être en anglais) à l'adresse suivante : http://support.microsoft.com/kb/893357/fr. ###### Configuration requise pour l'infrastructure serveur Comme nous l'avons vu précédemment, cette solution requiert l'utilisation de services de certificat et de composants IAS de Windows Server 2003. Certaines fonctions intégrées prises en charge par l'implémentation de services de certificat et d'IAS Windows Server 2003 sont spécifiques aux WLAN 802.1X. Bien qu'il soit possible de déployer IAS et des services de certificat sur des versions antérieures de Windows, ce guide a été rédigé spécifiquement pour un environnement Active Directory Windows Server 2003. ###### Configuration requise pour les points d'accès sans fil Ce guide met l'accent sur la sécurité d'une solution WLAN, il ne donne aucun conseil de déploiement, de positionnement ou de sélection de canal pour les points d'accès sans fil. Pour plus d'informations sur des problèmes spécifiques, sur la configuration ou sur le positionnement des points d'accès sans fil, reportez-vous aux guides ou au site Web du fournisseur. Cette solution est encore plus efficace lorsqu'elle est utilisée avec des points d'accès sans fil certifiés WPA2 IEEE 802.11i et dotés d'une fonction basculement/restauration automatique intégrée. Il est toutefois possible d'implémenter cette solution en utilisant un matériel certifié WPA sans s'éloigner véritablement des indications fournies dans ce guide, tout en maintenant un niveau de sécurité très élevé. Bien qu'il soit également possible d'implémenter cette solution avec la norme WEP, cette méthode n'est pas recommandée et n'est pas présentée dans ce guide. #### Déploiement et gestion Bien que cette section présente des instructions pas-à-pas d'installation et de configuration des serveurs et services requis dans le cadre de cette solution, elle ne décrit pas les étapes d'installation et de configuration requises pour des systèmes d'exploitation tels que Windows Server 2003 et Windows XP Professionnel. Il est entendu que la plupart des entreprises ont mis en place des processus de conception et des règles de renforcement. ##### Certificats Bien que cette section fournisse des conseils détaillés d'installation d'une infrastructure PKI, elle ne contient aucune information sur les processus de conception et de renforcement des serveurs car on considère ici qu'un processus standardisé est déjà mis en place pour ces procédures. On considère également que les serveurs d'autorité de certification ont déjà été configurés avec une image de base et renforcés par un processus d'entreprise standard préalablement à cette phase de la solution. **Remarque** N'oubliez pas que l'autorité de certification racine ne doit jamais être rattachée au réseau et que toute étape d'un processus de conception et de renforcement des serveurs de l'entreprise impliquant une connexion réseau doit être modifiée afin de tenir compte de cette exception. ###### Informations de configuration définies par l'utilisateur Le tableau suivant répertorie des paramètres spécifiques aux entreprises. Ces paramètres doivent être étudiés avant de mettre en œuvre le déploiement de la solution présentée plus loin dans ce guide. Tout au long du guide, les espaces utilisés pour décrire les paramètres utilisent un format calqué sur le nom du paramètre. Par exemple, le nom DNS du domaine racine d'une forêt Active Directory sera présenté comme suit : *NomDomaine*.com. Les valeurs répertoriées en italique doivent être remplacées par les informations spécifiques à l'entreprise, collectées au cours de ce processus. **Tableau 7. Informations de configuration définies par l'utilisateur**

Élément de configuration	Référence	Paramètre
Nom DNS de la forêt Active Directory
Nom distinctif (DN, Distinguished Name) de la racine de la forêt	Pkiparams.vbs
Nom NetBIOS du domaine
Nom NetBIOS du groupe de travail de l'autorité de certification racine
Nom du serveur de l'autorité de certification racine
Nom du serveur de l'autorité de certification émettrice
Nom commun (CN) X.500 de l'autorité de certification racine
Nom commun (CN) X.500 de l'autorité de certification émettrice
Nom d'hôte entièrement qualifié du serveur Web utilisé pour publier des certificats d'autorité de certification	Pkiparams.vbs

###### Éléments de configuration conseillés pour la solution Les éléments répertoriés dans le tableau suivant ne doivent pas nécessairement être modifiés, sauf si une configuration différente est requise. Avant de modifier des paramètres du tableau ci-dessous, assurez-vous d'avoir bien évalué les conséquences qui peuvent en découler et les modifications de dépendance que cela peut entraîner. **Tableau 8. Éléments de configuration conseillés pour la solution**

Élément de configuration	Référence	Paramètre
Groupes de sécurité du rôle d'administration
Administrateurs du conteneur de configuration des services de clés publiques.	ca_setup.wsf	Enterprise PKI Admins
Groupe administratif autorisé à publier des listes de révocation de certificats (CRL) et des certificats d'autorité de certification (CA) dans le conteneur Configuration de l'entreprise.	ca_setup.wsf	Enterprise PKI Publishers
Groupe administratif chargé de la configuration et de la maintenance des autorités de certification, du contrôle de l'affectation de tous les autres rôles de l'autorité de certification et du renouvellement du certificat de l'autorité de certification.	ca_setup.wsf	CA Admins
Groupe administratif chargé de l'approbation de l'inscription des certificats et des demandes de révocation (rôle CA Officer).	ca_setup.wsf	Certificate Managers
Groupe administratif chargé de gérer l'audit et les journaux de sécurité sur l'autorité de certification.	ca_setup.wsf	CA Auditors
Groupe administratif chargé de gérer les sauvegardes de l'autorité de certification	ca_setup.wsf	CA Backup Operators
Configuration IIS
Nom du répertoire virtuel IIS utilisé pour publier des informations sur les listes de révocation et les certificats de l'autorité de certification.	Pkiparams.vbs	pki
Chemin physique de l'autorité de certification émettrice qui correspond au répertoire virtuel IIS.	C:\CAWWWPub	Pkiparams.vbs
Paramètres de l'autorité de certification courants
Lecteur et chemin de stockage des fichiers de demande de services de certificats	C:\CAConfig	Pkiparams.vbs
Lecteur et chemin de stockage des journaux de la base de données des services de certificat.		%windir%\System32\CertLog
Configuration de l'autorité de certification racine
Longueur de la clé de l'autorité de certification racine (voir Remarque)	4096
Période de validité du certificat de l'autorité de certification racine (années)	Pkiparams.vbs	16
Période de validité maximum pour les certificats émis par l'autorité de certification racine (années)	Pkiparams.vbs	8
Intervalle de publication de la liste de révocation pour l'autorité de certification racine (mois)	Pkiparams.vbs	6
Période de chevauchement de la liste de révocation (jours)	Pkiparams.vbs	10
Période de publication des CRL-Delta pour l'autorité de certification racine (heures, 0 = désactivée)	Pkiparams.vbs	0
Configuration de l'autorité de certification émettrice
Lecteur et chemin de stockage de la base de données des services de certificat.		D:\CertLog
Longueur de la clé de l'autorité de certification émettrice		2048
Période de validité du certificat de l'autorité de certification émettrice (années)	Pkiparams.vbs	8
Période de validité maximum pour les certificats émis par l'autorité de certification émettrice (années)	Pkiparams.vbs	4
Intervalle de publication de la liste de révocation pour l'autorité de certification émettrice (jours)	Pkiparams.vbs	7
Période de chevauchement de la liste de révocation (jours)	Pkiparams.vbs	4
Période de publication des CRL-Delta pour l'autorité de certification émettrice (jours, 0 = désactivée)	Pkiparams.vbs	1
Période de chevauchement des CRL-Delta (jours)	Pkiparams.vbs	1
Divers
Chemin des scripts d'installation		C:\MSSScripts

**Remarque** L'utilisation de clés de 4 096 bits peut poser des problèmes de compatibilité lorsqu'elles sont utilisées par certains périphériques ou par d'anciens logiciels d'autres fournisseurs. Toutes les applications susceptibles d'utiliser des certificats émis par l'autorité de certification racine doivent être testées avec des clés de certificat de cette taille afin de garantir leur bon fonctionnement. En cas de problème de compatibilité lié à la longueur de la clé de l'autorité de certification racine, celle-ci peut être réduite à 2 048 bits. ###### Installations de scripts de configuration sur les serveurs CA Les scripts de support fournis dans ce guide sont destinés à vous aider à configurer la solution présentée dans les sections suivantes. Ces scripts doivent être installés sur chaque serveur CA. Vous ne devez pas les supprimer après les avoir utilisés sur les serveurs. Pour installer ces scripts, créez tout d'abord un dossier C:\\MSSScripts, puis copiez-les dans ce dossier. ###### Installation et configuration d'IIS sur le serveur d'autorité de certification émettrice IIS (Internet Information Services) est utilisé comme point de téléchargement par les clients non-Windows afin de récupérer des listes de révocation et des certificats CA. L'autorité de certification racine n'est pas obligée de fournir ce service, notamment parce qu'elle ne doit pas être connectée au réseau, mais l'autorité de certification émettrice doit pouvoir y accéder. IIS peut également être utilisé pour héberger des pages d'inscription Web des services de certificat, bien que celles-ci ne soient pas utilisées dans le cadre de la solution. Si les pages d'inscription Web sont installées sur un système autre que l'autorité de certification émettrice, ce serveur doit être signalé comme « Approuvé pour la délégation » en définissant cette propriété dans l'objet ordinateur du serveur dans Active Directory. IIS peut être installé à l'aide du gestionnaire de composants facultatifs de Windows (Panneau de configuration, puis Ajouter/Supprimer des composants Windows). La liste suivante répertorie les composants à installer : - Serveur d'application - Activer l'accès réseau COM+ - Services IIS - Fichiers communs - Gestionnaire des services IIS - Service World Wide Web **Pour installer IIS** 1. À l'invite, exécutez la commande suivante : ``` Sysocmgr /i:sysoc.inf /u:C:\\MSSScripts\\OC\_AddIIS.txt ``` Cette commande invite le gestionnaire de composants facultatifs à utiliser les configurations de composants spécifiées dans le fichier d'installation automatique C:\\MSSScripts\\OC\_AddIIS.txt, comme suit : ``` [Components] complusnetwork = On iis_common = On iis_asp = On iis_inetmgr = On iis_www = On ``` **Remarque** Dans ce fichier de configuration les pages ASP (Active Server Pages) sont activées, toutefois, si les pages d'inscription Web des services de certificat ne sont pas nécessaires, les pages ASP doivent être désactivées en supprimant la ligne **iis\_asp = on** avant d'exécuter le fichier sysocmgr.exe. Ce paramètre peut être activé ultérieurement si nécessaire. 2. Exécutez à nouveau le gestionnaire de composants facultatifs comme suit et vérifiez que les composants installés correspondent à ceux répertoriés dans le tableau précédent. ``` sysocmgr /i:sysoc.inf ``` Aucun autre sous-composant du serveur d'application n'est requis et n'a donc besoin d'être sélectionné. Configuration d'IIS pour l'accès aux informations de l'autorité (AIA) et la publication des points de distribution de la liste de révocation de certificats (CDP) sur l'autorité de certification émettrice Vous devez créer un répertoire virtuel sur IIS pour l'utiliser comme emplacement HTTP pour les points de publication du certificat CA et de la liste de révocation de certificats (identifiés en tant qu'AIA et CDP). **Pour créer un répertoire virtuel sur IIS** 1. Ouvrez une session sur le serveur IIS en disposant de privilèges d'administrateur local. 2. Créez un dossier **C:\\CAWWWPub**, destiné à recevoir les certificats CA et les listes de révocation de certificats. 3. Définissez la sécurité applicable au dossier selon le tableau suivant : **Tableau 9. Autorisations du répertoire virtuel**

Utilisateur/Groupe	Autorisation	Autoriser/Refuser
Administrateurs	Contrôle total	Autoriser
Système	Contrôle total	Autoriser
Créateurs propriétaires	Contrôle total (sous-dossiers et fichiers uniquement)	Autoriser
Utilisateurs	Lecture et affichage du contenu du dossier	Autoriser
IIS_WPG	Lecture et affichage du contenu du dossier	Autoriser
Compte Invité Internet	Écriture	Refuser

4. À l'aide de la console de gestion d'IIS, créez un nouveau répertoire virtuel sous le site Web par défaut : - Nommez le répertoire virtuel **pki** - Spécifiez le chemin **C:\\CAWWWPub** 5. Désactivez l'option **Exécuter les scripts** au niveau des autorisations d'accès au répertoire virtuel. 6. Vérifiez que l'authentification anonyme est activée pour le répertoire virtuel. Choix d'un alias DNS pour le point de publication HTTP Vous devez créer un alias DNS générique (CNAME) qui corresponde au serveur IIS hébergeant CDP et AIA. Cet alias DNS doit être utilisé lors de la configuration des chemins CDP et AIA des autorités de certification dans les sections suivantes. L'utilisation d'alias permet de déplacer facilement les points de publication CA sur d'autres serveurs ou emplacements du réseau sans avoir à émettre de nouveau des certificats d'autorité de certification. ###### Autres configurations et composants de système d'exploitation Outre les étapes de configuration présentées jusqu'ici, d'autres éléments recommandés doivent être pris en compte, et notamment les suivants : - Service Mettre les certificats racine à jour Le service Mettre les certificats racine à jour doit être désactivé. En effet, il n'est pas souhaitable que l'approbation de racine des autorités de certification soit mise à jour automatiquement. Pour supprimer ce service : à l'invite, exécutez la commande suivante : ``` sysocmgr /i:sysoc.inf /u:C:\\MSSScripts\\OC\_RemoveRootUpdate.txt ``` Le fichier OC\_RemoveRootUpdate.txt contient les lignes suivantes : ``` \[Components\] rootautoupdate = off ``` - Vérifiez que l'autorité de certification racine n'est pas connectée au réseau et que l'autorité de certification émettrice est dépourvue de toute connectivité Internet entrante ou sortante. - Recherchez les service packs et mises à jour supplémentaires éventuellement requis suite à l'installation d'IIS. - Installez les outils de support Windows Server 2003. Bien qu'ils ne soient pas indispensables, il peut être utile d'avoir ces outils à disposition pour certaines opérations de l'autorité de certification et de dépannage général. - Installez CAPICOM. CAPICOM 2.1 est requis sur l'autorité de certification racine et l'autorité de certification émettrice pour certains scripts de configuration et de gestion fournis dans ce guide. Pour plus d'informations sur [CAPICOM](http://www.microsoft.com/downloads/details.aspx?displaylang=fr&familyid=860ee43a-a843-462f-abb5-ff88ea5896f6) et pour accéder à un lien de téléchargement, consultez la page www.microsoft.com/downloads/details.aspx?displaylang=fr&FamilyID=860ee43a-a843-462f-abb5-ff88ea5896f6. ###### Préparation d'Active Directory pour l'infrastructure PKI La configuration minimum requise pour une infrastructure de domaine Active Directory présentée dans cette section est basée sur une architecture Active Directory Microsoft Windows Server 2003. Si l'implémentation d'Active Directory utilisée est basée sur Windows 2000, une autre configuration peut être nécessaire. Pour plus d'informations sur la configuration supplémentaire requise pour une structure de domaine basée sur Windows 2000, consultez la page [Comment faire pour augmenter les niveaux fonctionnels du domaine et de la forêt dans Windows Server 2003](http://support.microsoft.com/kb/322692/fr) (cette page peut être en anglais) à l'adresse suivante : http://support.microsoft.com/kb/322692/fr. Cette solution requiert également un niveau fonctionnel de Windows 2000 en mode natif (ou supérieur) pour le domaine dans lequel les serveurs des autorités de certification seront installés. Cette exigence est due au fait que cette solution utilise des groupes Active Directory universels, disponibles dans Windows 2000 en mode natif (ou supérieur). Création de groupes d'administration pour l'autorité de certification et l'infrastructure de clés publiques (PKI) Cette solution définit plusieurs groupes de sécurité qui correspondent à des rôles administratifs distincts. Cette approche offre un contrôle accru de la délégation des responsabilités relatives à l'administration de l'autorité de certification ainsi que des principes de sécurité de moindres privilèges. Toutefois, il n'est pas nécessaire d'utiliser ces rôles s'ils ne correspondent à aucun modèle administratif de l'entreprise. **Pour créer des groupes d'administration de l'autorité de certification dans un domaine** 1. Ouvrez une session sur un ordinateur membre du domaine en utilisant un compte permettant de créer des objets de groupe et utilisateur dans le conteneur Utilisateurs. 2. Exécutez la commande suivante pour créer des groupes de gestion de l'autorité de certification pour le domaine : ``` Cscript //job:CertDomainGroups C:\\MSSScripts\\ca\_setup.wsf ``` Ce script crée les groupes de sécurité répertoriés dans le tableau ci-dessous. Ces groupes sont créés en tant que groupes universels dans le conteneur Utilisateurs du domaine. Vous pouvez les déplacer dans une unité d'organisation plus appropriée, en fonction des éventuelles stratégies mises en place par l'entreprise. **Tableau 10. Noms de groupe et objectifs**

Nom de groupe	Objectif
Enterprise PKI Admins	Administrateurs du conteneur de configuration des services de clés publiques.
Enterprise PKI Publishers	Autorisés à publier les listes de révocation et les certificats de l'autorité de certification dans le conteneur Configuration de l'entreprise.
CA Admins	Dotés de fonctions d'administration complètes de l'autorité de certification, y compris pour déterminer l'appartenance des autres rôles.
Certificate Managers	Gèrent l'émission et la révocation des certificats.
CA Auditors	Gèrent les données d'audit relatives à l'autorité de certification.
CA Backup Operators	Sont autorisés à sauvegarder et restaurer les données et les clés de l'autorité de certification.

Les procédures de configuration présentées ci-après dans ce guide requièrent l'utilisation de comptes appartenant aux groupes Enterprise PKI Admins, Enterprise PKI Publishers et CA Admins. Ainsi ces groupes doivent comporter les comptes appropriés avant de poursuivre. Si une seule personne est chargée des rôles relatifs à l'autorité de certification, un seul compte peut être affecté à tous les groupes. Toutefois, dans la plupart des entreprises, une séparation des rôles et des tâches du personnel est définie, même si elle n'est pas toujours aussi complexe que dans le tableau précédent. Pour les entreprises qui ont mis en place une séparation simplifiée des tâches, le tableau suivant répertorie des séparations de responsabilité courantes. **Tableau 11. Modèle d'administration simplifié**

Rôle d'administration	Appartenance au groupe
CA Administrator	Enterprise PKI Admins, CA Admins, Certificate Managers, Administrateurs
CA Auditor	CA Auditors, Administrateurs
CA Backup Operator	CA Backup Operators

**Suggestion de structure d'UO du domaine** Plusieurs types de groupe et de compte utilisateur sont associés à la gestion et à l'exploitation d'une infrastructure de clés publiques. En fonction des stratégies mises en place, il peut être nécessaire d'organiser ces groupes et utilisateurs dans une structure d'unités d'organisation (UO) spécifique. Dans la mesure où des recommandations existantes de l'entreprise peuvent définir cette structure, les informations suivantes constituent une suggestion de structure qui peut être modifiée en fonction des besoins. **Pour créer une hiérarchie d'UO des services de certificats** 1. Ouvrez une session en utilisant un compte permettant de créer des UO et de déléguer des autorisations à ces UO. 2. Créez une structure d'UO en vous basant sur le tableau suivant : **Tableau 12. Exemple de structure d'UO**

Unité d'organisation	Objectif
Certificate Services	Parent OU
\-Certificate Services Administration	Contient les groupes d'administration chargés de gérer la configuration des autorités de certification et de l'infrastructure de clés publiques de l'entreprise.
\-Certificate Template Management	Contient les groupes chargés de gérer les modèles de certificats.
\-Certificate Template Enrollment	Contient les groupes disposant des autorisations d'inscription et d'inscription automatique pour les modèles du même nom. Le contrôle de ces groupes peut être délégué au personnel approprié sans apporter de modification aux modèles.
\-Certificate Services Test Users	Contient les comptes de test provisoires.

3. Accordez au groupe Enterprise PKI Admins l'autorisation de créer et supprimer des groupes dans l'UO des services de certificats et tous les conteneurs enfants. Octroi d'autorisations au conteneur des services de clés publiques La sécurité du conteneur des services de clés publiques doit être modifiée afin d'autoriser le groupe Enterprise PKI Admins à installer des autorités de certification d'entreprise et à configurer des modèles de certificats même si les comptes du groupe n'appartiennent pas nécessairement au groupe Enterprise Admins. Il est également indispensable d'autoriser le groupe Enterprise PKI Publishers à publier des listes de révocation de certificat et des certificats d'autorité de certification sans disposer des droits Enterprise Admin. Pour apporter les modifications suivantes, vous devez utiliser un compte équivalent à Active Directory Enterprise Admin. **Pour accorder des autorisations au groupe Enterprise PKI Admins** 1. Ouvrez une session en tant que membre du groupe de sécurité Enterprise Admins. 2. Dans le composant logiciel enfichable MMC Sites et Services Active Directory, affichez le nœud **Services** (à partir du menu **Affichage**). Naviguez jusqu'au sous-conteneur Public Key Services et affichez ses propriétés. 3. Dans l'onglet **Sécurité**, ajoutez le groupe de sécurité Enterprise PKI Admins et accordez-lui le Contrôle total. 4. Dans la vue **Avancée**, modifiez les autorisations de ce groupe de sorte que le Contrôle total s'applique à cet objet et à tous les objets enfants. 5. Sélectionnez le conteneur **Services** et affichez ses propriétés. 6. Dans l'onglet **Sécurité**, ajoutez le groupe de sécurité Enterprise PKI Admins et accordez-lui le Contrôle total. 7. Dans la vue **Avancée**, modifiez les autorisations de ce groupe de sorte que le Contrôle total s'applique à cet objet uniquement. **Pour accorder des autorisations au groupe Enterprise PKI Publishers** 1. Ouvrez une session en tant que membre du groupe de sécurité Enterprise Admins. 2. Dans le composant logiciel enfichable MMC Sites et Services Active Directory, affichez le nœud **Services**, puis les propriétés du conteneur Public Key Services\\AIA. 3. Dans l'onglet **Sécurité**, ajoutez le groupe de sécurité Enterprise PKI Publishers et accordez-lui les autorisations suivantes : - Lecture - Écriture - Créer tous les objets enfants - Supprimer tous les objets enfants 4. Dans la vue **Avancée**, modifiez les autorisations de ce groupe de sorte qu'elles s'appliquent à cet objet et à tous les objets enfants. 5. Répétez les étapes 2 à 4 pour les conteneurs suivants : - Public Key Services\\CDP - Public Key Services\\Certification Authorities Octroi d'autorisations au groupe Cert Publishers Le groupe de sécurité Cert Publishers contient les comptes d'ordinateur de toutes les autorités de certification du domaine. Ce groupe sert à appliquer des autorisations aux objets d'ordinateur et d'utilisateur, ainsi qu'aux objets du conteneur CDP mentionné précédemment. Lorsqu'une autorité de certification est installée, son compte d'ordinateur doit être ajouté à ce groupe. Pour autoriser les membres du groupe Enterprise PKI Admins à installer des autorités de certification d'entreprise, vous devez modifier les autorisations de ce groupe. **Pour accorder l'autorisation de modifier l'appartenance au groupe Cert Publishers** 1. Ouvrez une session en tant que membre de Domain Admins pour le domaine dans lequel les autorités de certification émettrices seront installées. 2. Ouvrez le composant MMC Utilisateurs et ordinateurs Active Directory. 3. Dans le menu **Affichage** du composant MMC, vérifiez que l'option **Fonctionnalités avancées** est activée. 4. Localisez le groupe Cert Publishers (par défaut dans le conteneur Utilisateurs) et affichez les propriétés du groupe. 5. Dans l'onglet **Sécurité**, ajoutez le groupe Enterprise PKI Admins, puis cliquez sur le bouton **Avancé**. 6. Sélectionnez le groupe Enterprise PKI Admins dans la liste et cliquez sur le bouton **Modifier**. 7. Sélectionnez l'onglet **Propriétés** et vérifiez que **Cet objet uniquement** est sélectionné dans la zone **Appliquer à**. 8. Faites défiler l'affichage vers le bas et activez la case **Écriture Membres** dans la colonne **Autoriser**. 9. Fermez toutes les boîtes de dialogue en cliquant sur **OK** dans chacune d'elles pour enregistrer les modifications. 10. Vous devez redémarrer le serveur de l'autorité de certification émettrice avant d'installer le composant des services de certificats. Le redémarrage permet au serveur d'intégrer la nouvelle appartenance au groupe à son jeton d'accès. Octroi d'autorisations de restauration au groupe Enterprise PKI Admins Pour pouvoir installer des services de certificats, vous devez être autorisé à restaurer des fichiers et des répertoires dans le domaine dans lequel l'autorité de certification d'entreprise sera installée. Ce droit est notamment requis permettre la fusion des descripteurs de sécurité dans les modèles et les autres objets du répertoire, et accorder aux objets PKI du domaine les autorisations adéquates. Par défaut, ce droit est accordé aux groupes de domaine intégrés : Administrateurs, Opérateurs de serveur et Opérateurs de sauvegarde. Comme vous allez utiliser le groupe Enterprise PKI Admins pour installer l'autorité de certification, vous devez lui accorder le droit de restauration des fichiers et des répertoires. **Pour accorder l'autorisation de restauration au groupe Enterprise PKI Admins** 1. Ouvrez une session en tant que membre de Domain Admins dans le domaine dans lequel l'autorité de certification émettrice sera installée. 2. Ouvrez le composant MMC Utilisateurs et ordinateurs Active Directory. 3. Sélectionnez l'UO des contrôleurs de domaine et affichez les propriétés de cette UO. 4. Dans l'onglet **Stratégie de groupe**, sélectionnez l'objet de stratégie de groupe **Stratégie contrôleurs de domaine par défaut** et cliquez sur **Modifier**. 5. Accédez au dossier Configuration ordinateur\\Paramètres Windows\\Paramètres de sécurité\\Stratégies locales\\Attribution des droits utilisateur et double-cliquez sur **Restauration de fichiers et de répertoires**. 6. Ajoutez le groupe Enterprise PKI Admins à la liste affichée. 7. Fermez la boîte de dialogue et le composant MMC de modification de l'objet de stratégie de groupe. **Remarque** Si vous avez d'autres objets de stratégie de groupe qui définissent le droit utilisateur Restauration de fichiers et de répertoires pour les contrôleurs de domaine, vous devez effectuer cette procédure sur l'objet de stratégie de groupe dont la priorité est la plus haute et non sur la Stratégie contrôleurs de domaine par défaut. Les paramètres de droit utilisateur ne sont pas cumulables. Seul le dernier objet de stratégie de groupe appliqué bénéficiant de ce droit est effectif. ###### Déploiement d'un serveur d'autorité de certification racine Comme mentionné précédemment, ce guide ne fournit pas d'instructions détaillées d'installation de Windows Server 2003 car la plupart des entreprises possèdent déjà des documents relatifs au processus de mise en œuvre des serveurs. Les serveurs d'autorité de certification racine sont différents des autres serveurs dans la mesure où ils ne doivent jamais être connectés à un réseau, et ce afin de garantir leur intégrité. Il est donc primordial de s'assurer que le serveur de l'autorité de certification racine n'est pas connecté au réseau lors du processus de mise en œuvre et qu'à un moment donné les cartes réseau sont désactivées afin d'éviter toute connexion accidentelle. Comme le serveur n'est pas connecté au réseau, il doit résider dans un groupe de travail dont le nom doit être choisi et documenté avant l'installation. **Remarque** Même si l'autorité de certification racine est mise en œuvre et maintenue hors ligne, il est essentiel de lui attribuer un nom unique dans l'environnement réseau. Fichier CAPolicy.inf Après avoir mis en place le serveur requis pour l'autorité de certification racine et installé le système d'exploitation, vous devez créer un fichier capolicy.inf. Ce fichier est indispensable à la création d'une autorité de certification racine car il précise les caractéristiques du certificat CA auto-signé, comme les longueurs de clé et la période de validité du certificat. Les informations CRL et AIA ne sont pas nécessaires pour un certificat CA racine, c'est pourquoi les paramètres CRLDistributionPoint et AuthorityInformationAccess sont définis comme Vide dans le fichier capolicy.inf. **Pour créer un fichier CAPolicy.inf** 1. Créez un fichier de texte brut dans un éditeur de texte comme par exemple le Bloc-notes, et entrez le texte suivant :

```
                [version]
                Signature=”$Windows NT$”

                [Certsrv_server]
                RednewalKeyLength=4096
                RenewalValidityPeriod=Years
                RenewalValidityPeriodUnits=16

                [CRLDistributionPoint]
                Empty=true

                [AuthorityInformationAccess]
                Empty=true
              
```

Si une déclaration CPS est définie pour cette autorité de certification, insérez le texte suivant dans le fichier capolicy.inf. Remplacez toutes les valeurs en italique par celles qui correspondent spécifiquement à cette implémentation.
```
                [CAPolicy]
                Policies=company CPS name

                [company CPS name]
                OID=the.company.OID
                URL=”http://www.companyurl.com/cpspagename.htm”
```
Enregistrez ce fichier texte sous %windir%\Capolicy.inf (remplacez %windir% par le chemin de dossier absolu dans lequel Windows est installé, tel que C:\Windows). Vous devez être administrateur local ou bénéficier d'autorisations équivalentes pour enregistrer le fichier dans le dossier Windows.

Installation des composants logiciels des services de certificats
Pour installer les composants logiciels de l'autorité de certification, utilisez l'Assistant composants de Windows. Notez que le support d'installation de Windows Server 2003 est nécessaire pour terminer cette installation.

Pour installer les services de certificats

Ouvrez une session en tant que membre des administrateurs locaux et exécutez le gestionnaire de composants facultatifs ou, à partir du Panneau de configuration, cliquez sur Ajout/Suppression de programmes/Composants Windows.
```
sysocmgr /i:sysoc.inf  
```
Sélectionnez le composant des services de certificats (cliquez sur Oui pour ignorer le message d'avertissement sur le changement de nom).
Sélectionnez Autorité de certification racine autonome comme type de CA et vérifiez que l'option Utiliser les paramètres personnalisés est activée.
Dans la boîte de dialogue Paire de clés publique et privée, conservez les valeurs par défaut des paramètres, sauf pour la longueur de clé qui doit être fixée à 4 096 et pour le type de fournisseur de services cryptographiques qui doit être défini sur Microsoft Strong Cryptographic Provider.
Entrez dans les champs suivants les informations d'identification de l'autorité de certification collectées au cours de la phase de prérequis :
- Nom commun de l'autorité de certification :
- Suffixe du nom distinctif :
- Période de validité : 8 ans
Le fournisseur de services cryptographiques génère la paire de clés, qui est ensuite enregistrée dans la base de clés de l'ordinateur local.

Remarque Si une autorité de certification était déjà installée sur ce système, un message d'avertissement vous signale que vous risquez d'écraser la clé privée de l'installation précédente. Avant de poursuivre, assurez-vous au préalable que vous n'aurez plus besoin de cette clé.
Conservez les valeurs par défaut pour les emplacements de la base de données de certificats, les journaux de la base de données et le dossier de configuration. Le gestionnaire de composants facultatifs installe alors les composants des services de certificats. Le support d'installation de Windows Server 2003 est requis.
Cliquez sur OK pour ignorer les messages d'avertissement relatifs à IIS et terminer l'installation.

Configuration des propriétés de l'autorité de certification racine
Certains paramètres spécifiques à l'environnement seront utilisés dans le cadre de la configuration de l'autorité de certification racine. Ces paramètres doivent être collectés conformément aux instructions de la section relative aux prérequis (développée précédemment dans ce guide) avant de poursuivre.

Pour configurer les propriétés de l'autorité de certification racine

Ouvrez une session sur le serveur de l'autorité de certification en tant que membre du groupe des administrateurs locaux.
Personnalisez le script C:\MSSScripts\pkiparams.vbs de sorte qu'il inclue les éléments suivants :
- Modifiez la valeur du paramètre AD_ROOT_DN de façon à ce qu'elle corresponde au DN du domaine de la racine de la forêt Active Directory.
- Modifiez le paramètre HTTP_PKI_VROOT de façon à ce qu'il corresponde au chemin HTTP vers le répertoire IIS virtuel défini précédemment.

Exécutez le script suivant :

Cscript //job:RootCAConfig C:\\MSSScripts\\ca\_setup.wsf

Configuration des rôles d'administration
Pour utiliser les groupes de sécurité créés précédemment, vous devrez les associer à des rôles d'administration (auditeur, gestionnaire de certificat, etc.).

Remarque Le modèle de délégation simplifié présenté précédemment dans ce guide sera probablement utilisé par la plupart des entreprises de taille moyenne, toutefois, nous vous présentons ici un modèle plus flexible au cas où davantage de séparations seraient requises.

Pour configurer les rôles d'administration de l'autorité de certification racine

Dans la console de gestion de l'autorité de certification, cliquez sur Propriétés.
Cliquez sur l'onglet Sécurité, ajoutez les groupes de sécurité locaux répertoriés dans le tableau suivant, puis ajoutez les autorisations présentées pour chaque groupe.

Tableau 13. Entrées des autorisations de l'autorité de certification

Groupe	Autorisation	Autoriser/Refuser
CA Admins	Gérer l'autorité de certification	Autoriser
Certificate Managers	Émettre et gérer des certificats	Autoriser

3. D'autres rôles de sécurité de l'autorité de certification ont déjà été définis pour ce serveur par l'intermédiaire de la stratégie de sécurité appliquée précédemment. Transfert sur disque du certificat de l'autorité de certification racine et de la liste de révocation de certificats Vous devez copier le certificat de l'autorité de certification racine et la liste de révocation de certificats à partir de l'autorité de certification afin qu'ils puissent être publiés sur le serveur Active Directory et sur le serveur de publication de la liste de révocation et du certificat IIS. Dans l'exemple suivant, nous utiliserons un disque, mais tout support amovible peut être utilisé, y compris les lecteurs USB. **Pour copier sur disque le certificat de l'autorité de certification racine et la liste de révocation de certificats** 1. Ouvrez une session sur l'autorité de certification racine en tant que membre du groupe CA Admins local, puis insérez le support amovible dans le serveur. 2. Exécutez le script suivant pour copier sur disque le certificat de l'autorité de certification : ``` Cscript //job:GetCACerts C:\\MSSScripts\\CA\_Operations.wsf ``` 3. Exécutez le script suivant pour copier sur disque la liste de révocation de certificats de l'autorité de certification : ``` Cscript //job:GetCRLs C:\\MSSScripts\\CA\_Operations.wsf ``` 4. Nommez, datez et conservez le disque dans un endroit sûr en vue d'une utilisation ultérieure. ###### Publication des informations relatives à l'autorité de certification racine Avant d'installer l'autorité de certification émettrice, vous devez publier le certificat de l'autorité de certification racine dans le magasin racine approuvé d'Active Directory et publier la liste de révocation de l'autorité de certification racine dans le conteneur CDP d'Active Directory. Ainsi, tous les membres du domaine importent le certificat de l'autorité de certification dans leur propre magasin racine, ce qui leur permet de vérifier l'état de révocation de tous les certificats émis par l'autorité de certification racine. Pour effectuer cette procédure, il est recommandé d'utiliser l'autorité de certification émettrice car elle contient déjà les fichiers requis (Certutil.exe et les bibliothèques certadm.dll et certcli.dll). Toutefois, vous pouvez utiliser n'importe quel serveur membre à condition que l'exécutable certutil.exe et les fichiers DLL associés soient installés sur ce système Windows Server 2003. **Pour publier le certificat de l'autorité de certification racine et la liste de révocation de certificats dans Active Directory** 1. Ouvrez une session en tant que membre du groupe Enterprise PKI Admins sur un ordinateur membre du domaine et satisfaisant aux exigences mentionnées précédemment, puis insérez le disque créé pour stocker le certificat de l'autorité de certification et la liste de révocation de certificats 2. Exécutez le script suivant pour publier le certificat de l'autorité de certification dans Active Directory. ``` Cscript //job:PublishCertstoAD C:\\MSSScripts\\CA\_Operations.wsf ``` 3. Exécutez le script suivant pour publier la liste de révocation de certificats dans Active Directory. ``` Cscript //job:PublishCRLstoAD C:\\MSSScript\\CA\_Operations.wsf ``` Publication du certificat de l'autorité de certification racine et de la liste de révocation de certificats sur le serveur Web Cette étape est nécessaire car des versions HTTP des URL CDP et AIA sont spécifiées dans les extensions des certificats émis par cette autorité de certification. Lorsque ces extensions existent, elles doivent être respectées en publiant les listes de révocation de certificats et les certificats dans les URL configurées. **Remarque** Cette procédure reste la même, que le serveur Web de publication des informations CDP et AIA se trouve sur l'autorité de certification émettrice ou sur un autre serveur. Toutefois, elle suppose que le répertoire virtuel correspond à celui défini précédemment dans la procédure de configuration d'IIS (C:\\CAWWWPub). Si le chemin choisi est différent, vous devez modifier la valeur de WWW\_LOCAL\_PUB\_PATH dans le script PKIParams.vbs. **Pour publier le certificat de l'autorité de certification racine et la liste de révocation de certificats sur l'URL Web** 1. Ouvrez une session sur le serveur Web en tant qu'administrateur local ou en utilisant un compte disposant d'autorisations équivalentes. 2. Vérifiez que le disque contenant le certificat de l'autorité de certification racine et la liste de révocation de certificats se trouve dans le lecteur. 3. Exécutez le script suivant pour publier le certificat de l'autorité de certification dans le dossier du serveur Web : ``` Cscript //job:PublishRootCerttoIIS C:\\MSSScripts\\CA\_Operations.wsf ``` 4. Exécutez le script suivant pour publier les listes de révocation de certificats de l'autorité de certification dans le dossier du serveur Web : ``` Cscript //job:PublishRootCRLstoIIS C:\\MSSScripts\\CA\_Operations.wsf ``` ###### Déploiement du serveur de l'autorité de certification émettrice L'autorité de certification racine est installée et ses certificats publiés. À présent, le serveur de l'autorité de certification émettrice peut être déployé. L'installation des services de certificats implique un ensemble complexe d'interactions entre l'autorité de certification émettrice, l'autorité de certification racine, Active Directory et le serveur Web. Pour mieux comprendre ces interactions, prenez comme exemple le schéma suivant. [![](images/Cc875845.SWCG5(fr-fr,TechNet.10).gif)](https://technet.microsoft.com/fr-fr/cc875845.swcg5_big(fr-fr,technet.10).gif) **Figure 5. Processus d'installation des certificats** Les phases d'interaction présentées dans ce schéma sont les suivantes : 1. Publication du certificat de l'autorité de certification racine et de la liste de révocation de certificats dans Active Directory à l'aide d'un support amovible. 2. Publication du certificat de l'autorité de certification racine et de la liste de révocation de certificats sur le serveur Web à l'aide d'un support amovible. 3. Installation du logiciel des services de certificats, ce qui génère une demande de certificat que vous devez transmettre à l'autorité de certification racine sur un support amovible. 4. Installation du certificat de l'autorité de certification émettrice correspondant à l'aide du support amovible. 5. Publication du certificat de l'autorité de certification émettrice et de la liste de révocation de certificats sur le serveur Web x. Cette étape s'effectue automatiquement au cours de la routine d'installation de l'autorité de certification de l'entreprise. **Préparation du fichier Capolicy.inf pour l'autorité de certification émettrice** Le fichier CAPolicy.inf n'est pas indispensable pour l'autorité de certification émettrice. En revanche, il est indispensable si vous devez modifier la taille de la clé utilisée par l'autorité de certification. Vous devez créer ce fichier avant d'installer l'autorité de certification émettrice, même s'il est possible d'en ajouter un ultérieurement et de renouveler le certificat de l'autorité de certification si nécessaire. **Pour créer un fichier CAPolicy.inf** 1. Ouvrez une session sur le serveur de l'autorité de certification émettrice en tant qu'administrateur local ou en utilisant un compte disposant d'autorisations équivalentes. 2. Créez un fichier de texte brut dans un éditeur de texte, tel que le Bloc-notes, et entrez les informations suivantes : ``` \[Version\] Signature= “$Windows NT$” \[Certsrv\_Server\] RenewalKeyLength=2048 ``` 3. Si une déclaration CPS est définie pour cette autorité de certification, intégrez les lignes suivantes dans le fichier Capolicy.inf : ``` \[CAPolicy\] Stratégies=policyname \[policyname\] OID=the.org.oid URL=”http://the.org.url/TheCPSPage.htm” ``` **Remarque** Les éléments en italique doivent être remplacés par les informations spécifiques à l'entreprise. 4. Enregistrez le fichier sous *%windir%*\\Capolicy.inf (remplacez *%windir%* par le chemin de dossier absolu dans lequel Windows est installé, tel que C:\\Windows). **Installation des composants logiciels des services de certificats** Dans cette étape, comme lors de l'installation des services de certificats sur l'autorité de certification racine, vous allez devoir utiliser le support d'installation de Windows Server 2003 et l'Assistant Composants Windows. **Pour installer les services de certificats** 1. Ouvrez une session sur l'autorité de certification émettrice en tant que membre du groupe d'administrateurs locaux ou en utilisant un compte équivalent, puis exécutez le gestionnaire de composants facultatifs : ``` sysocmgr /i:sysoc.inf ``` 2. Sélectionnez le composant des services de certificats (cliquez sur **OK** pour ignorer le message d'avertissement sur le changement de nom). 3. Sélectionnez Autorité de certification secondaire d'entreprise comme type CA et vérifiez que l'option **Utiliser les paramètres personnalisés** est activée. 4. Dans la boîte de dialogue **Paire de clés publique et privée**, conservez les paramètres par défaut, sauf pour : - Longueur de clé : 2 048 bits - Type CSP : Microsoft Strong Cryptographic Provider 5. Entrez les informations d'identification de l'autorité de certification comme suit : - Nom commun de l'autorité de certification - Suffixe du nom distinctif - Période de validité : (déterminée par l'autorité de certification parente) 6. Le fournisseur de services cryptographiques (CSP) génère une paire de clés et l'enregistre dans la base de clés de l'ordinateur local. 7. Indiquez les emplacements de la base de données de certificats, des journaux de la base de données et du dossier de configuration, de la manière suivante : - Base de données de certificats : D:\\CertLog - Journal de la base de données de certificats : %windir%\\System32\\CertLog - Dossier partagé : désactivé Lorsque cela est possible, conservez les bases de données et journaux de l'autorité de certification sur des volumes distincts pour des raisons de performances et de récupération. La base de données de certificats et les journaux de la base de données doivent être conservés sur des disques locaux NTFS. 8. À ce stade, un fichier de demande de certificat est généré. Copiez-le sur un disque. Le gestionnaire de composants facultatifs installe alors les composants des services de certificats. Pour ce faire, il doit accéder au support d'installation de Windows Server 2003. 9. Cliquez sur **OK** pour ignorer le message d'avertissement relatif à IIS et poursuivez l'installation. L'Assistant d'installation affiche un message précisant que pour continuer, vous devrez fournir un certificat délivré par l'autorité de certification parente. **Soumission de la demande de certificat à l'autorité de certification racine** Ensuite, vous devez transmettre la demande de certificat de l'autorité de certification émettrice à l'autorité de certification racine afin qu'elle soit signée et qu'un certificat soit émis en direction de l'autorité de certification émettrice. **Pour soumettre la demande de certificat à l'autorité de certification racine** 1. Ouvrez une session sur l'autorité de certification racine en tant que membre du groupe Certificate Managers. 2. Vérifiez que le disque utilisé pour stocker le fichier de demande de certificat se trouve dans le lecteur. 3. À partir de la console de gestion de l'autorité de certification, dans le menu **Tâches**, sélectionnez **Soumettre une nouvelle demande**, puis soumettez la demande transférée à partir de l'autorité de certification émettrice. 4. Localisez le certificat nouvellement délivré dans le conteneur Certificats délivrés et ouvrez-le. 5. Vérifiez l'exactitude des informations du certificat, puis exportez le certificat dans un fichier en cliquant sur Copier dans un fichier. Enregistrez ce fichier sur un disque sous forme de fichier PKCS\#7 et sélectionnez l'option permettant d'inclure tous les certificats de la chaîne possibles. **Actualisation des informations de certificat sur l'autorité de certification émettrice** Le certificat de l'autorité de certification racine a été préalablement publié dans le magasin racine approuvé d'Active Directory. Vous devez à présent vérifier que l'autorité de certification émettrice a téléchargé ces informations et placé le certificat dans son propre magasin racine approuvé. **Pour actualiser les informations de confiance du certificat au niveau de l'autorité de certification émettrice** 1. Ouvrez une session sur l'autorité de certification émettrice en tant qu'administrateur local ou en utilisant un compte disposant d'autorisations équivalentes. 2. À l'invite, exécutez la commande suivante : ``` certutil –pulse ``` Cette commande oblige l'autorité de certification à télécharger les nouvelles informations racine approuvées à partir du répertoire et à placer le certificat de l'autorité de certification racine dans son propre magasin racine approuvé. Bien que cette étape ne soit pas indispensable, elle permet de vérifier, avant de poursuivre, que les étapes de publication précédentes se sont déroulées avec succès. 3. Exécutez mmc.exe et ajoutez le composant logiciel enfichable Certificats. 4. Sélectionnez **Compte d'ordinateur** comme magasin de certificats à gérer. 5. Vérifiez que le certificat de l'autorité de certification racine figure dans le dossier Autorités de certification racines approuvées. **Installation du certificat sur l'autorité de certification émettrice** La réponse signée de l'autorité de certification racine a été créée sous forme de package de certificat PKCS\#7 et peut désormais être installée sur l'autorité de certification émettrice. Pour publier le certificat de l'autorité de certification dans le magasin Active Directory NTAuth (qui identifie l'autorité de certification comme une autorité de certification d'entreprise), vous devez installer le certificat de l'autorité de certification sur l'autorité de certification émettrice en utilisant un compte appartenant à la fois au groupe Enterprise PKI Admins et au groupe des administrateurs locaux. Le premier groupe est autorisé à installer le certificat de l'autorité de certification dans le répertoire et le second à installer le certificat sur le serveur de l'autorité de certification. Si vous utilisez le modèle d'administration simplifié présenté précédemment, le rôle CAAdmin appartient déjà à ces deux groupes. **Pour installer le certificat de l'autorité de certification émettrice** 1. Ouvrez une session sur l'autorité de certification émettrice en utilisant un compte appartenant à la fois au groupe Enterprise PKI Admins et au groupe des administrateurs locaux. 2. Insérez le disque contenant le certificat signé émis par l'autorité de certification racine. 3. Pour installer le certificat de l'autorité de certification émettrice à partir du disque, dans le menu **Tâches** de la console de gestion de l'autorité de certification, sélectionnez **Installer le certificat**. L'autorité de certification doit alors démarrer. **Configuration des propriétés de l'autorité de certification émettrice** La procédure suivante permet de configurer les paramètres spécifiques à l'environnement (collectés dans la phase des prérequis) sur l'autorité de certification émettrice. Avant de commencer, vérifiez que les informations spécifiques à l'entreprise collectées dans les étapes de prérequis ont été insérées dans le fichier C:\\MSSScripts\\pkiparams.vbs sur l'autorité de certification racine et que ces modifications ont également été transférées sur l'autorité de certification émettrice. **Pour configurer les propriétés de l'autorité de certification émettrice** 1. Ouvrez une session sur le serveur de l'autorité de certification émettrice en tant que membre du groupe des administrateurs locaux. 2. Vérifiez que les modifications apportées au fichier C:\\MSSScripts\\pkiparams.vbs correspondent aux paramètres spécifiques à votre environnement, comme nous l'avons mentionné précédemment. 3. Exécutez le script suivant : ``` Cscript //job:IssCAConfig C:\\MSSScripts\\ca\_setup.wsf ``` **Configuration des rôles d'administration de l'autorité de certification émettrice** Pour utiliser les rôles présentés dans ce guide, vous devez les faire correspondre à des groupes de sécurité. Comme nous l'avons vu précédemment, même si les rôles simplifiés peuvent suffire à la plupart des entreprises de taille moyenne, le processus suivant implémente les rôles détaillés conçus pour offrir une flexibilité et une séparation des responsabilités maximales. **Pour configurer des rôles sur l'autorité de certification émettrice** 1. Ouvrez une session sur le serveur de l'autorité de certification émettrice en tant que membre du groupe des administrateurs locaux. 2. Dans la console de gestion de l'autorité de certification, cliquez sur Propriétés pour modifier les propriétés de l'autorité de certification. 3. Cliquez sur l'onglet **Sécurité**, ajoutez les groupes de sécurité de domaine répertoriés dans le tableau suivant, puis ajoutez les autorisations pour chaque groupe, comme indiqué. **Tableau 14. Autorisations de l'autorité de certification émettrice**

Groupe	Autorisation	Autoriser/Refuser
CA Admins	Gérer l'autorité de certification	Autoriser
Certificate Managers	Émettre et gérer des certificats	Autoriser

4. Vous devez ajouter le groupe CA Auditors au groupe des administrateurs locaux même si ce groupe a déjà été partiellement défini via la stratégie de sécurité appliquée précédemment. ###### Publication des informations relatives à l'autorité de certification émettrice Les certificats et les listes de révocation de certificats sont publiés automatiquement depuis l'autorité de certification émettrice vers Active Directory, sauf lorsqu'il s'agit de leur publication vers les chemins d'accès aux informations de l'autorité (AIA) et des points de distribution (CDP) HTTP. Pour automatiser la publication du certificat de l'autorité de certification vers les chemins AIA et CDP HTTP, vous devez planifier une tâche. Les certificats de l'autorité de certification sont très rarement mis à jour. Ils peuvent donc être publiés manuellement vers AIA en suivant le processus ci-dessous. **Pour publier le certificat de l'autorité de certification émettrice** 1. Ouvrez une session sur l'autorité de certification émettrice en utilisant un compte autorisé à écrire dans le dossier du serveur Web publié. 2. Mettez à jour le paramètre WWW\_REMOTE\_PUB\_PATH dans le fichier C:\\MSSScripts\\PKIParams.vbs afin qu'il corresponde au chemin de destination du dossier du serveur Web. 1. Si le serveur Web se trouve sur un serveur distant, assurez-vous que le dossier du serveur Web est partagé et enregistrez ce chemin UNC pour le dossier partagé. 2. Si le serveur Web se trouve sur le même serveur que l'autorité de certification, enregistrez le chemin local vers ce dossier. (par défaut, il s'agit du chemin local C:\\CAWWWPub) 3. Exécutez le script suivant pour publier le certificat de l'autorité de certification sur le serveur Web : ``` Cscript //job:PublishIssCertsToIIS C:\\MSSScripts\\CA\_Operations.wsf ``` **Remarque** Cette procédure est conçue en vue de fonctionner avec des serveurs Web internes. Si les certificats ne sont pas publiés sur un serveur Web relié à Internet, des étapes supplémentaires seront nécessaires car cette solution repose sur le partage de fichiers Windows (fonctionnalité généralement bloquée par les pare-feu Internet). Les listes de révocation de certificats sont publiées plus fréquemment que les certificats de l'autorité de certification. Il est donc nécessaire d'automatiser leur publication sur le serveur Web. **Pour automatiser la publication des listes de révocation de certificats** 1. Ouvrez une session sur l'autorité de certification émettrice en utilisant un compte appartenant au groupe des administrateurs locaux. 2. Vérifiez que le dossier du serveur Web est accessible à partir de ce serveur. 3. Si le serveur Web est distant, autorisez à l'autorité de certification émettrice l'accès en écriture au dossier du système de fichiers (activez Modify access) et au partage (activez Change access). Si le serveur Web distant est membre de la forêt, autorisez l'accès par l'intermédiaire du groupe Cert Publishers du domaine pour permettre à toutes les autorités de certification d'entreprise de publier des certificats et des listes de révocation de certificats. 4. Créez une tâche planifiée pour copier les listes de révocation de certificats en exécutant la commande ci-dessous. **Remarque** Certaines parties de l'extrait de code suivant sont présentées sur plusieurs lignes pour une meilleure lisibilité. Elles doivent être saisies sur une seule ligne. ``` schtasks /creat /tn “Publish CRLs” /tr “cscript.exe //job:PublishIssCRLsToIIS C:\ MSSScripts\CA_Operations.wsf” /sc Hourly /ru “System” ``` Retrait des modèles indésirables de l'autorité de certification émettrice Il est généralement recommandé de retirer les modèles qui ne correspondent à aucun type de certificat utilisé afin qu'ils ne soient pas émis par erreur. Ces modèles pourront être récréés très facilement en cas de besoin car ils restent disponibles dans le répertoire. **Pour retirer les modèles indésirables de l'autorité de certification émettrice** 1. Ouvrez une session en tant que membre du groupe CA Admins du domaine. 2. Dans la console de gestion de l'autorité de certification, sélectionnez le conteneur Modèles de certificats. 3. Retirez les types de modèle suivants : - Agent de récupération EFS - EFS basique - Serveur Web - Ordinateur - Utilisateur - Autorité de certification subordonnée - Administrateur ##### Authentification Internet Cette section fournit des informations détaillées qui vous aideront à implémenter une infrastructure RADIUS destinée à prendre en charge la solution WLAN sécurisée présentée dans ce guide. L'infrastructure RADIUS présentée dans ce guide est basée sur le service d'authentification Internet (IAS) de Windows Server 2003. ###### Conception de l'infrastructure RADIUS Vous pouvez utiliser les tableaux suivants comme feuilles de calcul dans lesquelles vous rassemblerez toutes les informations prérequises auxquelles il sera fait référence tout au long de ce guide. Certaines de ces informations sont définies à l'aide des scripts de ce guide ou manuellement, comme indiqué dans les différentes sections. **Informations de configuration définies par l'utilisateur** Le tableau suivant répertorie les informations spécifiques à chaque entreprise. Avant de poursuivre, vérifiez que ces informations sont collectées, étudiées et enregistrées. **Tableau 15. Paramètres de configuration définis par l'utilisateur**

Élément de configuration	Paramètre
Nom DNS du domaine racine de la forêt Active Directory
Nom NetBIOS du domaine
Nom du serveur IAS principal
Nom du serveur IAS secondaire

**Informations de configuration requises définies par la solution** Les paramètres spécifiés dans le tableau suivant n'ont pas à être modifiés, sauf si vous avez expressément besoin d'utiliser un paramètre différent. Avant de modifier ces paramètres et d'apporter les éventuelles modifications requises dans les scripts, assurez-vous d'avoir bien évalué et planifié les conséquences et dépendances que cela implique. **Tableau 16. Paramètres de configuration définis par la solution**

Élément de configuration	Paramètre
Nom complet du groupe d'administration contrôlant la configuration d'IAS	IAS Admins
Nom complet du groupe qui examine les journaux de requêtes d'authentification et de gestion de compte IAS	IAS Security Auditors
Chemin d'accès des scripts d'installation	C:\MSSScripts
Fichier de commandes exporté de configuration IAS	IASExport.bat
Fichier de commandes importé de configuration IAS	IASImport.bat
Fichier de commandes exporté de configuration du client RADIUS IAS	IASClientExport.bat
Fichier de commandes importé de configuration du client RADIUS IAS	IASClientImport.bat
Chemin d'accès des fichiers de sauvegarde de configuration	D:\IASConfig
Emplacement des journaux de requête d'authentification et d'audit IAS	D:\IASLogs
Nom de partage des journaux de requêtes RADIUS	IASLogs

###### Déploiement du serveur IAS La solution présentée dans les sections suivantes comprend deux serveurs IAS centraux configurés en tant que serveurs RADIUS pour le contrôle d'accès au réseau local sans fil. Compte tenu de cela, vous devez effectuer les tâches suivantes avant de poursuivre. - Allouer et configurer le matériel du serveur. - Installer et configurer le système d'exploitation du serveur pour chaque procédure de l'entreprise. - Vérifier le bon fonctionnement d'Active Directory. - Vérifier que les procédures de renforcement et applications supplémentaires du serveur de l'entreprise requises par les stratégies mises en œuvre sont en place. **Installation des scripts de configuration** Pour simplifier l'implémentation de la solution, un certain nombre de scripts de support sont fournis dans ce guide. Vous devez les installer sur tous les serveurs avant de poursuivre. Vous ne devez pas les supprimer, même après avoir suivi toutes les étapes de ce guide. **Pour installer les scripts de configuration** 1. Créez un dossier C:\\MSSScripts. 2. Copiez les scripts dans ce dossier, à partir de la source de distribution. **Configuration logicielle supplémentaire requise pour le serveur** Outre le système d'exploitation du serveur et toute autre application requise dans une stratégie de conception de serveur établie, la prise en charge des scripts fournis dans ce guide exige que l'exécutable CAPICOM 2.1 et le fichier de bibliothèque DLL associé soient installés. Pour plus d'informations sur [CAPICOM](http://www.microsoft.com/downloads/details.aspx?displaylang=fr&familyid=860ee43a-a843-462f-abb5-ff88ea5896f6), notamment sur l'emplacement de téléchargement et pour obtenir des instructions d'installation, consultez la page www.microsoft.com/downloads/details.aspx?displaylang=fr&FamilyID=860ee43a-a843-462f-abb5-ff88ea5896f6 **Configuration de groupes d'administration IAS** La commande du script suivant permet de créer les groupes de sécurité IAS Admins et IAS Security Auditors : ``` Cscript //job:CreateIASGroups C:\\MSSScripts\\IAS\_Tools.wsf ``` Dans les environnements à domaines multiples, ces groupes doivent être créés dans le même domaine que les serveurs IAS. Une fois les groupes requis créés, configurez-les de sorte qu'ils puissent effectuer des tâches de configuration IAS en procédant comme suit : - Ajoutez le groupe global du domaine IAS Admins aux groupes des administrateurs locaux sur chaque serveur. - Si IAS est installé sur les contrôleurs de domaine, le groupe IAS Admins doit être ajouté au groupe des administrateurs du domaine. - Vous devez insérer les comptes appropriés dans les groupes IAS Admins et IAS Security. **Configuration des paramètres de sécurité du système du serveur** Comme mentionné précédemment, dans ce guide, nous partons du principe que la plupart des entreprises de taille moyenne ont mis en place des stratégies et des procédures de renforcement des serveurs. Pour cette raison, nous ne donnons aucune instruction détaillée concernant le processus de sécurisation des serveurs requis dans le cadre de cette solution. Si aucune stratégie ou procédure de renforcement des serveurs n'est mise en place, ou pour plus d'informations sur la sécurisation des serveurs IAS, consultez la page relative à la [sécurité de Windows 2003](http://go.microsoft.com/fwlink/?linkid=14846) (cette page peut être en anglais), à l'adresse suivante : http://go.microsoft.com/fwlink/?LinkId=14846. ###### Installation et configuration d'IAS La section suivante décrit la procédure d'installation d'IAS sur des serveurs. Vous devez absolument effectuer chaque étape d'installation et de configuration sur chaque serveur IAS. Pour installer IAS, sélectionnez Services réseau – Service d'authentification Internet (IAS) dans le gestionnaire de composants facultatifs de Windows (Panneau de configuration, puis Ajouter ou supprimer des composants Windows). Pour simplifier ce processus, utilisez le script suivant : ``` sysocmgr /i:sysoc.inf /u:C:\\MSSScripts\\OC\_AddIAS.txt ``` **Enregistrement d'IAS dans Active Directory** Les serveurs IAS devant être enregistrés dans chaque domaine, vous devez faire en sorte que le compte d'ordinateur de chaque serveur IAS soit membre du groupe de sécurité RAS (Remote Access Service) et serveurs IAS dans chaque domaine où les serveurs seront requis pour l'authentification. En appartenant ainsi à ces groupes, les serveurs IAS sont autorisés à lire les propriétés d'accès distant de tous les comptes d'utilisateur et d'ordinateur des domaines. **Pour enregistrer IAS dans Active Directory** 1. Ouvrez une session sur chaque serveur en utilisant un compte disposant du privilège Domain Admin pour les domaines où le serveur IAS doit être enregistré. 2. Pour le domaine par défaut, exécutez la commande suivante à l'invite : ``` netsh ras add registeredserver ``` 3. Pour les autres domaines, à l'invite, exécutez la commande suivante : ``` netsh ras add registeredserver domain = nomdomaine ``` **Remarque** Vous pouvez également ajouter l'objet ordinateur serveur IAS aux groupes de sécurité RAS et serveurs IAS par l'intermédiaire du composant MMC Utilisateurs et ordinateurs Active Directory. Création et sécurisation des annuaires de données IAS Le stockage des données de configuration et des fichiers journaux sur les serveurs IAS est soumis à certaines exigences d'annuaire. Pour simplifier le processus de configuration permettant de créer et de sécuriser les annuaires, utilisez le fichier batch suivant à l'invite de commande : ``` C:\\MSSScripts\\IAS\_Data.bat ``` **Remarque** Avant d'exécuter ce fichier batch, vous devrez peut-être modifier et remplacer les entrées %*nomdomaine*% afin d'utiliser le nom de domaine NETBIOS spécifique à l'environnement. ###### Configuration du serveur IAS principal Vous devez configurer le serveur choisi comme serveur IAS principal avant les autres serveurs IAS de l'environnement, car il servira de modèle pour configurer les paramètres de tous les autres serveurs IAS. **Journalisation des demandes d'authentification et de gestion des comptes** Par défaut, IAS journalise les demandes d'authentification et de gestion des comptes RADIUS mais il doit être activé de façon à ce que les événements de sécurité soient enregistrés et qu'ils puissent être utilisés en cas de besoin. **Pour configurer la journalisation des demandes d'authentification et de gestion des comptes** 1. Dans le composant logiciel enfichable MMC Service d'authentification Internet, sélectionnez Connexion à distance, puis affichez les propriétés de la méthode de journalisation du fichier journal local. 2. Sélectionnez Requêtes de gestion de compte et Requêtes d'authentification. 3. Vérifiez que le répertoire du fichier journal est bien D:\\IASLogs et que le format Compatible avec les bases de données est sélectionné (afin que les journaux puissent être importés directement dans des bases de données telles que Microsoft SQL Server™). ##### Authentification WLAN 802.1X Cette section présente les étapes du processus d'implémentation de la sécurité WLAN basée sur le protocole 802.1X sur des plates-formes Windows Server 2003 et Windows XP SP1. Ces instructions incluent des informations relatives à la configuration des groupes Active Directory, au déploiement de certificats X.509, à la modification de paramètres du serveur IAS, au déploiement de stratégies de groupe WLAN, ainsi que des conseils de configuration des points d'accès sans fil afin d'assurer la prise en charge de l'implémentation 802.1X EAP-TLS présentée dans ce guide. ###### Préparation de l'environnement pour un réseau local sans fil sécurisé Maintenant que les infrastructures de certificat sous-jacentes et RADIUS sont en place, les véritables étapes de configuration du réseau 802 1X peuvent être implémentées. Les tableaux suivants répertorient des paramètres prérequis qui peuvent vous aider dans le cadre du processus de collecte d'informations qui doit avoir lieu avant l'implémentation réelle de la solution. Certains paramètres sont activés manuellement, alors que d'autres font partie de scripts fournis dans ce guide. **Paramètres de configuration définis par l'utilisateur** Le tableau suivant répertorie des paramètres spécifiques à l'entreprise. Vous devez les collecter et les étudier avant de continuer cette phase de l'implémentation d'un réseau local sans fil sécurisé. L'espace disponible peut être utilisé pour consigner les paramètres requis pour chaque environnement. **Tableau 17. Paramètres définis par l'utilisateur**

Élément de configuration	Paramètre
Nom DNS du domaine racine de la forêt Active Directory
Nom du domaine NetBIOS
Nom du serveur IAS principal
Nom du serveur IAS secondaire

**Paramètres de configuration définis pour la solution** Les paramètres spécifiés dans le tableau suivant n'ont pas à être modifiés, sauf si vous avez expressément besoin d'utiliser un paramètre différent. Avant de modifier ces paramètres et d'apporter les éventuelles modifications requises dans les scripts, assurez-vous d'avoir bien évalué et planifié les conséquences et dépendances que cela implique. **Tableau 18. Paramètres de configuration définis par la solution**

Élément de configuration	Paramètre
Groupe global Active Directory contrôlant le déploiement des certificats d'authentification utilisateur 802.1X	Inscription automatique authentification client – Certificat utilisateur
Groupe global Active Directory contrôlant le déploiement des certificats d'authentification ordinateur 802.1X	Inscription automatique authentification client – Certificat ordinateur
Groupe global Active Directory comprenant les serveurs IAS nécessitant des certificats d'authentification 802.1X	Inscription automatique serveurs RAS et IAS – Certificat d'authentification
Groupe global Active Directory comprenant les utilisateurs autorisés à accéder au réseau sans fil	Stratégie d'accès distant – Utilisateurs sans fil
Groupe global Active Directory comprenant les utilisateurs autorisés à accéder au réseau sans fil	Stratégie d'accès distant – Ordinateurs sans fil
Groupe universel Active Directory comprenant le groupe des utilisateurs sans fil et celui des ordinateurs sans fil	Stratégie d'accès distant – Accès sans fil
Groupe global Active Directory comprenant les ordinateurs nécessitant la configuration de propriétés de réseau sans fil	Stratégie réseau sans fil – Ordinateur
Modèle de certificat utilisé pour la génération de certificats pour l'authentification du client utilisateur	Authentification client – Utilisateur
Modèle de certificat utilisé pour la génération de certificats pour l'authentification du client ordinateur	Authentification client – Ordinateur
Modèle de certificat utilisé pour la génération de certificats d'authentification serveur pour IAS	Authentification serveurs RAS et IAS
Chemin d'accès des scripts d'installation	C:\MSSScripts
Chemin d'accès des fichiers de sauvegarde de configuration	D:\IASConfig
Chemin d'accès des journaux d'authentification et d'audit IAS	D:\IASLogs
Nom de stratégie	Autoriser l'accès sans fil
Nom de l'objet Stratégie de groupe (GPO) Active Directory	Stratégie réseau sans fil
Stratégie réseau sans fil dans l'objet Stratégie de groupe ci-dessus	Configuration sans fil ordinateur client

**Création des groupes Active Directory requis pour l'accès au réseau local sans fil** Vous devez exécuter le script suivant en utilisant un compte autorisé à créer des groupes de sécurité Active Directory. Ce script crée les groupes requis dans le cadre de l'implémentation de l'inscription de certificats d'authentification sans fil, de la stratégie d'accès distant et de la stratégie de groupe du réseau sans fil : ``` Cscript //job:CreateWirelessGroups C:\\MSSScripts\\wl\_tools.wsf ``` **Remarque** Dans les environnements de forêt à domaines multiples, ces groupes doivent être créés dans le même domaine que les utilisateurs sans fil. **Vérification des paramètres DHCP** Pour la mise en réseau sans fil, configurez les serveurs DHCP de façon à ce qu'ils disposent de portées spécifiques sans fil et de durées de bail d'adresses IP plus courtes que celles des clients câblés. Pour vérifier que les serveurs DHCP sont configurés correctement, contactez les administrateurs de ces serveurs. Pour obtenir plus d'informations sur la planification DHCP pour les réseaux locaux sans fil, reportez-vous au [Kit de déploiement de Windows Server 2003](http://www.microsoft.com/windowsserver2003/techinfo/reskit/deploykit.mspx) à l'adresse suivante : www.microsoft.com/windowsserver2003/techinfo/reskit/deploykit.mspx. ###### Configuration des certificats d'authentification de réseau local sans fil Pour implémenter la sécurité WLAN basée sur EAP-TLS comme indiqué dans ce guide, vous devez créer et déployer les types de certificats suivants : - Authentification client – Ordinateur - Authentification client – Utilisateur - Authentification serveurs RAS et IAS **Création d'un modèle de certificat pour l'authentification serveur IAS** Un certificat serveur est requis sur le serveur IAS pour authentifier les ordinateurs auprès des clients lors de la négociation EAP-TLS. L'administrateur des services de certificats doit effectuer les opérations suivantes pour créer un modèle de certificat d'authentification serveur qui sera utilisé par les serveurs IAS. **Pour créer un modèle de certificat pour l'authentification serveur** 1. Ouvrez une session sur l'autorité de certification émettrice en utilisant un compte membre du groupe d'administration de l'autorité de certification, puis exécutez le composant logiciel enfichable MMC Certificate Templates. 2. Créez une copie du modèle de certificat RAS et IAS. Dans l'onglet **Général** des propriétés du nouveau modèle, entrez **Authentification serveurs RAS et IAS**, dans le champ **Nom complet du modèle**. 3. Dans l'onglet **Extensions**, vérifiez que les stratégies d'émission incluent uniquement Authentification serveur (OID 1.3.6.1.5.5.7.3.1). 4. Toujours dans l'onglet **Extensions**, modifiez les stratégies d'émission en ajoutant la stratégie Garantie moyenne. 5. Dans l'onglet **Nom du sujet**, sélectionnez **Construire à partir de ces informations Active Directory**. Vérifiez également que **Format du nom du sujet** est configuré sur **Nom commun** et que **Nom DNS** est le seul élément sélectionné dans **Inclure cette information** dans le **nom de substitution du sujet**. 6. Dans l'onglet **Traitement de la demande**, cliquez sur le bouton **CSP**, vérifiez que **Les requêtes doivent utiliser l'un des fournisseurs de services de cryptographie suivants** est activé et que **le fournisseur de services cryptographiques Microsoft RSA SChannel** est sélectionné. 7. Dans l'onglet **Sécurité**, ajoutez le groupe de sécurité **Inscription automatique serveurs RAS et IAS - certificat d'authentification** avec les permissions Lecture, Inscription et Inscription automatique, et supprimez tous les autres groupes autorisés à inscrire ou à inscrire automatiquement ce modèle de certificat. **Remarque** Il peut être intéressant de définir ce certificat de sorte que l'approbation du Gestionnaire de certificats soit requise. Cela permet de garantir un niveau de sécurité élevé. L'activation de cette valeur permet d'éviter qu'un serveur IAS non autorisé ne s'inscrive. Toutefois, une approbation manuelle sera requise une fois les certificats émis et envoyés automatiquement par les serveurs IAS. **Création d'un modèle de certificat pour l'authentification des utilisateurs** Les utilisateurs finaux ont besoin de certificats utilisateur pour s'authentifier sur le serveur IAS lors du processus de négociation EAP-TLS. Les opérations suivantes doivent être effectuées par le détenteur du compte désigné comme Administrateur des services de certificats. **Pour créer un modèle de certificat pour l'authentification utilisateur** 1. Lancez le composant logiciel enfichable MMC Certificate Templates sur le serveur de l'autorité de certification émettrice. 2. Créez un double du modèle Session authentifiée, et tapez **Authentification client – Utilisateur** dans le champ **Nom complet du modèle** de l'onglet **Général** du nouveau modèle. 3. Dans l'onglet **Traitement de la demande**, sélectionnez **CSP** et désactivez **Microsoft Base DSS** **Cryptographic Provider**. 4. Dans l'onglet **Nom du sujet**, sélectionnez **Construire à partir de ces informations Active Directory**. Dans **Format du nom du sujet**, sélectionnez **Nom commun**. Vérifiez que **Nom** **d'utilisateur principal (UPN)** est la seule option sélectionnée dans **Inclure cette information dans le nom de substitution du sujet**. 5. Dans l'onglet **Extensions**, vérifiez que les **stratégies d'application** incluent uniquement **Authentification client (OID 1.3.6.1.5.5.7.3.2)**. Toujours dans l'onglet Extensions, modifiez les stratégies d'émission et ajoutez la stratégie **Garantie faible**. 6. Dans l'onglet **Sécurité**, ajoutez le groupe de sécurité **Inscription automatique authentification client – Certificat utilisateur** avec les permissions Lecture, Inscription et Inscription automatique. Supprimez tous les autres groupes disposant des permissions Inscription ou Inscription automatique. **Création d'un modèle de certificat pour l'authentification ordinateur** Les ordinateurs utilisent ce certificat pour s'authentifier sur le serveur IAS lors de la négociation EAP-TLS. Les opérations suivantes doivent être effectuées par l'administrateur des services de certificats. **Pour créer un modèle de certificat pour l'authentification ordinateur** 1. Lancez le composant logiciel enfichable MMC Certificate Templates sur l'autorité de certification émettrice. 2. Créez un double du modèle Authentification de station de travail. Dans l'onglet **Général** du nouveau modèle, entrez **Authentification client – Ordinateur** dans le champ **Nom complet du modèle**. 3. Dans l'onglet **Nom du sujet**, sélectionnez **Construire à partir de ces informations Active Directory**. Dans **Format du nom du sujet**, sélectionnez **Nom commun**. Vérifiez que **Nom** **DNS** est la seule option sélectionnée dans Inclure cette information dans le nom de substitution du sujet. 4. Dans l'onglet **Extensions**, modifiez les stratégies d'application et vérifiez que seule l'option **Authentification client (OID 1.3.6.1.5.5.7.3.2)** est incluse. Toujours dans l'onglet Extensions, modifiez les stratégies d'**émission** et ajoutez la stratégie **Garantie faible**. 5. Dans l'onglet **Sécurité**, ajoutez le groupe de sécurité **Inscription automatique authentification client – Certificat ordinateur** avec les permissions Lecture, Inscription et Inscription automatique. Supprimez tous les autres groupes disposant de permissions. **Ajout des certificats d'authentification du réseau local sans fil à l'autorité de certification** Une fois les modèles de certificats configurés, vous devez les ajouter à l'autorité de certification afin d'activer l'inscription. Pour ce faire, demandez à l'administrateur des services de certificats d'effectuer les opérations suivantes : **Pour ajouter des modèles de certificats à l'autorité de certification** - Lancez le composant logiciel enfichable MMC Certificate Authority sur l'autorité de certification émettrice, cliquez avec le bouton droit de la souris sur le dossier **Modèles de certificats**, cliquez sur **Nouveau**, puis sur **Modèle de certificat à délivrer**. Sélectionnez les certificats suivants puis cliquez sur **OK**: - Authentification client – Ordinateur - Authentification client – Utilisateur - Authentification serveurs RAS et IAS **Inscription d'un certificat de serveur IAS** Le déploiement des certificats d'authentification de serveur sur les serveurs est un processus automatisé relativement simple. **Pour inscrire un serveur IAS** 1. Lancez le composant logiciel enfichable MMC Utilisateurs et ordinateurs Active Directory et ajoutez les comptes ordinateur IAS au groupe de sécurité Inscription automatique certificat d'authentification serveurs RAS et IAS. 2. Redémarrez le serveur IAS, puis ouvrez une session en tant que membre du groupe des administrateurs locaux. 3. À une invite de commande, exécutez GPUPDATE /force 4. Ouvrez MMC, puis ajoutez le composant logiciel enfichable Certificats. Lorsque vous y êtes invité, sélectionnez l'option Compte d'ordinateur, puis sélectionnez Ordinateur local. 5. Sélectionnez **Certificats (Ordinateur local)** dans l'arborescence de la console, sélectionnez **Toutes les tâches** dans le menu **Action**, puis cliquez sur **Inscrire automatiquement les certificats**. **Remarque** Si l'option d'approbation du Gestionnaire de certificats est sélectionnée, l'administrateur de l'autorité de certification doit vérifier la validité de cette demande et émettre le certificat. **Ajout d'utilisateurs et d'ordinateurs aux groupes d'inscription automatique** Les utilisateurs et ordinateurs qui doivent se connecter au réseau local sans fil doivent disposer de certificats utilisateur et ordinateur émis au préalable afin de pouvoir s'authentifier et accéder au réseau via une connexion sans fil. Le processus d'émission et de renouvellement de ces certificats est transparent pour l'utilisateur final grâce aux groupes d'inscription automatique définis précédemment. Pour ajouter des utilisateurs ainsi que leurs ordinateurs aux groupes d'inscription automatique, utilisez le composant logiciel enfichable MMC Utilisateurs et ordinateurs Active Directory pour ajouter les comptes utilisateur au groupe Inscription automatique authentification client – Certificat utilisateur et ajouter leurs ordinateurs au groupe Inscription automatique authentification client – Certificat ordinateur. Lorsque vous avez terminé, les utilisateurs concernés reçoivent leurs certificats utilisateur et ordinateur après avoir redémarré leurs ordinateurs et ouvert une nouvelle session sur le réseau. **Remarque** Pour contrôler les utilisateurs et ordinateurs en droit de recevoir les certificats, cette solution utilise des groupes personnalisés. Si l'environnement exige que tous les utilisateurs et ordinateurs possèdent des certificats, il vous suffit d'ajouter Utilisateurs du domaine au groupe Inscription automatique authentification client – Certificat utilisateur et Ordinateurs du domaine au groupe Inscription automatique authentification client – Certificat ordinateur. ###### Configuration de l'infrastructure d'accès au réseau local sans fil Vous devez configurer sur le serveur IAS principal une stratégie d'accès distant et des paramètres de requête de connexion déterminant l'authentification et l'autorisation des clients sur le réseau local sans fil. Vous devez ensuite répliquer ces paramètres sur les autres serveurs IAS, puis configurer chaque serveur individuellement de sorte qu'ils acceptent les connexions de clients RADIUS, comme les points d'accès sans fil. Vous devez ensuite configurer les points d'accès pour qu'ils utilisent les serveurs IAS comme sources d'authentification et d'autorisation pour le réseau sans fil 802.1X. **Création d'une stratégie d'accès distant IAS pour les réseaux locaux sans fil** Utilisez le composant logiciel enfichable MMC Services d'authentification Internet sur le serveur IAS principal afin de configurer IAS avec une stratégie d'accès distant comme suit. **Pour créer une stratégie d'accès distant** 1. Cliquez avec bouton droit de la souris sur le dossier **Stratégies d'accès distant**, puis cliquez sur **Nouvelle stratégie d'accès distant**. 2. Nommez la nouvelle stratégie **Autoriser l'accès sans fil** et demandez à l'Assistant de configurer **Une stratégie typique pour un scénario commun**. 3. Choisissez la méthode d'accès **Sans fil**. 4. Autorisez l'accès sur la base du groupe et utilisez le groupe de sécurité Stratégie d'accès distant – Accès sans fil. 5. Choisissez **Carte à puce ou autre certificat** comme type EAP (Extensible Authentication Protocol), puis sélectionnez le certificat d'authentification serveur installé pour IAS. 6. Terminez, puis quittez l'Assistant. 7. Ouvrez les propriétés de la stratégie Autoriser l'accès sans fil, puis cliquez sur **Modifier le profil**. 8. Dans l'onglet **Avancé**, ajoutez l'attribut **Ignore-User-Dialin-Properties**, configurez-le sur **Vrai**, puis ajoutez l'attribut **Termination-Action** et configurez-le sur **Requête RADIUS**. **Remarque** La stratégie Autoriser l'accès sans fil peut cohabiter avec d'autres stratégies créées par l'utilisateur ou avec les stratégies d'accès par défaut. Toutefois, pour fonctionner correctement, la stratégie d'accès sans fil par défaut doit être répertoriée après la stratégie Autoriser l'accès sans fil dans le dossier Stratégies d'accès distant. **Ajout de clients RADIUS à IAS** Vous devez ajouter des points d'accès sans fil et des proxy RADIUS comme clients RADIUS à IAS afin qu'ils puissent exploiter les services d'authentification et de gestion des comptes via le protocole RADIUS. **Pour ajouter des clients RADIUS à IAS** 1. Lancez le composant logiciel enfichable MMC Serveur d'authentification Internet. 2. Cliquez avec le bouton droit de la souris sur le dossier **Clients RADIUS**, puis cliquez sur **Ajouter un client RADIUS**. 3. Entrez le nom convivial et l'adresse IP du point d'accès sans fil. 4. Sélectionnez RADIUS Standard comme attribut client-vendeur, puis entrez le secret partagé correspondant à ce point d'accès sans fil particulier. Sélectionnez ensuite l'attribut **Les requêtes doivent contenir l'attribut de l'authentificateur de message**. **Remarque** Vous devez répéter ce processus sur chaque serveur IAS afin d'être sûr que chaque serveur possède un jeu unique de secrets partagés et de clients de point d'accès sans fil. Pour simplifier ce processus, vous pouvez utiliser le script ci-dessous pour générer des secrets partagés que vous pourrez ensuite stocker dans un endroit sûr au cas où une restauration système serait requise. Pour utiliser ce script, exécutez la commande suivante : ``` Cscript //job:GenPWD C:\\MSSScripts\\wl\_tools.wsf /client:ClientName ``` ###### Déploiement des configurations sur plusieurs serveurs IAS Une fois les éléments suivants configurés sur le serveur IAS principal, exportez-les dans des fichiers texte à l'aide de la commande **netsh**. Lorsque les éléments sont exportés, importez les fichiers texte sur chaque serveur IAS ayant un rôle similaire dans l'environnement. Cela permet de garantir la mise en place d'une configuration commune dans l'ensemble de l'environnement. Parmi les paramètres de configuration pouvant être exportés figurent notamment : - Paramètres du serveur - Configuration de la journalisation - Stratégies d'accès distant - Clients RADIUS - Configuration complète Chaque serveur doit contenir sa propre liste de clients RADIUS et de secrets partagés. Vous devez donc configurer ces informations individuellement sur chaque serveur et les sauvegarder séparément. En outre, un fichier de vidage de configuration complet contient des informations sensibles à sécuriser avec le plus grand soin. En effet, en cas de vol, ces informations pourraient permettre d'accéder au réseau sans fil. **Exportation de la configuration du serveur IAS principal** Exportez les types de paramètres suivants dans des fichiers texte en vue de leur réplication sur d'autres serveurs IAS. - Configuration du serveur - Paramètres de journalisation - Stratégie d'accès distant - Stratégies de requêtes de connexion Pour simplifier ce processus, ce guide fournit des fichiers batch contenant les commandes **netsh** permettant d'exporter les informations de configuration communes dans des fichiers texte, dans le répertoire D:\\IASConfig. Pour ce faire, à une invite, exécutez la commande suivante : ``` C:\\MSSScripts\\IASExport.bat ``` **Importation des informations de configuration à partir du serveur IAS principal** Comme nous l'avons vu précédemment, IAS utilise la commande **netsh** pour transférer des états de configuration entre les serveurs. Grâce à ce processus, le déploiement est plus efficace et les risques d'erreur réduits. Une fois les informations de configuration du serveur IAS principal exportées, les serveurs IAS secondaires peuvent importer l'état de configuration. **Pour importer l'état de configuration du serveur IAS principal sur d'autres serveurs IAS** 1. Copiez tous les fichiers du répertoire D:\\IASConfig du serveur IAS principal dans le dossier D:\\IASConfig des autres serveurs IAS. 2. Pour importer l'état de configuration, utilisez le fichier batch ci-dessous (fourni dans ce guide) sur les serveurs secondaires : ``` C:\\MSSScripts\\IASImport.bat ``` ##### Clients et points d'accès sans fil La procédure de configuration des points d'accès sans fil peut varier considérablement en fonction de la marque et du modèle du périphérique concerné. Cependant, les fournisseurs de points d'accès sans fil fournissent généralement des instructions détaillées sur la configuration des périphériques, y compris les informations requises suivantes : - Paramètres réseau 802.1X - Configuration de l'adresse du serveur RADIUS principal - Configuration de l'adresse du serveur RADIUS secondaire - Secret RADIUS partagé avec le serveur RADIUS principal - Secret RADIUS partagé avec le serveur RADIUS secondaire Pour obtenir des instructions pour une marque et un modèle d'équipement sans fil particuliers, reportez-vous aux instructions ou au site Web de support du fournisseur. ###### Déploiement de certificats d'authentification de réseau local sans fil Cette section décrit des tâches de configuration importantes requises pour activer l'inscription automatique de certificats pour les clients Windows XP. Dans les sections précédentes nous avons pu aborder l'activation des stratégies et des modèles pour la prise en charge de l'inscription automatique de certificats dans l'infrastructure de certificat. Toutefois, la prise en charge de cette fonctionnalité est désactivée par défaut dans Windows XP. Pour l'activer, vous devez utiliser les paramètres appropriés en exploitant la stratégie de groupe. Lorsque vous utilisez les groupes de sécurité pour contrôler l'inscription automatique, cette fonctionnalité peut être activée pour tous les utilisateurs et ordinateurs d'un domaine et les groupes de sécurité peuvent identifier à qui sont remis les certificats de chaque type. **Pour activer l'inscription automatique pour tous les utilisateurs et ordinateurs d'un domaine** 1. Ouvrez une session en utilisant un compte permettant de créer des objets de stratégie de groupe (GPO) et de lier ces objets GPO au domaine. 2. Dans Utilisateurs et ordinateurs Active Directory, cliquez avec le bouton droit de la souris sur l'objet de domaine, puis cliquez sur Propriétés. 3. Dans l'onglet **Stratégie de groupe**, cliquez sur **Nouveau**, puis entrez un nom pour l'objet GPO (Stratégies PKI du domaine, par exemple). 4. Cliquez sur **Modifier**, puis accédez à **Stratégies de clé publique** sous Configuration de l'ordinateur/Paramètres Windows/Paramètres de sécurité. 5. Dans le volet **Détails**, double-cliquez sur **Paramètres d'inscription automatique**. 6. Vérifiez que les éléments suivants sont sélectionnés : - Inscrire les certificats automatiquement - Renouveler les certificats expirés, mettre à jour les certificats en attente, et supprimer les certificats révoqués - Mettre à jour les certificats qui utilisent les modèles de certificats 7. Répétez les étapes 5 et 6 pour les paramètres d'inscription automatique utilisateur sous Configuration de l'utilisateur\\Paramètres Windows\\Paramètres de sécurité\\Stratégies de clé publique. 8. Fermez l'objet GPO. 9. Assurez-vous que la priorité de l'objet GPO est plus élevée que celle de l'objet GPO de la stratégie de domaine par défaut. 10. Reprenez ce processus pour chaque domaine dans lequel l'inscription automatique de certificats sera activée dans le cas d'une forêt à domaines multiples. **Remarque** Si les utilisateurs n'utilisent pas de profils d'itinérance et que l'inscription automatique est généralisée, les certificats seront émis sur chaque ordinateur sur lequel l'utilisateur ouvrira une session. Ce phénomène peut être gênant lorsque les administrateurs ouvrent des sessions sur les serveurs. Pour éviter cela, il est recommandé de créer un objet GPO pour les serveurs afin de désactiver l'inscription automatique. Par ailleurs, si vous ne souhaitez pas activer l'inscription automatique pour tous les utilisateurs, liez un objet GPO aux UO qui contiennent le sous-ensemble d'utilisateurs qui requiert l'inscription automatique. ###### Activation de l'accès au réseau local sans fil pour les utilisateurs et ordinateurs Pour donner l'accès au réseau local sans fil sécurisé aux utilisateurs et aux ordinateurs, vous avez encore quelques tâches à réaliser sur des objets Active Directory. Ces tâches incluent la modification des autorisations des comptes et des groupes, et l'implémentation des paramètres de stratégie de groupe du réseau local sans fil. Ajout d'utilisateurs aux groupes de stratégie d'accès distant La stratégie d'accès distant IAS utilise des groupes de sécurité Active Directory pour déterminer si les utilisateurs et les ordinateurs sont autorisés à se connecter au réseau local sans fil. Parmi ces groupes de sécurité créés dans les sections précédentes de ce guide figurent notamment : - Stratégie d'accès distant – Utilisateurs sans fil - Stratégie d'accès distant – Ordinateurs sans fil - Stratégie d'accès distant – Accès sans fil **Pour ajouter des utilisateurs et des ordinateurs aux groupes d'accès au réseau local sans fil** 1. Ouvrez le composant MMC Utilisateurs et ordinateurs Active Directory. 2. Ajoutez les groupes Stratégie d'accès distant – Utilisateurs sans fil et Stratégie d'accès distant – Ordinateurs sans fil au groupe Accès distant – Accès sans fil. 3. Ajoutez les utilisateurs autorisés à accéder au réseau local sans fil au groupe Stratégie d'accès distant – Utilisateurs sans fil. 4. Ajoutez les ordinateurs autorisés à accéder au réseau local sans fil au groupe Stratégie d'accès distant – Ordinateurs sans fil. **Remarque** Si vous avez décidé qu'il était préférable d'autoriser tous les utilisateurs et ordinateurs à accéder au réseau local sans fil, vous pouvez alors ajouter les groupes Utilisa. du domaine et Ordinateurs du domaine aux groupes de stratégie correspondant afin de simplifier l'administration. **Création d'une stratégie de groupe de réseau local sans fil Active Directory** Vous pouvez utiliser une stratégie de groupe pour automatiser et mettre en œuvre les paramètres de configuration du réseau local sans fil de l'ordinateur client dans la mesure où le composant MMC Stratégie de groupe de Windows Server 2003 contient des paramètres de stratégie réseau sans fil liés aux normes 802.1X et 802.11. **Pour créer une stratégie de groupe de réseau sans fil** 1. Ouvrez le composant logiciel enfichable MMC Utilisateurs et ordinateurs Active Directory sur un serveur Windows Server 2003 ou sur une station de travail équipée des outils d'administration Windows Server 2003. 2. Sélectionnez les propriétés de l'objet de domaine, puis dans l'onglet **Stratégie de groupe**, cliquez sur **Nouveau** et nommez l'objet GPO Stratégie réseau sans fil. 3. Cliquez sur le bouton **Propriétés** et, dans l'onglet **Sécurité,** attribuez les autorisations Lecture et Appliquer la stratégie de groupe au groupe Stratégie réseau sans fil – Ordinateur. Supprimez également les autorisations Appliquer la stratégie de groupe des Utilisateurs authentifiés de l'objet GPO. 4. Dans l'onglet **Général**, sélectionnez **Désactiver les paramètres de configuration de l'utilisateur** sur l'objet de stratégie et sélectionnez **Oui** si des messages d'avertissement apparaissent. Appliquez les modifications, puis fermez la fenêtre. 5. Cliquez sur le bouton **Modifier**, puis accédez aux stratégies réseau sans fil (\\Configuration ordinateur\\Paramètres Windows\\Paramètres de sécurité\\Stratégies de réseau sans fil (IEEE 802.11)). 6. Sélectionnez l'objet Stratégies de réseau sans fil (IEEE 802.11) dans le panneau de navigation, puis cliquez sur **Créer une stratégie de réseau sans fil** dans le menu **Action**. Utilisez l'Assistant pour nommer la stratégie **Configuration sans fil ordinateur client**. Laissez l'option **Modifier les propriétés** sélectionnée, puis cliquez sur **Terminer** pour fermer l'Assistant. 7. Sélectionnez **Ajouter** dans l'onglet **Réseaux favoris** de la stratégie **Configuration sans fil ordinateur client**, puis entrez le nom de réseau ou l'identifiant SSID du réseau sans fil. 8. Cliquez sur l'onglet **IEEE 802.1X**, puis ouvrez les paramètres du type EAP **Carte à puce ou autre certificat**. Sous **Autorités de certification racines de confiance**, sélectionnez le certificat de l'autorité de certification racine pour l'infrastructure PKI qui a émis les certificats du serveur IAS. 9. Fermez les propriétés de la Configuration sans fil ordinateur client et l'éditeur d'objet Stratégie de groupe. **Remarque** À l'heure actuelle WPA2 n'est pas compatible avec les objets GPO. Toutefois, WPA2 prendra en charge les objets GPO dans Windows Vista et Longhorn et des mises à jour sont prévues pour résoudre ce problème dans les versions de Windows existantes. **Ajout d'ordinateurs aux groupes de sécurité pour la stratégie de groupe de réseau local sans fil** Des groupes de sécurité Active Directory sont utilisés pour déterminer les ordinateurs auxquels sont appliquées des stratégies de réseau sans fil afin de configurer automatiquement les paramètres 802.11 et 802.1X requis. Déployez ces paramètres avant de configurer les paramètres 802.1X sur des points d'accès sans fil et avant d'activer le réseau local sans fil. Cette approche permet de s'assurer que les ordinateurs clients auront la possibilité de télécharger et d'appliquer la stratégie de groupe de l'ordinateur, même s'ils ne se connectent qu'occasionnellement au réseau local filaire. Vous pouvez même appliquer les paramètres de stratégie de groupe avant d'installer une carte réseau (nic) de réseau local sans fil, car celle-ci récupèrera et appliquera automatiquement les paramètres de stratégie de groupe de réseau sans fil appropriés. Pour ajouter des ordinateurs aux groupes de la stratégie de groupe de réseau sans fil, utilisez le composant logiciel enfichable MMC Utilisateurs et ordinateurs Active Directory et ajoutez des objets ordinateurs autorisés au groupe Stratégie de réseau sans fil – Ordinateur. **Remarque** Les paramètres de l'objet GPO du réseau sans fil seront mis à jour sur les ordinateurs clients lors de la prochaine actualisation de la stratégie de groupe des ordinateurs. Pour forcer l'actualisation de la stratégie, exécutez la commande suivante : GPUPDATE /force. ###### Configuration requise pour les clients WPA2 La solution mise en avant dans ce guide a été conçue pour les ordinateurs clients sans fil exécutant Windows XP Professionnel avec SP2 ou Windows XP Édition Tablet PC. Ces versions de Windows offrent une prise en charge 802.1X et WLAN intégrée. En outre, les clients Windows XP disposent de la fonction d'inscription et de renouvellement automatique des certificats, rendant ainsi une solution comme celle-ci (basée sur les certificats) particulièrement rentable lorsqu'elle est associée à une infrastructure de certificat. Bien que Windows XP avec SP2 offre une prise en charge intégrée de WPA, il est indispensable d'installer une mise à jour supplémentaire pour activer la prise en charge de WPA2 IEEE 802.11i sur les clients Windows XP avec SP2. Pour plus d'informations sur cette mise à jour supplémentaire ainsi que pour obtenir des instructions de téléchargement, reportez-vous à la page sur la [mise à jour WPA2/WPS IE pour Windows XP avec Service Pack 2](http://support.microsoft.com/kb/893357/fr) (cette page peut être en anglais) à l'adresse suivante : http://support.microsoft.com/kb/893357/fr. [](#mainsection)[Haut de page](#mainsection) ### Résumé Après avoir passé en revue les nombreuses solutions disponibles pour résoudre les problèmes des anciennes normes de sécurité sans fil et observé comment les normes rendent ces solutions de contournement obsolètes, la solution permettant d'optimiser la sécurité des réseaux sans fil dans un environnement d'entreprise de taille moyenne s'est précisée. Désormais, les entreprises de taille moyenne peuvent implémenter la solution présentée dans ce guide, consistant à utiliser WPA ou WPA2 EAP-TLS avec des services de certificat, et ainsi profiter en toute sécurité d'une productivité accrue. Après avoir suivi les étapes détaillées et utilisé les outils de ce guide, une entreprise de taille moyenne dispose d'une solution sans fil plus sûre et fiable qui dynamise sa productivité et ce, sans interrompre l'utilisateur final sur le réseau. **Télécharger** [Obtenir l'article Configuration de points d'accès sans fil sécurisés](http://go.microsoft.com/fwlink/?linkid=71716) [](#mainsection)[Haut de page](#mainsection)

Last updated on 2018-02-21

Configuration de points d'accès sans fil sécurisés

Sur cette page

Introduction

Synthèse

Présentation

Personnes concernées par ce guide

Définition

Enjeux

Solutions

Évaluation de la sécurité WLAN

Avantages du réseau sans fil

Avantages commerciaux

Avantages opérationnels

Vulnérabilités des réseaux sans fil

Certificats

Créer une déclaration CPS (Certificate Practices Statement)

Hiérarchie des autorités de certification

Sécuriser l'autorité de certification racine

Authentification Internet

Implémentations RADIUS préexistantes

Basculement et équilibrage de la charge du serveur RADIUS

Exigences relatives à la journalisation RADIUS

Serveurs IAS centralisés ou distribués

Considérations sur l'emplacement et la mutualisation des serveurs IAS

Estimation de la charge du serveur et de la configuration matérielle requise

Ressources supplémentaires