Numéro spécial : Windows Server 2008

Nouveautés des services de domaine Active Directory

Gil Kirkpatrick

 

Vue d'ensemble:

• Utilisation du nouveau Gestionnaire de serveur avec les Services de domaine Active Directory (ADDS)
• Exécution de services de domaine sur Server Core
• Contrôleurs de domaine en lecture seule
• Modifications de mots de passe, sauvegardes et audits

Avec Windows 2000, Microsoft a révélé Active Directory. La version suivante, à savoir Windows Server 2003, contenait des améliorations significatives pour Active Directory, mais aucune

modification bouleversante. Aujourd'hui, Active Directory® est un service d'annuaire robuste et parvenu à maturité. Et pourtant, l'équipe d'Active Directory a fourni plusieurs améliorations non négligeables à la dernière version pour améliorer la sécurité et la gérabilité de ces principaux services réseau.

Début 2000, Active Directory permettait d'authentifier un utilisateur lorsqu'il se connectait, d'appliquer des stratégies de groupe à l'utilisateur et son ordinateur et de l'aider à trouver l'imprimante appropriée. Quelques années plus tard, Microsoft a mis sur le marché une variante autonome appelée Active Directory en mode application (ADAM).

En 2006, tout avait changé. Active Directory n'était plus une technologie spécifique. Active Directory est désormais un nom de marque qui identifie une collection de services de contrôle d'accès et d'identité Windows®. La figure 1 fournit un récapitulatif rapide de la composition d'Active Directory.

Figure 1 Composants Active Directory

Technologie Active Directory actuelle	précédemment appelée	Description
Services de domaine Active Directory	Active Directory	que nous appelions Active Directory. Elle fournit une authentification Kerberos et NTLM pour les ordinateurs et les utilisateurs de domaine, gère les unités organisationnelles, les utilisateurs, les groupes, les stratégies de groupe et plus encore.
Active Directory Lightweight Directory Services (ADLDS)	Active Directory Application Mode (ADAM)	Un serveur LPAD hautes performances basé sur le même code source que ADDS.
Services de certification d'Active Directory (ADCS)	Service de certification	Fournit une authentification puissante à l'aide de certificats X.509.
Services AD RMS (Active Directory Rights Management Services)	Serveur de gestion des droits	Protège les biens numériques, tels que les documents et les messages électroniques, d'une utilisation non autorisée en créant des fichiers et des conteneurs protégés par des droits.
Active Directory Federation Services (ADFS)	Active Directory Federation Services	Fournit des technologies Web d'authentification unique (SSO) et de fédération d'identité pour les services Web conformes à WS-*.

Donc, pour utiliser la terminologie appropriée, cet article est relatif aux Services de domaine. Mais pour clarifier les choses, il s'agit toujours de l'Active Directory que vous avez appris à aimer depuis 2000.

Gestionnaire de serveur dans Windows Server 2008

Les deux premières améliorations d'Active Directory que je vais aborder ne sont pas de réelles modifications dans les Services de domaine Active Directory. Il s'agit plutôt de modifications dans Windows qui modifieront la manière dont vous gérez Active Directory. La première amélioration, le nouveau Gestionnaire de serveur, apparaît dès que vous démarrez le serveur Windows Server® 2008 pour la première fois. (La seconde correspond à l'installation Server Core que j'aborderai ultérieurement.)

Le Gestionnaire de serveur vous sera probablement familier si vous connaissez l'Assistant Configurer votre serveur dans Windows Server 2003, qui apparaît par défaut après l'installation de Windows Server 2003. Cependant, cette version n'est pas très utile pour l'administration quotidienne et toutes les personnes que je connais cochent la case « Ne pas afficher cette page à l'ouverture de session ».

D'un autre côté, le Gestionnaire de serveur dans Windows Server 2008 est très utile (voir l'article de Byron Hynes dans ce numéro de TechNet Magazine pour une présentation du Gestionnaire de serveur). Tout d'abord, comme vous pouvez voir à la figure 2, le Gestionnaire de serveur est désormais un composant logiciel enfichable Microsoft ® Management Console (MMC) au lieu d'être une application HTML de Microsoft (HTA). Ceci signifie qu'il dispose d'une interface utilisateur complète que vous connaissez déjà et qui est facile à personnaliser. Prêt à l'emploi, le Gestionnaire de serveur vous permet de gérer l'installation de rôles de serveur (principaux services tels que DNS, ADDS et IIS) et de fonctionnalités (composants logiciel tels que Microsoft .NET Framework, chiffrement de lecteur BitLockerTM et Windows PowerShellTM). Au-delà de la possibilité d'ajouter et de supprimer des logiciels, le Gestionnaire de serveur fournit également un point de contact unique pour exécuter des outils de diagnostic (tels que l'Observateur d'événements et PerfMon) et des utilitaires de configuration du système (tels que le Gestionnaire de périphériques et le composant logiciel enfichable du Pare-feu Windows). Si vous ajoutez des composants logiciel enfichables MMC pour Active Directory (par exemple, Utilisateurs et ordinateurs, Domaines et approbations et Sites et services), vous aurez une interface conviviale pour exécuter la gestion quotidienne de votre contrôleur de domaine Windows Server 2008.

