5. Sécurisation de l'infrastructure du domaine

Le chapitre 4, « Application de la discipline de gestion du risque de sécurité », identifiait les risques de sécurité spécifiques du scénario de la société Contoso SA à l'aide de la discipline de gestion du risque de sécurité (SRMD). Les chapitres suivants de ce guide traitent de l'atténuation des risques ainsi identifiés ou de leur résolution au moyen de mesures de prévention.

Ce chapitre s'attache en particulier aux vulnérabilités au niveau du domaine. Il fournit une description générale de la structure du service Microsoft® Active Directory®, de la structure de l'unité d'organisation (OU, organizational unit) et de la stratégie de domaine. Il explique en outre dans le détail les stratégies de domaine spécifiques implémentées dans la société Contoso.

Structure d'Active Directory

Un ouvrage tout entier pourrait être consacré à l'étude détaillée de la conception d'une structure Active Directory. Cette technologie Microsoft fait partie d'Active Platform. Elle est conçue pour permettre aux applications de rechercher, d'utiliser et de gérer des ressources d'annuaire dans un environnement informatique distribué. Le contenu de cette section est consacré à quelques-uns de ces concepts. L'objectif est d'acquérir ici des connaissances suffisantes pour l'assimilation des autres informations connexes de ce chapitre.

L'un des aspects les plus importants à envisager lors de la création d'une architecture Active Directory concerne les frontières de sécurité qui seront imposées à l'organisation. Si vous prenez le temps de planifier correctement les modalités de la délégation et de l'implémentation des tâches de sécurité dans l'organisation, la structure finale d'Active Directory sera beaucoup plus sécurisée. Cette opération ne devrait pas nécessiter une restructuration de votre environnement à moins que des modifications majeures soient apportées à l'entreprise, comme une acquisition ou une restructuration organisationnelle.

Si une structure Active Directory a déjà été implémentée dans l'organisation, ce chapitre peut vous aider à mieux appréhender certains des avantages ou problèmes potentiels posés par la mise en place d'une structure particulière dans votre environnement du point de vue de la sécurité.

Établissement des frontières d'Active Directory

Il existe dans Active Directory différents types de frontières. Ces « frontières » peuvent correspondre à la forêt, au domaine, à la topologie de site et à la délégation d'autorisations.

Bon nombre de ces frontières sont établies au moment de l'installation d'Active Directory. Lors de la définition de la délégation d'autorisations dans l'environnement, vous devez tenir compte des stratégies et des impératifs organisationnels pour trouver le juste équilibre entre la sécurité et les fonctionnalités administratives. Vous pouvez bénéficier d'une grande souplesse lors de l'établissement de la délégation d'autorisations administratives, en fonction des besoins de votre organisation. Les frontières de délégation peuvent être subdivisées en frontières de sécurité et en frontières administratives.

Frontières de sécurité

Les frontières de sécurité permettent de définir l'autonomie octroyée aux différents groupes de l'organisation. Il est difficile de trouver le compromis idéal pour assurer, d'une part, une sécurité adéquate, fondée sur la définition de ces frontières, et offrir, d'autre part, un niveau adéquat et suffisant de fonctionnalités de base.

Cet équilibre entre les frontières de sécurité et les fonctionnalités existe. Vous devez appréhender correctement les menaces à l'origine de risques pour votre organisation et comparer ensuite cette évaluation avec les implications qu'il y a, au niveau de la sécurité, à déléguer l'administration ou à prendre d'autres décisions essentielles au niveau de l'architecture réseau de votre environnement.

Frontière de sécurité : la forêt

Au moment de la sortie de Microsoft® Windows® 2000 Server, le domaine était défini comme une frontière de sécurité dans une grande partie de la documentation afférente. Plus récemment toutefois, c'est la forêt qui émerge comme véritable frontière de sécurité. En réalité, celle-ci se situe quelque part entre les deux.

Un domaine est une frontière administrative d'Active Directory. Dans une organisation qui occupe uniquement des personnes bien intentionnées, la frontière de domaine permet une gestion autonome des services et des données à l'intérieur de chaque domaine de l'organisation.

Hélas, cet objectif n'est pas simple à réaliser lorsque la sécurité est au centre du débat. Ainsi, un domaine n'est pas parfaitement à l'abri d'une attaque possible par un administrateur de domaine malveillant. Ce niveau de séparation ne peut être obtenu qu'au niveau de la forêt.

Par conséquent, votre organisation devra peut-être envisager de dissocier le contrôle administratif des services et des données de la structure effective. Si vous comprenez parfaitement les besoins de l'organisation en termes d'autonomie et d'isolation des services et des données, votre structure Active Directory n'en sera que plus solide.

Frontières administratives

Dans la mesure où il peut s'avérer nécessaire de segmenter les services et les données, différents niveaux d'administration doivent être définis.

Administrateurs de service

Les administrateurs de service Active Directory sont chargés de configurer et de fournir le service d'annuaire. Par exemple, ils gèrent les serveurs jouant le rôle de contrôleurs de domaines, contrôlent les paramètres de configuration au niveau de l'annuaire et doivent garantir la disponibilité du service.

Souvent, la configuration du service Active Directory est déterminée par des valeurs d'attributs correspondant à des paramètres de leurs objets respectifs, lesquels sont stockés dans l'annuaire. Par conséquent, dans Active Directory, les administrateurs de service sont également des administrateurs de données et peuvent être notamment :

· des groupes d'administrateurs responsables de la gestion de la forêt ;

· des groupes d'administrateurs chargés de la gestion du domaine ;

· des groupes d'administrateurs chargés de la gestion de DNS (Domain Name System) ;

· des groupes d'administrateurs responsables de la gestion des unités d'organisation ;

· des groupes d'administrateurs chargés de la gestion de serveur d'infrastructure.

Les groupes qui ont la charge de l'administration de la forêt doivent assurer l'accessibilité du service d'annuaire au réseau. Celui qui assure la gestion de la forêt doit être un groupe présentant un très haut niveau d'approbation. L'équipe chargée de l'administration de la forêt contrôle cette dernière par l'intermédiaire du groupe Administrateur du domaine, du domaine racine de la forêt, du groupe Administrateurs de l'entreprise et du groupe Administrateurs du schéma.

Un groupe assurant l'administration du domaine est principalement responsable des services d'annuaire. C'est l'administrateur de la forêt qui a pour mission de choisir le groupe chargé d'administrer chaque domaine. En raison de l'accès de haut niveau accordé à l'administrateur du domaine, veillez à attribuer ce rôle à une personne digne de confiance. Le groupe chargé de l'administration du domaine contrôle le domaine via le groupe Admins du domaine et d'autres groupes intégrés.

