L'avenir de WindowsLes services d'annuaire dans le serveur Windows « Longhorn »
Byron Hynes
Cet article est basé sur une version préliminaire de Windows Server, dont le nom de code est « Longhorn ». Toutes les informations contenues dans le présent document peuvent faire l'objet de modifications.
De nombreuses améliorations apportées à Active Directory seront fournies avec la nouvelle version de Windows Server, dont le nom de code est « Longhorn ». Certaines des modifications sont importantes et ouvrent de nouvelles portes passionnantes pour une meilleure gestion et une meilleure efficacité. L'une des modifications les plus évidentes dans Active Directory concerne le nom des fonctions. Tout ce qui traite de la gestion de l'identité est désormais regroupé sous la bannière Directory®. Ce que l'on considérait auparavant comme Active Directory dans Microsoft® Windows Server® 2003 s'appelle maintenant Active Directory Domain Services (ADDS), et il existe de nombreux services supplémentaires, notamment Active Directory Federation Services (ADFS), Active Directory Lightweight Directory Services (ADLDS, auparavant Active Directory/Application Mode ou ADAM), Active Directory Certificate Services (ADCS) et Active Directory Rights Management Services (ADRMS).
Tous ces services représentent un rôle serveur, concept nouveau dans Windows Server « Longhorn ». Vous pouvez choisir d'avoir un ordinateur dédié à un ou plusieurs rôles serveur et administrer des rôles serveur à l'aide de Server Manager, comme indiqué dans la figure 1. À partir de là, vous pouvez ajouter des rôles, trouver de l'aide et effectuer d'autres tâches administratives nécessaires.
Figure 1** Server Manager **(Cliquer sur l'image pour l'agrandir)
Comme vous pouvez le voir, la nouvelle approche organise des fonctions quotidiennes dans des groupes logiques accessibles dans Server Manager.
Niveaux fonctionnels
Windows Server « Longhorn » introduit un niveau fonctionnel pour les forêts et les domaines. Le niveau fonctionnel de forêt Windows Server « Longhorn » (qui sera renommé à sa sortie) n'ajoute pas de fonctions à proprement parler, mais veille à ce que tous les domaines de la forêt soient au niveau fonctionnel de domaine Windows Server « Longhorn », qui permet deux nouvelles améliorations. La première est l'utilisation du nouveau moteur de réplication de système de fichiers distribués (DFS) pour partage SYSVOL, plus robuste, plus granulaire et plus efficace. La deuxième est l'ajout de la prise en charge du cryptage AES (Advanced Encryption Standard) 256 bits pour le protocole d'authentification Kerberos. L'utilisation de ce dernier niveau fonctionnel offrira les meilleures performances, mais vous pouvez continuer à fonctionner à des niveaux fonctionnels inférieurs en migrant vers Windows Server « Longhorn ».
Plusieurs extensions de schéma permettant la prise en charge de nombreuses fonctions ont également été introduites, toutes compatibles avec les schémas existants en usage aujourd'hui. Les contrôleurs de domaine exécutant Windows Server « Longhorn » peuvent coexister en harmonie et interagir avec ceux exécutant Windows Server 2003.
Support pour Server Core
Active Directory Domain Services est l'un des rôles de serveur qui fonctionnera dans une installation Server Core de Windows Server « Longhorn ». Server Core, qui n'est pas abordé en détail dans cet article, est une option d'installation minimale où seules les fonctionnalités principales du serveur sont conservées. Server Core n'installe pas le shell Windows et n'utilise pas d'interface utilisateur graphique, ce qui évite la surcharge.
Contrôleur de domaine en lecture seule
Sous certains environnements, la fonction la plus importante pour ADDS dans Windows Server « Longhorn » est un contrôleur de domaine en lecture seule (RODC, Read-Only Domain Controller), vous permettant de déployer facilement un contrôleur de domaine hébergeant une réplique en lecture seule de la base de données du domaine. Cela convient pour les emplacements où la sécurité physique du contrôleur de domaine ne peut pas être garantie ou pour les emplacements où d'autres applications doivent s'exécuter sur le contrôleur de domaine et être maintenues par un administrateur du serveur (qui, idéalement, n'est pas un membre du groupe Administrateurs du domaine). Ces deux scénarios sont courants dans les déploiements des succursales.
Un contrôleur de domaine en lecture seule s'installe simplement en cochant une case dans l'assistant d'installation, comme indiqué dans la figure 2.
Figure 2** Installation du contrôleur de domaine en lecture seule **(Cliquer sur l'image pour l'agrandir)
Avant la sortie de Windows Server « Longhorn », si les utilisateurs devaient s'authentifier avec un contrôleur de domaine à un emplacement différent, le trafic devait traverser une liaison réseau étendu (WAN). Les liaisons WAN sont souvent plus lentes et plus onéreuses que les connexions de réseau local et sont parfois plus propices aux interruptions de service. Une solution possible consistait à déployer un contrôleur de domaine sur le site à distance ou sur la succursale. Cependant, cela entraînait d'autres problèmes, notamment le trafic de réplication, et la nécessité de maintenir une sécurité physique sur le contrôleur de domaine de la succursale, sécurité faisant souvent défaut dans les petites succursales et les succursales distantes. Dans d'autres cas, les succursales disposent d'une bande passante insuffisante connectée au site hub, ce qui augmente le temps requis pour se connecter.
À l'exception des mots de passe de compte (sauf configuration contraire), un RODC détient tous les objets et attributs Active Directory Domain Services dont dispose un contrôleur de domaine réinscriptible. Cependant, les modifications générées localement ne peuvent pas être effectuées sur la réplique stockée sur le RODC. À la place, elles sont effectuées sur un contrôleur de domaine réinscriptible et répliquées sur le RODC. Cela empêche toute modification apportée aux succursales de polluer ou corrompre la forêt par réplication, supprimant ainsi une voie d'attaque.
Les applications locales demandant l'accès en lecture aux informations d'annuaire du domaine peuvent obtenir un accès directement à partir du RODC, tandis que les applications du protocole LDAP (Lightweight Directory Access Protocol) demandant l'accès en écriture reçoivent une réponse de référence LDAP. Cette réponse de référence les dirige vers un contrôleur de domaine inscriptible, généralement dans un site hub.
Étant donné qu'aucune modification n'est inscrite directement sur le RODC, aucune modification n'apparaît au niveau du RODC. En conséquence, les contrôleurs de domaine inscriptibles partenaires de réplication n'ont pas besoin d'extraire les modifications depuis le RODC. Cela réduit la charge de travail des serveurs pont dans le hub et l'effort requis pour surveiller la réplication. La réplication RODC unidirectionnelle s'applique à la fois à la réplication ADDS et à la réplication Distributed File System (DFS). Le RODC effectue une réplication entrante normale pour les changements de réplication ADDS et DFS.
Dans la base de données du domaine, chaque entité de sécurité dispose d'un ensemble d'environ 10 mots de passe ou secrets, appelés informations d'identifications. Un RODC ne stocke pas d'informations d'identification d'ordinateur ou d'utilisateur, sauf pour le compte de son propre ordinateur et un compte « krbtgt » spécial (compte utilisé pour l'authentification Kerberos) pour chaque RODC. Le RODC est annoncé comme le centre de distribution de clés (KDC, Key Distribution Center) pour son site (généralement la succursale). Lorsque le RODC signe ou crypte une demande TGT (Ticket Granting Ticket), il utilise un compte et un mot de passe krbtgt différents de celui du KDC sur un contrôleur de domaine inscriptible.
Lors de la première tentative d'authentification d'un compte auprès d'un RODC, celui-ci envoie la requête à un contrôleur de domaine inscriptible sur le site hub. Si l'authentification réussit, le RODC demande également une copie des informations d'identification appropriées. Le contrôleur de domaine inscriptible reconnaît que la demande provient d'un RODC et consulte la stratégie de réplication des mots de passe en vigueur pour ce RODC.
La stratégie de réplication des mots de passe détermine si les informations d'identification sont autorisées pour la réplication et le stockage sur le RODC. Si tel est le cas, un contrôleur de domaine inscriptible envoie les informations au RODC, et le RODC les met en cache, comme indiqué dans la barre latérale « Fonctionnement d'un contrôleur de domaine en lecture seule ».
Une fois les informations d'identification mises en cache sur le RODC, dès qu'un utilisateur tente de se connecter, la demande peut être directement traitée par le RODC jusqu'à ce que les informations d'identification changent. Lorsqu'un TGT (Ticket Granting Ticket) est signé avec le propre compte krbtgt de RODC, celui-ci reconnaît qu'il possède une copie en cache des informations d'identification. Si un autre contrôleur de domaine a signé le TGT, le RODC fera suivre les demandes vers un contrôleur de domaine inscriptible.
En limitant la mise en cache des informations d'identification uniquement aux utilisateurs s'étant authentifiés au RODC, l'exposition potentielle des informations d'identification par un compromis du RODC est également limitée.
Par défaut, aucun mot de passe utilisateur ne sera mis en cache sur un RODC, mais cela n'est pas forcément le scénario le plus efficace. Normalement, seuls quelques utilisateurs de domaine ont besoin des informations d'identification mises en cache sur n'importe quel RODC donné, comparé au nombre total d'utilisateurs sur un domaine. Vous pouvez utiliser la stratégie de réplication des mots de passe pour spécifier les groupes d'utilisateurs pouvant être pris en compte pour la mise en cache. Par exemple, en limitant la mise en cache RODC aux seuls utilisateurs qui se trouvent souvent dans cette succursale, ou en empêchant la mise en cache d'informations d'identification de haute valeur, telles que celles des administrateurs, vous pouvez réduire l'exposition potentielle.
Ainsi, si le RODC est volé ou compromis, seules les informations d'identification mises en cache doivent être réinitialisées et, comme nous le verrons, vous saurez exactement de quels comptes il s'agit, comme le montre la figure 3.
Figure 3** Mise en cache des informations de compte **(Cliquer sur l'image pour l'agrandir)
Séparation du rôle administrateur
Dans de nombreuses succursales, on donne au contrôleur de domaine des rôles ou des tâches serveurs supplémentaires, par exemple rôle de serveurs de fichiers ou de serveur d'impression. Dans d'autres cas, une application métier est installée inutilement sur un contrôleur de domaine. Cela engendre un problème : Pour administrer ces applications et ces serveurs, un employé de la succursale doit disposer d'informations d'identification. Toute personne capable d'administrer un contrôleur de domaine Windows Server 2003 peut administrer le domaine complet.
Sous Windows Server « Longhorn », un administrateur peut être autorisé à gérer uniquement un RODC spécifique, sans qu'il dispose de l'accès qui lui permettrait de gérer d'autres contrôleurs de domaine et sans qu'il soit nécessairement membre du groupe de sécurité Administrateurs du domaine.
Améliorations apportées à l'interface utilisateur et aux outils
Pour prendre en charge les fonctions d'un RODC et pour simplifier la surveillance de la réplication du mot de passe, un nouvel onglet, Stratégie de réplication des mots de passe, s'affiche sur la page des propriétés d'un contrôleur de domaine dans Utilisateurs et ordinateurs Active Directory, comme indiqué sur la figure 4.
Figure 4** L'onglet Stratégie de réplication des mots de passe **(Cliquer sur l'image pour l'agrandir)
En cliquant sur le bouton Avancé de cet onglet, vous pouvez afficher les mots de passe envoyés au RODC. Ces mots de passe y sont stockés authentifiés par rapport au RODC, comme indiqué dans la figure 5. Étant donné que la liste inclut des comptes authentifiés, même s'ils se trouvent hors des groupes autorisés à avoir leur mot de passe répliqué, vous pouvez utiliser ces informations pour décider quels groupes doivent être inclus dans la stratégie de réplication des mots de passe.
Figure 5** Stratégie de réplication des mots de passe avancée **(Cliquer sur l'image pour l'agrandir)
Plusieurs modifications ont été apportées au fameux utilitaire dcpromo, plus formellement connu sous le nom d'Assistant Installation des services Active Directory. Il est possible de lancer cet Assistant comme une application graphique complète grâce à la commande Ajouter des rôles dans la page Tâches de configuration initiales (ICT, Initial Configuration Tasks) qui s'exécute immédiatement après l'installation du système d'exploitation. Sélectionnez Ajouter des rôles, puis ADDS dans Server Manager, ou appelez dcpromo à partir d'une ligne de commande ou de la boîte d'exécution.
Dès que vous utilisez l'Assistant en mode graphique, vous remarquerez une meilleure organisation des éléments et des choix, dans la mesure où les articles associés sont regroupés. Il existe d'autres options. Vous pouvez accéder au mode avancé à partir de l'interface utilisateur sans utiliser le commutateur /adv pour effectuer des tâches telles que la création d'une nouvelle arborescence de domaine, l'installation à partir du support (pour réduire la réplication initiale sur un réseau étendu) ou la sélection du contrôleur de domaine source pour réplication initiale.
Certaines améliorations ont été apportées pour vous faciliter le travail et réduire les erreurs frustrantes. Par exemple, si vous utilisez l'Assistant pour créer un nouveau contrôleur de domaine dans une forêt ou un domaine existant, vous pouvez parcourir les domaines existants au lieu de devoir saisir le nom NetBIOS.
De nouvelles pages ont été ajoutées pour spécifier les options supplémentaires. Vous pouvez ainsi configurer le contrôleur de domaine comme un serveur de catalogue global, un serveur DNS ou un RODC. Dans l'Assistant, vous pouvez également configurer la sélection du site, définir des niveaux fonctionnels, créer une stratégie de réplication des mots de passe pour RODC et configurer la délégation DNS.
Lorsqu'il est utilisé en tant qu'outil de ligne de commande, dcpromo peut être exécuté sans assistance. Contrairement au même outil disponible dans Windows Server 2003, une installation sans assistance ne requiert pas de réponse à une invite d'interface utilisateur, telle qu'un redémarrage de l'ordinateur. Cela facilite l'utilisation de ADDS sur les installations Server Core de Windows Server « Longhorn ».
Audit ADDS
Microsoft ajoute de nombreuses autres fonctionnalités à l'audit des services d'annuaire dans Windows Server « Longhorn ». Sous Windows Server 2003, vous pouviez activer ou désactiver l'audit pour l'accès à l'annuaire, mais même si vous réussissiez à l'activer, la trace d'audit n'incluait pas les informations modifiées. Maintenant, c'est possible.
Sous Windows Server « Longhorn », la stratégie d'audit pour ADDS dispose des quatre sous-catégories suivantes :
- Accès au service d'annuaire
- Modifications du service d'annuaire
- Réplication du service d'annuaire
- Réplication détaillée du service d'annuaire
La plupart des professionnels informatiques doivent garder en mémoire deux éléments essentiels à propos de ces modifications. Tout d'abord, l'audit d'accès au service d'annuaire apporte essentiellement les mêmes informations que sous Windows Server 2003, mais l'ID événement passe de 566 à 4662. Prenez note de ce changement si vous utilisez des outils d'analyse du journal d'événements de sécurité. Ensuite, la nouvelle catégorie Modifications du service d'annuaire enregistre à la fois la valeur précédente et la valeur en cours de l'attribut modifié.
Pour implémenter l'audit dans ADDS, utilisez la stratégie d'audit globale, les listes de contrôle d'accès système (SACL, system access control lists) et le schéma ADDS. Les composants fonctionnent conjointement pour vous donner un environnement d'audit complet et flexible.
La stratégie d'audit globale contrôle si un audit est effectué sur ADDS. Si l'audit est activé, la stratégie globale contrôle laquelle des quatre sous-catégories d'accès (répertoriées ci-dessus) est soumise à un audit. La stratégie d'audit globale est généralement appliquée dans l'objet de stratégie de groupe des contrôleurs de domaine par défaut. Elle s'applique donc au répertoire entier sur le contrôleur de domaine.
Même si les outils de stratégie de groupe peuvent activer ou désactiver la stratégie d'audit globale, vous devez utiliser l'outil de la ligne de commande Auditpol.exe pour afficher ou configurer les sous-catégories. Elles ne sont pas exposées dans l'interface graphique.
Une SACL est une pièce du descripteur de sécurité de l'objet. En spécifiant les entrées dans la SACL, vous fournissez deux éléments au système : les actions et les utilisateurs (ou entités de sécurité) qui vous intéressent. En d'autres termes, vous spécifiez quels utilisateurs tentant d'effectuer quelles actions doivent être enregistrés dans le journal d'événements. Donc si vous souhaitez enregistrer des modifications aux objets utilisateur effectuées par les Administrateurs du domaine et non par les utilisateurs eux-mêmes, vous pouvez contrôler cela grâce aux SACL. Une SACL s'applique à un objet (et peut être définie pour de nouveaux objets et héritée à partir d'objets de conteneur).
Vous pouvez également configurer le schéma ADDS pour limiter l'audit de modification à des attributs particuliers. Étant donné que les SACL sont appliquées à l'objet par défaut, l'accès ou les modifications apportées à un attribut sont enregistrés. Cela pourrait générer une forte activité de journalisation et tous les attributs peuvent ne pas vous concerner. Ainsi, au niveau attribut, vous pouvez définir un indicateur pour empêcher la journalisation des modifications apportées à cet attribut.
SearchFlags est un attribut défini dans la classe définissant les attributs, il s'agit donc d'un attribut d'un attribut. C'est également un bitmask, où chaque bit d'une valeur d'un octet représente un paramètre on/off différent. Pour vous en souvenir plus facilement, vous pouvez l'assimiler à la propriété d'un attribut. Sous Windows Server 2003, sept de ces valeurs sont utilisées pour contrôler plusieurs paramètres, notamment l'indexation et la réplication GC de l'attribut. Sous Windows Server « Longhorn », le huitième bit (dont la valeur est 128) est utilisé pour contrôler si les modifications sont journalisées. Si ce bit est défini, ADDS ne va pas journaliser les événements de modification lors de modifications de cet attribut. Cela s'applique à tous les objets contenant l'attribut. Dans la version Bêta 2, vous ne pouvez pas utiliser l'interface graphique pour définir le huitième bit.
Par défaut, sous Windows Server « Longhorn », la stratégie d'audit globale est activée et la catégorie Modifications de services d'annuaire est définie pour journaliser les modifications réussies.
ADDS redémarrables
Sous Windows Server « Longhorn », ADDS est un service redémarrable. Cela signifie simplement que les services ADDS peuvent être arrêtés et démarrés sans relancer le contrôleur de domaine. Cela permet aux administrateurs d'exécuter des fonctions non réalisables lorsque le service est en cours d'exécution (pendant une défragmentation hors ligne d'une base de données, par exemple) et ce, plus facilement et sans entrer dans le mode de restauration des services d'annuaire.
Un contrôleur de domaine exécutant Windows Server « Longhorn » peut prendre trois états : ADDS démarré, ADDS arrêté et Mode de restauration des services d'annuaire. Examinons chacun de ces états.
ADDS démarré Le contrôleur de domaine fonctionne normalement.
ADDS arrêté Le serveur possède les caractéristiques d'un contrôleur de domaine dans le mode de restauration des services d'annuaire et d'un serveur membre d'un domaine.
Concernant le mode de restauration des services d'annuaire, la base de données ADDS (Ntds.dit) est hors ligne. Le mot de passe du mode de restauration des services d'annuaire peut être utilisé pour se connecter localement si un autre contrôleur de domaine ne peut pas être contacté.
Avec un serveur membre, le serveur rejoint le domaine. Les utilisateurs peuvent se connecter de manière interactive ou via le réseau en utilisant un autre contrôleur de domaine pour la connexion au domaine. Cependant, un contrôleur de domaine ne doit pas conserver cet état pour une période étendue, car il ne peut pas mettre en service les demandes de connexion ou effectuer une réplique avec d'autres contrôleurs de domaine.
Mode de restauration des services d'annuaire Ce mode (ou état) n'a pas été modifié depuis Windows Server 2003.
L’organigramme de la figure 6 montre comment un contrôleur de domaine exécutant Windows Server « Longhorn » peut passer d'un de ces trois états à l'autre.
Figure 6** Un contrôleur de domaine exécutant Windows Server « Longhorn » peut présenter trois états **
Vous souhaitez en savoir davantage ?
Un court article ne suffit pas à expliquer en détail les nouvelles fonctions ADDS dans Windows Server « Longhorn ». Mais comme vous l'avez vu, les nouvelles fonctions Active Directory vont résoudre une série de problèmes que vous deviez contourner ou accepter. Si vous souhaitez en savoir plus, à l'approche de la sortie de la version finale, vous pourrez consulter de la documentation supplémentaire, bientôt disponible au public. En attendant, le meilleur endroit pour rechercher des mises à jour lors de la phase bêta est le site Web Windows Server « Longhorn ».
Byron Hynes travaille pour le groupe d'assistance utilisateur du serveur Windows chez Microsoft. Par le passé, il a travaillé comme consultant et formateur et dispose d'une vaste expérience, notamment à la tête d'une antenne régionale Internet, dans le dépannage des serveurs client et des applications Web et dans la conception de schémas de bases de données, d'infrastructures réseau et de modèles de sécurité. Vous pouvez le contacter à l'adresse bhynes@microsoft.com.
© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.