Figure 2** Gestionnaire de serveur dans Windows Server 2008 **(Cliquer sur l'image pour l'agrandir)

Windows Server 2008 Server Core

Windows Server Core est une nouvelle option d'installation Windows qui offre une version allégée de Windows contenant uniquement les composants nécessaires pour exécuter certains rôles de serveur clé, y compris les Services de domaine Active Directory. (La figure 3 répertorie les rôles pris en charge par Server Core.) Bien qu'une installation Server Core dispose d'une interface utilisateur graphique, elle n'exécute pas le shell de bureau Windows et ne contient quasiment pas d'outils graphiques pour gérer et configurer Windows (voir la figure 4). À leur place, vous obtenez une fenêtre de commande et l'étrange sensation que vous ne savez pas vraiment quoi faire. Comment puis-je modifier le nom de l'ordinateur ? Comment puis-je configurer une adresse IP statique ?

Figure 4** L'interface utilisateur Server Core n'a rien d'exceptionnel **(Cliquer sur l'image pour l'agrandir)

Les premières minutes d'une installation Server Core peuvent être déstabilisantes. Mais après un petit délai de familiarisation avec WMIC, NETSH et NETDOM, vous pourrez effectuer les tâches de configuration et d'installation normales sans aucune difficulté. Et vous avez toujours Regedit et le Bloc-notes pour vos outils graphiques.

Principal avantage de Server Core : une grande partie du code que vous obtenez avec une installation Windows typique, et dont vous n'aurez peut-être pas besoin pour ces rôles serveur de base, est supprimé. La surface d'attaque potentielle est réduite (ce qui est une bonne chose), réduisant ainsi la quantité de corrections et de démarrages à effectuer sur vos contrôleurs de domaine (ce qui est encore mieux). Vous obtenez une réduction de l'encombrement de disque et des exigences de disque dur local. En général, ceci n'est pas un problème mais peut vous aider dans les environnements de serveur virtualisés.

Le manque d'utilitaires graphiques rendra-t-il la gestion de Services de domaine Active Directory difficile ? Pas du tout ! Vous pouvez exécuter presque toutes vos tâches de gestion à distance en exécutant les utilitaires sur votre poste de travail et en vous connectant au contrôleur de domaine sur le réseau. Je pense que la grande majorité des contrôleurs de domaine sera exécutée sur les installations Server Core.

Modifications DCPROMO

La première modification que vous remarquerez dans Services de domaine Active Directory est le nouveau DCPROMO. Il fonctionne comme DCPROMO dans Windows Server 2003 mais il a été complètement réécrit pour une utilisation simplifiée. Par exemple, vous n'avez pas besoin d'entrer vos informations d'identification d'administrateur de domaine. DCPROMO peut utiliser les informations d'identification de votre connexion actuelle pour promouvoir le serveur. Vous n'avez pas non plus à entrer DCPROMO /ADV pour obtenir les options DCPROMO en mode Avancé. Il existe désormais une case à cocher dans la première boîte de dialogue DCPROMO pour activer ces options. Le mode Avancé vous permet également de sélectionner le contrôleur de domaine existant à partir duquel vous pouvez effectuer des réplications. Ceci signifie que vous pouvez garder la charge de réplication de DCPROMO à l'extérieur de vos contrôleurs de domaine de production.

Lorsque vous promouvez un contrôle de domaine dans un nouveau domaine ou une nouvelle forêt, DCPROMO vous offre la possibilité de définir le niveau fonctionnel de la forêt et du domaine, au lieu de devoir le faire ultérieurement. Vous pouvez également spécifier le site Active Directory sur lequel vous souhaitez placer le contrôleur de domaine lors du processus de promotion, ce qui s'avère très utile dans un scénario DCPROMO inattendu. DCPROMO suggérera même le site idéal pour le contrôleur de domaine en fonction de l'adresse IP du contrôleur de domaine.

Le nouveau DCPROMO recueille également toutes les options de configuration dans une page seule, fournissant un emplacement où vous choisissez si le nouveau contrôleur de domaine sera un catalogue global (GC), un serveur DNS ou un contrôleur de domaine en lecture seule. Vous n'avez pas besoin d'atteindre un emplacement obscur dans le composant logiciel enfichable Sites et services d'Active Directory pour marquer le contrôleur de domaine en tant que catalogue global.

Mais peut-être la fonctionnalité la plus agréable dans le nouveau DCPROMO est la capacité à enregistrer tous les paramètres DCPROMO dans un fichier de réponse avant le démarrage du processus de promotion. Cette opération est beaucoup plus simple (et moins sujette aux erreurs) que de bricoler un fichier de réponse manuellement. Vous pouvez ensuite utiliser le fichier de réponse pour exécuter les DCPROMO indépendants sur les autres serveurs. Et pour les mordus de scripts, toutes les options DCPROMO sont désormais accessibles à partir de la ligne de commande.

Contrôleurs de domaine en lecture seule

Au tout début d'Active Directory, les entreprises déployaient souvent des contrôleurs de domaine sur tous les sites où les utilisateurs pouvaient se connecter. Par exemple, pour les banques, en plaçant un contrôleur de domaine dans chaque succursale. La logique voulait que les utilisateurs au sein de la succursale puissent se connecter et accéder aux ressources réseaux locales même si le réseau WAN était en panne.