Le groupe des administrateurs DNS est pour sa part responsable du parachèvement de la structure DNS et de la gestion de l'infrastructure DNS, et ce, par l'intermédiaire du groupe des administrateurs DNS.

L'administrateur des unités d'organisation désigne un groupe ou un individu en qualité de gestionnaire de chacune des unités d'organisation. Chaque administrateur d'une unité d'organisation a le devoir de gérer les données stockées dans l'unité d'organisation qui lui est assignée. Ces groupes peuvent contrôler la manière dont l'administration est déléguée et dont la stratégie est appliquée aux objets de leurs unités d'organisation. Les administrateurs des unités d'organisation peuvent également créer de nouvelles sous-arborescences et déléguer l'administration des unités d'organisation dont ils sont responsables.

Le groupe chargé de l'administration du serveur d'infrastructure a pour mission de gérer les services WINS (Windows Internet Name Service), DHCP (Dynamic Host Configuration Protocol) et éventuellement l'infrastructure DNS. Dans certains cas, le groupe responsable de la gestion du domaine gère aussi l'infrastructure DNS puisque Active Directory est intégré à DNS et qu'il est stocké et géré sur les contrôleurs de domaines.

Administrateurs de données

Les administrateurs de données Active Directory sont responsables de la gestion des données stockées dans Active Directory ou sur les ordinateurs faisant partie d'Active Directory. Ils n'ont aucun contrôle sur la configuration ou la mise à disposition du service d'annuaire et peuvent être notamment :

· des administrateurs qui contrôlent un sous-ensemble d'objets de l'annuaire puisque, via le contrôle d'accès héritable au niveau de l'attribut, ils peuvent se voir accorder le contrôle de sections très spécifiques de l'annuaire mais n'ont aucun contrôle sur la configuration du service lui-même ;

· des administrateurs qui gèrent les ordinateurs membres faisant partie de l'annuaire et les données stockées sur ces ordinateurs.

Remarque : Très souvent, la configuration du service d'annuaire est déterminée par les valeurs d'attribut des objets stockés dans l'annuaire.

En résumé, les conséquences potentielles de l'intégration d'une organisation à une infrastructure de forêt ou de domaine sur les structures du service Active Directory et les propriétaires de la structure de répertoires contraignent l'organisation à approuver tous les administrateurs de service de la forêt et de tous les domaines. Dans ce contexte, approuver les administrateurs de service signifie :

· croire raisonnablement qu'ils opéreront dans le meilleur intérêt de l'organisation, laquelle ne doit pas rejoindre une forêt ou un domaine si les propriétaires de la forêt ou du domaine peuvent avoir des raisons légitimes de lui nuire ;

· croire raisonnablement qu'ils suivront les meilleures pratiques et qu'ils imposeront des restrictions en termes d'accès physique aux contrôleurs de domaines ;

· comprendre et accepter les risques que représentent pour l'organisation des administrateurs malintentionnés ou corrompus.

· Administrateurs malintentionnés. Il est possible qu'un administrateur digne de confiance décide d'abuser du pouvoir dont il dispose sur le système.

· Administrateurs corrompus. Un administrateur de confiance peut être corrompu ou forcé à effectuer certaines opérations qui violent la sécurité du système.

Certaines organisations peuvent accepter le risque d'une violation de sécurité par un administrateur de service malintentionné ou corrompu provenant d'une autre partie de l'organisation. Elles jugent peut-être que ce risque est accessoire comparativement aux avantages en termes d'économies financières et de collaboration qu'elles tirent à faire partie d'une infrastructure partagée. D'autres peuvent refuser ce risque dans la mesure où les conséquences potentielles d'une violation de la sécurité sont trop graves.

Conception d'unité d'organisation orienté sécurité

Si ce guide n'est pas consacré à la structure Active Directory, certaines informations relatives à la conception sont toutefois nécessaires afin que le lecteur puisse se faire une idée précise de l'utilisation de la stratégie de groupe en vue d'assurer l'administration sécurisée du domaine, des contrôleurs de domaines et des rôles de serveur spécifiques.

Les unités d'organisation simplifient le regroupement des utilisateurs et d'autres entités de sécurité, mais elles offrent en outre un mécanisme efficace pour définir des frontières administratives.

De plus, le recours à des unités d'organisation pour fournir différents objets Stratégie de groupe (GPO, Group Strategy Object) basés sur un rôle de serveur fait partie intégrante de l'architecture de sécurité globale de l'organisation.

Délégation de l'administration

Une unité d'organisation n'est autre qu'un conteneur dans un domaine. Le contrôle d'une unité d'organisation peut être délégué à un groupe ou à un individu en affectant à ce conteneur des listes de contrôle d'accès (ACL, Access Control List) spécifique.

Une unité d'organisation sert généralement à offrir des fonctionnalités administratives similaires à celles des domaines de ressources Microsoft® Windows NT® 4.0. Elle peut également être créée pour contenir un groupe de serveurs de ressources administrés par d'autres utilisateurs. Si ce groupe d'autres utilisateurs peut contrôler de façon autonome cette unité d'organisation particulière, il n'est pas isolé du reste du domaine.

Les administrateurs qui délèguent le contrôle d'unités d'organisation spécifiques sont, dans la plupart des cas, des administrateurs de service. À un niveau d'autorité inférieur, les utilisateurs qui contrôlent les unités d'organisation sont généralement des administrateurs de données.

Groupes d'administration

La création de groupes d'administration offre aux administrateurs un moyen de segmenter les groupes d'utilisateurs, les groupes ou les serveurs en conteneurs afin de leur accorder des fonctions d'administration autonome.

Prenons l'exemple des serveurs d'infrastructure d'un domaine : ces derniers regroupent tous les ordinateurs qui ne sont pas contrôleurs de domaines et qui exécutent des services réseau de base, comme les serveurs DNS, WINS ou DHCP.

Souvent, ces serveurs sont gérés par un groupe d'opérations ou un groupe d'administration de l'infrastructure. Une unité d'organisation peut être employée pour accorder des fonctionnalités d'administration de ces serveurs.