À l'époque, personne ne comprenait vraiment la nécessité de sécurité physique des contrôleurs de domaine. Dans ma tête, les contrôleurs de domaine étaient cachés sous les bureaux et facilement accessibles par le personnel. Ce n'est que quelques années plus tard que les architectes d'Active Directory ont compris le risque que présentait un contrôleur de domaine non sécurisé. Les organisations informatiques ont commencé à consolider leurs contrôleurs de domaine dans des centres de données plus centralisés. Les utilisateurs des succursales devaient alors s'authentifier sur le réseau WAN, procédure pénible mais très utile pour accroître la sécurité.

Active Directory dans Windows Server 2008 modifie l'équation par rapport aux déploiements de succursales en introduisant des contrôleurs de domaine de lecture seule ou RODC. Ceux-ci représentent la plus grande modification des services de domaine Windows Server 2008.

L'équipe d'Active Directory s'est penchée sur les exigences du scénario des succursales lors de la conception de RODC et a adopté le slogan « ce qui se passe dans la succursale reste dans la succursale. » En d'autres termes, si vous déployez un contrôleur de domaine dans une succursale non sécurisée physiquement, vous ne pouvez pas empêcher le contrôleur de domaine (et les ordinateurs qui font confiance à ce contrôleur de domaine) d'être vulnérable, mais vous pouvez empêcher que ce problème se propage de la succursale au reste du domaine.

Remarque : bien que les RODC constituent une importante modification à l'infrastructure ADDS, ils sont relativement faciles à implémenter. Votre domaine doit être au niveau fonctionnel de la forêt Windows Server 2003. De plus, le domaine doit contenir au moins un contrôleur de domaine Windows Server 2008. Au-delà d'une simple solution pour les succursales, les RODC sont une évidence dans les environnements Internet et les situations où le contrôleur de domaine est placé dans le périmètre du réseau.

Le contrôleur de domaine est parti sans laisser d'adresse

Il existe plusieurs classes de menaces à prendre en considération dans une succursale. La première est le scénario de « contrôleur de domaine volé », où quelqu'un s'en va avec le contrôleur de domaine ou le disque du contrôleur de domaine. Au-delà de l'interruption locale de service, le risque est réel et l'attaquant pourrait accéder à tous les noms d'utilisateur et les mots de passe dans le domaine. Puis, il pourrait élever ses privilèges pour accéder aux ressources protégées ou entraîner un déni de service. Pour se protéger de cette menace, les RODC, par défaut, ne stockent pas les hachages de mot de passe dans l'arborescence d'information d'annuaire (DIT) du RODC. Par conséquent, pour authentifier un utilisateur au domaine, lorsqu'un utilisateur s'authentifie d'abord à un RODC, le RODC envoie la requête à un contrôleur de domaine complet (FDC) dans le domaine. Le FDC traite la requête et, si elle aboutit, le RODC émet une requête de réplication pour le hachage de mot de passe.

Un RODC compromis pourrait demander des hachages de mot de passe pour les comptes sensibles. Pour empêcher ceci, l'administrateur de domaine peut configurer une stratégie de réplication de mot de passe pour chaque RODC. La stratégie de réplication de mot de passe est composée de deux attributs sur l'objet Ordinateur du RODC. L'attribut msDS-RevealOnDemandGroup contient les noms distingués de groupes, d'utilisateurs ou de comptes d'ordinateur dont les mots de passe peuvent être mis en cache sur le RODC (il s'agit généralement des utilisateurs et des ordinateurs dans le même site que le RODC). ms-NeverRevealGroup contient les noms distingués de groupes, d'utilisateurs ou de comptes d'ordinateur dont les mots de passe peuvent ne pas être mis en cache sur le RODC (par exemple, le compte administrateur de domaine ne devrait jamais avoir ses mots de passe hachés mis en cache sur un RODC). Lorsque le RODC demande le hachage de mot de passe pour un compte particulier, le FDC évalue la requête par rapport à la stratégie de réplication de mot de passe pour déterminer si le hachage de mot de passe devrait être répliqué sur le RODC. Lorsqu'un contrôleur de domaine est volé, la vulnérabilité est limitée aux mots de passe qui ont été mis en cache sur le RODC volé au moment où il a été supprimé du réseau. De plus, la possibilité d'un mot de passe critique étant compromis est supprimée.

L'objet Ordinateur RODC contient deux autres attributs pour vous aider à déterminer exactement les comptes qui devraient avoir leurs mots de passe mis en cache. L'attribut msDS-AuthenticatedAtDC répertorie les comptes qui ont été authentifiés au RODC et l'attribut msDS-RevealedList nomme les comptes dont les mots de passe sont actuellement stockés par le RODC.

Les hachages de mots de passe utilisateur et informatique ne sont pas les seuls secrets enregistrés sur un contrôleur de domaine. Le compte KrbTGT contient les clés pour le service de Centre de distribution de clés Kerberos (KDC) s'exécutant sur chaque contrôleur de domaine. Dans un scénario typique, chaque KDC dans le domaine partage le même compte KrbTGT et il est possible qu'un attaquant puisse récupérer ces clés d'un contrôleur de domaine volé et les utilise pour attaquer le reste du domaine. Cependant, chaque RODC dispose de son propre compte et ses propres clés KrbTGT, ce qui élimine cette éventualité.

Il n'est également pas inhabituel pour les applications de stocker les mots de passe ou autres secrets dans la DIT. Si un attaquant venait à voler un contrôleur de domaine, il pourrait probablement voler les mots de passe de ces applications et les utiliser pour accéder aux applications. Pour atténuer ce risque, les services de domaine de Windows Server 2008 permettent aux administrateurs de définir le jeu d'attributs filtré pour contrôleur de domaine en lecture seule (RO-FAS). Les attributs qui font partie du RO-FAS ne sont jamais répliqués dans le RODC, et par conséquent, ne peuvent pas être récupérés depuis un contrôleur de domaine compromis. Attribuez des attributs aux RO-FAS en définissant le bit 9 (0x0200) de l'attribut d'indicateurs de recherche de l'objet attributeSchema correspondant dans le schéma.

Les pirates sont déjà là !

Autre classe de menace pour les contrôleurs de domaine de succursale : cas d'un administrateur de serveur local élevant son privilège en mettant à niveau les privilèges du contrôleur de domaine pour accéder aux autres ressources de domaine ou pour organiser une attaque de déni de service. Là encore, si l'administrateur local dispose de l'accès physique au contrôleur de domaine, rien ne peut être fait pour empêcher le compromis. Mais il est possible d'empêcher l'attaquant d'utiliser le contrôleur de domaine de la succursale pour compromettre les autres contrôleurs de domaine dans le domaine.

Les contrôleurs de domaine complets dans le domaine ne font pas confiance aux RODC en tant que contrôleurs de domaine. Du point de vue de la confiance, les FDC traitent les RODC comme des serveurs membres dans le domaine. Un RODC n'est pas membre des groupes des contrôleurs de domaine d'entreprise ou des contrôleurs de domaine. Le compte RODC dispose d'une capacité très limitée pour mettre à jour quoi que ce soit dans le répertoire. Par conséquent, même si un attaquant compromet le compte RODC, il n'obtiendra quasiment aucun privilège utile.

RODC ne s'affiche même pas dans la topologie de réplication de service d'annuaire normale. Étant donné que RODC ressemble à des serveurs membres normaux au lieu de contrôleurs de domaine, le Vérificateur de cohérence des données (qui correspond au processus sur chaque contrôleur de domaine responsable du calcul de la topologie de réplication de service d'annuaire) ne générera pas d'objet de connexion à partir de RODC. Aucun contrôleur de domaine complet ou RODC n'essaiera de répliquer à partir d'un RODC. D'autre part, le RODC créera un objet de connexion représentant un accord de réplication entrant à partir d'un contrôleur de domaine complet, mais cet objet de connexion existe uniquement dans le réplica de RODC ; aucun autre contrôleur de domaine ne dispose d'une copie de cet objet de connexion. Du point de vue de la réplication, RODC fonctionne comme un parasite pour les objets de répertoire. Les objets se répliquent à l'intérieur mais pas à l'extérieur.

Séparation des rôles administratifs sur RODC

Il est très courant pour un contrôleur de domaine de succursale d'être géré par un administrateur du serveur local qui effectue tout, de l'exécution de sauvegardes sur le contrôleur de domaine au nettoyage des claviers. Mais accorder à un administrateur du site à distance les droits nécessaires pour effectuer la maintenance générale sur un contrôleur de domaine constitue un risque en matière de sécurité. Et l'administration de site peut potentiellement élever ses privilèges dans le domaine. RODC fournit deux genres de séparation des rôles administratifs pour limiter cette menace.

Avec le premier formulaire de séparation des rôles, l'administrateur de domaine peut promouvoir le RODC normalement avec DCPROMO ou il peut utiliser un processus en deux étapes. Dans ce cas, le véritable processus de promotion est délégué de manière sécurisée à l'administrateur du site de succursale, sans accorder de droits d'administrateur du domaine. L'administrateur de domaine crée au préalable le compte d'ordinateur RODC dans le domaine avec le composant logiciel enfichable MMC Active Directory Utilisateurs et ordinateurs, comme indiqué à la figure 5.

Figure 5** Création au préalable du compte d'ordinateur RODC **(Cliquer sur l'image pour l'agrandir)

La sélection de l'option « Créer au préalable un compte de contrôleur de domaine en lecture seule » exécute une version abrégée du DCPROMO qui exécute toutes les tâches nécessitant un accès administratif au domaine, y compris la création du compte d'ordinateur, l'attribution du RODC à un site, la spécification de rôles de contrôleur de domaine, la spécification de la stratégie de réplication de mot de passe et la définition de l'utilisateur ou du groupe qui devra terminer l'opération DCPROMO sur le RODC. L'administrateur ou le groupe délégué est enregistré dans l'attribut managedBy de l'objet Ordinateur RODC.

L'administrateur délégué peut ensuite exécuter DCPROMO sur le serveur lui-même. DCPROMO détectera le compte créé au préalable et transformera le serveur en RODC. Exécuter DCPROMO de cette manière ne nécessite pas d'informations d'identification d'administrateur de domaine.

La deuxième manière dont RODC fournit la séparation des rôles administratifs est en créant des rôles administratifs locaux sur le RODC lui-même. Ces rôles ressemblent à des groupes locaux. Ils sont enregistrés dans le registre du RODC et ils peuvent être évalués uniquement sur le RODC. Mais au lieu d'utiliser le composant logiciel enfichable de la console MMC pour les gérer, l'administrateur gère les rôles RODC locaux avec NTDSUTIL. La figure 6 répertorie les rôles administratifs locaux sur un RODC. Ces rôles correspondent exactement aux groupes intégrés à Windows.

Figure 6 Rôles administratifs RODC locaux

Opérateurs de compte

Administrateurs

Opérateurs de sauvegarde

Accès DCOM au service de certification

Opérateurs cryptographiques

Utilisateurs COM distribués

Lecteurs de journaux d'événements

Invités

IIS_IUSRS

Générateurs d'approbations de forêt entrante

Opérateurs de Configuration réseau

Utilisateurs du journal de performances

Utilisateurs de l'analyseur de performances

Accès Compatible antérieur à Windows 2000

Opérateurs d’impression

Utilisateurs du Bureau à distance

Duplicateur

Opérateurs de serveur

Serveurs de licences de serveur Terminal Server

Utilisateurs

Groupe d'accès d'autorisation Windows

Singularités RODC

Étant donné que les RODC sont en lecture seule et qu'aucun autre contrôleur de domaine ne peut effectuer de réplications à partir de ces derniers, les RODC peuvent se comporter de manière imprévisible. Par exemple, les objets sans but (c'est-à-dire les objets qui ont été supprimés partout sauf sur un contrôleur de domaine particulier parce que le contrôleur de domaine était incapable de continuer la réplication plus longtemps que la durée de vie de désactivation de la forêt) sont normalement détectés par les partenaires de réplication sortants du contrôleur de domaine. Mais étant donné que les RODC ne disposent pas de partenaires de réplication entrants, il n'existe pas de détection d'objets sans but pour ces derniers.