Pour cela, il faut tout d'abord créer une unité d'organisation appelée Serveurs d'infrastructure, dans laquelle tous les serveurs DNS, WINS ou DHCP peuvent ensuite être placés. Un groupe de sécurité global appelé Administrateurs de l'infrastructure peut être créé et les comptes de domaine appropriés peuvent y être ajoutés. Enfin, l'Assistant Délégation de contrôle peut être exécuté pour donner à ce groupe le contrôle total sur l'unité d'organisation. La figure ci-dessous propose une vue générale de cette unité d'organisation.

Figure 5.1.

Délégation de l'administration à l'unité d'organisation.

Il s'agit là d'une des nombreuses méthodes d'utilisation possibles des unités d'organisation pour établir une segmentation de l'administration. Si votre organisation est plus complexe, reportez-vous aux autres références répertoriées à la fin de ce chapitre.

Au terme de cette procédure, le groupe Administrateurs de l'infrastructure doit disposer du contrôle total sur l'unité d'organisation Serveurs d'infrastructure et sur tous les serveurs et objets qu'elle contient. Ainsi s'achève l'étape préparatoire de la phase « sécurisation des rôles de serveur à l'aide d'une stratégie de groupe ».

Application de la stratégie de groupe

La stratégie de groupe peut être associée à la délégation de l'administration pour garantir l'application des paramètres, des droits et d'un comportement spécifiques à tous les serveurs d'une unité d'organisation. Le recours à la stratégie de groupe au lieu des procédures manuelles simplifie la mise à jour de nombreux serveurs lors des modifications qui ne manqueront pas d'intervenir.

Les stratégies de groupe sont accumulées et appliquées dans l'ordre indiqué ci-dessous.

Figure 5.2.

Hiérarchie d'application des objets Stratégie de groupe.

Comme vous pouvez le constater, les stratégies sont appliquées en commençant par la stratégie locale de l'ordinateur. Après cela, les objets Stratégie de groupe (GPO) sont appliqués au niveau du site puis au niveau du domaine. Si le serveur est imbriqué dans plusieurs unités d'organisation, tous les GPO existant dans l'unité d'organisation de premier niveau sont appliqués en premier lieu. Le processus d'application des GPO se poursuit en respectant un ordre décroissant dans la hiérarchie d'unités d'organisation. Le dernier objet GPO à être appliqué sera celui de l'unité d'organisation locale où se trouve l'objet serveur.

Ce modèle donne lieu à diverses observations.

· Si plusieurs GPO sont définis à l'un des niveaux de la stratégie de groupe illustrée ci-dessus, un administrateur établira l'ordre dans lequel ces objets seront appliqués. Si la même option est spécifiée dans plusieurs stratégies, la dernière à être appliquée sera prioritaire.

· Une stratégie de groupe peut être configurée avec l'option Ne pas passer outre. Si vous sélectionnez cette option, d'autres GPO ne peuvent pas remplacer les paramètres configurés dans le cadre de cette stratégie.

Modèles de sécurité

Les modèles de stratégie de groupe sont des fichiers texte. Il est possible d'y apporter des modifications à l'aide du composant logiciel enfichable Modèles de sécurité de la MMC (Microsoft Management Console) ou au moyen d'un simple éditeur de texte tel que le Bloc-notes. Certaines sections des fichiers de modèle contiennent des listes ACL spécifiques définies par le langage SDDL (Security Descriptor Definition Language). Pour plus d'informations sur l'édition des modèles de sécurité et sur SDDL, reportez-vous au site Microsoft® MSDN®.

Centralisation des modèles

Il est très important de stocker les modèles de sécurité utilisés pour la production dans un emplacement sécurisé de votre environnement, accessible uniquement par les administrateurs chargés de l'implémentation de la stratégie de groupe. Par défaut, les modèles de sécurité se trouvent dans le dossier %SystemRoot%\security\templates de tous les ordinateurs Windows 2000.

Ce dossier n'est pas répliqué entre les contrôleurs de domaines. Il faut donc sélectionner un contrôleur de domaine qui hébergera la copie principale des modèles de sécurité de façon à éviter les conflits liés à des versions de modèles différentes. De cette façon, vous êtes certain de toujours modifier le même exemplaire des modèles.

Configuration de l'heure

Il est essentiel de disposer d'une heure système exacte et d'avoir pour tous les serveurs la même source de temps. Le service W32Time de Windows 2000 assure la synchronisation des heures pour les ordinateurs Microsoft® Windows® 2000 et Microsoft® Windows® XP appartenant à un domaine Active Directory.

Il garantit la synchronisation de toutes les horloges des systèmes clients Windows 2000 avec celles des contrôleurs du domaine, élément indispensable au bon fonctionnement du protocole d'authentification Kerberos version 5. La synchronisation de l'heure facilite également l'analyse des journaux des événements.

Kerberos est un protocole d'authentification réseau développé par le MIT (Massachusetts Institute of Technology). Il authentifie l'identité des utilisateurs qui tentent de se connecter au réseau et crypte leurs communications par une technique basée sur une clé secrète.

Le service W32Time synchronise les horloges à l'aide du protocole SNTP (Simple Network Time Protocol) conformément à la RFC 1769. Dans une forêt Windows 2000 Server, l'heure est synchronisée comme suit :

· Le maître des opérations émulateur du contrôleur principal (PDC) du domaine racine de la forêt est la source de temps qui fait autorité pour l'organisation.

· Tous les maîtres des opérations PDC des autres domaines de la forêt respectent la hiérarchie de domaines lors de la sélection d'un émulateur PDC avec lequel synchroniser l'heure.

· Tous les contrôleurs d'un domaine synchronisent leur heure avec le maître des opérations de l'émulateur PDC dans leur domaine en tant que partenaires de service de temps entrant.

· Tous les serveurs membres et les ordinateurs clients utilisent le contrôleur de domaine d'authentification comme leur partenaire pour la synchronisation du temps.

Pour s'assurer que l'heure est exacte, l'émulateur PDC du domaine racine de la forêt peut être synchronisé avec un serveur de temps SNTP externe. Toutefois, cette opération peut exiger l'ouverture de ports du pare-feu, c'est pourquoi il est indispensable de mettre en balance au préalable les avantages offerts par l'opération et le risque de sécurité potentiel qu'elle présente.

Souvent, il n'est pas nécessaire que tous les serveurs soient synchronisés avec une source de temps externe, à condition qu'ils le soient avec la même source de temps à l'intérieur du réseau de l'organisation.

Si votre réseau comprend des ordinateurs Microsoft® Windows® 95 ou Microsoft® Windows® 98, les horloges de ces ordinateurs doivent être synchronisées en insérant la commande suivante dans un script d'ouverture de session où <ordinateur_temps> est un contrôleur de domaine du réseau :