Les RODC n'entretiendront pas les opérations de mise à jour LDAP (ajout, modification, suppression, renommage ou déplacement). À la place, les RODC renvoient une erreur avec une référence LDAP à un contrôleur de domaine inscriptible qui peut entretenir l'opération. Si l'application ayant émis la mise à jour LDAP ne traite pas correctement l'opération de référence, l'application pourrait échouer.

Enfin, si un utilisateur d'un autre domaine dans la forêt tente de s'authentifier à un RODC, le RODC doit pouvoir accéder à un contrôleur de domaine complet dans son propre domaine afin d'obtenir le mot de passe de confiance pour transmettre correctement la requête d'authentification au contrôleur de domaine dans le domaine de l'utilisateur. Si la connexion réseau entre le RODC et le contrôleur de domaine complet dans son domaine est indisponible, l'authentification échouera.

Stratégies de mots de passe affinées

La possibilité de définir plus d'une stratégie de mot de passe dans le domaine était probablement la fonctionnalité la plus demandée pour Windows Server 2008 ADDS. Comme vous le savez probablement, dans Windows 2000 et Windows Server 2003 Active Directory, chaque domaine prend en charge une seule stratégie de mot de passe qui est appliquée à toutes les entités de sécurité dans le domaine. Si vous avez besoin d'une stratégie de mot de passe séparée pour un groupe d'utilisateurs spécifique, vous devez créer un domaine séparé. Il existe désormais une nouvelle fonctionnalité dans Windows Server 2008 ADDS, celle de stratégies de mot de passe affinées, qui vous permettent de définir plusieurs stratégies de mot de passe dans un domaine.

La nouvelle stratégie utilise des groupes pour appliquer des stratégies de mot de passe affinées aux utilisateurs. Vous devez d'abord définir une stratégie de mot de passe affinée en créant un nouvel objet msDS-PasswordSettings dans le conteneur CN=Password Settings Container, CN=System, DC=<domain>. L'objet msDS-PasswordSettings (ou PSO) contient des attributs qui correspondent au paramètre de la stratégie de mot de passe dans la Stratégie de groupe (voir la figure 7).

Figure 7 Attributs dans l'objet mSDS-PasswordSettings

Attribut	Description
mSDS-PasswordReversibleEncryptionEnabled	Booléen indiquant si les mots de passe sont chiffrés à l'aide du chiffrement réversible.
mSDS-PasswordHistoryLength	Nombre d'entrées maintenues dans l'historique des mots de passe.
mSDS-PasswordComplexityEnabled	Booléen indiquant si les restrictions de complexité des mots de passe sont activées.
mSDS-MinimumPasswordLength	Entier définissant la longueur minimale du mot de passe.
mSDS-MinimumPasswordAge	INTEGER8 indiquant la durée de vie minimale du mot de passe avant sa possible modification.
mSDS-MaximumPasswordAge	INTEGER8 indiquant la durée de vie maximale du mot de passe avant sa possible modification.
mSDS-LockoutThreshold	Entier indiquant le nombre d'échecs de connexion avant verrouillage.
mSDS-LockoutObservationWindow	INTEGER8 indiquant que le nombre de nanosecondes durant lequel des connexions ratées consécutives doivent se produire pour déclencher le verrouillage.
mSDS-LockoutDuration	INTEGER8 indiquant que le nombre de nanosecondes durant lequel le compte est verrouillé.