net time \\<ordinateur_temps> /set /yes

L'exécution de cette commande permet d'empêcher que les horloges de ces ordinateurs présentent une différence de temps par rapport à d'autres ordinateurs du domaine.

Remarque : Les ordinateurs du réseau exécutant des systèmes d'exploitation non-Windows doivent également synchroniser leurs horloges avec l'émulateur PDC du domaine Windows 2000 pour permettre une analyse des événements du journal basée sur la même heure.

Unités d'organisation par rôle de serveur

L'exemple précédent illustrant la gestion des serveurs d'infrastructure de l'organisation peut être également étendu au scénario Contoso. L'objectif est de créer une stratégie de groupe générale qui englobe tous les serveurs, tout en s'assurant que les serveurs résidant dans Active Directory respectent les normes de sécurité requises par votre environnement.

Stratégie de domaine

La première étape de ce processus consiste à créer une nouvelle stratégie au niveau du domaine. En effet, la stratégie de domaine par défaut de Windows 2000 doit être mieux sécurisée. L'administrateur doit créer une nouvelle stratégie et la lier à l'objet GPO du domaine. Pour être certain que cette nouvelle stratégie a la priorité sur la stratégie par défaut, déplacez-la pour qu'elle présente le niveau de priorité le plus élevé dans les liaisons de l'objet Stratégie de groupe.

Il est évidemment toujours possible de modifier directement la stratégie par défaut pour créer une nouvelle configuration de sécurité, mais la création d'une toute nouvelle stratégie permet en cas de problème une désactivation facile et le remplacement de la nouvelle stratégie par la stratégie de domaine par défaut.

Stratégie de base

La deuxième étape consiste à créer une stratégie de base. Pour cela, il faut créer un modèle de sécurité de base et l'importer dans la stratégie. Le modèle MSS Baseline.inf, inclus dans cette solution, fournit cette fonctionnalité. Ce modèle de sécurité GPO doit être lié à l'unité d'organisation Serveurs membres. Le modèle MSS Baseline.inf applique les paramètres de la stratégie de base à tous les serveurs de l'unité d'organisation Serveurs membres ainsi qu'à ceux des unités d'organisation enfants.

La stratégie de base doit définir les paramètres voulus pour tous les serveurs de l'organisation. Elle doit en outre être aussi restrictive que possible, et tous les serveurs auxquels elle ne doit pas être appliquée doivent être placés dans des unités d'organisation de serveurs spécifiques, comme l'unité d'organisation Serveurs d'infrastructure.

Unités d'organisation par rôle de serveur

Pour reprendre l'exemple ci-dessus, une stratégie distincte, contenant les modifications incrémentielles, doit être créée pour les serveurs d'infrastructure. Un modèle de sécurité appelé MSS Infrastructure Role.inf peut contenir tous les paramètres nécessaires pour assurer le bon fonctionnement des services d'infrastructure et leur disponibilité sur l'ensemble du réseau.

Ce GPO doit être lié à l'unité d'organisation Infrastructure. Enfin, le paramètre Groupes restreints doit être utilisé pour ajouter les trois groupes suivants au groupe Administrateurs locaux de l'objet GPO Stratégie d'infrastructure : Administrateurs du domaine, Administrateurs de l'entreprise et Administrateurs de l'infrastructure.

Ce processus est illustré par la figure ci-dessous.

Figure 5.3.

Configuration de stratégies de groupe incrémentielles.

Pour rappel, il s'agit là d'une des nombreuses approches possibles pour créer une structure d'unités d'organisation en vue du déploiement d'objets GPO.

Pour plus d'informations sur la création d'unités d'organisation en vue de l'implémentation de la stratégie de groupe, reportez-vous à l'article Microsoft® TechNet intitulé « Best Practice Active Directory Design for Managing Windows Networks » (en anglais), disponible à l'adresse suivante : http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/ad/windows2000/deploy/depovg/bpaddply.asp.

Dans ce guide, plusieurs rôles de serveur sont définis. Les modèles de sécurité indiqués dans le tableau suivant ont été créés conformément au processus décrit plus haut, afin de renforcer la sécurité pour ces rôles.

Tableau 5.1. Rôles de serveur Windows 2000

Rôle de serveur	Description	Modèle de sécurité
Contrôleur de domaine Windows 2000	Groupe contenant les contrôleurs de domaine Active Directory.	MSS DCBaseline.inf
Serveurs membres Windows 2000	Tous les serveurs membres du domaine résidant dans l'unité d'organisation des serveurs membres ou sous son arborescence	MSS Baseline.inf
Serveur de fichiers et d'impression Windows 2000	Groupe contenant les serveurs de fichiers et d'impression.	MSS FilePrint Role.inf
Serveur d'infrastructure Windows 2000	Groupe contenant les serveurs DNS, WINS et DHCP.	MSS Infrastructure Role.inf
Serveur IIS Windows 2000	Groupe contenant les serveurs IIS.	MSS IIS Role.inf

Tous les fichiers de modèle incrémentiel sont censés être appliqués aux unités d'organisation situées sous l'unité d'organisation des serveurs membres. Dès lors, chacune de ces unités d'organisation de niveau inférieur doit se voir appliquer à la fois le modèle MSS Baseline.inf et le fichier incrémentiel spécifique, afin de définir le rôle que chacune va jouer dans l'organisation.

Chacun de ces rôles répond à des impératifs différents sur le plan de la sécurité. Les paramètres de sécurité requis pour chacun d'eux sont décrits dans le détail au chapitre 7, « Renforcement de la sécurité pour des rôles de serveur spécifiques ».

Important : Ce guide suppose que les serveurs Windows 2000 remplissent des rôles spécifiques définis. Si les serveurs de votre entreprise ne correspondent pas à ces rôles ou s'ils doivent remplir plusieurs fonctions, créez vos propres modèles de sécurité en vous inspirant des paramètres indiqués ici. Il est toutefois important de garder à l'esprit que le degré de vulnérabilité d'un serveur aux attaques croît proportionnellement au nombre de fonctions qu'il doit assumer.

La structure d'unités d'organisation finale nécessaire à la prise en charge de ces rôles de serveur est illustrée dans la figure ci-dessous.

Figure 5.4.

Exemple de structure d'unités d'organisation.

Conception d'OU, de GPO et de groupes administratifs de Contoso

Les recommandations ci-dessus sont appliquées à la société Contoso afin de réorganiser sa structure d'unités d'organisation existante pour les serveurs Windows 2000. De plus, les administrateurs de Contoso utilisent leurs frontières d'administration prédéfinies pour créer leurs groupes administratifs. La corrélation existant entre ces groupes et les unités d'organisation qu'ils gèrent est décrite dans le tableau suivant.

Tableau 5.2. Unités d'organisation et groupes administratifs de Contoso

Nom de l'unité d'organisation	Groupe administratif
Contrôleurs de domaines	Ingénierie du domaine
Serveurs membres	Ingénierie du domaine
Infrastructure	Opérations
Fichiers et impression	Opérations
Web	Services Web

Au sein de Contoso, chaque groupe administratif a été créé en tant que groupe global dans le domaine enfant NorthAmerica

Contoso a ajouté chacun de ces groupes au groupe restreint approprié au moyen de la GPO correspondante. Les groupes administratifs créés précédemment seront uniquement membres du groupe Administrateurs locaux pour les ordinateurs se trouvant dans les unités d'organisation regroupant les ordinateurs en fonction de leur rôle.

Enfin, Contoso a défini des autorisations sur chaque objet GPO de sorte qu'ils puissent être modifiés uniquement par les administrateurs du groupe ingénierie du domaine.

Par défaut, la nouvelle structure d'unités d'organisation hérite de nombreux paramètres de sécurité de son conteneur parent. La case à cocher Permettre aux autorisations pouvant être héritées du parent d'être propagées à cet objet doit être désactivée pour chaque unité d'organisation. Tous les groupes précédemment créés par les administrateurs qui ne présentent pas réellement d'utilité doivent être supprimés, et le groupe de domaine correspondant à chaque unité d'organisation de rôle de serveur doit être ajouté. Le groupe Administrateurs du domaine doit conserver le contrôle total.

Les tâches requises pour établir ces unités d'organisation ne doivent pas être effectuées dans un ordre particulier, mais il est clair que certaines sont tributaires d'autres tâches. Ainsi, il faut avoir créé les groupes du domaine avant de pouvoir leur déléguer le contrôle des différentes unités d'organisation. Voici l'ordre dans lequel nous vous suggérons d'accomplir ces tâches :

Création de la structure d'unités d'organisation
Déplacement des ordinateurs vers les unités d'organisation adéquates
Création des groupes administratifs
Ajout des comptes de domaine adéquats aux groupes administratifs
Délégation de l'administration de chacune des unités d'organisation aux groupes de domaine appropriés
Création des stratégies de groupe dans l'unité d'organisation où elles seront appliquées
Liaison de chaque stratégie de groupe à d'autres unités d'organisation en fonction des besoins
Importation du modèle de sécurité voulu pour chaque objet GPO
Définition des autorisations de chaque objet GPO pour qu'ils soient contrôlés par les groupes de domaine voulus
Ajout des groupes de domaine requis aux groupes restreints pour chaque objet GPO
Test et amélioration des stratégies de groupe

Stratégie de domaine

Les paramètres de sécurité de la stratégie de groupe peuvent être appliqués à différents niveaux de l'organisation. Contoso a décidé d'utiliser la stratégie de groupe pour appliquer ces paramètres aux trois niveaux suivants :

· Stratégie de domaine. Pour répondre aux impératifs de sécurité communs, comme les stratégies de comptes à appliquer pour tous les serveurs.

· Stratégie de base. Pour répondre aux conditions de sécurité requises pour tous les serveurs du réseau.

· Stratégie de rôle. Pour satisfaire aux exigences de sécurité propres aux différents rôles de serveur. Par exemple, les serveurs d'infrastructure n'ont pas les mêmes impératifs en termes de sécurité que les serveurs Microsoft® Internet Information Services (IIS).

En matière d'audit de sécurité, IIS crée des fichiers journaux assurant le suivi des tentatives de connexion aux services Web, FTP (File Transfer Protocol), NNTP (Network News Time Protocol) et SMTP (Simple Mail Transfer Protocol).

Présentation de la stratégie de domaine

La stratégie de groupe est un outil extrêmement puissant puisqu'elle permet d'appliquer une configuration standard à tous les ordinateurs du réseau. Les GPO constituent un élément essentiel d'une solution de gestion de la configuration pour toute entreprise puisqu'ils offrent aux administrateurs la possibilité d'apporter des modifications de sécurité sur tous les ordinateurs (ou des sous-ensembles d'ordinateurs) du domaine à la fois.

Parmi les types de modifications de sécurité qu'il est possible d'appliquer simultanément à l'aide de la stratégie de groupe, il faut citer celles qui concernent :

· les autorisations sur le système de fichiers ;

· les autorisations sur les objets du Registre ;

· les paramètres du Registre ;

· les affectations de droits d'utilisateur ;

· la configuration des services système ;

· la configuration des journaux d'audit et des événements ;

· la définition des stratégies de comptes et de mot de passe.

Les paramètres de la stratégie de groupe qui concernent ces modifications de sécurité sont répartis dans plusieurs sections de la stratégie des ordinateurs Windows 2000 Server.

Tableau 5.3. Sections de la stratégie des ordinateurs Windows 2000 Server

Nom de la section de stratégie dans l'interface	Description
Stratégie de comptes\Stratégie de mot de passe	Configure la durée de vie, la longueur et la complexité des mots de passe.
Stratégie de comptes\Stratégie de verrouillage des comptes	Configure la durée et le seuil de verrouillage, ainsi que la réinitialisation du compteur.
Stratégie de comptes\Stratégie Kerberos	Configure la durée de vie des tickets.
Stratégies locales\Stratégie d'audit	Active ou désactive l'enregistrement d'événements spécifiques.
Stratégies locales\Attribution des droits utilisateur	Définit des droits tels que l'ouverture de session en local et l'accès au réseau.
Stratégies locales\Options de sécurité	Modifie des valeurs de Registre spécifiques liées à la sécurité.
Journal des événements	Active la surveillance des réussites et des échecs.
Groupes restreints	Les administrateurs contrôlent les membres de groupes spécifiques.
Services système	Contrôle le mode de démarrage de chaque service.
Registre	Configure les autorisations et l'audit de clés de Registre.
Système de fichiers	Configure les autorisations et l'audit de dossiers, sous-dossiers et fichiers.