Vous devez ensuite attribuer la stratégie de mot de passe aux utilisateurs ou aux groupes en ajoutant les noms d'utilisateur ou de groupe à l'attribut mDS-PSOAppliesTo du PSO ayant plusieurs valeurs. Après avoir accepté l'idée que vous n'appliquez pas les stratégies de mot de passe aux unités organisationnelles, c'est assez simple. Il existe néanmoins une complexité supplémentaire.

Les utilisateurs sont généralement des membres de plusieurs groupes. Que se passe-t-il s'il existe plusieurs stratégies de mot de passe conflictuelles associées à un utilisateur en raison d'une appartenance à plusieurs groupes ? Dans ce cas, ADDS utilise une évaluation de priorité pour déterminer la stratégie de mot de passe à appliquer. Voilà comment ça fonctionne :

1. Si une stratégie de mot de passe est directement liée à un objet utilisateur (et non via l'appartenance de groupe), cette stratégie de mot de passe sera appliquée.
2. S'il existe plusieurs stratégies de mot de passe liées directement à l'utilisateur, la stratégie avec la valeur de priorité la plus basse (déterminée par la valeur de l'attribut msDS-PasswordSettingsPrecendence du PSO) sera appliquée.
3. S'il existe plusieurs objets PSO avec la même priorité, la stratégie avec la valeur objectGUID la plus basse sera appliquée.
4. Si aucun objet PSO n'est directement lié à l'utilisateur, ADDS évaluera l'objet PSO lié aux groupes de l'utilisateur. S'il existe plus d'un objet PSO, l'objet PSO avec la valeur la plus basse dans l'attribut msDS-PasswordSettingsPrecedence sera appliquée.
5. S'il existe plus d'un objet PSO avec la même valeur de priorité, la stratégie avec la valeur objectGUID la plus basse sera appliquée.
6. Si aucun objet PSO n'est associé à l'utilisateur, la stratégie de mot de passe de domaine sera utilisée.

Les objets utilisateur ont un nouvel attribut msDS-ResultantPSO permettant de savoir quel objet PSO s'applique à un utilisateur. Cet attribut contient le nom unique de l'objet PSO qui régit le mot de passe de cet utilisateur.

Les stratégies de mot de passe affinées vous fournissent une flexibilité accrue. Cependant, vous devez gérer ces stratégies avec attention et les garder simples. Il n'existe pas d'utilitaire complet pour définir les stratégies de mot de passe affinées. Vous devez utiliser ADSIEdit ou trouver un utilitaire tiers.

Service Active Directory redémarrable

À chaque fois que vous arrêtez un contrôleur de domaine pour la maintenance DIT, cela entraîne des interruptions dans vos niveaux de service réseau. Les contrôleurs de domaine Windows Server 2008 disposent d'une nouvelle fonctionnalité qui vous permet d'arrêter le service d'annuaire sans arrêter complètement le contrôleur de domaine.

La commande NET STOP NTDS arrête ADDS sur un contrôleur de domaine Windows Server 2008. Lorsque vous faites cela, le processus d'autorité de sécurité locale (LSASS) sur le contrôleur de domaine continue à s'exécuter mais il décharge toutes les DLL associées à ADDS et le service d'annuaire devient indisponible. LSASS se comporte ensuite comme il le ferait sur un serveur membre en transférant les requêtes d'authentification de domaine à un contrôleur de domaine. Étant donné que les DLL qui traitent ADDS sont déchargées, vous pouvez appliquer des correctifs associés à ADDS ou exécuter une défragmentation autonome de la DIT. Démarrer ADDS est aussi simple que NET START NTDS. Cependant, restaurer la DIT à partir d'une sauvegarde d'état du système nécessite toujours le redémarrage en mode de restauration de service d'annuaire.

Vous devez comprendre que le service d'annuaire n'est pas un service Windows réel. Il est toujours un composant intégral de LSASS et vous ne pouvez pas arrêter LSASS sans arrêter l'ordinateur. Mais la possibilité de démarrer et d'arrêter le service d'annuaire dans Windows Server 2008 est une solution pratique.

Sauvegarde et restauration

Le mécanisme de sauvegarde et de restauration a été revisité dans Windows Server 2008. Je ne vais pas entrer dans les détails ici mais la nouvelle sauvegarde Windows Server contient certaines modifications qui concernent ADDS.

La Sauvegarde Windows Server est une solution de sauvegarde basée sur le volume, ce qui signifie qu'elle sauvegarde tous les volumes de disque. Elle sauvegarde également uniquement sur des périphériques disque (ou semblables à des disques). Une prise en charge de bande n'est pas nécessaire.

Il existe une option de sauvegarde d'état du système pour l'utilitaire de sauvegarde de ligne de commande WBADMIN. À l'aide de la commande WBADMIN START SYSTEMSTATEBACKUP, vous pouvez désormais créer une image de sauvegarde qui contient tous les fichiers système critique nécessaires pour restaurer Active Directory sur un contrôleur de domaine. Cependant, il peut y avoir jusqu'à cinq volumes dans le jeu de sauvegarde, mais les volumes dans le jeu de sauvegarde contiendront uniquement les fichiers nécessaires pour une restauration d'état du système. Encore plus gênant et comme pour la version RC0 de Windows Server 2008, vous ne pouvez pas exécuter de sauvegarde d'état du système sur un partage réseau. Vous devez disposer d'un volume de disque local disponible pour stocker les images de sauvegarde d'état du système et ce volume ne doit pas faire partie de l'ensemble du volume de sauvegarde d'état du système. Vous devrez peut-être ajouter un nouveau volume de disque à tous les contrôleurs de domaine sur lesquels vous exécutez les sauvegardes d'état du système.

L'exécution d'une restauration d'état du système est simple. Il vous suffit de démarrer le contrôleur de domaine en mode restauration des services d’annuaire et d'exécuter la commande WBADMIN START SYSTEMSTATERECOVERY. Le résultat est une DIT restaurée ne faisant pas autorité, sur laquelle vous pouvez restaurer des objets spécifiques faisant autorité à l'aide de NTDSUTIL, comme vous le faisiez dans Windows Server 2003.

Un aspect de la Sauvegarde Windows Server mérite une mention spéciale : les images de sauvegarde sont stockées au format VHD (Virtual Hard Disk, disque dur virtuel). Ce format est le même que celui utilisé par Microsoft Virtual Server 2005 pour stocker ses images de disque virtuel. Ceci signifie que vous pouvez prendre une image de sauvegarde créée avec la Sauvegarde Windows Server et la monter en tant que lecteur de disque dans une machine virtuelle qui s'exécute sur Microsoft Virtual Server. Vous pouvez ensuite parcourir les contenus de sauvegarde comme s'il s'agissait un lecteur de disque normal !

Une autre modification concernant la sauvegarde ADDS est la possibilité d'utiliser le service de cliché instantané de volume pour créer des instantanés d'Active Directory. Lorsque vous créez un instantané avec NTDSUTIL, le service de cliché instantané de volume enregistre l'image précédente de chaque bloc de disque de la DIT avant sa mise à jour. En associant les images enregistrées précédemment avec la version actuelle de la DIT, le service de cliché instantané de volume peut construire un instantané complet de la DIT avec une surcharge minime. Créer un instantané typique ne prend qu'une poignée de secondes, et ce, quelle que soit la taille de la DIT.

Cette possibilité est, en elle-même, intéressante mais pas réellement utile. Cependant, dans Windows Server 2008, ADDS comprend un utilitaire de ligne de commande appelé DSAMAIN qui monte l'instantané en mode de lecture seule. Ceci fournit un serveur LDAP autonome, qui ressemble à l'instance ADLDS contenant les contenus de votre répertoire au moment de la capture de l'instantané. Vous pouvez parcourir le répertoire avec l'utilitaire LDP ou les autres outils LDAP et récupérer les versions des objets répertoire à un moment antérieur.

Réplication SYSVOL avec DFS-R

Windows Server 2003 R2 contient un service de fichiers distribués (DFS, Distributed File Service) qui contient désormais un tout nouveau mécanisme de réplication de fichier appelé DFS-R. Il utilise la compression différentielle à distance, qui réduit considérablement le trafic de réplication de fichier en déterminant les blocs d'un fichier cible qui doivent être répliqués pour être synchronisés avec le fichier source. Cependant, Windows Server 2003 R2 utilise toujours le service de réplication de fichiers (et pas DFS-R) pour répliquer SYSVOL entre les contrôleurs de domaine. Pour cette raison, la réplication SYSVOL est encore et toujours une source de problèmes pour les administrateurs d'Active Directory.

Lorsqu'il s'exécute au niveau fonctionnel du domaine Windows Server 2008, Windows Server 2008 peut répliquer SYSVOL avec DFS-R, améliorant la vitesse et la robustesse de réplication SYSVOL. Et ainsi, lui permet de placer des fichiers volumineux dans SYSVOL pour les mettre à disposition sur tous les contrôleurs de domaine. Pour utiliser DFS-R pour SYSVOL, vous devez d'abord migrer les anciennes données de SYSVOL vers DFS-R avec l'utilitaire DFSRMIG. Ce processus se déroule en quatre étapes :

• Création des objets Active Directory requis par DFS-R.
• Création de la nouvelle structure de fichiers pour SYSVOL sur chaque contrôleur de domaine.
• Transfert de tous les contrôleurs de domaine pour qu'ils utilisent le nouveau SYSVOL.
• Suppression de l'ancien SYSVOL.

En fonction de la taille de votre SYSVOL et du nombre de contrôleurs de domaine dont vous disposez, ce processus peut prendre un certain temps. Cependant, les performances et la fiabilité améliorées que vous en tirerez valent la peine d'effectuer cette opération.

Améliorations d'audit

Le système d'audit dans Active Directory pour Windows Server 2003 est à la fois une bénédiction et une malédiction. D'une part, il fournit une solution assez complète, flexible et sécurisée pour suivre les modifications dans le répertoire. Mais certains diront qu'il contient de sérieux problèmes d'utilisabilité.

L'activation de l'audit de modifications du répertoire sur un contrôleur de domaine Windows Server 2003 n'est pas une mince affaire. C'est tout ou rien ! Et le volume de trafic d'audit sur un contrôleur de domaine d'entreprise occupé peut rendre l'audit inefficace. La configuration du système d'audit pour produire les messages dont vous avez vraiment besoin nécessite de bricoler les descripteurs de sécurité individuels. C'est ennuyeux et enclin aux erreurs. Quant aux messages d'audit, ils sont souvent énigmatiques, et dans la plupart des cas, ne contiennent pas les informations dont vous avez besoin, telles que les valeurs avant et après des attributs modifiés. Et la collecte, la correspondance et l'archivage des messages de plusieurs contrôleurs de domaine ne sont pas réellement réalisables avec les outils Windows natifs.

Le système d'audit du service d'annuaire dans Windows Server 2008 résout quelques-uns de ces problèmes. Tout d'abord, il existe quatre nouvelles sous-catégories d'audit pour l'audit du service d'annuaire : Accès DS, Modifications DS, Réplication de service d'annuaire et Réplication de service d'annuaire détaillée. Si vous souhaitez simplement auditer les modifications d'annuaire, vous n'avez pas à passer en revue tous les événements de réplication et de lecture. Mais, si vous souhaitez inclure les suppressions d'objet dans votre journal d'audit, vous devez activer Accès DS. Ceci génère des messages pour tous les accès d'objets DS, générant beaucoup trop de messages. Et vous devez toujours configurer les descripteurs de sécurité pour générer les messages d'audit que vous souhaitez pour les objets dont vous vous occupez.

Les messages d'audit ont été considérablement nettoyés pour être lisibles et contiennent les données dont vous avez besoin. En particulier, les modifications de l'annuaire génèrent des entrées du journal d'audit qui contiennent les anciennes et nouvelles valeurs d'attributs modifiés. Il s'agit d'une amélioration énorme. Seul inconvénient : les anciennes et nouvelles valeurs s'affichent dans des entrées du journal d'audit séparées. Par conséquent, vous devez les faire correspondre pour comprendre la modification qui a été effectuée. De nombreux produits de collecte de journaux d'audit modules complémentaires, y compris les Services ACS de Microsoft, prennent en charge ce genre de corrélation.

Améliorations de l'interface utilisateur

Les composants logiciel enfichables MMC pour Active Directory (par exemple, Utilisateurs et ordinateurs, Domaines et approbations et Sites et services) ont toujours été appropriés à la gestion d'Active Directory. Dans Windows Server 2008, les outils administratifs fondamentaux ont été nettoyés et nous avons introduit deux nouvelles fonctionnalités agréables. Si vous activez Fonctionnalités avancées, la boîte de dialogue Propriétés pour chaque objet affiche un onglet supplémentaire appelé Éditeur d'attributs. Il s'agit du même onglet d'éditeur d'attribut utilisé par ADSIEdit, qui vous permet d'inspecter et de modifier tous les attributs de l'objet. L'onglet lui-même offre désormais un meilleur décodage des attributs codés, tels que l'attribut userAccountControl. La figure 8 affiche la manière dont l'éditeur d'attributs est intégré.

Figure 8** Éditeur d'attributs dans Utilisateurs et ordinateurs d'Active Directory **(Cliquer sur l'image pour l'agrandir)

Conclusion

Mis à part les points clés que j'ai abordés dans cet article, vous trouverez d'autres améliorations dans ADDS dans Windows Server 2008. Par exemple, KDC utilise AES (Advanced Encryption Standard) 256 bits (AES-256) si le domaine se trouve au niveau fonctionnel du domaine Windows Server 2008. Vous pouvez activer la prévention de suppression accidentelle des objets en cochant la case appropriée sur l'onglet Objet pour tout objet DS. Le moteur ESE (Extensible Storage Engine) qui fournit le service de gestion des données a été amélioré pour utiliser la correction d'erreur de bit unique, réduisant la probabilité de corruption de la DIT due à une erreur matérielle ou logicielle dans le sous-système de disque. Le service DNS démarre les requêtes de traitement avant d'avoir complètement chargé la base de données DNS. Le module du localisateur de contrôleurs de domaine a été amélioré. Ainsi, s'il ne trouve pas un contrôleur de domaine dans le site souhaité, il tente de localiser un contrôleur de domaine dans le site suivant le plus proche au lieu de simplement utiliser n'importe quel contrôleur de domaine dans le domaine. Et NTDSUTIL prend désormais en charge les instantanés RODC et le service de cliché instantané de volume.

Il est clair que Windows Server 2008 fournit un nombre important d'améliorations dans les Services de domaine Active Directory. Toutes ensemble, ces modifications améliorent de manière significative la sécurité et la gérabilité d'ADDS. Cependant, l'amélioration la plus significative est sans aucun doute l'intégration de Windows Server 2008 dans votre environnement Active Directory, ce qui n'implique pas une migration importante. C'est un processus facile et incrémentiel.

Gil Kirkpatrick est directeur technique chez NetPro et développe des logiciels pour Active Directory depuis 1996. Avec Guido Grillenmeier, qui travaille chez HP, il anime des ateliers consacrés à la récupération après incident Active Directory, qui connaissent un grand succès. Gil est également le fondateur de Directory Experts Conference (www.dec2008.com).

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.