Tous les ordinateurs possèdent une stratégie locale prédéfinie. Lors de la création initiale d'un domaine Active Directory, des stratégies de domaine et de contrôleur de domaine par défaut sont également générées. Au lieu de modifier les stratégies par défaut, il est conseillé de créer une nouvelle stratégie et de la lier au domaine, ce qui permettra, le cas échéant, d'annuler tous les paramètres susceptibles de provoquer des problèmes non identifiés dans l'environnement. Si les stratégies par défaut sont modifiées, il est important de documenter les paramètres qu'elles contiennent, de sorte qu'il soit possible de rétablir rapidement les stratégies antérieures en cas de problème.

Figure 5.5.

Application de stratégies de domaine.

La section suivante traite des paramètres au niveau du domaine qu'il convient d'étudier et de documenter.

Stratégies de comptes

Les stratégies de comptes sont implémentées au niveau du domaine. Un domaine Windows 2000 Server doit disposer d'une stratégie de mot de passe unique, d'une stratégie de verrouillage des comptes et d'une stratégie Kerberos version 5 pour le domaine. Si vous définissez ces stratégies à un autre niveau d'Active Directory, elles sont appliquées uniquement aux comptes locaux des serveurs membres. Si certains groupes requièrent des stratégies de mot de passe distinctes, ils doivent être placés dans un autre domaine ou dans une autre forêt, en fonction des exigences supplémentaires qu'ils présentent.

Stratégie de mot de passe

Dans Windows 2000 Server, la méthode la plus courante pour authentifier l'identité d'un utilisateur consiste à recourir à un mot de passe secret. Une fois l'utilisateur identifié et authentifié, il peut accomplir toutes les tâches et accéder à toutes les ressources pour lesquelles il dispose des autorisations appropriées.

La sécurisation d'Active Directory dans votre environnement nécessite l'utilisation de mots de passe forts par tous les utilisateurs. En effet, il existe une menace bien réelle de voir un utilisateur non autorisé deviner un mot de passe trop simple soit manuellement, soit à l'aide d'outils capables d'obtenir les informations d'identification d'un compte utilisateur compromis. Le recours aux mots de passe forts permet de pallier à ce risque. Il est surtout essentiel dans le cas des comptes d'administration.

Un mot de passe complexe qui est modifié régulièrement réduit les chances de réussite d'une attaque des mots de passe. Les paramètres de la stratégie de mot de passe contrôlent la complexité et la durée de vie des mots de passe. Chaque paramètre de compte spécifique de cette stratégie est étudié dans cette section.

Les valeurs suivantes peuvent être configurées dans les paramètres de la stratégie de groupe du domaine, à l'emplacement suivant : Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\Stratégies de comptes\Stratégie de mot de passe

Conserver l'historique des mots de passe

Vulnérabilité

La réutilisation des mots de passe constitue un problème majeur dans toute organisation. Au moins trois modes de réutilisation des mots de passe sont à l'origine de cette vulnérabilité :

· Réutilisation d'un même mot de passe pour plusieurs comptes de l'organisation. Il arrive fréquemment que des utilisateurs ou des administrateurs possédant plusieurs comptes dans différents domaines (ou associés à différentes fonctions au sein d'un même domaine) choisissent le même mot de passe pour tous leurs comptes.

· Utilisation ou réutilisation du même mot de passe pour un compte quelconque pendant une période prolongée. Si les utilisateurs sont tenus de changer leur mot de passe, rien ne les empêche de spécifier à nouveau leur ancien mot de passe ou de réutiliser continuellement un nombre réduit de mots de passe. Dès lors, la stratégie de mot de passe est beaucoup moins efficace.

· Réutilisation du même mot de passe pour plusieurs comptes de service. Si une organisation doit utiliser des comptes de ce type, chacun doit disposer d'un mot de passe unique qui respecte au minimum les normes de base définies en matière de définition de mot de passe afin de s'assurer qu'il soit extrêmement difficile à décoder.

La valeur indiquée pour l'option Conserver l'historique des mots de passe détermine le nombre de nouveaux mots de passe uniques devant être associés à un compte utilisateur avant qu'un ancien mot de passe puisse être réutilisé.

Si vous spécifiez une valeur faible, les utilisateurs peuvent affecter continuellement le même nombre réduit de mots de passe à plusieurs reprises. Si, en outre, vous ne spécifiez pas de valeur pour l'option Durée minimale du mot de passe, les utilisateurs peuvent changer plusieurs fois leur mot de passe mais au final réutiliser leur mot de passe initial.

Pour que l'option Conserver l'historique des mots de passe soit efficace dans votre organisation, la configuration du paramètre Durée minimale du mot de passe doit empêcher que les mots de passe puissent être modifiés immédiatement.

Contre-mesure

Attribuez à l'option Conserver l'historique des mots de passe la valeur 24. Il s'agit de la valeur maximale puisque la plage de valeurs acceptées est de 0 à 24 mots de passe. Ce paramètre est défini avec la valeur 1 dans l'objet GPO Domaine par défaut et dans la stratégie de sécurité locale des stations de travail et des serveurs. Si vous lui affectez la valeur maximale, vous limitez les vulnérabilités liées à la réutilisation des mots de passe.

Impact potentiel

La principale conséquence de ce paramètre est, pour les utilisateurs, de devoir indiquer un tout nouveau mot de passe chaque fois qu'ils doivent modifier l’existant. En obligeant de la sorte les utilisateurs à spécifier systématiquement un nouveau mot de passe encore jamais choisi, vous vous exposez à un autre danger : que certains d'entre eux inscrivent leurs mots de passe quelque part afin de ne pas l'oublier.

Le mieux est de trouver une valeur qui soit un compromis raisonnable pour tous les utilisateurs de l'organisation, tant pour la durée de vie maximale des mots de passe que pour l'intervalle de modification requis.

Scénario Contoso

Dans le scénario Contoso, la valeur 24 a été définie pour le paramètre Conserver l'historique des mots de passe.

Durée maximale du mot de passe

Vulnérabilité

Tout mot de passe peut être décodé. Avec les puissances de traitement atteintes de nos jours, la découverte des mots de passe les plus complexes n'est jamais qu'une question de temps et d'efforts. Certains des paramètres suivants peuvent rendre l'opération plus longue et plus difficile. Toutefois, une modification fréquente des mots de passe dans un environnement contribue à atténuer les risques de décodage et d'utilisation d'un mot de passe obtenu de façon illicite.

Le paramètre Durée maximale du mot de passe détermine le nombre de jours pendant lequel un mot de passe peut être utilisé avant que le système oblige l'utilisateur à le modifier. Sa valeur peut être définie de sorte que les utilisateurs ne soient jamais forcés de changer leurs mots de passe, mais cela représente un risque considérable en termes de sécurité.

Contre-mesure

Attribuez à l'option Durée maximale du mot de passe une valeur située entre 30 et 60 jours. La plage de valeurs possibles va de 1 à 999 jours, mais il est possible de spécifier que le mot de passe ne doit jamais expirer, en spécifiant la valeur 0. Ce paramètre possède la valeur 42 dans l'objet GPO Domaine par défaut et dans la stratégie de sécurité locale des stations de travail et des serveurs.

Impact potentiel

Si vous spécifiez pour ce paramètre un trop petit nombre de jours, les utilisateurs devront modifier leurs mots de passe très souvent. Au bout du compte, une telle mesure peut être dangereuse pour la sécurité de l'organisation car elle peut augmenter les risques qu'un utilisateur inscrive son mot de passe sur un post-il pour éviter de l'oublier. Il en va de même lorsqu'une valeur excessive est spécifiée puisque, potentiellement, les pirates disposent de plus de temps pour décoder les mots de passe.

Scénario Contoso

Dans le scénario Contoso, la valeur 42 jours a été définie pour le paramètre Durée maximale du mot de passe.

Cette valeur renforce la sécurité de l'environnement de Contoso puisque les utilisateurs sont tenus de changer de mot de passe régulièrement mais pas trop souvent, ce qui limite les désagréments causés aux utilisateurs.

Durée minimale du mot de passe

Vulnérabilité

Les utilisateurs qui souhaitent réutiliser un mot de passe peuvent être obligés de le modifier régulièrement. Si une stratégie est mise en place pour qu'ils ne puissent pas réutiliser leurs 12 derniers mots de passe, il leur suffit de changer consécutivement leur mot de passe 13 fois pour revenir au mot de passe initial.

Le paramètre Durée minimale du mot de passe détermine le nombre de jours pendant lesquels un mot de passe peut être utilisé avant qu'un utilisateur ne soit autorisé à le changer. La valeur spécifiée doit être inférieure à la valeur choisie comme durée maximale du mot de passe.

Pour rappel, une valeur supérieure à 0 doit être attribuée au paramètre Durée minimale du mot de passe pour que le paramètre Conserver l'historique des mots de passe soit efficace. En l'absence d'une durée minimale des mots de passe, l'utilisateur peut modifier son mot de passe plusieurs fois de suite, pour revenir à son ancien mot de passe favori.

Contre-mesure

Attribuez à l'option Durée minimale du mot de passe la valeur 2 jours. Cette valeur peut se situer entre 1 et 998 jours. Il est même possible de spécifier la valeur 0, qui permet de modifier plusieurs fois de suite un mot de passe, mais cela n'est pas recommandé. Ce paramètre n'est pas défini dans l'objet GPO Domaine par défaut et dans la stratégie de sécurité locale des stations de travail et des serveurs, si bien que le mot de passe peut être modifié plusieurs fois à la suite.

Impact potentiel

L'attribution d'une valeur supérieure à 0 au paramètre Durée minimale du mot de passe pose un problème mineur. Si un administrateur définit temporairement un mot de passe pour un utilisateur et souhaite que celui-ci change ce mot de passe, il doit activer la case à cocher L'utilisateur doit changer de mot de passe à la prochaine ouverture de session. Sans cela, l'utilisateur ne pourra effectuer de modification avant le lendemain.

Scénario Contoso

Dans le scénario Contoso, le paramètre Durée de vie minimale du mot de passe a été établi à 2 jours, de façon à éviter la tentation d’enregistrer successivement des mots de passe pour revenir au final à un mot de passe familier.

Longueur minimale du mot de passe

Vulnérabilité

Plusieurs types d'attaques permettent d'obtenir le mot de passe d'un compte utilisateur particulier. Citons notamment les attaques par dictionnaire, qui consistent à essayer une multitude de mots et expressions courantes, et les attaques par force brute, qui tentent toutes les combinaisons possibles de chiffres et de lettres. Une attaque peut également s'appuyer sur la découverte du hachage de mot de passe LM et sur l'emploi d'utilitaires pour décoder les hachages et identifier les mots de passe.

La longueur minimale du mot de passe détermine le nombre minimal de caractères composant le mot de passe d'un compte utilisateur. Plusieurs théories ont été avancées pour déterminer la longueur de mot de passe idéale pour une organisation.

Contre-mesure

Attribuez au paramètre Longueur minimale du mot de passe la valeur 8 au moins. Les valeurs acceptables sont comprises entre 1 et 14 caractères. Aucun mot de passe n'est requis si vous spécifiez une longueur de 0. Ce paramètre possède la valeur 0 dans l'objet GPO Domaine par défaut et dans la stratégie de sécurité locale des stations de travail et des serveurs.

Dans la majorité des environnements, une longueur de mot de passe de 8 caractères est recommandée, puisque ce nombre suffit à fournir un niveau de sécurité correct tout en garantissant des mots de passe faciles à mémoriser. Cette valeur assure une mesure de défense adéquate contre les attaques par force brute. Si, parmi les conditions requises, figure en outre la complexité des mots de passe, les risques de voir une attaque par dictionnaire aboutir sont réduits. Nous aborderons les conventions de complexité à la section suivante.

L'attaque visant à découvrir le hachage de mot de passe est décrite dans le détail au chapitre 6, « Renforcement de la sécurité du serveur Windows 2000 de base ».

Impact potentiel

Si la longueur minimale du mot de passe définie est trop faible, la sécurité est réduite puisque les mots de passe courts peuvent être facilement décodés à l'aide d'outils spécialisés d'attaques par dictionnaire ou par force brute. En revanche, une longueur excessive augmente les risques de d’erreurs lors de la saisie des mots de passe, donc éventuellement des verrouillages de compte et, par suite, une hausse du volume d'appels au service d'assistance technique.

A fortiori, si des mots de passe extrêmement longs sont requis, cela peut finir par nuire à la sécurité d'une organisation car les utilisateurs noteront vraisemblablement leur mot de passe par crainte de l'oublier.

Scénario Contoso

Le scénario Contoso prévoit 8 caractères comme valeur de Longueur minimale du mot de passe.

Les mots de passe doivent respecter certaines exigences

Vulnérabilité

Les mots de passe contenant uniquement des caractères alphanumériques sont extrêmement faciles à décoder à l'aide de plusieurs utilitaires accessibles au grand public. Pour éviter cela, les mots de passe doivent contenir des caractères spéciaux et être soumis à certaines exigences de complexité.

Le paramètre Les mots de passe doivent respecter des exigences de complexité détermine si les mots de passe doivent respecter une série de conventions considérées comme importantes pour obtenir des mots de passe forts.

Si ce paramètre de stratégie est activé, les mots de passe doivent être conformes aux exigences suivantes :

· Le mot de passe ne doit pas contenir la totalité ou une partie du nom du compte utilisateur.

· Le mot de passe doit comporter au minimum six caractères.

· Le mot de passe doit contenir des caractères appartenant à trois des quatre catégories suivantes :

· caractères majuscules (de A à Z) ;

· caractères minuscules (de a à z) ;

· chiffres de 0 à 9 ;

· caractères non alphanumériques (comme !, $, # ou %).

Ces exigences de complexité sont appliquées lors de la modification ou de la création de nouveaux mots de passe.

Les règles incluses dans la stratégie Windows 2000 Server ne peuvent pas être modifiées directement. Toutefois, une nouvelle version du fichier passfilt.dll peut être créée, afin d'appliquer un autre jeu de règles. Vous trouverez le code source de passfilt.dll dans l'article 151082 de la Base de connaissances Microsoft, intitulé « HOW TO: Password Change Filtering & Notification in Windows NT » (en anglais).

Contre-mesure

Attribuez à l'option Les mots de passe doivent respecter des exigences de complexité la valeur Activé. Ce paramètre est désactivé dans l'objet GPO Domaine par défaut et dans la stratégie de sécurité locale des stations de travail et des serveurs.

Son activation, associée à une longueur minimale du mot de passe de 8 caractères, garantit qu'il existe au minimum 218 340 105 584 896 possibilités différentes de mots de passe, ce qui rend une attaque par force brute très difficile, voire impossible.

Impact potentiel

Si vous activez le fichier passfilt.dll par défaut, il se peut que vous constatiez une augmentation du volume d'appels au service d'assistance technique pour cause de comptes d'utilisateur verrouillés. En effet, les utilisateurs ne sont peut-être pas familiers avec les mots de passe contenant des caractères différents de ceux que l'on trouve dans l'alphabet. Toutefois, ce paramètre offre suffisamment de liberté pour que tous les utilisateurs puissent se faire aux exigences de complexité en un temps réduit.

D'autres exigences peuvent être stipulées dans un fichier passfilt.dll personnalisé, par exemple l'emploi de caractères non associés à la ligne de touches supérieure du clavier, c'est-à-dire ceux saisis en maintenant la touche maj enfoncée et en appuyant sur l'une des touches correspondant aux chiffres de 1 à 0 (sur un clavier US).

De plus, l'utilisation des combinaisons de caractères avec la touche alt peut augmenter considérablement la complexité d'un mot de passe. Toutefois, un tel niveau d'exigences de complexité dans l'ensemble de l'organisation peut provoquer le mécontentement des utilisateurs et se traduire par un service d'assistance technique débordé. Vous pouvez envisager de mettre en vigueur une convention qui requiert l'utilisation de caractères accessibles au moyen de la combinaison de touches alt + 0128 à 0159 pour tous les mots de passe d'administrateur. En dehors de cette plage, les caractères obtenus représentent souvent des caractères alphanumériques standards n'apportant rien à la complexité des mots de passe.

Scénario Contoso

Dans le scénario Contoso, la valeur Activé a été définie pour le paramètre Les mots de passe doivent respecter des exigences de complexité.

Stocker le mot de passe en utilisant le cryptage réversible pour tous les utilisateurs du domaine

Vulnérabilité

Certaines applications peuvent nécessiter l'accès via des mots de passe utilisateur pour proposer des fonctionnalités supplémentaires. Souvent, il faut pour cela que le stockage du mot de passe dans un format à « cryptage réversible », et donc non sécurisé, soit autorisé.

Le paramètre Stocker le mot de passe en utilisant le cryptage réversible pour tous les utilisateurs du domaine détermine si Windows 2000 Server stocke les mots de passe dans un format nettement moins sécurisé, comparable à du texte en clair, donc non crypté (on parle aussi parfois de message en texte brut). Son activation affaiblit les mots de passe de votre environnement.

Impact potentiel

Ce paramètre de stratégie est requis lorsque le protocole d'authentification CHAP est utilisé via les services d'accès distant ou d'authentification Internet (IAS, Internet Authentication Service), mais également lors de l'utilisation de l'authentification Digest dans IIS. Il est extrêmement dangereux d'appliquer ce paramètre à l'aide de la stratégie de groupe au cas par cas en fonction de l'utilisateur, car cela nécessite l'ouverture de l'objet de compte utilisateur approprié dans la console MMC Utilisateurs et ordinateurs Active Directory.

Avertissement : Ce paramètre de stratégie ne doit jamais être activé à moins que les fonctionnalités de l'application priment sur la nécessité de protéger les mots de passe.

Contre-mesure

Attribuez la valeur Désactivé au paramètre Stocker le mot de passe en utilisant le cryptage réversible pour tous les utilisateurs du domaine.

Ce paramètre est désactivé dans l'objet GPO Domaine par défaut et dans la stratégie de sécurité locale des stations de travail et des serveurs.

Scénario Contoso

Dans le scénario Contoso, la valeur Désactivé a été conservée pour le paramètre Stocker le mot de passe en utilisant le cryptage réversible pour tous les utilisateurs du domaine.

Résumé de la stratégie de mot de passe

Quelles que soient les stratégies de domaine définies, les paramètres L'utilisateur doit changer de mot de passe à la prochaine ouverture de session, L'utilisateur ne peut pas changer de mot de passe, Le mot de passe n'expire jamais et Stocker le mot de passe en utilisant le cryptage réversible pour tous les utilisateurs du domaine peuvent être configurés pour n'importe quel utilisateur individuel. Pour cela, il faut afficher l'onglet Compte de la boîte de dialogue des propriétés de l'utilisateur. Ces paramètres de stratégie de mot de passe d'utilisateur individuel priment les stratégies de domaine. Le tableau ci-dessous propose un récapitulatif des paramètres de stratégie de mot de passe dans l'environnement Contoso.

Tableau 5.4. Stratégies de mot de passe de Contoso

Nom du paramètre de stratégie de mot de passe dans l'interface	Valeur
Conserver l'historique des mots de passe	24 mots de passe mémorisés
Durée maximale du mot de passe	42 jours
Durée minimale du mot de passe	2 jours