Vous êtes sur la page 1sur 800

Windows Server 2008 -

MCTS 70-640
Infrastructure Active Directory

Jean-François APRÉA

Résumé
L’examen MCTS 70-640 "Configuration d’une infrastructure Active Directory avec Windows Server 2008" est l’un des
examens obligatoires pour l’obtention de la certification MCITP Administrateur de serveurs ou MCITP Administrateur
informatique en entreprise.
Pour vous aider à préparer efficacement l’examen, ce livre couvre tous les objectifs officiels, tant d’un point de vue
théorique que d’un point de vue pratique. Il a été rédigé en français (il ne s’agit pas d’une traduction) par un formateur
professionnel reconnu, également consultant, certifié techniquement (MCP, MCSE Charter Member, MCSE+I) et
pédagogiquement (MCT) par Microsoft. Ainsi, les savoir-faire pédagogique et technique de l’auteur conduisent à une
approche claire et visuelle, d’un très haut niveau technique.
Chapitre après chapitre, vous pourrez valider vos acquis théoriques, à l’aide d’un grand nombre de questions-réponses
(310 au total) mettant en exergue aussi bien les éléments fondamentaux que les caractéristiques spécifiques aux concepts
abordés.
Chaque chapitre s’achevant par des travaux pratiques (71 au total) vous aurez les moyens de mesurer votre autonomie.
Ces manipulations concrètes, au-delà même des objectifs fixés par l’examen, vous permettront de vous forger une première
expérience significative et d’acquérir de véritables compétences techniques sur des mises en situations réelles.
A cette maîtrise du produit et des concepts, s’ajoute la préparation spécifique à la certification : vous pourrez accéder
gratuitement à 1 examen blanc en ligne, sur www.edieni.com, destiné à vous entraîner dans des conditions proches
de celles de l’épreuve. Sur ce site, chaque question posée s’inscrit dans l’esprit de la certification MCP et, pour chacune, les
réponses sont suffisamment commentées pour combler ou identifier vos ultimes lacunes. A vous de juger quand vous serez
prêt pour l’examen final !

Jean-François APRÉA est reconnu MVP (Microsoft Most Valuable Professionnal) Windows Server System - Directory
Services depuis plusieurs années.
 Commander le livre

L'auteur
Jean-François APRÉA est Consultant Senior - Architecte Infrastructures Microsoft. Outre sa participation aux
programmes béta et séminaires techniques de Microsoft, il a conduit de nombreux projets d'infrastructures globales pour
des clients prestigieux. Il est reconnu MVP (Microsoft Most Valuable Professionnal) Windows Server System - Directory
Services. En 2007, il a participé à l'étude et la mise en oeuvre de l'une des premières plates-formes AD RMS de gestion
des droits numériques. Sa passion est grande et son engagement en tant qu'instructeur certifié Microsoft depuis 1992 lui
permet de répondre aux attentes des spécialistes Windows Server.

Retrouvez l'interview de Jean-François APRÉA : "Le mot de l'auteur", à propos de son livre Windows Server 2008 -
Architecture et Gestion des services de domaine Active Directory (AD DS).
Ce livre numérique a été conçu et est diffusé dans le respect des droits d’auteur. Toutes les marques citées ont été déposées par leur
éditeur respectif. La loi du 11 Mars 1957 n’autorisant aux termes des alinéas 2 et 3 de l’article 41, d’une part, que les “copies ou
reproductions strictement réservées à l’usage privé du copiste et non destinées à une utilisation collective”, et, d’autre part, que les
analyses et les courtes citations dans un but d’exemple et d’illustration, “toute représentation ou reproduction intégrale, ou partielle, faite
sans le consentement de l’auteur ou de ses ayants droit ou ayant cause, est illicite” (alinéa 1er de l’article 40). Cette représentation ou
reproduction, par quelque procédé que ce soit, constituerait donc une contrefaçon sanctionnée par les articles 425 et suivants du Code
Pénal. Copyright Editions ENI

Page 1
À propos de Windows Server 2008
Avec Windows Server 2008, Microsoft introduit un nombre impressionnant de nouvelles fonctionnalités !
Pour la plupart, celles-ci n’étaient pas disponibles avec Windows Server 2003, ni même avec la version
R2. Pour encore parfaire le produit, les fonctionnalités déjà présentes dans les précédentes versions de
Windows Server ont fait l’objet de dizaines d’améliorations ou d’évolutions positives… Windows Server
2008 est une version « vraiment » majeure !

Windows Server 2008 … une grande version !

Pour s’en convaincre, il suffit de lister les axes d’évolutions apporté aux services de sécurité, aux services
de déploiement, aux services d’administration, au support des sites distants, à l’accès aux applications
quel que soit l’emplacement, à la plate-forme et aux applications Web, aux services de haute -
disponibilité, sans oublier les avancées significatives apportées au stockage et à la virtualisation des
serveurs, avec la prometteuse technologie Hyper-V.

À propos des services Active Directory … Évolution ou révolution ?

Active Directory, apparu avec Windows 2000 Server - et conforté par Windows Server 2003 - forme,
depuis maintenant plusieurs années, la fondation des réseaux d’entreprise basés sur Microsoft Windows.
Les nouveautés et améliorations apportées par Windows Server 2008 à Active Directory sont
nombreuses, mais les fondamentaux sont toujours les mêmes, et ce, bien heureusement pour toutes les
infrastructures déjà déployées depuis plusieurs années !

Au fur et à mesure du parcours de cet ouvrage, les architectes et ingénieurs systèmes qui connaissent
déjà les services Active Directory auront l’occasion de valider leurs acquis tout en découvrant les
évolutions apportées par Windows Server 2008. De leur côté, ceux qui se plongent dans les services de
domaine Active Directory pour la première fois découvriront l’ensemble de ces fondamentaux, et bien
plus, si l’on considère les nouveautés apportées par cette nouvelle version !

Windows Server 2008 est donc une version majeure à plus d’un titre et elle permettra à coup sûr
d’augmenter les services offerts tout en renforçant encore le niveau de sécurité.

Page 2
À propos de l’ouvrage
Pour vous aider à préparer efficacement l’examen, cet ouvrage couvre les objectifs officiels, tant d’un
point de vue théorique que d’un point de vue pratique. Il se divise en quatorze chapitres comportant -
chacun l’organisation ci-après :

 Une définition des objectifs à atteindre : permet d’exposer précisément les compétences
données par le chapitre une fois celui-ci validé.
 Une partie cours théorique : permet de définir les termes et concepts abordés et de
schématiser sous forme d’un fil conducteur les différents points à assimiler.
 Une partie application du cours : permet de suivre le déroulement précis d’une manipulation
(copies d’écran et schémas).
 Une partie validation des acquis proposée sous forme de questions/réponses (310 au total).
Ces questions mettent en exergue aussi bien les éléments fondamentaux que les
caractéristiques spécifiques aux concepts abordés. La partie réponses reprend les questions
posées avec des réponses rédigées pour chacune d’entre elles.
 Les travaux pratiques (71 au total) : ils permettent d’illustrer précisément certaines parties
du cours et vous donnent aussi les moyens de mesurer votre autonomie. Ces manipulations
concrètes, au-delà même des objectifs fixés par l’examen, vous permettront de vous forger une
première expérience significative et d’acquérir de véritables compétences techniques sur des
mises en situations réelles.

Après une introduction aux Services d’annuaire Active Directory (chapitre 1), cet ouvrage est organisé en
quatre modules principaux :

Le premier module (chapitres 2 à 10) présente les Fondements des services d’annuaire Active
Directory :

 Chapitres 2 à 8 : Les services fondamentaux et les éléments de structure logique.


 Chapitres 9 et 10 : La topologie physique Active Directory et les services d’infrastructure.

Le second module (chapitres 11 à 12) présente la Gestion des stratégies de groupes, les nouvelles
préférences des objets stratégies de groupe ainsi que le déploiement des logiciels.

Le troisième module (chapitre 13) présente la Maintenance d’une infrastructure de services de


domaine Active Directory.

Enfin le quatrième module (chapitre 14) présente la configuration des nouveaux rôles de serveurs AD CS,
AD FS, et AD RMS inclus avec Windows Server 2008.

Pour la préparation spécifique à l’examen MCTS 70-640, à l’adresse http://www.edi-


eni.com/francais/certifications, vous pourrez accéder gratuitement à 1 examen blanc en ligne,
destiné à vous entraîner dans les conditions de l’épreuve. Sur ce site, chaque question posée s’inscrit
dans l’esprit de la certification MCTS et, pour chacune, les réponses sont suffisamment commentées pour
combler ou identifier vos ultimes lacunes.

Page 3
À propos de l’auteur
Jean-François APREA est Consultant, spécialiste des Infrastructures Microsoft.

En 1992, Jean-François obtient sa première certification MCP et MCT sur Microsoft OS/2 Lan Manager
puis peu de temps après sur Microsoft Windows NT 3.1. Jean-François a contribué à la formation de
nombreux consultants et ingénieurs des équipes de support de Microsoft France sur Windows NT,
Windows 2000 et Systems Management Server.

Sa connaissance des technologies et infrastructures Microsoft font de lui un consultant passionné par ses
activités d’audit et de conseil.

C’est avec le même enthousiasme qu’il intervient pour le groupe Marketing Technique de Microsoft
France dans l’animation de séminaires Microsoft Technet ou dans le cadre du lancement des nouveaux
produits avec Microsoft. Son activité de formation intra ou inter entreprises lui permet de faire le lien
entre les technologies et les attentes des architectes et administrateurs des infrastructures Windows.

Ses domaines d’activité sont axés sur les services distribués de Windows Server 2003 et Windows Server
2008 et tout particulièrement sur Active Directory et ses services de sécurité.

Outre sa participation aux programmes béta de Microsoft, Jean-François a participé au prélancement de


Windows Server 2003 (Rapid Deployment Program) avec Microsoft Corp. à Redmond et l’ETSI à Sophia-
Antipolis. Ce programme a permis à l’ETSI (l’Institut Européen des Télécommunications
http://www.etsi.org) d’évaluer puis de déployer les services Windows Media Server inclus dans Windows
Server 2003 Enterprise Edition.

Ses contacts avec l’industrie sont constants et de nombreuses entreprises lui font confiance, tout
particulièrement dans le sud-est de la France.

Jean-François est MCP et MCT depuis 1992, MCSE Charter Member depuis 1994, MCSE + I, MCSE Early
Achiever sur Windows 2000, MCSE et MCSA sur Windows Server 2003, MCSE Security, MCSA Exchange
Server et MCTS sur Windows Vista. Il a reçu le label Microsoft MVP Windows Server Management
Infrastructure en 2005 et 2006, et MVP Windows Server Directory Services en 2007 et 2008. Vous
pouvez le contacter via son site web à l’adresse : http://www.ads-training.com

Page 4
Introduction aux services de domaine Active Directory

Pré-requis et objectifs
1. Pré-requis

Notions de base sur les systèmes d’information.

Connaissances générales sur les systèmes d’exploitation.

Connaissances générales sur les méthodes et concepts d’administration des systèmes.

Connaissances générales du protocole TCP/IP.

2. Objectifs

À la fin de ce chapitre, vous serez en mesure de :

Comprendre le rôle et l’importance des services de domaine Microsoft Active Directory de Windows Server
2008.

Comprendre le positionnement des services d’annuaire de Microsoft par rapport aux autres solutions du
marché.

Comprendre le rôle des services et protocoles utilisés par Active Directory.

Comprendre le positionnement et les innovations de Windows Server 2008.

Décrire les nouveautés apportées par Windows Server 2008.

Cette introduction présente les concepts fondamentaux de l’Active Directory, ses éléments de structure
et ses grandes fonctionnalités.

L’annuaire Active Directory est plus qu’une simple fonctionnalité offerte par Windows 2000, Windows
Server 2003 et aujourd’hui par Windows Server 2008. Il joue un rôle central au sein de la stratégie
"Systèmes Distribués" de Microsoft. Cette introduction indispensable vous permettra de bien
comprendre les fondements de cette stratégie.

Page 5
Rôle du service d’annuaire dans l’entreprise
Le service d’annuaire est l’un des composants les plus importants d’un système d’information, et ce,
quelle que soit sa taille. Il offre des services centraux capables de fédérer les multiples éléments qui
composent le système d’information lui-même. Par exemple, imaginez qu’un utilisateur recherche un
élément du réseau sans pour autant en connaître le nom ou l’endroit ! De prime abord, le problème
semble insoluble alors que finalement il n’en est rien. En fait, l’utilisateur pourra résoudre lui-même ce
problème en initiant une recherche vers le système d’annuaire sur la base d’un ou de plusieurs attributs
qu’il connaît. De cette manière, il est par exemple possible à notre utilisateur de localiser une imprimante
couleurs supportant l’impression recto verso, l’agrafage et ce, à un emplacement géographique
particulier.

Au travers de ce premier exemple, nous pouvons maintenant introduire les fondements de l’annuaire
Active Directory. L’annuaire Active Directory doit offrir les moyens de stocker toutes les informations qui
caractérisent l’ensemble des objets pouvant exister dans le réseau de l’entreprise ainsi que disposer des
services capables de rendre ces informations globalement utilisables par les utilisateurs, et ce, en
fonction de leurs droits et privilèges.

Par voie de conséquence, les services de domaine Active Directory de Windows Server offrent les
services ci-dessous :

 La possibilité de publier à l’échelle de l’entreprise des services indispensables au bon


fonctionnement de celle-ci. Les services à caractères globaux pourront trouver leur place au
sein d’un service d’annuaire offrant de telles possibilités de publication et de sélection. Par
exemple, il pourrait s’agir pour une application s’exécutant sur le poste de travail, de localiser le
serveur de messagerie instantanée le plus proche et le plus disponible. Pour reprendre
l’exemple précédent, il pourrait aussi s’agir d’un poste de travail devant sélectionner une
autorité de certification capable de délivrer un certificat permettant d’accéder à un site ou une
application particulièrement sécurisée.
 Ils pourront, si nécessaire, jouer le rôle de colonne vertébrale pour l’ensemble des services de
sécurité du réseau de l’entreprise. De cette manière, les administrateurs pourront s’appuyer sur
un modèle de gestion globale de la sécurité, lequel permettra de garantir plus facilement un
haut niveau de sécurité des accès et une meilleure confidentialité des données sensibles. Par
exemple, ce pourrait être le cas de la distribution automatique de certificats numériques pour
signer un message électronique ou aussi prendre en charge l’authentification des utilisateurs
sur présentation d’une carte à puce ou via la vérification de l’empreinte digitale ou pourquoi pas
aussi de l’iris. Il pourra aussi s’agir de distribuer les listes de contrôle d’accès à un firewall en
fonction de l’authentification d’un utilisateur sur une connexion VPN.De cette manière, les
services de domaine Active Directory permettent ou ne permettent pas à un utilisateur distant
d’accéder à certaines ressources du réseau privé en contrôlant dynamiquement les règles
contenues dans un firewall.
 L’annuaire est globalement distribué. Cette fonctionnalité permet à l’ensemble des utilisateurs
du réseau de s’appuyer sur l’ensemble des services de sécurité, des services applicatifs et des
services de recherche de l’Active Directory. Évidemment, les services globaux doivent être
globalement accessibles ! Il ne saurait en être autrement, surtout s’il s’agit des contrôles
d’accès et du bon fonctionnement d’applications critiques telles que la messagerie ou les
services de collaboration. Il est clair que ces exigences nécessiteront une adoption généralisée
des technologies indispensables à l’implémentation de celles-ci.
 L’annuaire doit disposer de fonctions naturelles qui lui permettent de résister aux défaillances.
La réplication de l’annuaire Active Directory sur chaque site géographique important permettra
à l’annuaire de jouer son rôle central. Par exemple, la disparition d’un contrôleur de domaine
sur un site géographique donné doit être solutionnée sans nécessiter d’intervention humaine.
 Les services de domaine Active Directory apportent avec eux la technologie de partitionnement
qui permet de s’appuyer sur un espace de stockage distribué à l’échelle de l’entreprise. De cette
manière, l’annuaire Active Directory est capable de gérer des millions d’objets et permet aux
utilisateurs d’y accéder quel que soit leur emplacement ou même celui des ressources. Ce rôle
central donnera au service d’annuaire Active Directory un caractère particulièrement
stratégique et critique qu’il conviendra de considérer au plus tôt.

Page 6
Positionnement et innovations de Windows Server 2008

1. Version majeure de Windows Server

Windows Server 2008 a été conçu comme une version majeure pour fournir aux entreprises une plate-
forme plus productive pour virtualiser de charges de travail, alimenter les applications et protéger des
réseaux. Les plus grosses évolutions et avancées permettent de fournir une plate-forme sécurisée facile
à gérer, du simple serveur de groupe de travail au centre de données d’entreprise.

2. Évolutions en matière de sécurité

La sécurité a également été améliorée grâce à la protection des accès réseaux (NAP, Network Access
Protection), des nouveaux contrôleurs de domaine en lecture seule (RODC, Read Only Domain
Controller) et à la nouvelle version des services et infrastructure à clé publique (AD CS, Active Directory
Certificate Services). Les services de gestion des droits numériques RMS (AD RMS, Active Directory
Rights Management Services) permettent aussi une gestion des informations critiques et données
confidentielles au sein et en dehors de l’entreprise. La présence des fonctions de renforcement des
services Windows, du nouveau pare-feu Windows bidirectionnel et des fonctions cryptographiques CNG
(Crypto Next Generation) sont aussi des points essentiels.

3. Accès aux applications et mobilité

Les utilisateurs mobiles ne sont pas en reste puisqu’il est désormais possible d’exécuter des
programmes de n’importe quel emplacement distant grâce à RemoteApp et les fonctions de Terminal
Services Gateway. Windows Server 2008 permet aussi aux équipes de déploiement de progresser grâce
aux Services de déploiement Windows (Windows Deployment Services).

4. Virtualisation des serveurs

Enfin, les progrès accomplis dans l’intégration des technologies virtuelles au matériel permet à Hyper-V
de virtualiser des charges de travail beaucoup plus exigeantes que les versions précédentes et avec une
plus grande flexibilité. L’architecture est basée sur un hyperviseur 64 bits à faible surcharge spécialisé
pour les processeurs 64 bits d’Intel (Intel VT) et AMD (Pacifica). Windows Server 2008 et Hyper-V
prennent en charge la gestion des configurations de type multinoyaux. Chaque machine virtuelle (VM)
peut recevoir un maximum de huit processeurs logiques pour virtualiser des charges de travail
intensives qui profitent du traitement en parallèle des noyaux des VM multiprocesseurs. Le système
hôte 64 bits prend en charge les systèmes d’exploitation invités en mode 64 bits pour assurer un accès
rapide aux grandes zones mémoires des VM invitées. Hyper-V supporte aussi les systèmes
d’exploitation invités 64 bits et 32 bits s’exécutant sur le même serveur consolidé. Enfin, Hyper-V
supporte les accès directs aux disques. Les systèmes d’exploitation invités peuvent être configurés pour
accéder directement au stockage local ou au réseau SAN (Storage Area Network), garantissant ainsi
des performances supérieures aux applications d’E/S (entrées/ sorties) intensives telles que SQL Server
ou Microsoft Exchange Server.

À la sortie de Windows Server 2008, Hyper-V n’est pas encore disponible. Cependant, il faut remarquer que
Windows Server 2008 Standard ou Entreprise en version x 64 US est livré avec une "Preview" de la
technologie Hyper-V. La version finale est planifiée pour être disponible dans le courant du mois d’août
2008.

5. Nouveautés apportées par Windows Server 2008

Après le passage de Windows NT à Windows 2000, Windows Server 2008 est réellement le point de
départ d’une nouvelle génération de Windows Server. La liste des fonctionnalités ci-dessous illustre
l’ensemble des évolutions :

 Windows Firewall with Advanced Security


 Server Manager

Page 7
 Server Core Installation Option
 Active Directory Certificate Services Role
 AD CS: Enterprise PKI (PKIView)
 AD CS: Network Device Enrollment Service
 AD CS: Online Certificate Status Protocol Support
 AD CS: Policy Settings
 AD CS: Web Enrollment
 Cryptography Next Generation
 Active Directory Domain Services Role
 AD DS: Auditing
 AD DS: Fine-Grained Password Policies
 AD DS: Read-Only Domain Controllers
 AD DS: Restartable Active Directory Domain Services
 AD DS: Snapshot Viewer
 AD DS: User Interface Improvements
 Active Directory Federation Services Role
 Active Directory Lightweight Directory Services Role
 Active Directory Rights Management Services Role
 Application Server
 DNS Server Role
 File Services Role
 Windows Server Backup
 Services for Network File System
 Transactional NTFS
 Self-Healing NTFS
 Symbolic Linking
 Network Policy and Access Services Role
 Network Policy and Access Services
 Network Access Protection
 Streaming Media Services Role
 Terminal Services Role
 Terminal Services Core Functionality
 Terminal Services Printing
 TS RemoteApp
 TS Web Access
 TS Licensing
 TS Gateway
 TS Session Broker
 Terminal Services and Windows System Resource Manager
 Web Server (IIS) Role
 Windows Deployment Services Role
 Windows SharePoint Services Role
 BitLocker Drive Encryption
 Failover Clustering
 Network Load Balancing Improvements
 Next Generation TCP/IP Protocols and Networking Components
 Windows Reliability and Performance Monitoring

6. Innovations apportées à Active Directory

Comme cela a été le cas sous Windows Server 2003, les services d’annuaire Active Directory ont
comme fonction et vocation première de gérer les utilisateurs, les ressources telles que les ordinateurs,
les imprimantes et aussi des applications telles que Microsoft Exchange Server ou Microsoft Office
Communication Server.

Les services Active Directory de Windows Server 2008 comprennent de nouvelles fonctionnalités dont la
plupart n’étaient pas présentes dans les versions précédentes de Windows Server. De fait, les services
d’annuaire Active Directory sont-ils rebaptisés Services de domaine Active Directory (AD DS, Active
Directory Domain Services). Cette introduction présente ces nouveautés.

a. AD DS: Audit

Page 8
Les contrôleurs de domaine Windows Server 2008 supportent de nouvelles sous-catégories -
(Directory Service Changes) pour consigner lors des opérations de changements d’attributs sur les
objets Active Directory, les anciennes valeurs ainsi que les nouvelles valeurs d’attributs. Un nouveau
paramètre, à définir dans la stratégie des contrôleurs de domaine - Audit directory service access,
permet d’activer ou de désactiver cette nouvelle fonctionnalité. Bien sur, cette fonctionnalité est très
intéressante pour tous ceux qui souhaitent surveiller les opérations réalisées sur les objets. Notez que
l’administration des attributs à auditer est toujours définie au niveau des objets, permettant ainsi une
extrême finesse de configuration. Les nouveaux services d’audit permettent donc de journaliser les
valeurs des attributs lors des changements.

Windows Server 2003 avait la possibilité de consigner les événements de modification des attributs, mais il
ne permettait pas d’enregistrer ni les anciennes, ni les nouvelles valeurs. Notez aussi que les nouvelles
fonctionnalités d’audit des services de domaine Active Directory s’appliquent de la même manière sur les
services AD LDS (Active Directory Lightweight Directory Services).

b. AD DS: Gestion granulaire des stratégies de mot de passe

Avec les domaines Windows 2000 et Windows Server 2003, une seule et unique stratégie de mots de
passe et de verrouillage des comptes pouvait être appliquée à l’ensemble des utilisateurs d’un
domaine. Les services de domaine Active Directory de Windows Server 2008 permettent désormais de
définir différentes stratégies de mots de passe ainsi que différentes stratégies de verrouillage des
comptes.

Cette nouvelle fonctionnalité intéressera les nombreux administrateurs qui recherchaient cette
possibilité. Il est désormais possible de créer de multiples stratégies de mot de passe au sein du
même domaine et de les appliquer sur différents ensembles d’utilisateurs. Ces nouvelles stratégies de
comptes s’appliquent uniquement sur des objets utilisateurs, de la classe inetOrgPerson mais aussi
sur des groupes globaux de sécurité.

c. AD DS: Contrôleurs de domaine en lecture seule

Les contrôleurs de domaine fonctionnant sous Windows 2000 Server ou Windows Server 2003 sont
par définition disponibles en lecture et en écriture. Lorsque les contraintes d’architecture réseau
l’exigent, il est nécessaire de placer sur un site distant un contrôleur de domaine afin d’authentifier les
utilisateurs et d’offrir les services d’infrastructure habituels. Le problème est que, trop souvent, les
sites distants ne disposent pas du niveau de sécurité nécessaire à des serveurs d’infrastructure, tels
que des contrôleurs de domaine disponibles en écriture.

Windows Server 2008 permet désormais d’installer un nouveau type de contrôleur de domaine appelé
contrôleur de domaine en lecture seule ou RODC (Read-Only Domain Controller). Cette nouvelle
solution permet de déployer des contrôleurs de domaine dans les emplacements ou un bon niveau de
sécurité ne peut être garanti. En plus de forcer la base de données Active Directory en mode lecture
seule, les RODC introduisent aussi d’autres améliorations telles que la réplication unidirectionnelle, la
mise en cache des données d’identification, la séparation des rôles ainsi que la prise en charge de la
problématique des inscriptions dynamiques DNS dans les zones DNS intégrées à des bases de
données Active Directory disponibles en lecture seule.

d. AD DS: Redémarrage des services de domaine Active Directory

Les serveurs Windows Server 2008 permettent aux administrateurs d’arrêter et de démarrer les
services AD DS à l’aide des outils habituels de Windows Server 2008. Cette nouvelle fonctionnalité est
très intéressante lors du passage de certaines mises à jour ou lors d’une opération de
défragmentation de la base de données Active Directory, sachant que les services ne dépendant pas
d’Active Directory peuvent continuer de fonctionner normalement.

e. AD DS: Aide à la récupération des données

Avant l’utilisation des contrôleurs de domaine Windows Server 2008, lorsque des objets étaient
accidentellement détruits, la seule façon de déterminer quels objets avaient été effacés était de
restaurer la base de données Active Directory.

Bien que la fonctionnalité d’aide à la récupération des données Active Directory ne permette pas de
directement restaurer les données éventuellement effacées, elle aidera lors de la procédure de
récupération des données.

Page 9
Grâce à l’outil de montage de base Active Directory, les données Active Directory enregistrées dans
les clichés instantanés sont exposées. De cette manière, l’administrateur peut comparer les données à
différents moments sans aucun arrêt système.

Pendant la phase Beta de Windows Server 2008, cette fonctionnalité était appelée Snapshot Viewer.

f. AD DS: Améliorations de l’interface Active Directory

Windows Server 2008 introduit un nouvel assistant d’installation des services Active Directory. Il
permet notamment d’installer les nouveaux contrôleurs de type RODC, ainsi que de définir les options
de réplication des mots de passe sur ces contrôleurs. La nouvelle console de gestion Utilisateurs et
ordinateurs Active Directory permet aussi de pré-créer et de déléguer l’installation d’un contrôleur de
domaine en mode lecture seule.

En plus de ces améliorations, l’assistant d’installation d’Active Directory supporte une nouvelle option
qui permet d’utiliser un mode plus avancé. Ce nouveau mode permet notamment :

 Lors de l’installation d’un nouveau contrôleur de domaine dans un domaine enfant, de


détecter lorsque l’IM - Infrastructure Master, est positionné sur un GC - Global Catalog.
Dans ce cas, l’assistant propose de réaliser l’opération de transfert du rôle de maître
d’infrastructure vers le nouveau contrôleur en cours d’installation, bien sûr dans le cas où
celui-ci ne joue pas le rôle de catalogue global. Cette nouvelle option est très intéressante
car elle permet de conserver une configuration Active Directory valide lors de l’ajout ou la
suppression des contrôleurs.
 Lors de l’exécution de l’assistant d’installation d’Active Directory, il est désormais possible
d’exporter l’ensemble des paramètres pour les utiliser dans un fichier de réponses. Cette
nouvelle option est très intéressante pour l’installation d’un contrôleur de domaine en mode
"Server Core".
 Enfin, une nouvelle option très importante permet de forcer la suppression des services
Active Directory lorsque le contrôleur de domaine défaillant est démarré en mode Directory
Services Restore Mode.

Toutes ces nouvelles fonctionnalités sont détaillées plus loin dans l’ouvrage.

Page 10
Windows Server 2008 : stratégie de Microsoft
Cette section présente la stratégie à long terme de Microsoft concernant la famille Windows Server en
tenant compte des évolutions qui seront perceptibles via les Services Packs, Feature Packs, mises à
niveau et la prochaine version majeure. La stratégie système présentée par Microsoft vous permet de
percevoir les prochaines évolutions du produit et les enjeux qui y sont rattachés :

 Intégration de l’innovation au sein de Windows Server ;


 Le nouveau cycle de produits pour Windows Server ;
 Windows Server 2008 "R2" ;
 Planification des évolutions de Windows Server ;

1. Intégration de l’innovation au sein de Windows Server

Windows Server intègre un nombre important de technologies, fonctionnalités et services conçus pour
former une solution pérenne et adaptée aux besoins des clients. L’un des plus grands avantages de
l’intégration de cette plate-forme concerne l’intégration de ces services au centre du système, de la
plate-forme toute entière et la facilité de mise en œuvre de celle-ci. Windows Server a été architecturé
sur la base de scénarios qui sont le reflet d’une expérience dans les entreprises. L’objectif de cette
approche est de permettre un déploiement rapide de solutions au départ complexes tout en étant au
plus près des attentes et besoins exprimés par les clients.

La stratégie consiste à innover autour de la plate-forme Windows Server. En effet, cette plate-forme a
vraiment vocation à explorer et ouvrir un certain nombre de voies. Ce point concerne particulièrement
les fournisseurs d’applications, les fournisseurs de services, les intégrateurs système, les centres de
formation et bien sûr, les développeurs de matériels qui pourront, sur la base des technologies
présentes dans Windows Server, créer des solutions intéressantes. Les services de base intégrés au
système ainsi que les fonctionnalités que Windows Server fournit permettent aux constructeurs et
partenaires de se concentrer sur la fourniture de solutions pour étendre les services fondamentaux de
Windows et apporter une plus-value substantielle aux clients.

Les clients et analystes extérieurs ont constaté que l’approche de Microsoft à propos de l’innovation a
pour effet d’accentuer le développement d’applications de très haute qualité, de favoriser la baisse du
coût total de possession (TCO) en permettant une meilleure productivité et efficacité par rapport aux
solutions concurrentes.

Une innovation permanente est indispensable pour permettre que les initiatives technologiques
majeures conduites par Microsoft, telles que DSI - Dynamic Systems Initiative et la technologie
Microsoft .NET, puissent aboutir.

2. Le nouveau cycle de produits Windows Server

Aujourd’hui, Windows Server 2003 et Windows Server 2008 fournissent les services d’infrastructure
fondamentaux ainsi que les services globaux de Windows Server. Depuis sa date de sortie en avril
2003, Microsoft a rajouté de nouvelles fonctionnalités à Windows Server 2003 grâce à la fourniture de
"Feature Packs". Avec Windows Server 2008, Microsoft a poursuivi son effort d’innovation en
fournissant une version majeure de son système d’exploitation serveur.

Microsoft essaie de fournir un cycle d’évolution des prochaines versions de Windows Server de telle
sorte que les clients puissent planifier et budgétiser ces évolutions. La règle est de fournir une version
majeure de Windows Server à peu près tous les quatre ans, puis une mise à niveau de version tous les
deux ans après chaque version majeure.

a. Versions majeures

Les versions majeures de Windows Server incluent un nouveau noyau et sont ainsi capables de
supporter de nouveaux matériels, de nouveaux modèles de programmation et des évolutions
fondamentales dans les domaines de la sécurité et de la stabilité. Ces changements "majeurs"
peuvent bien entendu générer des incompatibilités du nouveau système avec les matériels et logiciels
existants.

b. Versions mises à jour

Page 11
Les versions mises à jour incluent la précédente version majeure en y incluant le dernier Service
Pack, certains Feature Packs, et de nouvelles fonctionnalités additionnelles. Comme une version mise
à jour est basée sur la précédente version majeure, les clients peuvent incorporer ces versions dans
leur environnement de production sans tests supplémentaires autres que ceux que pourraient
nécessiter un simple Service Pack. Toutes les fonctionnalités additionnelles fournies par une mise à
jour sont optionnelles et de fait, elles n’affectent pas la compatibilité des applications existantes. Par
conséquent, les clients n’ont pas à recertifier ou à retester leurs applications.

c. Service Packs

Les Services Packs incorporent tous les correctifs de types critiques, de type non critiques ainsi que
les dernières demandes des clients au sein d’un même package.

Les Services Packs sont testés de manière intensive par Microsoft et par les clients et partenaires
participant à un programme de Beta test. Les Services Packs peuvent aussi inclure des améliorations
importantes de la sécurité comme le "Security Configuration Wizard" qui est inclus dans le Service
Pack 1 de Windows Server 2003.

Il sera parfois nécessaire de réaliser des changements à certains programmes pour supporter les
nouveaux standards de l’industrie ou des fonctionnalités demandées par les clients. Ces changements
sont soigneusement évalués et testés avant d’être finalement inclus dans le Service Pack.

Afin de permettre au maximum les extensions et évolutions d’architecture, Microsoft s’impose de


maintenir un niveau de compatibilité entre les Services Packs en réalisant des tests intensifs avec les
applications et ces différents Service Packs. En général, les problèmes de compatibilité concernent les
applications qui utilisent de manière inappropriée des appels système, des interfaces internes ou des
fonctions spécifiques à l’application.

d. Feature Packs

Lorsque cela s’avère nécessaire, Microsoft fournira des extensions fonctionnelles appelées Feature
Packs. Ces services additionnels sont généralement des composants importants de Windows Server
et, à ce titre, ces modules sont bien entendu officiellement supportés. C’est pour cette raison que tous
ces composants sont téléchargeables à partir du site de Microsoft dans une rubrique qui leur est
particulièrement dédiée (site Microsoft/Windows Server 2003/Downloads/Feature Packs). Cependant,
afin de simplifier le processus de mise à niveau des administrateurs système, Microsoft prévoit de
limiter le nombre et la fréquence des Feature Packs. La plupart des Feature Packs seront intégrés via
des mises à jour ou la mise à niveau vers une nouvelle version majeure.

3. Windows Server 2008 "R2"

Aujourd’hui, Windows Server 2008 est disponible en version 32 bits et 64 bits, sachant que les éditions
incluant Hyper-V existent uniquement en 64 bits.

La version R2 de Windows Server 2008 devrait voir le jour courant 2009 et ne sera disponible qu’en
version 64 bits.

Pour en savoir plus sur la vision à long terme de Microsoft concernant les services de la famille de
produits Windows Server System, consultez la "Common Engineering Roadmap" disponible sur le site
Web de Microsoft.

Ce planning prévisionnel des évolutions des systèmes Windows est libre d’accès et vous permettra de
découvrir les prochaines fonctionnalités et axes d’évolution qui seront intégrés dans les versions
ultérieures de Windows. Cette stratégie est disponible à l’adresse :
http://www.microsoft.com/windowsserver2008/en/us/20admap.aspx

Page 12
Services fondamentaux et protocoles standard
Les services d’annuaire permettent la mise en œuvre d’un espace logique organisé de manière
hiérarchique où il devient aisé pour tout utilisateur habilité du réseau de localiser et utiliser tout type
d’information.

Tout le monde doit finalement y trouver son intérêt puisque les utilisateurs pourront par exemple utiliser
les services de recherche et ainsi localiser les ressources dont ils ont besoin tandis que les
administrateurs pourront, quant à eux, mieux gérer les comptes d’utilisateurs, leurs privilèges ainsi que
les ressources et leurs droits associés.

La centralisation des informations au sein des services d’annuaire permettra aussi d’éviter les
innombrables pertes de temps occasionnées par de longues "promenades" sur les serveurs à la recherche
de l’hypothétique présence de l’élément recherché.

Quel que soit le système d’annuaire et l’usage pour lequel il a été conçu au départ, il est clair qu’au final,
il permet de structurer l’information en organisant celle-ci sur la base d’objets plus ou moins complexes
et de leurs attributs respectifs, eux-mêmes plus ou moins nombreux et spécifiques.

De manière tout à fait logique, si l’annuaire est positionné au centre du système d’information, alors il
deviendra automatiquement un élément de choix pour servir de composant central pour l’ensemble des
services de sécurité et de contrôle des accès aux objets pris en charge.

Ce choix est bien sûr au cœur de la stratégie de Microsoft. Parmi les points les plus importants, nous
pouvons d’ores et déjà remarquer que l’implémentation de Kerberos V5 comme méthode
d’authentification principale et l’intégration forte des services de gestion de certificats numériques X509
v3 sont autant d’éléments qui font aujourd’hui le succès de l’Active Directory.

Ainsi, l’annuaire peut offrir de manière générique et sécurisée tout type de données à tout type de
clients. Les services du système d’exploitation, les applications et au sens large, toute entité de sécurité
habilitée disposant des droits suffisants y parviendront.

Un autre point positif induit par les services de sécurité intégrés dans le système d’annuaire est de
permettre l’implémentation d’une authentification unique disponible partout à l’échelle de l’entreprise.
Cette fonctionnalité n’a pas fait son apparition avec Windows 2000, ni avec Windows Server 2003. Dès
Windows NT (et même avant dans une moindre mesure avec LAN Manager), l’ouverture de session de
domaine via le protocole NTLM v1 ou v2 a été largement utilisée par les applications Windows tierces
parties. Depuis, Windows 2000 Server, Windows Server 2003 et Windows Server 2008, étendent ces
concepts en s’appuyant sur les technologies les plus abouties et éprouvées de l’industrie.

Le tableau suivant résume les points clés qui caractérisent l’Active Directory.

Fonctionnalités Active Directory Avantages pour l’entreprise

Stockage des données d’annuaire unifié nécessitant peu de


Système de stockage réparti.
tâches administratives.

Intégration d’applications tierces avec extension du schéma


Extensibilité de l’annuaire.
Active Directory.

Contrôle des privilèges d’administration et des paramètres de


Administration centralisée et délégation.
sécurité de manière hiérarchique à l’échelle de l’entreprise.

L’annuaire peut être mis à jour à partir de tout contrôleur de


domaine et ce, même lorsqu’un contrôleur de domaine est
indisponible. La disponibilité et la gestion des flux de
réplication sont contrôlées grâce à l’ajustement dynamique de
Disponibilité des informations de l’annuaire, tolérance de
la topologie de réplication et au mode de réplication
panne, hautes performances.
multimaître. La structure de forêt Active Directory - les arbres,
les domaines et les contrôleurs de domaine - supporte des
structures comportant des milliers de sites géographiques et des
millions d’objets.

Gestion des configurations et des changements de configuration Cohérence des paramètres appliqués et opérations réalisées
à l’aide de la technologie IntelliMirror. grâce aux stratégies de groupe.

Page 13
Fonctionnalités Active Directory Avantages pour l’entreprise

Services de sécurité à l’échelle des entreprises de toutes tailles


via le support de Kerberos v5, SSL (Secure Socket Layer) 3.0,
Les services d’authentification et de contrôle des accès assurent
TLS (Transport Layer Security) et les services de clés
une prise en charge au sein du réseau privé et aussi sur Internet.
publiques (PKI - Public Key Infrastructure et certificats X509
V3).

La granularité descend jusqu’à l’attribut et l’étendue de


Gestion de la sécurité et délégation de gestion de
management s’exerce sur les objets de types Site, Domaine et
l’administration.
OU.

L’entreprise est assurée d’une pérennité de ses choix de par la


participation active de Microsoft aux standards de l’industrie.
Support des standards de l’Internet : un domaine Windows est
TCP/IP v4 et v6, DNS, DDNS (Dynamic DNS), IPSec, DHCP
un domaine DNS (Domain Name System), un domaine
(Dynamic Host Configuration Protocol), Kerb5, Radius
d’authentification est un royaume Kerberos, les certificats sont
(Remote Authentication Dial-in User Service), EAP (Extensible
utilisables de manière naturelle pour l’authentification
Authentication Protocol), PEAP (Protected EAP), LDAP
(ouverture de session par carte à puce (Smart logon) et la
(Lightweight Directory Access Protocol), LT2P (Layer 2
sécurisation des informations (signatures numériques et
Tunneling Protocol), PPTP (Point to Point Tunneling
chiffrement des données locales et transitant sur le réseau).
Protocol), SSL3, TLS, Infrastructure à clés publique (PKI),
certificats X509 V3 et authentification par cartes à puce.

Validation des acquis : questions/réponses


1. Questions

Si l’état de vos connaissances sur ce chapitre vous semble suffisant, répondez aux questions ci-après.

1 Quel est le rôle des services de domaine Active Directory dans l’entreprise ?

2 À quoi correspond la publication de services au sein de l’Active Directory ?

3 Quels sont les avantages d’un système d’annuaire globalement distribué ?

4 Pourquoi est-il judicieux de disposer un serveur d’annuaire sur un site géographique donné ?

5 Que signifie le terme "partitionnement" dans un espace tel que les services de domaine Active Directory ?

6 Sélectionnez dans la liste ci-dessous les critères qui caractérisent le mieux une version majeure de
Windows.

 Nouveau noyau

 Même noyau

 Nouveaux pilotes

 Anciens pilotes

Il se peut que le système fasse apparaître des incompatibilités avec des applications.

7 Sélectionnez dans la liste ci-dessous les critères qui caractérisent le mieux une version "Mise à jour" de
Windows.

 Nouveau noyau

 Même noyau

 Nouveaux pilotes

 Anciens pilotes

 Nouveau modèle de programmation

 Intégration des derniers Services Pack (BR)

Page 14
 Intégration des derniers correctifs de sécurité (BR)

 Il se peut que le système fasse apparaître des incompatibilités avec des applications.

8 Sélectionnez dans la liste ci-dessous les critères qui caractérisent le mieux un Service pack.

 Nouveaux pilotes

 Anciens pilotes

 Nouveau modèle de programmation

 Correctifs fonctionnels

 Amélioration de la stabilité et des performances

 Mise à niveau des API du système d’exploitation

9 Sélectionnez dans la liste ci-dessous les critères qui caractérisent le mieux un "Feature Pack" pour la
famille de systèmes Windows Server 2003.

 Correctifs fonctionnels

 Amélioration de la stabilité et des performances

 Mise à niveau des API du système d’exploitation

 Ajout d’une fonctionnalité spécifique en tant qu’extension des services offerts par la plate-forme
Windows Server System.

 Version intermédiaire non supportée en attendant la prochaine version majeure.

10 Sélectionnez dans la liste ci-dessous les critères qui caractérisent le mieux une nouvelle version telle
que, par exemple, Windows Server 2003 R2 ou Windows Server 2008 R2, lorsque cette version sera
disponible ?

 Nouveaux pilotes

 Correctifs fonctionnels

 Améliorations fonctionnelles

 Nouvelles fonctionnalités

 Intégration du dernier "Service Pack"

 Intégration de précédents "Feature Pack"

11 Lister les différentes versions de la famille Windows Server 2008.

12 Quelles sont les capacités de gestion mémoire et processeur de Windows Server 2008 Standard,
Enterprise et Datacenter en version x86 ?

13 Quelles sont les capacités de gestion mémoire et processeur de Windows Server 2008 Standard,
Enterprise et Datacenter en version x64 ?

14 Quelle politique de gestion des images virtuelles est définie par Microsoft pour Windows Server 2008
Standard, Windows Server 2008 Enterprise et Windows Server 2008 Datacenter avec la technologie de
virtualisation Hyper-V ?

15 Les services de recherche de l’annuaire Active Directory sont-ils optionnels ou intégrés de base au sein
du système d’annuaire Active Directory ?

2. Résultats

Reférez-vous aux pages suivantes pour contrôler vos réponses. Pour chacune de vos bonnes réponses,
comptez un point.

Nombre de points /15

Pour ce chapitre, votre score minimum doit être de 11 sur 15.

Page 15
3. Réponses

1 Quel est le rôle des services de domaine Active Directory dans l’entreprise ?

Les services d’annuaire Active Directory inclus avec Windows 2000 ou Windows Server 2003 renferment les
informations relatives aux objets d’un réseau et facilitent leur recherche et leur utilisation pour les
administrateurs, les utilisateurs et aussi les applications. Active Directory repose sur un magasin de données
structuré qui permet une organisation hiérarchique et logique des informations d’annuaire.

2 À quoi correspond la publication de services au sein de l’Active Directory ?

La publication des services est l’action qui permet de déclarer un service particulier au sein de
l’infrastructure technique et logique Active Directory. Lorsqu’un service est publié, alors le service offert est
globalement disponible dans le cadre de l’annuaire Active Directory.

3 Quels sont les avantages d’un système d’annuaire globalement distribué ?

Un tel système distribué permet à tous les utilisateurs, ordinateurs et services de l’entreprise d’avoir
potentiellement accès à toutes les informations stockées dans l’annuaire et ce, en tout point du réseau.

4 Pourquoi est-il judicieux de disposer un serveur d’annuaire sur un site géographique donné ?

Sur un site donné, un serveur d’annuaire, permet à ce site de disposer localement d’une version de la base
de données de l’annuaire. De cette façon, le site dispose d’une autonomie totale quant aux opérations
classiques de recherches, d’authentifications et de localisation des services offerts par l’annuaire.

5 Que signifie le terme "partitionnement" dans un espace tel que les services de domaine Active Directory ?

Le terme "partitionnement" signifie que la totalité de l’annuaire est répartie en plusieurs parties appelées
partitions. Une partition correspond à un domaine Active Directory, tandis que la totalité est représentée par
la somme des domaines de la forêt, c’est-à-dire la forêt.

6 Sélectionnez dans la liste ci-dessous les critères qui caractérisent le mieux une version majeure de
Windows.

Bonnes réponses : Nouveau noyau, Nouveaux pilotes, Il se peut que le système fasse apparaître des
incompatibilités avec des applications.

7 Sélectionnez dans la liste ci-dessous les critères qui caractérisent le mieux une version "Mise à jour" de
Windows.

Bonnes réponses : Intégration des derniers Services Pack, Intégration des derniers correctifs de sécurité, Il
se peut que le système fasse apparaître des incompatibilités avec des applications.

8 Sélectionnez dans la liste ci-dessous les critères qui caractérisent le mieux un Service pack.

Bonnes réponses : Correctifs fonctionnels, Amélioration de la stabilité et des performances, Mise à niveau
des API du système d’exploitation.

9 Sélectionnez dans la liste ci-dessous les critères qui caractérisent le mieux un "Feature Pack" pour la
famille de systèmes Windows Server 2003.

Bonne réponse : Ajout d’une fonctionnalité spécifique en tant qu’extension des services offerts par la plate-
forme Windows Server System. (BR)

10 Sélectionnez dans la liste ci-dessous les critères qui caractérisent le mieux une nouvelle version telle
que, par exemple, Windows Server 2003 R2 ou Windows Server 2008 R2, lorsque cette version sera
disponible ?

Correctifs fonctionnels, Améliorations fonctionnelles, Nouvelles fonctionnalités, Intégration de précédents


"Feature Pack".
Page 16
11 Lister les différentes versions de la famille Windows Server 2008.

La famille Windows Server 2008 contient les versions suivantes : Windows Server 2008 Standard, Windows
Server 2008 Enterprise, Windows Server 2008 Datacenter, Windows Web Server 2008, Windows Server
2008 for Itanium, Windows HPC Server 2008.

Notez qu’il existe aussi les versions ne disposant pas de la technologie de virtualisation Hyper-V, à savoir,
Windows Server 2008 Standard without Hyper-V, Windows Server 2008 Enterprise without Hyper-V,
Windows Server 2008 Datacenter without Hyper-V.

12 Quelles sont les capacités de gestion mémoire et processeur de Windows Server 2008 Standard,
Enterprise et Datacenter en version x86 ?

4 Go de RAM pour la version Windows Server 2008 Standard.

64 Go de RAM pour la version Windows Server 2008 Enterprise et aussi la version Windows Server 2008
Datacenter.

4 processeurs physiques pour la version Windows Server 2008 Standard.

8 processeurs physiques pour la version Windows Server 2008 Enterprise.

32 processeurs physiques pour la version Windows Server 2008 Datacenter.

13 Quelles sont les capacités de gestion mémoire et processeur de Windows Server 2008 Standard,
Enterprise et Datacenter en version x64 ?

32 Go de RAM pour la version Windows Server 2008 Standard.

2 To de RAM pour la version Windows Server 2008 Enterprise et aussi la version Windows Server 2008
Datacenter.

4 processeurs physiques pour la version Windows Server 2008 Standard.

8 processeurs physiques pour la version Windows Server 2008 Enterprise.

64 processeurs physiques pour la version Windows Server 2008 Datacenter.

14 Quelle politique de gestion des images virtuelles est définie par Microsoft pour Windows Server 2008
Standard, Windows Server 2008 Enterprise et Windows Server 2008 Datacenter avec la technologie de
virtualisation Hyper-V ?

Windows Server 2008 Standard autorise 1 seule machine virtuelle gratuite.

Windows Server 2008 Enterprise autorise 4 machines virtuelles Windows Server 2008 gratuites.

Windows Server 2008 Datacenter autorise un nombre illimité de machines virtuelles Windows Server 2008.

15 Les services de recherche de l’annuaire Active Directory sont-ils optionnels ou intégrés de base au sein
du système d’annuaire Active Directory ?

Les services de recherche LDAP vers les contrôleurs de domaine ainsi que les recherches globales vers les
catalogues globaux font partie intégrante des services d’annuaire Active Directory.

Page 17
Travaux pratiques
1. Installation de Windows Server 2008

Pré-requis

Pour utiliser la version finale de Windows Server 2008, vous devez disposer des éléments suivants :

Composant Exigence

Minimum : 1 GHz (processeur x86) ou 1,4 GHz (processeur


x64)

Processeur Recommandé : 2 GHz ou plus rapide

Remarque : un processeur Intel Itanium 2 est requis pour


Windows Server 2008 pour les systèmes Itanium.

Minimum : 512 Mo de RAM


Recommandé : 2 Go de RAM ou plus

Mémoire Maximum (systèmes 32 bits) : 4 Go (Standard) ou 64 Go


(versions Enterprise et Datacenter)

Maximum (systèmes 64 bits) : 32 Go (Standard) ou 2 To


(versions Enterprise, Datacenter et systèmes Itanium)

Minimum : 10 Go
Recommandé : 40 Go ou plus
Espace disque disponible
Remarque : les ordinateurs de plus de 16 Go de RAM
nécessitent plus d’espace disque pour les fichiers de pagination,
de veille prolongée et d’image mémoire.

Lecteur Lecteur DVD-ROM

Moniteur Super VGA (800 x 600) ou de résolution supérieure


Écran et périphériques Clavier
Souris Microsoft ou périphérique de pointage compatible

Faites attention au fait que la configuration minimale réelle varie selon votre configuration système et
les applications et fonctionnalités que vous choisissez d’installer. Les performances du processeur
dépendent non seulement de la fréquence d’horloge du processeur, mais également du nombre de
cœurs et de la taille du cache du processeur. L’espace disque requis pour la partition système est
approximatif. Pour les systèmes d’exploitation Itanium et x64, ces estimations de taille de disque
peuvent varier. Un espace de disque dur disponible plus important peut être nécessaire si vous
procédez à une installation via un réseau. Pour plus d’informations, consultez le lien :
http://www.microsoft.com/windowsserver2008/en/us/default.aspx

À propos de la clé d’activation : ce produit requiert une clé de produit valide pour l’activation. Vous pouvez
l’installer sans l’activer, mais si vous n’entrez pas une clé de produit valide et que vous n’activez pas le
produit dans les 30 jours suivant l’installation, le logiciel cessera de fonctionner. Pendant l’installation, il
vous sera demandé de sélectionner l’édition de Windows Server 2008 que vous souhaitez installer. Assurez-
vous que vous choisissez l’édition de Windows Server 2008 pour laquelle vous avez obtenu une clé de
produit, sinon vous ne pourrez pas activer le produit.

Recommandations pour les configurations dédiées aux tests et évaluations des fonctionnalités de
Windows Server 2008 :

Page 18
 Utilisez un ordinateur type Intel Core 2 Duo ou AMD équivalent ou supérieur équipé de 2 Go
de RAM et d’un disque de 100 Go ou supérieur.
 Installez un produit de virtualisation qui vous permette d’exécuter plusieurs sys- tèmes
d’exploitation en parallèle sur la même machine. Vous pouvez utiliser une machine
fonctionnant sous Windows Server 2003 SP2 avec Microsoft Virtual Server R2 EE SP1, ou une
machine hôte fonctionnant sous Windows Server 2008 x64 Edition Entreprise avec la nouvelle
technologie de virtualisation Microsoft Hyper-V. Attention, votre ordinateur (carte mère) et
votre processeur (Intel VT - AMD Pacifica) doivent supporter la virtualisation assistée par le
matériel.

Installation de Windows Server 2008 à partir du DVD

Si vous installez Windows Server 2008 directement sur un ordinateur, vous pouvez lancer le
programme d’installation en démarrant l’ordinateur en tant que VM à partir du DVD de Windows Server
2008.

Si vous installez Windows Server 2008 "virtuellement" sur Microsoft Virtual PC 2007, procédez de la
manière suivante :

1.
Lancez Microsoft Virtual PC 2007 et cliquez sur Nouveau.
2.
Cliquez sur Suivant sur la page de Bienvenue.
3.
Choisissez Créer une machine virtuelle.
4.
Choisissez le nom et l’emplacement du fichier de configuration de votre nouvelle machine virtuelle (fichier
.vmc).
5.
Sélectionnez le type de système d’exploitation que vous comptez installer au sein de la machine virtuelle,
c’est-à-dire Windows Vista.
6.
Sélectionnez la quantité de mémoire RAM à affecter à cette configuration. La taille recommandée est de 512
Mo. Avec 4 Go de RAM installée dans l’ordinateur, vous pourrez donc faire fonctionner en parallèle 5 ou 6
serveurs Windows Server 2008.
7.
Sélectionnez la création d’un nouveau disque virtuel (fichier .vhd) puis spécifiez son emplacement.
8.
Cliquez sur le bouton Terminer. Une fois la configuration de cette machine virtuelle terminée, vous pouvez
modifier certains paramètres de ressources matérielles en cliquant sur le bouton Paramètres.
9.
Pour démarrer l’installation de Windows Server 2008, démarrez votre machine virtuelle Windows Server
2008 sur le CD-Rom de Windows Server 2008.

Microsoft Virtual PC 2007 vous permet de démarrer sur un CD-Rom virtuel redirigé vers une image ISO. Cela
vous permettra d’éviter l’usage d’un CD-Rom, périphérique bien plus lent qu’un disque dur. Microsoft
distribue les fichiers ISO de tous ces produits à ses clients (contrats en volume, abonnements MSDN, et/ou
Technet, etc).Les versions d’évaluation sont aussi disponibles en téléchargement.

Étapes d’installation de Windows Server 2008

L’installation de Windows Server 2008 utilise la même technologie de programme d’installation que
Windows Vista. La logique d’installation est donc similaire à celle de Windows Vista.

Page 19
Écran de bienvenue pour Installer ou réparer Windows Server 2008

À ce stade de l’installation le noyau Windows est déjà chargé sous la forme de Windows PE.

Écran de sélection de la version de Windows Server 2008

Page 20
Remarquez que les principales versions de Windows Server 2008 sont disponibles sur un seul DVD.

Il existe un DVD spécifique par langage (Français, anglais, italien,…) et aussi en fonction de la plate-forme
32 bits ou 64 bits.

http://www.microsoft.com/windowsserver2008/en/us/default.aspx

Écran d’acceptation du contrat de licence

Page 21
Écran de sélection du processus de mise à niveau

Cette option n’est disponible que lorsqu’une version susceptible d’être mise à niveau est détectée.

Notez qu’il n’est pas possible de mettre à niveau une version inférieure, ni de changer de langage, ni de
changer le type d’architecture (32 bits/64 bits).

Page 22
Écran de gestion des partitions

Cette option vous permet d’accepter la configuration courante, lorsque celle-ci est valide ou de la
modifier.

Notez que vous avez aussi la possibilité de spécifier les pilotes supplémentaires nécessaires à la prise en
charge de contrôleurs de sous-systèmes d’entrées-sorties disques non pris en charge par la distribution
utilisée.

Page 23
Écran d’installation de Windows Server 2008

Les différentes étapes se poursuivent sans aucune interaction jusqu’à la fin du processus complet de
l’installation.

Ce TP vous a permis d’installer Windows Server 2008 dans sa configuration par défaut.

2. Configuration des paramètres généraux du serveur Windows Server


2008

Lors de l’ouverture de session initiale vous devez obligatoirement changer le mot de passe de
l’administrateur.

Une fois cette opération réalisée, vous pouvez configurer l’ensemble des paramètres généraux de
Windows Server 2008 à l’aide de la page d’accueil du Gestionnaire de serveur.

Page 24
Vue d’ensemble de l’état du serveur

La fenêtre principale Gestionnaire de serveur vous permet d’afficher un instantané détaillé des
informations d’identité de votre serveur, des options de configuration de sécurité sélectionnées, ainsi
que des rôles et fonctionnalités installés. Vous pouvez découvrir au sein de cette interface que la zone
Ressources et support de la fenêtre principale Gestionnaire de serveur contient des liens qui vous
aident à rester connecté aux dernières documentations et téléchargements.

Paramètres gérés au niveau de cette zone de consultation et de modification via le Gestionnaire de


serveur.

 Zone Résumé serveur : la zone Résumé serveur affiche des détails sur votre serveur qui
se révèlent particulièrement utiles lors du dépannage, tels que le nom d’ordinateur et les
adresses réseau, ainsi que l’ID de produit du système d’exploitation exécuté sur l’ordinateur.
À partir de la zone Résumé serveur, vous pouvez afficher et modifier des connexions
réseau, modifier des propriétés du système et activer et configurer le Bureau à distance.

En cliquant à l’aide des différents liens de l’interface, renseignez l’ensemble des paramètres déclarés
dans les tableaux ci-après :

 Informations sur l’ordinateur

Paramètre Description des données

Nom complet de l’ordinateur : Nom de domaine pleinement qualifié (FQDN) du serveur cible.

Domaine (ou groupe de travail si l’ordinateur n’est pas joint au


Suffixe DNS principal
domaine.

<nom de connexion réseau 1>: Adresse IP :

<nom de connexion réseau 2>: Adresse IP :

<nom de connexion réseau 3>: Adresse IP :

Nombre de jours restant pour activer le système d’exploitation


État d’activation de produit Windows :
Windows du serveur

Page 25
Paramètre Description des données

ID de produit (si active) : ID de produit

Attention : l’ID du produit n’est pas la clé produit permettant l’activation de votre licence Windows.

 Informations sur la sécurité

Le tableau suivant décrit les informations qui apparaissent dans la section Informations sur la sécurité.

Paramètre Description des données

État du Pare-feu Windows Indique si le Pare-feu Windows est activé sur le serveur.

Affiche si le serveur est configuré pour télécharger et installer


État de Windows Update
des mises à jour logicielles Windows automatiquement.

Affiche le jour et l’heure de la dernière vérification par le


Dernière recherche de mises à jour
serveur de la présence de mises à jour logicielles.

Affiche le jour et l’heure de la dernière installation des mises à


Dernières mises à jour installées
jour.

Indique si la configuration de sécurité avancée d’Internet


Configuration de sécurité renforcée d’Internet Explorer Explorer est activée pour les membres du groupe
Administrateurs et les autres utilisateurs.

À partir de la zone Informations sur la sécurité, vous pouvez aussi démarrer l’Assistant Configuration de
la sécurité qui vous aide à créer une stratégie de sécurité pouvant être appliquée à n’importe quel
serveur sur votre réseau.

 Zone Résumé des rôles :

La zone Résumé des rôles de la fenêtre principale Gestionnaire de serveur affiche une liste de tous
les rôles installés sur l’ordinateur. Les noms des rôles installés sur l’ordinateur s’affichent au format
hypertexte. Lorsque vous cliquez sur un nom de rôle, la page d’accueil Gestionnaire de serveur pour
gérer ce rôle s’ouvre.

 Zone Résumé des fonctionnalités :

La zone Résumé des fonctionnalités de la fenêtre principale Gestionnaire de serveur affiche une
liste de toutes les fonctionnalités installées sur l’ordinateur.

Notez que le Gestionnaire de serveur de Windows Server 2008 est automatiquement chargé lors de
l’ouverture de session.

3. Configuration des paramètres TCP/IP

Ce TP va vous permettre de configurer les paramètres TCP/IP généraux de votre serveur Windows
Server 2008 puis de vérifier leur exactitude. Vous testerez ensuite le chargement et la liaison du
protocole TCP/IP.

Les opérations décrites précédemment dans le TP 1 vous ont déjà permis de configurer les paramètres
TCP/IP du serveur à l’aide du nouveau gestionnaire de serveur.

Cette fois-ci nous utilisons l’interface classique de Windows Server 2008.

Déclaration des paramètres

Page 26
Généralement, les serveurs sont configurés de manière statique. Cependant, ceci n’est pas toujours
vrai. En effet, il peut être intéressant de configurer plusieurs centaines ou milliers de serveurs situés
dans un datacenter à l’aide du protocole DHCP, en effectuant des réservations statiques des
configurations IP de chaque serveur. De cette manière, toutes les configurations IP des serveurs de la
salle machine sont globalement centralisées.

Configuration du protocole TCP/IP de votre serveur :

1.
Accédez au Centre de réseau et partage.
2.
Accédez aux propriétés de votre connexion réseau. Par défaut, celle-ci est nommée Connexion au réseau
local. Cliquez sur Voir le statut - Propriétés.
3.
Accédez aux propriétés du protocole TCP/IP et procédez aux déclarations ci- dessous. Remplacez n par la
valeur correspondant au numéro de votre serveur (par exemple, déclarez l’adresse IP 192.168.0.1 pour le
serveur dont le nom est S1) :
 Adresse IP : 192.168.0.n
 Masque de sous-réseau : 255.255.255.0
 Passerelle par défaut : 192.168.0.254
 Serveur DNS : 192.168.0.200
4.
Validez et fermez les différentes fenêtres ouvertes sur le bureau.

Il n’est pas nécessaire de configurer le protocole TCP/IP version 6, ni de prendre l’initiative de le désactiver.

Vérification de votre configuration TCP/IP depuis l’invite de commande

1.
Démarrez une invite de commandes en cliquant sur Démarrer - Exécuter et tapez cmd
2.
Pour afficher et vérifier que vos paramètres TCP/IP sont correctement configurés, tapez la commande
Ipconfig /all.
3.
Notez ci-dessous les informations affichées par la commande précédente :
Adresse IP de votre serveur :
Masque de sous-réseau :
Adresse physique de la carte réseau :
Type de nœud TCP/IP :
Nom d’hôte :
Suffixe DNS principal :
Client DHCP :
Client DNS :
Client WINS :

Test de connectivité

1.
Testez l’adresse de bouclage interne (loopback address) en tapant la commande : ping 127.0.0.1.
2.
Quel retour obtenez-vous ?
3.
Testez votre adresse TCP/IP en tapant la commande : ping 192.168.0.n où n représente le numéro de
votre serveur, tel que précisé précédemment.
4.
Quel retour obtenez-vous ?

4. Vérification des paramètres

Utilisation de Netdiag (Outils de support de Windows Server 2003)

Page 27
Vous allez utiliser la commande Netdiag pour vous assurer que les couches et services réseau de base
sont bien opérationnels. Cette commande permet de vérifier le bon fonctionnement des services réseau
et de diagnostiquer d’éventuels problèmes de connectivité.

Pour fonctionner, la commande Netdiag exige que le protocole TCP/IP soit chargé et lié sur au moins une
interface réseau.

1.
Démarrez une invite de commandes en cliquant sur Démarrer - Exécuter et en tapant cmd.
2.
Exécutez la commande Netdiag.
3.
Vérifiez que les tests de connectivité sont concluants. Dans le cas où certaines erreurs sont remontées,
interprétez les messages d’erreurs pour déterminer si vous devez ou non les considérer.

Vous pouvez par exemple déclarer une passerelle par défaut inexistante. Cette erreur sera remontée par la
commande Netdiag.

Utilisation de Netdiag

Vous allez utiliser la commande Dcdiag pour vous assurer que la promotion de votre serveur au rôle de
contrôleur de domaine est possible. Cette commande permet de vérifier le côté fonctionnel d’un certain
nombre de composants centraux de Windows Server 2008.

1.
Démarrez une invite de commande en cliquant sur Démarrer - Exécuter et en tapant cmd.
2.
Exécutez la commande : netdiag /test:dcpromo /dnsdomain :RootCorp.net /newforest

L’usage du paramètre /test:dcpromo permet de vous assurer qu’il serait possible de réaliser la
promotion souhaitée.

Vous obtiendrez en retour un checkup des conditions importantes concernant la création du domaine
racine de la forêt Rootcorp.net.

Pour plus d’informations sur Netdiag, faites une recherche dans l’aide en ligne de Windows Server 2003, sur
un ordinateur disposant des outils de support de Windows Server 2003.

Page 28
DNS : Concepts, architecture et administration

Pré-requis et objectifs
1. Pré-requis

Connaissances générales sur l’utilisation de Windows Server : utilisation de la console de gestion MMC.

Connaissances générales sur les méthodes et concepts d’administration des systèmes.

Connaissances générales sur la résolution des noms d’hôtes dans les réseaux TCP/IP.

2. Objectifs

À la fin de ce chapitre, vous serez en mesure de :

Comprendre le rôle et l’importance du système de nommage et de résolution de noms DNS au sein des
réseaux Windows avec les services de domaine Microsoft Active Directory.

Décrire les grands principes du service DNS tels que :

 L’espace de noms
 La hiérarchie DNS avec le domaine racine, les domaines de premier et deuxième niveaux.
 Les enregistrements de ressources (RR) du DNS.
 Les différents types de domaines, serveurs et zones DNS.
 La mise en œuvre des redirecteurs et indications de racine.
 Les transferts de zones AXFR et IXFR.
 Les zones dynamiques sécurisées et non sécurisées.
 L’intégration des zones DNS dans l’annuaire Active Directory.

Décrire les nouveautés des services DNS de Windows Server 2008 :

 Chargement des zones.


 Support des adresses IPv6.
 Support des RODC (Branch Office Zones)
 Nouvelles zones GlobalNames.
 Nouveautés de la partie cliente DNS de Windows Vista et sélection des contrôleurs de
domaine.

Respecter les bonnes pratiques de gestion du DNS.

Page 29
Introduction aux services de résolution de noms DNS
Ce chapitre introduit les mécanismes de résolution et de gestion des noms avec le système DNS, Domain
Name System.

Les objectifs sont importants puisqu’ils nous permettront de :

 comprendre les principes de la résolution des noms DNS ;


 comprendre et configurer les zones DNS ;
 comprendre la réplication et le transfert des zones DNS ;
 comprendre la problématique d’intégration des serveurs DNS Windows au sein d’une
infrastructure DNS existante et gérer les problèmes d’interopérabilité.

L’étape suivante consistera à étudier les fonctionnalités propres au service DNS de Windows Server 2003
et Windows Server 2008 lorsque l’intégration Active Directory est utilisée et qu’un domaine DNS offre ses
services pour assurer un fonctionnement normal de l’annuaire Active Directory.

1. Un peu d’histoire

Toute machine au sein d’un réseau TCP/IP doit posséder une adresse IP (Internet Protocol) qui sera
utilisée dans le cadre des communications vers les autres machines. Les services TCP/IP, outre les
fonctions inhérentes aux protocoles de transport et de routage entre les réseaux, ont été conçus pour
supporter des applications réparties à l’échelle de réseaux dont la taille peut atteindre celle de
l’Internet.

Nous savons aujourd’hui à quel point TCP/IP est essentiel. Pour s’en convaincre, il suffit de constater
l’effervescence qui caractérise Internet et la banalisation des ordinateurs Windows dans les entreprises
mais aussi, petit à petit, dans nos universités, écoles et foyers.

Toutes ces machines sont bien entendu capables de manipuler aisément les adresses IP. Par contre, il
est clair qu’il n’en est pas de même des utilisateurs que nous sommes.

Au commencement et bien avant que l’Internet que nous connaissons aujourd’hui n’existe, la
manipulation des adresses IP était déjà source de nombreux problèmes au sein du réseau ARPANET
(Advanced Research Project Agency Network). À cette époque, le NIC (Network Information Center) - à
ne pas confondre avec l’InterNic - avait la responsabilité de tenir à jour le fichier HOSTS.TXT. Les
utilisateurs du réseau ARPANET devaient ensuite, pour être capables de résoudre les noms de machines
en adresses IP, disposer de la liste la plus à jour possible en la téléchargeant à l’aide du protocole FTP
(File Transfer Protocol).

L’InterNic, évoqué plus haut, a pour objectif de fournir au public les informations concernant les fournisseurs
de services d’enregistrement de noms de domaines DNS sur Internet. Vous pouvez par l’intermédiaire du
site http://www.internic.net : accéder à la liste des organismes autorisés au niveau mondial à enregistrer les
noms de domaines DNS, leur transmettre toute remarque concernant d’éventuels problèmes
d’enregistrement de noms de domaine et accéder à des informations concernant les opérations DNS
notables qui peuvent avoir lieu au niveau de l’Internet.

Les tâches de coordination nécessaires au bon fonctionnement de l’Internet comprennent


principalement la gestion des adresses IP et des noms de domaine DNS. Jusqu’en 1998, c’est le
gouvernement américain et certains de ses organismes (Recherche et Département de la Défense -
DoD) qui assuraient les tâches de coordination de l’Internet. L’attribution des blocs d’adresses IP était
sous la responsabilité globale de l’IANA (Internet Assignement Numbers Authority), lequel était sous
contrat avec le gouvernement américain.

Concernant la gestion des noms de domaines de premier niveau tels que .net, .gov, ou .com (on parle
de gTLDs pour "generic Top Level Domains"), c’est la société Network Solutions Inc. qui en avait le
monopole.

En 1998, l’ICANN (Internet Corporation for Assigned Names and Numbers) est créé afin de coordonner
l’attribution de ces ressources au niveau mondial, la gestion réelle des domaines DNS étant déléguée à
des instances régionales situées sur chaque continent.

Page 30
Pour la gestion des noms de domaines, vous pouvez consulter à l’adresse ci-après la liste des instances
responsables de la gestion des noms de domaines au sein de chaque pays, http://www.iana.org/cctld/cctld-
whois. htm.

Par exemple, la zone DNS .fr est gérée par l’AFNIC (Association Française pour le Nommage Internet en
Coopération, http://www.nic.fr).

Pour plus de détails, vous pouvez visiter les sites de l’ICANN aux adresses suivantes :
http://www.dnso.icann.org et http://www.pso.icann.org.

La solution : Merci Dr Mockapetris !

Suite à cette première implémentation d’un système de nommage et de résolution des noms de
machines en adresses IP, il était évident qu’une solution plus "moderne" devait être mise en place.

C’est en 1983 que le Dr Paul V. Mockapetris - diplômé du réputé MIT (Massachusetts Institute of
Technology) - proposera les fondements des services DNS par le biais des RFC 882 et 883.

Les RFC 882 et 883 sont aujourd’hui obsolètes et ont été remplacés par les RFC 1034 et 1035, lesquels sont
toujours écrits par le Dr Paul Mockapetris. Le RFC 1034 est toujours d’actualité mais fait l’objet des mises à
jour contenues dans les RFC 1101, 1183, 1348, 1876, 1982, 2065, 2181, 2308 et 253. Le RFC 1035 est lui
aussi toujours d’actualité mais fait l’objet des mises à jour contenues dans les RFC 1101, 1183, 1348, 1876,
1982, 1995, 1996, 2065, 2136, 2181, 2137, 2308, 2535, 2845, 3425 et 3658. Vous pouvez rechercher et
consulter ces RFC sur le site : http://www.rfc-editor.org

2. Qu’est-ce que les services DNS ?

Comme expliqué plus haut, le DNS est le protocole standard de résolution de noms défini par l’IETF
(Internet Engineering Task Force). Il permet à des machines clientes de s’enregistrer et de résoudre
des noms de machines appartenant à des domaines DNS. Une fois le nom de la machine cible résolu, il
devient possible d’accéder à la machine ainsi qu’à ces ressources.

Le DNS est, par définition, constitué de trois composants principaux :

1.
L’espace de noms de domaines (Domain Namespace), lequel comprend les enregistrements de ressources
associés à cet espace. Les enregistrements de ressources sont appelés RR pour Resources Records et
clarifient le type de chaque enregistrement.
2.
Les serveurs de noms DNS (DNS Name Servers). Il s’agit de machines sur lesquelles s’exécute le processus
offrant le service "Serveur DNS". Ces serveurs hébergent tout ou partie de l’espace de nom géré ainsi que
les enregistrements de ressources. Ils assurent aussi - et surtout ! - le bon fonctionnement des résolutions
de noms initiées par les clients DNS.
3.
Les clients DNS (DNS Resolvers ou DNR). Il s’agit des machines devant invoquer un ou plusieurs serveurs
DNS. Ces machines doivent disposer d’un client leur permettant de solliciter un ou plusieurs serveurs DNS.

Les concepts de résolution des noms DNS vont nous amener à traiter les points suivants :

 la résolution des noms ;


 les requêtes de résolution directes et inversées ;
 les mécanismes de cache côté serveur DNS et côté client DNS.

Ce que nous allons découvrir :

 Le service DNS est basé sur la demande de résolutions (en anglais "Lookup Queries").
 Les serveurs de noms DNS aident à résoudre des demandes de résolution directes et
inversées.
 Les demandes de résolution directes permettent de mapper un nom DNS en adresse IP.
 Les demandes de résolution inverses permettent de mapper une adresse IP sur un nom DNS.
 Un serveur de nom DNS peut résoudre une demande pour une zone pour laquelle il fait
autorité.
 Si un serveur de nom DNS ne peut résoudre la demande, peut-être peut-il solliciter un autre
serveur DNS qui pourra l’aider à résoudre la requête.
Page 31
 Les serveurs de noms DNS savent cacher les résolutions réussies et ayant échoué pour
réduire les flux sur le réseau.
 Le service DNS utilise un modèle client/serveur.

3. Terminologie du système DNS

Le protocole DNS a été conçu pour gérer une problématique propre aux réseaux de machines
fonctionnant sous TCP/IP. Les points ci-dessous rappellent quelques principes fondamentaux :

 La résolution des noms DNS est le processus qui permet de résoudre un nom DNS en adresse
IP.
 Une adresse IP identifie chaque nœud devant communiquer à l’aide du protocole TCP/IP.
 Une adresse IP est une valeur sur 32 bits, segmentée en 4 mots de 8 bits chacun (4 octets) et
composée de deux parties :
 La partie la plus à gauche référence le réseau et est appelée Net ID ou adresse du
réseau. Elle permet d’identifier de manière unique un segment réseau au sein d’un
inter-réseau TCP/IP beaucoup plus vaste.
 La partie la plus à droite référence la machine hôte sur le réseau et est appelée
Host ID ou adresse de l’hôte. Elle permet d’identifier de manière unique un nœud
TCP/IP au sein d’un réseau donné.
 Les adresses IP, qui techniquement sont des valeurs binaires, sont exprimées en
notation décimale et séparées par des points.

a. L’espace de nom DNS (Domain Namespace)

L’espace de nommage du système DNS est implémenté sous la forme d’une hiérarchie de noms
implémentée par un arbre structuré. Le nom de cet arbre est par convention indéfini mais sera appelé
racine de l’espace et prendra la forme d’un point. Par exemple, le domaine microsoft.com est
réellement et techniquement nommé "microsoft.com.", donc terminé par le caractère (.).

Points clés :

 L’espace peut être composé d’une ou de plusieurs branches.


 Chaque branche peut être composée de N noms.
 Chaque nom d’hôte est limité à 63 caractères.
 Le nom complet d’un nœud situé dans l’espace de nommage DNS est appelé FQDN (Fully
Qualified Domain Name) ce qui signifie "nom de domaine pleinement qualifié".

Il est recommandé de respecter le RFC 1123, lequel définit les conventions de nommage suivantes :

 Utiliser les caractères A-Z, a-z,0 -9 et le caractère "-"


 Le FQDN ne doit pas excéder 255 caractères.

Autres points à retenir :

 Sous Windows 2000, Windows XP et Windows Vista, le nom de l’ordinateur est basé sur le
FQDN et permet d’en déduire le nom NetBIOS. Il est formé en rajoutant au Computer Name,
le suffixe DNS principal (Primary DNS Suffix), lequel est par défaut le nom du domaine
Active Directory auquel appartient la machine.

Bien que cette possibilité de changement ne soit pas une bonne pratique, sachez que le suffixe DNS principal
de l’ordinateur peut être différent du nom de domaine Active Directory.

 À l’inverse, sous Windows NT, c’est le nom NetBIOS qui sera utilisé pour former le nom
d’hôte (Hostname).

Page 32
Identification de l’ordinateur et FQDN

Le nom NetBIOS n’est plus contrôlable

Ces écrans montrent à quel point Windows s’appuie aujourd’hui sur l’espace de nommage DNS. Le
nom de l’ordinateur s’écrit en minuscules, à l’inverse du nom NetBIOS où seuls les caractères
majuscules sont autorisés.

Le nom complet de l’ordinateur est aussi très clairement signifié dans l’interface graphique (xp-
clientx.corp2003.corporate.net). Vous remarquerez aussi que l’interface ne montre pas directement le
nom NetBIOS. Pour y accéder, vous devrez passer par le bouton Autres.

Les systèmes tels que Windows 9x et Windows NT sont d’abord des machines NetBIOS, lesquelles peuvent
aussi s’appuyer sur le système de résolution DNS. Prêtez attention au fait que si sous Windows 2000,
Windows XP, Windows Server 2003, Windows Vista et Windows Server 2008, le nom d’ordinateur
(hostname) contrôle le nom NetBIOS dans la limite des 15 caractères majuscules autorisés dans le cadre de
l’interface NetBIOS, il n’en est pas de même sous Windows NT.

Attention ! Le fait qu’un contrôleur de domaine Windows NT dispose d’un nom NetBIOS et d’un nom
DNS (hostname) différents pourra être la cause de multiples problèmes de réplication de l’annuaire
après que la migration vers Active Directory ait eu lieu.

À propos des minuscules et majuscules : RFC 1034

Page 33
Les noms de domaine peuvent être enregistrés en minuscules, en majuscules ou encore avec toute
combinaison des deux. Toutefois, le RFC 1034 précise que, quelle que soit la façon dont le nom est
enregistré, toutes les opérations seront insensibles à la casse.

À propos de NetBIOS
Espace de noms et Interface de programmation

Le terme NetBIOS (Network Basic Input/Output System) peut prendre de multiples significations. En
effet, il peut s’agir des services d’enregistrement de noms sur le réseau NetBIOS, des méthodes de
résolution disponibles au sein de cet espace de nommage mais aussi de l’interface de programmation
nécessaire au bon fonctionnement des applications NetBIOS.

À propos de la désactivation de NetBIOS, notez qu’il n’est pas possible d’envisager la désactivation de
l’interface NetBIOS tant que le réseau exploite encore des applications s’appuyant tant sur les services de
résolution que sur l’interface de programmation NetBIOS.

Aussi, il est possible :

 qu’une application NetBIOS s’enregistre sur un réseau NetBIOS sur le protocole de transport
TCP/IP. Les postes clients s’appuieront sur les services de résolution de noms NetBIOS tels
que le WINS (Windows Internet Naming Service) pour localiser le service demandé sur la
machine cible. Par la suite, cette même application fera appel aux services de gestion de
sessions NetBIOS en utilisant les API NetBIOS offertes par le système d’exploitation. Elle
pourra aussi invoquer une autre interface réseau telle que les MSRPC (Remote Procedure
Call) ou bien encore l’interface Windows Sockets.
 qu’une application NetBIOS s’appuie sur les services de résolution de noms DNS. Dans ce
cas, il ne sera pas possible d’utiliser les codes de services associés aux applications
NetBIOS.

La commande nbtstat affiche les noms enregistrés sur le réseau NetBIOS

Pour faire simple, rappelez-vous que par rapport au modèle OSI (Open System Interconnection), les
services NetBIOS se situent :

 Au niveau 4, pour ce qui concerne les services de transport de données. On ne parlera pas
du niveau 3 dans la mesure où NetBIOS n’est pas un protocole routable, mais seulement
"source routable" sur les réseaux Token-Ring IBM. Ces services sont mis en œuvre grâce au

Page 34
protocole NetBEUI (NetBIOS Extended User Interface) développé par IBM et Microsoft en
1985. Ce protocole de bas niveau offre des services élémentaires en mode connecté et en
mode déconnecté.
 Au niveau 5, pour ce qui concerne les services de noms et de sessions. Ces services
génériques sont indispensables pour toute application répartie ou distribuée sur un réseau.
On retrouvera à ce niveau l’interface NetBT (NetBIOS over TCP/IP) qui a pour objet de
permettre la correspondance entre les noms et services NetBIOS et les adresses IP.
 Au niveau 7 du modèle pour ce qui concerne les applications qui s’appuient par exemple sur
les canaux nommés (named pipes). Dans ce cas, il s’agira de l’interface de programmation
NetBIOS.

Un peu d’histoire...

À l’heure d’Internet, NetBIOS est une technologie obsolète. On se rappellera que ses services
élémentaires mais fondamentaux auront permis le développement de milliers d’applications et ce,
avec une grande indépendance vis-à-vis des protocoles de transport. À l’époque, Windows NT s’est
appuyé sur cette interface pour pénétrer les réseaux de toute nature, grâce aux nombreux protocoles
de transport qu’il a supportés dès la première version, Windows NT 3.1 en 1993. Ainsi, le tandem
"Windows NT/NetBIOS" aura permis la mise en œuvre de serveurs d’applications compétitifs
facilement intégrables dans des réseaux utilisant des protocoles de transport tels que DECnet, OSI
TP4, IPX/SPX et bien sûr, TCP/IP.
Et après...

Le développement de Windows NT 5.0 qui s’appellera peu de temps avant sa sortie, Windows 2000, a
commencé en 1997 - date des premiers builds Alpha, c’est-à-dire à peine un an après la sortie de
Windows NT 4.0. La route aura été longue, mais les milliers de développeurs de l’équipe NT y seront
arrivés. Avec le recul, il est intéressant de remarquer que la stratégie "tout Internet" de Microsoft est
alors déjà très avancée : le successeur de NT 4.0 s’appuiera sur IP, DNS, LDAP et Kerberos.
Aujourd’hui, l’effort de Microsoft se porte sur les services Web, la gestion des documents, les services
de collaboration et la sécurité des systèmes, des applications et du système d’information dans son
ensemble.

b. Hiérarchie DNS et espace de noms Internet

Chaque nœud au sein de l’espace du DNS dispose d’un nom qui lui est propre. Ce nom doit toujours
respecter le RFC 1035, lequel définit l’ensemble des principes et bonnes pratiques du DNS. Tel que
nous l’avons déjà expliqué précédemment, le nom, aussi appelé label, ne doit pas dépasser 63
caractères pour un FQDN complet ne dépassant pas 255 caractères.

4. Le DNS : base de données distribuée

Nous venons de voir que le système de nommage du DNS nous permet de déployer un espace sur la
base d’une hiérarchie de noms de domaines. Maintenant, nous pouvons imaginer qu’avec un tel
système et à partir du moment où l’espace est découpé en plusieurs arbres et sous-arbres, il devient
aisé de distribuer techniquement l’espace DNS comme une base de données répartie.

En fait, employer une base de données répartie signifie que l’information de tout l’espace DNS est
stockée sur N machines, lesquelles peuvent être situées à n’importe quel emplacement du réseau.

Cette remarque est particulièrement vraie dans le cas de l’Internet. Dans le cas d’un réseau s’appuyant
sur un nommage privé (non Internet), l’information de l’espace DNS sera à l’échelle de ce réseau. De
plus, avec les mêmes principes que ceux qui sont appliqués pour le réseau Internet, et si le réseau
privé de l’entreprise est composé de multiples sites, il sera bien sûr nécessaire de prévoir une
disponibilité de l’espace DNS sur chacun des sites. Nous reviendrons sur ce point important lorsque
nous discuterons de la relation DNS/Active Directory.

Finalement, chaque serveur DNS maintient seulement une partie de la base de données de l’espace
DNS. La base de données "totale" est divisée en différentes parties appelées zones, chaque zone
correspondant à une partie de l’espace DNS, donc à un domaine ou un sous-domaine particulier. Nous
reviendrons sur ce point plus loin.

Les fichiers de zone pourront ensuite être répliqués vers de multiples serveurs à l’aide de ce que l’on
appelle des transferts de zones. Ainsi, nous pouvons représenter l’espace DNS de l’Internet de la
manière suivante :

Page 35
 Le domaine racine (.) est sollicité via les treize serveurs DNS de la racine. Ces serveurs
contiennent les informations qui permettent de localiser les serveurs DNS du premier niveau
tels que .com, .org, .net ou encore .fr.
 Notez que les serveurs de la racine ne contiennent pas toutes les informations sur les
domaines du premier niveau. Ils connaissent seulement les serveurs qui ont la responsabilité
de ces domaines.
 Avec le même principe, pour être capable de résoudre le nom d’un hôte situé dans le domaine
microsoft.com, il sera nécessaire d’envoyer une demande de résolution vers le domaine de
premier niveau .com (pour rappel, TLD - Top Level Domain), lequel n’est pas directement
capable de répondre à la demande mais pourra retourner les adresses des serveurs de noms
DNS qui, eux, font autorité sur le domaine de deuxième niveau microsoft.com.

Le schéma ci-après montre le processus de résolution de nom au sein de l’espace de noms hiérarchique
de l’Internet.

Processus lié à la demande de résolution de nom directe

Retenez les points suivants :

 Par définition, le système de résolution DNS offre un espace de noms hiérarchique et


distribué.
 Le système DNS dispose de plusieurs techniques pour mettre en œuvre un espace distribué. Il
est ainsi possible de déterminer quel serveur de l’espace possède l’information demandée. Les
mécanismes sont simples mais très puissants. Le système DNS est de par sa conception,
capable de prendre en charge des espaces de n’importe quelle taille, comme par exemple
l’Internet. Il est donc de fait très utilisé dans les réseaux privés des entreprises.
 Les moyens dont dispose le DNS pour réaliser un espace de noms distribué sont :
 La délégation de domaines.
 Les redirecteurs conditionnels ou non conditionnels.
 Les indications de racines.

Ces points sont abordés plus loin.

Page 36
Structure de l’espace DNS et hiérarchie des domaines

1. Le domaine racine

Il s’agit du plus haut point de l’arborescence, lequel représente un niveau ne portant pas de nom
particulier. On pourra aussi dire que la racine n’a pas de nom ou est de type "non nommée". Elle est
parfois affichée sous la forme de deux guillemets vides (""), indiquant une valeur nulle. Quoiqu’il en
soit, lorsqu’elle est utilisée dans un nom de domaine DNS, elle est indiquée par un point à droite (.)
pour indiquer que le nom est situé à la racine ou niveau supérieur de la hiérarchie du domaine. Le nom
de domaine DNS est alors considéré comme complet et désigne un emplacement exact de
l’arborescence des noms.

Un serveur DNS peut gérer le domaine racine ou non, tandis que d’autres serveurs DNS devront
s’appuyer sur un serveur DNS gérant le domaine racine pour pouvoir résoudre tout ou partie de
l’espace de noms DNS.

Avec les services DNS de Windows Server 2003 et Windows Server 2008, la zone racine représentée par le
(.) dans les zones de recherches directes n’est plus ajoutée automatiquement. Sous Windows 2000, la zone
racine (.) était automatiquement ajoutée lors de la première initialisation du serveur DNS, si le serveur
n’était pas capable de contacter les serveurs de la racine (Root Hints). Le fait de disposer de cette zone avait
pour effet négatif d’empêcher l’utilisation des redirecteurs ainsi que des serveurs de la racine Internet.
L’administrateur devra donc créer manuellement la zone racine (.), si nécessaire.

2. Les domaines de premier et deuxième niveau

Les domaines de premier niveau sont aussi appelés TLDs pour Top Level Domains. Ce premier niveau
dans la hiérarchie DNS - positionné au-dessous de la racine - permet de structurer l’espace de départ
en fonction du type d’organisation utilisant un nom ou aussi en fonction d’une région ou d’un pays.

La liste ci-dessous décrit ces domaines et leur rôle.

aero

L’usage de ce domaine de premier niveau est réservé à l’industrie aéronautique.

biz

L’usage de ce domaine de premier niveau est réservé aux grandes et petites et entreprises au niveau
mondial.

com

Page 37
L’usage de ce domaine de premier niveau est réservé aux entreprises à caractère commercial telles que
Microsoft, avec le domaine microsoft.com. Presque toutes les entreprises ont pour première fonction de
vendre leurs produits. De fait, vous pourrez constater plus loin dans ce chapitre à quel point la zone
.com est largement plus volumineuse que toutes les autres.

coop

Ce domaine de premier niveau est réservé à l’usage des écoles et universités.

gov

L’usage de ce domaine de premier niveau est réservé aux agences gouvernementales américaines.
Vous y retrouverez par exemple le site du FBI (U.S. Federal Bureau of Investigation -
http://www.fbi.gov/) et le site de la NASA (National Aeronautics and Space Administration -
http://www.nasa.gov/).

info

Ce domaine ne dispose d’aucune restriction particulière. Il est particulièrement axé sur la fourniture
d’informations sur la consommation mondiale.

int

Ce domaine est dédié aux autorités et autres organismes liés par des traités internationaux. Il accueille
par exemple le site de l’OTAN - North Atlantic Treaty Organisation - http://www.nato.int).

mil

Ce domaine est dédié à l’armée américaine. Vous y retrouverez par exemple le site de U.S. Air Force -
http://www.af.mil/.

museum

Ce domaine est réservé aux musées, organisations et personnes affiliées.

name

Domaine global à l’usage des individus.

net

Ce domaine est dédié aux machines des fournisseurs de réseau, organismes dédiés à l’Internet et
autres fournisseurs d’accès Internet (ISPs). On y retrouvera le bien connu http://www.internic.net/
pour l’ancien Internet Network Information Center (InterNIC).

org

Domaine de premier niveau dédié aux groupes et organisations à but non lucratif et non
gouvernementales.

pro

Un domaine de premier niveau pour des professionnels tels que les médecins, les avocats et les
comptables.

La gestion des zones du premier niveau est très volumineuse. Pour s’en convaincre, il suffit de
consulter quelques statistiques Internet.

Page 38
Les domaines de premier niveau

Les domaines de premier niveau sont gérés par des organismes tels que "Network Solutions" aux États-
Unis ou pour la France, Transpac, une filiale bien connue de France Télécom. Par définition, l’ensemble
de ces autorités appelées Registrars sont sous contrôle de l’ICANN.

L’Internet Corporation for Assigned Names and Numbers (ICANN) est une organisation de droit privé à
but non lucratif. Son personnel et ses membres viennent du monde entier. La fonction de l’ICANN est
fondamentale puisqu’elle est chargée d’allouer l’espace des adresses du protocole Internet (IP),
d’attribuer les identificateurs de protocole, de gérer le système de nom de domaines de premier niveau
(Top Level Domains) pour les codes génériques (gTLD) et les codes nationaux (ccTLD), et aussi
d’assurer les fonctions de gestion du système de serveurs racine (DNS Root Servers).

Pour plus d’informations sur la gestion des Registrars réalisée par l’ICANN, vous pouvez consulter l’adresse
http://www.icann.org/.

Les domaines de deuxième niveau et leurs sous-domaines

Les domaines de deuxième niveau sont des noms de longueur variable attribués à un individu ou d’une
organisation, pour une utilisation sur Internet. Ces noms sont toujours associés à un domaine de
premier niveau approprié, selon le type d’organisation ou l’emplacement géographique dans lequel le
nom est utilisé. Il peut s’agir par exemple du domaine de Microsoft Corporation dont le nom est
"microsoft.com".

Page 39
Les enregistrements de ressources
Une base de données DNS est composée d’un ou de plusieurs fichiers de zones, lesquels seront utilisés
par le serveur DNS. Chaque zone - représentée par un fichier distinct - contient un ensemble
d’enregistrements. Ces enregistrements, qui sont donc réellement stockés dans les zones DNS,
s’appellent des enregistrements de ressources ou encore RRs (pour Resources Records).

Finalement, un fichier de base de données de zone contient tous les enregistrements de ressources qui
décrivent le domaine et son contenu.

Le serveur DNS de Windows Server 2003 vous permet de supporter aujourd’hui les vingt-deux types
différents d’enregistrements de ressources.

Le tableau suivant donne les caractéristiques des enregistrements de ressources les plus communément
utilisés.

Type d’enregistrements de ressources (RRs) Description - Rôle

Identifie le serveur désigné primaire pour la zone. Cet


enregistrement permet aussi de gérer les paramètres de la zone
tels que les transferts de zone, les temps d’expiration sur la
Start of Authority (SOA)
zone et le TTL (Time to Live) par défaut des enregistrements.
Les types et rôles des différents enregistrements de ressources
du système DNS.

Name Server (NS) Identifie tous les serveurs désignés pour le domaine.

Identifie l’adresse IP d’un nom d’hôte spécifique. Cet


Host (A) enregistrement d’adresse IP de l’hôte mappe un nom de
domaine DNS complet vers une adresse IP version 4 de 32 bits.

Identifie les noms d’hôte par rapport à une adresse IP


Pointer (PTR) spécifique. Ces enregistrements sont stockés dans la zone de
recherche inversée.

Canonical Name (CNAME) Identifie un nom d’emprunt pour un hôte du domaine.

Identifie des serveurs de messagerie Internet. Cet


enregistrement est employé par d’autres serveurs de messagerie
Mail Exchanger (MX) pour localiser les serveurs de messagerie d’un domaine
particulier. Finalement, cet enregistrement très important
permet le routage des messages sur Internet.

Identifie un service offert au niveau du domaine Active


Directory. L’annuaire Active Directory fait un usage avancé de
Service Locator (SRV) cet enregistrement. Il permet notamment aux contrôleurs Active
Directory de répliquer l’annuaire et aux postes clients Windows
2000 et XP de localiser les contrôleurs de domaines.

Les enregistrements présentés dans ce tableau sont placés dans un ordre logique qui ne fait pas apparaître
le côté crucial - voire critique - des enregistrements vitaux nécessaires au bon fonctionnement de l’Active
Directory.

La relation forte qui existe entre Active Directory et le DNS sera présentée plus loin.

Pour plus d’informations sur formats et syntaxes des enregistrements de ressources pris en charge par les
services DNS de Windows Server 2008, consultez l’aide en ligne de Windows Server 2008 en cherchant
"Référence des enregistrements de ressources".

Page 40
Domaines, zones et serveurs DNS
Pour bien comprendre comment une infrastructure DNS doit être mise en œuvre techniquement, il est
important d’identifier les éléments qui la composent et la façon de les utiliser. Une fois ces points traités,
tout devient clair !

1. Domaines DNS et zones DNS

Comme toutes les technologies, le système DNS introduit ses propres concepts assortis de sa propre
terminologie. En effet, la nature et les différences qui peuvent exister entre les domaines DNS et les
zones DNS doivent être bien assimilés. Ainsi, vous éviterez les pièges, erreurs de conception et
problèmes de fonctionnement des résolutions au sein de votre espace DNS. Un domaine DNS est une
partie de l’espace de noms au sens logique du terme, tandis qu’une zone est vraiment l’information
stockée concernant tout ou partie de l’espace de noms. Dans le premier cas, il s’agit d’un élément de
structuration logique, tandis que dans le deuxième cas, il s’agit d’un espace de stockage physique
composé d’une partie de l’espace de noms. Par exemple, une société possède un domaine DNS appelé
Corp2003.Corporate.net. Pour mettre en œuvre ce domaine "logique", il nous faudra implémenter
"physiquement" le domaine, via un fichier de base de données de zone, en anglais a database zone file.

Domaines DNS et zones

La figure précédente illustre les éléments suivants :

 Le domaine corporate.com est mis en œuvre à l’aide du fichier de base de données de zone
corporate.com.dns.
 Le domaine europe.corporate.com est mis en œuvre à l’aide du fichier de base de données de
zone europe.corporate.com.dns.
 Le domaine europe.corporate.com contient les sous-domaines be, de et nl (pour la Belgique,
l’Allemagne et les Pays-Bas).
 Le domaine fr.europe.corporate.com est mis en œuvre à l’aide du fichier de base de données
de zone fr.europe.corporate.com.dns
 Le domaine fr.europe.corporate.com contient les sous-domaines apps, research et paris.

De fait, les domaines DNS et zones DNS permettent et respectent les points listés ci-dessous :

 L’organisation de l’espace de noms DNS : tel que cela apparaît sur la figure précédente, les
zones hébergent les informations propres à un espace contigu de domaines.
 Deux domaines disjoints nécessitent forcément deux zones.
 Les serveurs DNS ne répliquent pas des domaines mais des zones, lesquelles contiennent un
ou plusieurs domaines et sous-domaines.
 La division d’un espace de domaines volumineux en plusieurs zones vous permettra d’éviter
d’importants trafics liés à la réplication puisque seules les zones DNS sont répliquées.
 Le découpage d’un espace logique en plusieurs morceaux (donc des zones) permet, tout en
conservant l’espace logique, de diviser une zone en plusieurs et ainsi d’en distribuer la
réplication.

Page 41
Ce découpage rend aussi possible la délégation de gestion des zones à différentes entités d’administration et
de responsabilités.

Le fait qu’un espace contigu soit mis en œuvre à l’aide de plusieurs zones implique la déclaration des
délégations qui permettront de faire descendre les résolutions - du haut vers le bas de l’espace. Ce
point fondamental est traité ci-après.

2. Zones et fichiers de zones

Nous venons de voir que le système DNS permet de diviser un espace de noms donné en zones. Ces
zones stockent des informations relatives à un ou plusieurs domaines DNS. Pour chaque nom de
domaine DNS d’une zone, la zone devient la source de référence (ou d’autorité) d’informations sur ce
domaine.

Au départ, une zone est un fichier de base de données pour un seul nom de domaine DNS. Par défaut,
un fichier de base de données de zone est situé dans le répertoire %system root%\System32\dns\.

Pour les zones standard (donc non intégrées à Active Directory), le nommage par défaut des fichiers est
très pratique puisque le nom généré sera simplement "nom du domaine géré.dns".

Dans le cas où d’autres domaines seraient ajoutés en dessous du domaine géré par la zone, il sera
possible de "ranger" le nouveau sous-domaine au sein de la même zone ou bien de créer une nouvelle
zone. Il conviendra donc de décider si un nouveau sous-domaine ajouté à une zone sera inclus au sein
de la zone originale, ou à l’extérieur de celle-ci. Dans ce cas, nous verrons plus loin que la gestion dudit
sous-domaine est dite déléguée à une autre zone.

Le schéma qui suit montre la mise en œuvre de plusieurs zones pour le domaine de deuxième niveau,
corporate.com. Au départ, le domaine corporate.com existe grâce à la zone corporate.com.

La suite de l’espace de noms nécessite la mise en œuvre de plusieurs sous-domaines. Ces sous-
domaines pourront alors être inclus dans la zone ou délégués au sein d’une autre zone.

La configuration illustrée montre :

 La zone dédiée à la racine. Lorsque cette zone est créée sur un serveur DNS Windows 2000
Server, Windows Server 2003 ou Windows Server 2008, le fichier Root.dns est créé dans le
répertoire %Systemroot%\system32\dns\.
 La zone dédiée au domaine Internet de premier niveau, .com.
 La zone dédiée au domaine Internet de deuxième niveau, corporate.com. Cette zone contient
uniquement ce domaine ainsi que les informations de délégation indiquant les serveurs DNS
qui font autorité pour le sous-domaine europe.corporate.com mis en délégation.

Page 42
 La zone dédiée au domaine Internet europe.corporate.com. Cette zone contient les
informations de ce domaine ainsi que les informations des sous-domaines be, de et
nl.europe.corporate.com. Le domaine europe.corporate.com contient aussi une délégation
indiquant les serveurs DNS qui font autorité pour le sous-domaine fr.europe. corporate.com.
 La zone dédiée au domaine Internet fr.europe.corporate.com. Cette zone contient les
informations de ce domaine ainsi que les informations des sous-domaines apps, research et
paris.fr.europe.corporate.com.

Retenez les points suivants :

 Lorsqu’un serveur DNS joue le rôle de serveur racine, c’est-à-dire qu’il gère la zone (.) via le
fichier de base de données de zone Root.dns, alors le serveur ne peut ni s’appuyer sur les
redirecteurs, ni faire appel à des serveurs racine.
 La mise en place d’un nouveau domaine de deuxième niveau nécessite la création d’un
nouveau fichier de base de données de zone.
 Si un sous-domaine de la zone europe.corporate.com n’est pas délégué, toutes les données
du sous-domaine sont conservées dans la zone europe.corporate.com.
 Dans le système DNS, on appelle domaine toute arborescence ou sous-arborescence se
trouvant dans l’espace de noms de domaine.

Il existe deux types de zones :

Les zones de recherches directes : une zone de recherches directes est employée principalement
pour résoudre des noms d’hôte en adresses IP. Ce sera le cas chaque fois qu’un client DNS
questionnera le serveur DNS pour localiser l’adresse IP d’un hôte sur le réseau. Au sein des zones, les
enregistrements de ressources de type A fournissent cette fonctionnalité. La zone de recherches
directes inclut aussi les enregistrements de ressources de type SOA et NS indispensables au bon
fonctionnement de la zone. Accessoirement, nous retrouverons aussi les enregistrements nécessaires
au bon fonctionnement de certains services CNAME pour les alias, MX pour les connecteurs SMTP des
serveurs de messagerie, SRV pour les enregistrements de services Active Directory ou de toute autre
application.

Les zones de recherches inversées : ce type de zone permet de résoudre, non pas un hôte en
adresse IP, mais une adresse IP en hôte. La demande de résolution (ou requête) est donc inversée.
Une telle demande de résolution ne peut être exécutée que lorsque l’adresse IP est connue, mais pas le
nom. Comme toutes les zones, cette zone dispose des enregistrements de SOA et de NS nécessaires.
Par contre, elle ne contiendra pas d’enregistrements de type A, mais l’équivalent inversé. Ces
enregistrements appelés enregistrements de type PTR (pointeur), permettent de faire pointer telle
ou telle adresse IP vers tel ou tel nom DNS pleinement qualifié.

Les zones de recherches inversées sont nommées de manière particulière. En fait, le nom de la zone
doit être en rapport avec les adresses IP demandées en résolution. Donc, de fait, le nom de la zone
devra faire apparaître le numéro du réseau ou du sous-réseau IP. D’un point de vue de son
implémentation sur Internet mais aussi sur les réseaux privés, le nom du domaine devra
obligatoirement commencer par in-addr.arpa. Il s’agit d’un nom spécialement réservé dans l’espace
DNS pour spécifier que la demande porte sur une zone de recherches inversées et pas sur une zone de
recherches directes.

Ensuite, le nom de la zone est complété par l’adresse du réseau, mais à l’envers. Ainsi, pour les
adresses IP qui concerneraient le réseau 192.168.1.0, il sera nécessaire de déclarer une zone de
recherches inversées dont le nom devra être 1.168.192.in-addr.arpa.

La console de gestion MMC (Microsoft Management Console) du service DNS est très intuitive. Vous y
retrouverez toutes les fonctions essentielles d’un service DNS.

Page 43
Zones de recherches directes, inversées, indications de racines et redirecteurs

Fichiers de configuration d’un serveur DNS

Les fichiers suivants permettent de prendre en charge la configuration des serveurs DNS.

Le fichier de Démarrage : ce fichier est appelé Fichier de configuration de démarrage BIND et


n’est par défaut pas créé par la console de gestion du service DNS. Cependant, en tant qu’option de
configuration du service Serveur DNS, il peut être copié à partir d’un autre serveur exécutant une
implémentation DNS de type BIND (Berkeley Internet Name Domain).

Sous Windows, le support de ce fichier n’a aucun intérêt pour le fonctionnement normal du service Serveur
DNS. Il sera utile de fonctionner dans ce mode uniquement pendant la phase de migration d’une
configuration DNS en provenance d’un système DNS BIND.

Le fichier cache.dns : ce fichier est appelé fichier cache. Il permet, au démarrage du service
Serveur DNS, le préchargement des enregistrements de ressources dans le cache du serveur DNS. Les
serveurs DNS utilisent ce fichier pour localiser les serveurs racine présents sur votre réseau ou
directement sur Internet. Notez que, par défaut, ce fichier contient les enregistrements de ressources
DNS qui fournissent le cache local du serveur avec les adresses des serveurs racine présents sur
Internet.

Pour les serveurs DNS fonctionnant exclusivement sur votre réseau interne, la console DNS peut
transférer et donc remplacer le contenu de ce fichier par les serveurs racine internes de votre réseau.
Cette opération sera possible à condition qu’ils soient accessibles via le réseau lorsque vous installez et
que vous configurez de nouveaux serveurs DNS. Sa mise à jour est possible grâce à la console DNS,
depuis l’onglet Indications racine situé dans les propriétés du serveur concerné.

Accès au domaine racine (.) via le fichier cache.dns et résolutions : si l’on considère le cas du réseau
Internet, il est connu que le nombre de résolutions vers les serveurs racine est important. Cependant, ce
point peut être relativisé puisque les noms d’hôtes ne sont généralement pas résolus à ce niveau. Le rôle
essentiel du fichier des indications de serveurs racine cache.dns est simplement de permettre la redirection
des résolutions de noms vers d’autres serveurs de référence pour les domaines et sous-domaines situés
sous la racine.

Le fichier de la zone racine Root.dns : ce fichier est visible sur un serveur DNS lorsque celui-ci est
configuré en tant que serveur racine de votre réseau. Il s’agit d’un fichier de zone classique. Sa seule
particularité réside dans le fait qu’il gère la zone (.), laquelle est située au plus haut de l’espace de
noms DNS.

Les fichiers de zones nom_zone.dns : chaque zone standard créée nécessitera son propre fichier de
zone quelque soit le type de zone (principale ou secondaire). Ces fichiers sont placés dans le dossier
\System32\dns du serveur. Bien entendu, les fichiers de ce type ne sont pas créés ni utilisés pour les
zones principales intégrées à Active Directory, lesquelles sont stockées dans la base de données Active
Directory.

Le fait que le fichier de zone existe dans le répertoire \System32\dns signifie qu’il ne peut s’agir d’une zone
intégrée à Active Directory. À l’inverse, une zone intégrée à l’annuaire Active Directory ne sera pas visible
sous la forme d’un fichier dans le répertoire \System32\dns.

Page 44
La console MMC de gestion du DNS vous donne la possibilité de changer à loisir le type de zone. Ainsi,
lorsqu’une zone DNS intégrée à Active Directory devient une zone primaire standard, les informations
nécessaires sont extraites de l’annuaire et intégrées au sein d’un nouveau fichier de zone. L’opération
inverse aura pour effet d’intégrer dans Active Directory tous les enregistrements de ressources
contenus dans le fichier de zone et de supprimer ce dernier du répertoire \System32\dns.

Structure d’un fichier de zone

Le détail du fichier de base de données de zone pour la zone corpnet.corporate.net est présenté ci-
après.

La structure d’un fichier de zone est expliquée ci-dessous avec les différents types d’enregistrements
nécessaires.

La ligne @ IN SOA booster2003.corp2003.corporate.com hostmaster. corp2003.corporate.net suivie des


différentes périodicités permet de fixer le comportement de la zone en terme de réplication. Le
caractère @ permet de pointer sur "le domaine courant" sachant que le domaine ou la zone en question
est aussi spécifié en commentaire en haut du fichier.

L’enregistrement de ressource SOA (Start of Authority) est toujours le premier enregistrement déclaré
dans une zone standard. Il permet de spécifier le serveur DNS original ou qui joue actuellement le rôle
de serveur principal pour la zone.

Cet enregistrement de ressource est également utilisé pour stocker des propriétés très importantes
telles que les informations de version (en anglais, le Serial Number) et les délais qui affectent le
renouvellement ou l’expiration des enregistrements de la zone et aussi de la zone elle-même. Ces
propriétés affecteront la périodicité des transferts entre les serveurs agissant en tant que serveurs de
noms de la zone.

Les serveurs de noms d’une zone sont aussi appelés serveurs de référence de la zone.

L’enregistrement de ressource SOA contient les informations suivantes :

Serveur principal (propriétaire) : ce champ désigne le nom d’hôte du serveur DNS principal de la
zone.

Responsable : ce champ désigne l’adresse électronique du responsable de l’administration de la zone.


Notez que dans cette adresse électronique, un point (.) est utilisé à la place du signe (@).

Le numéro de série : ce champ désigne le numéro de version ou de révision du fichier de zone. Cette
valeur augmente automatiquement de 1 chaque fois qu’un enregistrement de ressource de la zone est
modifié. Il est indispensable que cette valeur change pour que la réplication des modifications partielles
- ou totale - de la zone puisse se produire.

Page 45
Intervalle d’actualisation : ce champ désigne le délai (en secondes) qu’un serveur DNS secondaire
doit respecter avant d’interroger sa source de la zone pour tenter de renouveler la zone. Lorsque le
délai d’actualisation expire, le serveur DNS secondaire demande à sa source une copie de
l’enregistrement SOA actuel pour la zone. Le serveur DNS secondaire compare ensuite le numéro de
série de l’enregistrement SOA actuel du serveur source (comme indiqué dans la réponse) avec son
propre enregistrement SOA local. Si les deux valeurs sont différentes, alors le serveur DNS secondaire
demande un transfert de zone pour le serveur DNS principal. Notez que la valeur par défaut est de 900
secondes, soit 15 minutes.

Intervalle avant nouvelle tentative : ce champ désigne le délai (en secondes) qu’un serveur
secondaire doit respecter avant de retenter un transfert de zone après un échec. Cette valeur est
généralement plus courte que l’intervalle d’actualisation. Notez que la valeur par défaut est de 600
secondes, soit 10 minutes.

Intervalle d’expiration : ce champ est particulièrement important puisqu’il désigne le délai (en
secondes) qui précède l’expiration de la zone d’un serveur secondaire et qui suit un intervalle
d’actualisation pendant lequel la zone n’a pas été actualisée ou mise à jour. Le passage de la zone à
l’état "expiré" se produit car les données locales sont alors considérées comme non fiables. Le serveur
DNS est alors non répondant pour la zone. La valeur par défaut est de 86 400 secondes, soit 24 heures.

Durée de vie (TTL, Time-To-Live) minimale par défaut : ce champ désigne la durée de vie par
défaut de la zone et la valeur de l’intervalle de mise en cache des réponses DNS. La valeur par défaut
est de 3600 secondes (1 heure).

Si une valeur TTL individuelle est attribuée et appliquée à un enregistrement de ressource spécifique utilisé
dans la zone, elle annule et remplace le TTL minimum défini par défaut au niveau de l’enregistrement SOA.

L’enregistrement de ressource NS contient les informations suivantes :

L’enregistrement de ressource de type serveur de noms (NS) peut être utilisé de deux façons pour
désigner des serveurs de référence pour un nom de domaine DNS :

 Il permet de désigner les serveurs de référence pour le domaine de telle sorte que ces
serveurs soient communiqués à ceux qui demandent des informations sur ce domaine.
 Il permet aussi de désigner les serveurs DNS de référence pour les sous-domaines qui
seraient "délégués à l’extérieur de la zone". Dans ce cas, l’enregistrement de NS joue le rôle
de pointeurs vers les serveurs DNS qui prennent en charge la gestion des sous-domaines dont
la gestion est déléguée plus bas.

L’enregistrement de NS est donc utilisé pour mapper un nom de domaine DNS vers le nom des hôtes
qui exécutent des serveurs DNS. L’enregistrement de NS s’utilise très simplement tel que précisé dans
l’exemple suivant.

Par exemple, la ligne dom1.company.com. IN NS srv-dns1.dom1.company. com indique que le serveur


DNS srv-dns1.dom1.company.com agira en tant que serveur DNS de référence pour le domaine
dom1.company.com.

Utilisation du caractère @ avec l’enregistrement de type NS :

 La ligne @ NS booster2003.corp2003.corporate.net signifie que le serveur DNS


booster2003.corp2003.corporate.net agit en tant que serveur DNS de référence pour le
domaine concerné. Dans ce cas, la valeur du domaine est celle fixée en commentaire en tête
du fichier, laquelle est celle déclarée dans le fichier de démarrage sur un serveur DNS de type
BIND ou dans le registre d’un serveur DNS Windows 2000 ou Windows Server 2003.

Le fichier BOOT est décrit plus loin dans la section Options de démarrage du serveur DNS.

À propos des noms de serveurs DNS

Le fait que le nom "montre" que le serveur DNS lui-même fait partie du même domaine n’a aucune
conséquence. En effet, un serveur DNS donné peut gérer de multiples zones DNS.

Le nommage du serveur DNS sera principalement influencé par la position dudit serveur au sein du
réseau Intranet ou au sein du réseau Internet. Dans le cas d’un fournisseur de services Internet, il est
clair qu’il ne peut y avoir aucune dépendance vis-à-vis des zones hébergées, lesquelles appartiennent à
des tiers. À l’inverse, lorsque le serveur DNS est positionné dans l’entreprise, il est probable que son
nom complet sera dérivé du ou des espaces de noms existant dans l’entreprise.

Page 46
Quoi qu’il en soit, un serveur DNS doit être déclaré au sein d’une zone DNS à l’aide d’un nom de
domaine complètement qualifié (FQDN) pour pouvoir agir en tant qu’un hôte désigné comme serveur de
noms pour la dite zone. Ensuite, le nom doit correspondre à un enregistrement de ressource d’hôte (A)
valide dans l’espace de noms de domaines DNS.

Notez que par défaut, la console MMC DNS crée automatiquement un enregistrement de ressource NS
unique pour le serveur DNS local sur lequel la zone a été initialement créée.

3. Noms de domaines DNS et noms de domaines Active Directory

L’espace qui sera offert à Active Directory peut être dérivé de l’espace Internet ou être complètement
dissocié. Par exemple, l’entreprise corporate.com peut disposer d’un domaine Active Directory portant
le même nom, ou bien créer la rupture de différentes manières. Les points ci-dessus donnent les
grandes stratégies de nommage mais nous reverrons ces points en détail plus loin.

Les différentes ruptures d’espace sont brièvement présentées ci-dessous :

 privnet.corporate.com, pour implémenter un sous-domaine de l’espace existant officiellement


déclaré.
 privnet.corp.com, pour implémenter un nouveau domaine dérivé du nom officiel Internet
(corp) et un sous-domaine dédié à la racine Active Directory (privnet).
 privnet.corporate.local, pour implémenter un nouveau domaine dérivé du nom officiel Internet
(corp ou corporate), un sous-domaine dédié à la racine Active Directory (privnet) et un espace
de résolution privé en utilisant comme domaine de premier niveau le domaine .local.

À propos des noms de domaines DNS et Active Directory : bien que ce ne soit pas recommandé, Active
Directory n’impose pas l’usage d’un domaine de niveau supérieur valide tel que .com ou .net. Notez
cependant que la bonne pratique est de respecter les TLDs (Top Level Domains) bien connus.

Les noms de domaines DNS utilisés pour nommer les domaines Active Directory ne coïncident pas
forcément avec l’intégralité de l’espace DNS. De fait, même s’ils se ressemblent, ils ne doivent donc pas
être confondus.

Le tableau ci-dessous montre une telle configuration.

Nom de domaine DNS Domaine Active Directory

Domaine (.) Non recommandé.

company.com OUI. Ce domaine peut jouer le rôle de racine Active Directory.

emea.company.com OUI. (Europe Middle East and Africa).

asia.company.com OUI.

us.partners.com OUI. Ce domaine est réservé aux partenaires US.

OUI. Ce domaine est réservé aux partenaires de l’union


eu.partners.com
européenne.

Le domaine partners.com existe au niveau DNS mais n’existe pas en tant que domaine Active Directory.

Page 47
Le DNS offre ses services à l’Active Directory pour le nommage des noms de domaines et des noms
d’hôtes.

Par conséquent, tout domaine Active Directory est forcément un domaine DNS, mais tout
domaine DNS n’est pas forcément un domaine Active Directory.

4. Types de zones et serveurs de noms DNS

La configuration d’un serveur DNS dépendra du rôle que vous souhaitez affecter au serveur en fonction
de multiples paramètres tels que la topologie du réseau, la structure et la taille de l’espace DNS que
vous souhaitez prendre en charge.

Quelles que soient vos contraintes, les composants de base de toute infrastructure DNS seront basés
sur les trois types de zones présentés ci-après :

 les zones primaires ;


 les zones secondaires ;
 les zones de stub.

En fonction des cas, le fait d’utiliser plusieurs zones pourra faciliter la mise en œuvre d’une solution qui
au départ paraissait très complexe. À titre d’analogie, nous pouvons imaginer la gigantesque
problématique de gestion des services DNS à l’échelle de l’Internet !

Heureusement, les millions de zones qui composent l’espace DNS de l’Internet et les concepts de
délégation rendent cet immense réseau administrable et pleinement opérationnel à l’échelle de la
planète !

a. Serveurs de noms et zones primaires

Un serveur primaire (on dit aussi parfois principal) pour une zone donnée est le seul serveur
disposant d’une copie de la zone disponible en écriture. Ce point signifie que toute modification de la
zone nécessitera un accès au seul et unique serveur primaire pour la dite zone.

Une fois les opérations de modification apportées, les données seront automatiquement répliquées
vers le ou les autres serveurs DNS agissant en tant que serveurs de noms DNS secondaires pour la
zone.Ces opérations de réplication de zones sont bien sûr fondamentales pour assurer la disponibilité
d’une zone sur de multiples serveurs DNS locaux et aussi distants.

Les zones principales peuvent être de deux types :

Zones principales standard : lorsqu’il s’agit d’une zone principale standard, un seul serveur DNS
pourra héberger et charger la copie principale de la zone. Aucun autre serveur principal
supplémentaire ne sera autorisé pour cette zone. De plus, seul le serveur DNS principal pour la zone
sera autorisé à accepter des mises à jour dynamiques et à traiter des modifications qui concernent la
zone. Ce modèle fait apparaître un point de défaillance puisque l’indisponibilité du serveur assurant la
Page 48
gestion de la zone principale aura pour effet de ne plus permettre de mises à jour de la zone, tant via
les fonctions d’administration que via le protocole de mise à jour dynamique des enregistrements DNS
(DDNS, Dynamic DNS). Toutefois, les autres serveurs DNS jouant le rôle de secondaires pour la zone,
pourront continuer de répondre aux requêtes des clients, jusqu’à expiration de celle-ci.

L’expiration des zones secondaires est expliquée plus loin.

Zones principales intégrées dans Active Directory : vous pouvez créer une zone principale dont
les données et autres paramètres seront stockés dans l’annuaire Active Directory. Dans le même
ordre d’idée, vous pouvez aussi intégrer une zone primaire existante dans l’Active Directory en
modifiant le type de la zone sur le serveur principal d’origine.

Cet écran montre comment changer le type d’une zone DNS. Les zones de type zone principale et
zone de stub peuvent être créées normalement ou au sein de l’Active Directory. Très logiquement, les
zones secondaires ne le peuvent pas puisqu’elles n’ont aucune signification vis-à-vis des mécanismes
supportés par l’Active Directory.

Avantage majeur de l’intégration Active Directory

Nous verrons plus loin que les mécanismes supportés par les services de domaine Active Directory
permettent aux serveurs DNS fonctionnant sous Windows 2000 Server, Windows Server 2003 et
Windows Server 2008 de résoudre la quasi-totalité des problématiques propres au DNS.

Cependant, nous pouvons d’ores et déjà remarquer que l’intégration Active Directory nous permet de
disposer de plusieurs serveurs principaux pour la même zone. Cette configuration est possible car les
contrôleurs Active Directory sont - par définition - égaux et disponibles en lecture et aussi en écriture.

Ainsi, il en est de même pour tous les serveurs DNS qui profitent de ce mécanisme et peuvent donc
supporter le mode de mise à jour dynamique DNS pour une zone donnée.

De cette manière, le point de défaillance constitué par le serveur DNS primaire pour une zone est
supprimé grâce au fait que tous les contrôleurs de domaine agissent comme de multiples serveurs
primaires.

L’interface graphique de la console de gestion du DNS vous permet de consulter, modifier les zones
gérées.

Page 49
Exemple des propriétés d’une zone : états, type, nature de la réplication de la zone et support
des mises à jour dynamiques

Vous pouvez ajouter sur tout serveur DNS une nouvelle zone principale chaque fois que des domaines
ou des sous-domaines supplémentaires sont requis dans votre espace de noms DNS.

Vous pouvez effectuer d’autres tâches de configuration des zones en fonction de vos besoins.

Retenez les poins suivants :

 Le serveur DNS principal d’une zone joue le rôle de point de mise à jour pour la zone. Toute
nouvelle zone créée est une zone principale.
 Lors de l’utilisation des zones principales standard, il n’est pas recommandé qu’un autre
serveur DNS soit configuré pour agir en tant que serveur principal pour une zone déjà
existante. Même s’il semble que cela puisse fonctionner, ce fonctionnement n’est pas pris en
charge. En effet, il pourrait générer des erreurs ou des incohérences entre les serveurs qui
chargent des versions différentes de la même zone.
 Il existe deux types de zones principales : les zones principales standard et les zones
principales intégrées dans Active Directory. L’intégration des zones dans Active Directory est
traitée dans le chapitre Intégration des zones DNS dans Active Directory.

b. Serveurs de noms et zones secondaires

Un serveur secondaire pour une zone donnée possède une copie non modifiable du fichier de base de
données de la zone. Le seul moyen qui permette de mettre à jour les données et informations de zone
consiste à réaliser un transfert de zone à partir de l’un des serveurs agissant en tant que source pour
la zone.

Le serveur de nom secondaire pour une zone donnée connaît sa source de contenu par une
déclaration de l’adresse IP du serveur DNS jouant le rôle de serveur DNS maître. Les points ci-
dessous résument les possibilités qui permettent aux serveurs DNS d’échanger des informations :

 Le serveur maître peut être le serveur primaire.


 Le serveur maître peut aussi être tout serveur DNS secondaire pour la zone.
Page 50
 Le serveur maître peut aussi être tout serveur DNS faisant autorité pour une zone intégrée à
Active Directory.
 Un serveur secondaire peut s’appuyer sur plusieurs serveurs maîtres.
 La topologie est totalement libre. Ainsi, le serveur A peut être maître pour le serveur B, qui
peut être maître pour le serveur C et ainsi de suite.

Toutes les opérations de création, suppression, modification et réplication des zones sont réalisables
via la commande dnscmd.exe ou via la console MMC du DNS.

Une fois la zone secondaire créée, la dernière étape consiste à déclarer les adresses IP des serveurs
maîtres qui peuvent être contactés en vue d’obtenir des informations d’enregistrement mises à jour
concernant cette zone. Cette zone de liste ne s’affiche que si le type de zone est défini comme étant
secondaire ou stub. Lorsqu’une zone du serveur doit être répliquée, le serveur DNS utilise cette liste
pour contacter un serveur maître et obtenir une mise à jour de la zone. Si la zone a été modifiée et
qu’une mise à jour est requise, un transfert partiel ou total de la zone est alors effectué. Notez que
cette liste vous permet aussi de contrôler l’ordre dans lequel les serveurs maîtres seront sollicités.

Les premières versions des serveurs DNS réalisaient des transferts de zone complets.

Le RFC 1995 publié en 1996 implémente un mécanisme plus efficace de transfert de zone. Il s’agit du
transfert de zone incrémentiel par lequel seules les modifications sont répliquées vers le ou les
serveurs secondaires pour la zone.

Autorisation des transferts de zones uniquement vers les serveurs listés dans l’onglet Serveurs
de noms pour la zone support.corp2003.corporate.net

À l’inverse des zones standard où les transferts de zones sont activés par défaut vers les serveurs
listés dans l’onglet Serveurs de noms, les transferts de zones ne sont pas autorisés sur les zones
intégrées à Active Directory.

En fait, ce point est normal dans la mesure où les zones intégrées à Active Directory se répliquent
grâce à la réplication Active Directory.

Dans le cas où une zone Active Directory devrait être disponible en tant que zone secondaire sur un
serveur non contrôleur de domaine, il sera nécessaire d’autoriser ces serveurs à répliquer la zone
avec les contrôleurs de domaine Windows 2000 Server, Windows Server 2003 ou Windows Server
2008.
Page 51
Le RFC 1996 publié en 1996 implémente une autre amélioration du processus de transfert de zone. Il
décrit un mécanisme de notifications qui permet au serveur primaire d’alerter les serveurs
secondaires quand des changements ont été réalisés sur la zone.

L’écran qui suit montre que cette méthode permet de notifier le ou les serveurs DNS spécifiés par telle
ou telle adresse IP ou, plus simplement, tous les serveurs DNS spécifiés comme jouant le rôle de
serveurs de noms pour la zone.

Comme en ce qui concerne les transferts de zones, la fonction de notification est activée pour tous les
serveurs listés sous l’onglet Serveurs de noms lorsqu’il s’agit de zones primaires ou secondaires
standard. Rappelez-vous qu’il n’en est pas de même lorsqu’il s’agit de zones intégrées à Active
Directory.Toujours concernant les zones standard, vous pourrez optimiser les communications sur les
liens réseaux surchargés en déclarant uniquement les serveurs que vous souhaitez notifier.

Dans le cas des réseaux surchargés, la solution la plus optimisée consistera à utiliser la réplication
Active Directory.

Dans le cas où vous décideriez de ne pas utiliser la fonction de notification présentée plus haut, alors
le serveur secondaire ne pourra compter que sur les propriétés de l’enregistrement de SOA.

Page 52
Paramètres de réplication d’une zone grâce à l’enregistrement de SOA

Tel que spécifié sur l’écran précédent, le serveur secondaire entrera en contact avec le serveur de
nom primaire pour la zone :

 La première fois sur la base de l’intervalle d’actualisation, c’est-à-dire au bout de 15


minutes.
 Ensuite, sur la base de l’intervalle avant nouvelle tentative, c’est-à-dire toutes les 10
minutes, et ce, pendant au maximum une journée, valeur de la période d’expiration de la
zone. Notez que ces paramètres de réplication sont définis sur l’enregistrement de SOA au
niveau de chaque zone.

L’adresse de messagerie de la personne responsable ne doit pas contenir le symbole habituel @. En effet, ce
caractère est considéré par le DNS comme un symbole générique qui signifie la zone elle-même.

La durée de vie de l’enregistrement de SOA (valeur par défaut de 01H00) est automatiquement transmise à
tous les enregistrements de ressources de la zone, à moins qu’une valeur spécifique ne soit affectée de
manière particulière à un enregistrement donné.

N’oubliez pas que lorsqu’un serveur Windows 2000 Server, Windows Server 2003 ou Windows Server
2008 gère des zones DNS intégrées dans Active Directory, les transferts de zone sont pris en charge
par le moteur de réplication de l’Active Directory.

Le composant ayant en charge les opérations de réplication entre contrôleurs de domaine est appelé DRA
(Directory Replication Agent). Ce composant est particulièrement important, et peut nécessiter une
surveillance. De nombreux compteurs de performance sont exposés dans l’analyseur de performances sous
la rubrique DirectoryServices.

Les paramètres de SOA sont donc uniquement utiles et utilisables pour les serveurs secondaires de la
zone. En effet, une zone intégrée dans Active Directory devra être répliquée à la fois vers des
serveurs supportant l’intégration Active Directory et aussi vers des serveurs DNS standard supportant
uniquement les mécanismes de réplication traditionnels (c’est-à-dire complets et incrémentiels).

Page 53
c. Types de transferts de zones DNS

Nous venons de voir que les zones DNS sont maintenues à un état de mise à jour cohérent grâce à
l’enregistrement de SOA défini au niveau de la zone principale.

Les serveurs DNS disposant d’une zone secondaire respectent les paramètres de rafraîchissement du
SOA. De plus, ils peuvent aussi être notifiés à l’aide du protocole DNS NOTIFY défini dans le RFC 1996
"A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)".

Nous allons découvrir plus loin que les transferts de zones peuvent être réalisés de différentes
manières.

Transfert de zone initial

Lorsqu’un nouveau serveur DNS est déclaré pour jouer le rôle de serveur secondaire pour une zone
donnée, il négocie un transfert de zone complet (AXFR) de manière à obtenir une copie complète des
enregistrements de ressources pour la zone.

Les anciennes versions de serveurs DNS, telles que l’implémentation sous NT 4.0, prennent en charge
uniquement les transferts de zones complets.

Transferts de zone incrémentiels et serveurs BIND Unix

Concernant les transferts de zones incrémentiels sur plate-forme Unix, notez que les premières
versions réellement opérationnelles nécessitent une version de type BIND (Berkeley Internet Name
Domain) 8.2.3.

Les versions BIND 9.x fonctionnent correctement avec des serveurs Windows 2000, Windows Server
2003, Windows Server 2008 et aussi les anciennes versions BIND 8.2.3.

Sur les plates-formes Unix qui utilisent un serveur DNS de type BIND, il est recommandé que les
modifications réalisées sur la zone soient réalisées en mode mise à jour dynamique.

Dans ce cas, c’est le client DNS dynamique qui effectue l’opération de création ou de mise à jour de
l’enregistrement de ressource. Ensuite, le serveur DNS prendra en charge la gestion du numéro de
version de cet enregistrement pour les réplications et mises à jour ultérieures. Cela signifie que pour
profiter au mieux des transferts de zones incrémentiels (IXFR - Incremental Transfer), il faudra éviter
d’éditer directement les fichiers de zones.

Cette remarque concerne uniquement les implémentations BIND. Les serveurs DNS Windows 2000,
Windows Server 2003 et Windows Server 2008 s’appuient sur les transferts de zones incrémentiels
lorsque les opérations sont réalisées à partir de la console d’administration MMC du DNS ou bien en
profitant de la réplication Active Directory qui par définition réplique sur objets, attributs et valeurs.

Le stockage des zones DNS dans l’annuaire Active Directory est traité en détail dans le chapitre 3 -
Intégration des zones DNS dans Active Directory.

Vérification du transfert de zone incrémentiel

Quelle que soit la méthode de transfert de zone utilisée (AXFR ou IXFR), la première chose réalisée
par le serveur DNS consiste à vérifier s’il est nécessaire d’effectuer ou non un transfert de zone. Ce
contrôle est réalisé en fonction de la valeur de l’intervalle d’actualisation sur l’enregistrement de
ressource de type SOA (Start of Authority) dont la valeur par défaut est fixée à 15 minutes.

Pour pouvoir déterminer s’il est nécessaire ou non d’initier un transfert de zone, le serveur DNS
secondaire pour la zone considérée vérifie la valeur du numéro de série, à partir de l’enregistrement
de ressource SOA. Dans le cas où les deux versions sont identiques, alors aucun transfert n’est
effectué.

Si, par contre, le numéro de série de la zone est plus élevé sur le serveur maître que sur le serveur
secondaire, alors un transfert est réalisé. Si le serveur maître dispose d’un historique des
changements incrémentiels, alors le protocole IXFR sera négocié.

Évidemment, le processus de transfert incrémentiel défini dans le RFC 1995 génère un trafic réseau
beaucoup moins élevé. Un autre avantage concerne la rapidité de l’opération de réplication puisque
seules les modifications transitent entre les deux partenaires.

Quand un transfert de zone peut-il se produire ?

 Lorsque l’intervalle d’actualisation de la zone arrive à expiration (c’est-à-dire par défaut


toutes les 15 minutes).

Page 54
 Lorsqu’un serveur secondaire est averti par son serveur maître que la zone a changé. Les
notifications sont implémentées par le RFC 1996.
 Lorsque le service Serveur DNS est démarré sur un serveur secondaire de la zone.
 Lorsque la console DNS est utilisée sur un serveur secondaire de la zone pour lancer
manuellement un transfert de zone à partir de son serveur maître.

Transferts de zones : points généraux et ports TCP/IP et trames

Retenez les points suivants :

 Il n’est pas possible de configurer de liste de notification pour une zone de stub. Les zones
de stub sont traitées plus loin dans ce chapitre (Zones de stub).
 La notification DNS devrait être utilisée uniquement pour avertir les serveurs fonctionnant
en tant que serveurs secondaires pour la zone. En effet, les zones intégrées à Active
Directory sont répliquées par Active Directory qui dispose de ses propres mécanismes de
notification.
 L’utilisation des notifications avec des zones DNS intégrées à Active Directory peut dégrader
les performances du système en créant des requêtes de transfert supplémentaires pour la
zone mise à jour, alors que ce n’est pas nécessaire.

Notez que les trafics liés aux résolutions et réplications DNS sont faibles en comparaison des trafics
générés par les utilisateurs.

Le protocole DNS utilise le port 53 en TCP et UDP. Le détail des opérations réalisées sur chaque
transport (TCP ou UDP) est précisé ci-dessous :

Port Source UDP 53 vers la destination sur le même port

Le protocole "User Datagram Protocol" (protocole de type non connecté) est principalement utilisé
pour les demandes de résolution entre un client DNS et le serveur DNS sollicité. Cependant, si la
réponse dépasse un certain délai, alors le client DNS (la partie DNR) réitérera sa demande de
résolution via TCP, toujours sur le port 53. Par définition, le protocole de transport UDP est certes
rapide, mais il ne garantit pas que les données envoyées seront bien reçues.

Le protocole "Transport Control Protocol" (protocole de type connecté) est utilisé lors de requêtes plus
longues telles que les transferts de zones. À l’inverse du protocole UDP, le protocole TCP garantit que
les données envoyées seront bien reçues.

Lors de la configuration d’un firewall, veillez à autoriser les trafics UDP et TCP 53. En effet, le fait de ne
déclarer que l’un des deux protocoles de transport provoquera un dysfonctionnement aléatoire des services
DNS.

d. Serveurs de cache et serveurs DNS

Par définition, un serveur de cache ne contrôle ni ne gère aucune zone. Il se contente de cacher
toutes les résolutions de noms qu’il accomplit. Un serveur de cache pourra être utilisé lorsque, par
exemple, la bande passante disponible reliant un site à un autre site est insuffisante pour envisager la
réplication d’une ou de plusieurs zones.

Puisque le serveur de cache ne dispose d’aucune zone, il est clair qu’il n’y a aucun trafic de transfert
de zone DNS. Par défaut, le serveur de cache mémorise pendant une heure toutes les résolutions
réussies.

Finalement, un serveur DNS gérant des zones (primaires, secondaires, Active Directory) est par
nature aussi un serveur de cache. En fait, la seule différence est que les serveurs "de cache" ne
disposent d’aucune information de zone.

L’affichage détaillé vous permet de visualiser le contenu du cache du serveur DNS. Il s’active via un
clic droit sur l’objet serveur DNS puis Affichage/Affichage détaillé.

Dans le cas où une information cachée deviendrait invalide mais toujours active en cache, vous aurez
la possibilité de supprimer l’enregistrement. Notez qu’il n’est pas possible de modifier une information
"cachée". La seule opération autorisée est la suppression.

5. Mise en œuvre des zones standard : bonnes pratiques

Page 55
Quelle que soit la technologie utilisée (Apple, IBM, Novell, Microsoft, systèmes Unix) la mise en œuvre
de domaines DNS - et a fortiori des domaines DNS dans le cadre d’une infrastructure Active Directory !
- nécessite le respect d’un certain nombre de bonnes pratiques.

Vous retrouverez ci-après les points indispensables et autres bonnes pratiques à respecter.

Considérations propres aux serveurs et zones DNS

Utilisez au minimum deux serveurs DNS pour chaque zone de l’espace. Donc, pour chaque zone DNS,
vous devez disposer au minimum d’une zone principale standard et d’un serveur secondaire pour la
zone.

Pour les zones principales intégrées dans l’annuaire Active Directory, vous pourrez vous appuyer
exclusivement sur des serveurs Windows jouant le rôle de contrôleurs de domaine Active Directory.
Cette solution est considérée comme "la" bonne pratique puisque le service DNS tant nécessaire à
l’infrastructure de domaines profite alors des fonctions de redondance et de tolérance de pannes
inhérentes aux contrôleurs de domaine Active Directory.

Les serveurs secondaires vous permettront de répartir le trafic de requêtes DNS dans certaines parties
du réseau où une zone serait particulièrement utilisée.

Les serveurs secondaires assureront une disponibilité totale de la zone, en dehors de la possibilité d’en
modifier le contenu. Dans le cas où le serveur primaire pour la zone serait indisponible de manière
prolongée, vous aurez malgré tout la possibilité de "promouvoir la zone" d’un serveur secondaire
défaillant en primaire dans l’attente que le serveur principal original soit à nouveau disponible.

Statut de la zone europe.corp2003.corporate.net (état expiré) et modification du type de zone

Page 56
Modification du type de zone de secondaire en principale

Une zone dont l’état est A expiré devient non répondante. Le changement du type de la zone de secondaire
en principale permet de rendre la zone autonome. De fait, la zone passera à l’état En cours d’exécution et
sera à nouveau opérationnelle.

Positionnement des serveurs DNS

Pour optimiser les flux générés par les résolutions DNS, les serveurs secondaires doivent être installés
le plus près possible des clients. Dans le cas où un élément du réseau (routeur, firewall, éléments
actifs) pourrait être un point de défaillance pour contacter le serveur DNS par défaut, faites en sorte de
déclarer un autre serveur DNS. De cette manière, un élément défaillant ne perturbera pas les
résolutions.

Dans le cas des services de domaine Active Directory, il est fréquent de considérer les services
d’infrastructure comme un élément formant un tout. Ainsi, chaque site devrait disposer de "ses propres
services d’infrastructure", c’est-à-dire un contrôleur de domaine, un serveur DNS, un catalogue global et
pourquoi pas, un serveur faisant office de DFS (Distributed File System) racine, si le DFS est utilisé sur le
site. Cette liste de services n’est bien sûr pas exhaustive, mais vous pouvez d’ores et déjà considérer que de
tels services sont par définition des services d’infrastructure et, de fait, peuvent facilement être cumulés sur
le même serveur. Ce serveur sera alors appelé serveur d’infrastructure.

Influence des emplacements par rapport aux transferts de zones

Les flux pourront varier considérablement entre une configuration mettant en œuvre des transferts de
zones complets (AXFR - All Transfer) et incrémentiels (IXFR). Faites attention au fait que les transferts
IXFR peuvent échouer.

Réplication des zones de recherches inversées et nombre de serveurs DNS

La question qui se pose concerne le nombre de zones et le nombre d’enregistrements par zone qu’il
faudra répliquer sur les N serveurs DNS. Quoiqu’il en soit, vous remarquerez qu’il y a autant de noms
inscrits que d’adresses IP associées. De plus, les bonnes pratiques du DNS nous incitent à mettre en
place les zones de recherches inversées.

Donc, la problématique peut être minimisée et la question peut être réduite à ce qui suit : est-il
judicieux de répliquer sur tous les serveurs disposant de zones de recherches directes, les zones de
recherches inversées ?

Le constat est que les serveurs secondaires sont principalement utilisés pour les zones de recherches
directes. Il semble qu’en général, un serveur secondaire pour une zone de recherche inversée n’est pas
utilisé à l’extérieur du réseau et du sous-réseau qui concerne la zone indirecte. Ce point est
principalement dû au fait que la part la plus importante des trafics entre les machines clientes et les
serveurs a lieu sur le même réseau ou sous-réseau IP.

Page 57
La bonne pratique peut donc être de limiter le nombre de serveurs secondaires pour les zones de
recherches inversées ou bien d’en limiter les trafics en utilisant des zones intégrées Active Directory
pour profiter des réplications compressées, incrémentales, sécurisées et contrôlées par la topologie de
réplication de l’Active Directory.

Le stockage des zones DNS dans l’annuaire Active Directory est traité en détail dans le chapitre Intégration
des zones DNS dans Active Directory.

6. Délégation des zones

Ce mécanisme puissant permet la mise en place d’espaces de domaines quasiment infinis. Le plus bel
exemple à citer qui utilise la délégation est le réseau Internet. Chaque domaine acheté est bien
entendu une zone dont la gestion est déléguée à un tiers responsable.

Ainsi, la délégation des zones DNS implique nécessairement une division de l’espace de noms en une ou
plusieurs parties, lesquelles peuvent ensuite être stockées, distribuées et répliquées vers d’autres
serveurs DNS.

Pour rappel, nous avons vu précédemment que l’utilisation de zones supplémentaires permettait de
répondre aux besoins suivants :

 Déporter la gestion d’une partie de votre espace de noms à un autre emplacement


géographique ou à une autre autorité d’administration.
 Diviser une zone particulièrement volumineuse en plusieurs zones plus petites pour répartir
les trafics entre différentes régions géographiques du réseau.
 Diviser un espace composé de n domaines DNS en plusieurs zones pour implémenter une
meilleure tolérance de panne en cas de défaillance de la zone.

Le point le plus important pour réaliser la mise en place de la délégation d’une zone consiste à ce que
soient déclarés les enregistrements de délégation.

Ces enregistrements joueront le rôle de "pointeurs" vers les serveurs DNS faisant autorité pour
résoudre les noms appartenant aux sous-domaines délégués.

Pour illustrer cette technique, nous pouvons nous baser sur l’exemple présenté ci-après.

Enregistrements de délégation dans le fichier de zone corporate.net.dns

Au départ, l’entreprise met en œuvre un domaine nommé corporate.net. Comme à chaque fois, le
domaine est implémenté sous la forme d’une zone hébergée par un ou plusieurs serveurs DNS. Ces
serveurs peuvent être situés tant sur Internet que sur l’intranet de l’entreprise, sachant que le concept
de délégation est rigoureusement dans ces deux parties du réseau.

Une zone de type primaire sera généralement créée, et de fait, le fichier de base de données de la zone
nommé corporate.net.dns sera placé dans le répertoire %Systemroot\ system32\dns.

Ensuite, il convient de disposer des enregistrements qui permettront de localiser le sous- domaine en
question. Dans notre exemple, il faut qu’il soit possible d’en référer aux serveurs faisant autorité pour
le domaine DNS corpnet.corporate.net.

Page 58
Vous pourrez déclarer ces enregistrements en rajoutant les enregistrements nécessaires dans le fichier
de zone de la zone corporate.net - tel que spécifié ci-après - ou utiliser les assistants de la console de
gestion du service DNS.

Localisation des serveurs de référence pour la zone corpnet.corporate.net à l’aide des


enregistrements de ressources de types NS et A

Les déclarations présentes dans le fichier montrent que le sous-domaine corpnet.corporate.net est géré
par quatre serveurs DNS, lesquels sont situés sur quatre sous-réseaux différents. De cette manière, il
est possible de résoudre le contenu du sous-domaine corpnet.corporate.net sur les quatre points
géographiques.

Finalement, il ne reste plus qu’à s’assurer qu’il est possible de résoudre ces noms de serveurs DNS.

Résolution des noms des serveurs DNS

Lors de l’attribution de serveurs avec des noms d’hôtes dans la même zone, les enregistrements de
ressources A (adresse IP) correspondants sont idéalement utilisés.

Pour les serveurs spécifiés en utilisant un enregistrement de ressource comme partie d’une délégation
de zone à un autre sous-domaine ou si, plus simplement le nom complet était différent, alors les noms
de ces machines seront appelés des noms hors zone.

Résolution des noms des serveurs DNS hors zone

Pour la résolution des noms hors zone, les enregistrements de ressources A pour les serveurs hors zone
spécifiés seront alors obligatoires. Notez que lorsque des enregistrements de type NS et A hors zone
sont nécessaires pour réaliser une délégation, ils sont appelés enregistrements par requêtes
successives. Ce cas est relativement classique et n’a donc rien d’atypique.

Page 59
Propriétés du sous-domaine corpnet.corporate.net

L’écran précédent montre que le domaine corpnet.corporate.net est géré par quatre serveurs DNS
situés dans des domaines ou sous-domaines différents du domaine contenant les enregistrements de
délégation.

À propos du FQDN de l’enregistrement de NS et des enregistrements de A, l’interface graphique peut mettre


en évidence les adresses IP récupérées via une requête DNS. Dans ce cas, une étoile apparaîtra à côté de
l’adresse IP.

Nous venons de voir que la délégation des zones permettait la mise en œuvre d’un espace logique
physiquement distribué en de multiples points du réseau. Les délégations permettent la résolution des
domaines directement inférieurs, donc de faire descendre les demandes de résolution. À l’inverse, pour
changer ou remonter dans l’espace de résolution, il sera nécessaire de remonter au plus haut de la
hiérarchie, c’est-à-dire jusqu’au domaine racine (.) grâce à l’utilisation des indications de racine.

7. Utilisation des redirecteurs

Généralement, un redirecteur est un serveur DNS configuré pour rediriger les requêtes DNS concernant
des noms DNS externes vers des serveurs DNS situés hors du réseau de l’entreprise. Cependant, notez
qu’il est aussi possible de rediriger les requêtes pour un domaine non pris en charge mais situé dans le
réseau privé de l’entreprise.

Pour qu’un serveur DNS joue le rôle de redirecteur, il faut que les autres serveurs DNS du réseau
redirigent les requêtes qu’ils ne peuvent résoudre localement vers ce serveur particulier.

De cette manière, le redirecteur vous permettra de gérer la résolution des noms situés hors de votre
réseau, c’est-à-dire principalement sur Internet. La figure suivante montre comment les redirecteurs
sont sélectionnés et transmettent les requêtes de noms externes vers l’Internet.

Page 60
Utilisation des redirecteurs entre les réseaux intranet et l’Internet

Comme vous pouvez le voir, le serveur DNS est particulièrement important puisqu’il joue un rôle tant
au niveau des résolutions internes qu’externes. Les points qui suivent traitent de la connectivité
Internet, du bon usage des redirecteurs ainsi que de l’éventuelle désactivation de requêtes récursives.

Exposition du réseau privé sur Internet

Lorsqu’il n’y a pas de serveur DNS spécialement désigné comme redirecteur, tous les serveurs DNS
peuvent envoyer des requêtes à l’extérieur du réseau en utilisant leurs indications de serveurs racine.

S’il est vrai que les indications de racine permettent de résoudre l’intégralité de l’espace géré,
l’inconvénient est que cette méthode de résolution aura pour effet de générer un volume
supplémentaire de trafic. Dans le cas d’une connexion Internet lente ou saturée, cette configuration
sera à la fois inefficace et coûteuse en terme de bande passante consommée.

Attention : les demandes de résolution non satisfaites - par exemple, dans le cas d’une panne d’un serveur
DNS interne - pourraient avoir comme conséquence d’exposer sur Internet des informations DNS internes
qui peuvent être confidentielles.

Le bon usage des redirecteurs pour optimiser les résolutions DNS

Si vous mettez en œuvre un serveur DNS en tant que redirecteur, alors vous rendez ce serveur
responsable de la gestion des résolutions externes et vous pourrez bénéficier des avantages suivants :

 L’exposition de votre réseau est supprimée puisque seules les résolutions non résolues en
interne seront dirigées vers le redirecteur puis sur Internet.
 Le redirecteur jouera le rôle de serveur de cache dans la mesure où toutes les requêtes DNS
externes du réseau seront résolues par son intermédiaire. En peu de temps, le redirecteur
sera capable de résoudre la plus grande partie des requêtes DNS externes en exploitant
directement son cache, ce qui aura pour effet de réduire d’autant les trafics de résolution vers
Internet.
 Dans le cas d’une connexion Internet surchargée, l’utilisation du cache du redirecteur
permettra aussi d’améliorer le temps de réponse pour les clients DNS.
Page 61
Comportement des serveurs DNS avec ou sans l’usage d’un redirecteur

Un serveur DNS ne se comporte pas de la même manière selon qu’il est ou non configuré pour utiliser
un redirecteur. Lorsqu’un serveur DNS est configuré pour utiliser un redirecteur, alors il se comporte
comme suit :

 Lorsqu’il reçoit une requête, le serveur DNS essaie de la résoudre à l’aide des zones
principales et secondaires qu’il héberge et aussi sur la base des résolutions déjà présentes
dans son cache.
 S’il ne parvient pas à résoudre la requête avec ces données, alors il l’envoie au serveur DNS
désigné comme redirecteur. Pour disposer des redirecteurs toujours disponibles, vous avez la
possibilité de déclarer plusieurs redirecteurs, d’en fixer l’ordre de sélection dans une liste,
ainsi que le délai d’attente qui provoquera l’usage d’un autre redirecteur.
 Le serveur DNS attend un instant la réponse du redirecteur avant d’essayer de contacter les
serveurs DNS indiqués dans ses indications de racine.

Comme vous pouvez le constater à l’étape 3, les résolutions ayant échoué sont d’abord décalées vers le
redirecteur avant d’être renvoyées vers les indications de racine. Normalement, les indications de
racine devraient être des serveurs internes.

Redirecteurs et types de requêtes DNS

Habituellement, lorsqu’un serveur DNS transmet une demande de résolution à un autre serveur DNS, il
s’agit d’une requête itérative.

Par contre, lorsqu’un serveur DNS transmet une requête à un redirecteur, il se comporte comme un
simple client et transmet à ce dernier une requête récursive. De fait, le serveur DNS - jouant le rôle
d’un simple client DNS - attend que la requête soit résolue.

Lorsque des délégations de zones sont configurées, la référence normale à une zone peut aléatoirement
échouer si le serveur DNS est aussi configuré pour utiliser des redirecteurs.

8. Zones de stub

Une zone de stub est une copie d’une zone contenant uniquement les enregistrements de ressources
nécessaires pour identifier les serveurs DNS faisant autorité pour la dite zone. Ce type de zone est
utilisé pour veiller à ce qu’un serveur DNS hébergeant une zone parent sache quels serveurs DNS font
autorité sur sa zone enfant.

De cette manière, l’efficacité de résolutions est maintenue.

Faites attention au fait que les zones de stub sont uniquement prises en charge sur les serveurs DNS
Windows Server 2003, Windows Server 2008 et les serveurs DNS BIND modernes.

Les zones de stub ne sont pas supportées sur les serveurs DNS fonctionnant sous Windows NT 4.0 et
Windows 2000.

a. Contenu d’une zone de stub

Comme expliqué précédemment, une zone de stub contient un sous-ensemble des données de zone
composé uniquement de l’enregistrement de SOA (Start of Authority) ainsi que des enregistrements
de NS (Name Server) et de A. Ces derniers enregistrements, appelés Glue records, permettent de
déterminer directement au sein de la zone les adresses IP des serveurs de noms (NS).

En fait, une zone de stub joue le rôle de table de pointeurs en permettant de localiser directement le
ou les serveurs de noms faisant autorité pour telle ou telle zone.

La création d’une zone de stub nécessite que les adresses TCP/IP d’un ou plusieurs serveurs maîtres
soient déclarées. Ces déclarations seront utilisées - comme cela est le cas pour les zones secondaires
- pour mettre à jour la zone de stub.

Les serveurs maîtres associés à une zone de stub sont un ou plusieurs serveurs DNS qui font autorité
pour la zone enfant. En général, il s’agit du serveur DNS qui héberge la zone principale pour le
domaine délégué.

Page 62
b. Avantages des zones de stub

Les zones de stub offrent de nombreux avantages, notamment vis-à-vis des délégations de zone
traditionnelles. Les points présentés ci-dessous vous inciteront certainement à utiliser les zones de
stub :

 Les informations relatives aux zones déléguées sont maintenues dynamiquement au sein de
la zone de stub.

La déclaration des enregistrements nécessaires à la mise en délégation d’un sous-domaine est une
information qui est susceptible d’évoluer en fonction de la politique d’administration définie au niveau de la
zone déléguée. Il est donc clair qu’il peut être judicieux de planifier la modification des délégations en zones
de stub.

 Les résolutions de noms sont nettement améliorées.


 L’administration des zones DNS est simplifiée.

Attention : les zones de stub n’ont pas le même objectif que les zones secondaires. En effet, une zone
secondaire contient tous les enregistrements tandis qu’une zone de stub ne contient que les enregistrements
SOA, NS et A de type Glue records.

Les zones de stub ne doivent pas être utilisées pour remplacer des zones secondaires, lesquelles permettent
une véritable redondance ainsi qu’une répartition de la charge des résolutions.

Suppression de la délégation et création d’une zone de stub

Le problème exposé est résolu en créant sur le serveur DNS faisant autorité sur la zone parent
company.com, une zone de stub qui correspond au sous-domaine mis en délégation,
europe.company.com. De cette manière, les administrateurs de la zone parent pourront s’appuyer sur
les serveurs maîtres déclarés pour rester informés des éventuels changements de configuration
concernant les serveurs DNS faisant ou non autorité sur la zone enfant mise en délégation.

c. Mise à jour des zones de stub

Les mises à jour des zones de stub fonctionnent sur le même principe que les mises à jour des zones
DNS secondaires.

Lors des mises à jour de la zone de stub

Le serveur DNS interroge le serveur maître pour demander des enregistrements de mêmes types que
ceux demandés à l’étape précédente. De la même manière que dans le cas des zones DNS
secondaires, l’intervalle d’actualisation de l’enregistrement de ressource SOA conditionne alors le
déclenchement (ou non) du transfert de zone qui provoquera la mise à jour.

Expiration des zones de stub

L’échec répété de nouvelles tentatives de mise à jour à partir du serveur maître peut atteindre la
valeur du paramètre d’expiration spécifié sur l’enregistrement de SOA. Lorsque ce délai sera atteint,
alors le statut de la zone de stub passera à l’état expiré et le serveur DNS cessera alors de répondre à
toute demande de résolution sur la zone.

d. Opérations sur les zones de stub

Les opérations relatives aux zones de stub sont analogues aux opérations qui concernent les zones
secondaires. La grande différence concerne le stockage. Par définition, une zone secondaire ne peut
être stockée au sein de l’annuaire Active Directory tandis qu’une zone de stub le peut.

Les opérations disponibles sur une zone de stub sont réalisables à l’aide de la console MMC de gestion
du DNS :

Page 63
Charger à nouveau : la zone de stub sera rechargée à partir du stockage local du serveur DNS
possédant une copie de la zone de stub.

Transfert à partir du maître : cette opération vous permet de forcer le serveur DNS hébergeant la
zone de stub à vérifier si le numéro de série (ou numéro de version) de l’enregistrement de SOA de la
zone a changé, puis à effectuer un transfert de zone à partir du serveur maître de la zone de stub, si
nécessaire.

Rechargement à partir du maître : la zone de stub sera rechargée à l’aide d’un transfert de zone à
partir du serveur maître et ce, quelle que soit la valeur du numéro de série indiqué sur
l’enregistrement de SOA. Cette opération est bien sûr très utile dans le cas où une zone de stub serait
en situation de défaut et refuserait de se synchroniser normalement.

Utilisation de la commande DNSCMD pour recharger une zone défaillante

La commande dnscmd dispose de tous les paramètres pour réaliser toutes les opérations disponibles
dans la console de gestion MMC du DNS. Vous trouverez ci-dessous deux opérations importantes
réalisées à l’aide cette commande. La première opération purge le cache des résolutions réalisées par
le serveur DNS tandis que la deuxième recharge la zone défaillante :

La commande DNSCMD est une commande système de Windows Server 2008.

Sur les systèmes fonctionnant sous Windows Server 2003, l’installation de cet outil est réalisée en
installant les Outils de support à partir du répertoire \Support Tools du CD-Rom de Windows Server
2003. Pour obtenir de l’aide sur l’utilisation de cette commande, tapez dnscmd /? à l’invite de
commandes ou utilisez l’aide des outils de support de Windows.

Pour plus d’informations sur la commande dnscmd, cherchez "Administration du serveur à l’aide de Dnscmd"
dans l’aide en ligne de Windows Server 2008. Vous y trouverez de nombreux exemples utiles qui vous
permettront d’écrire des scripts en vue d’automatiser la gestion et la mise à jour de la configuration de vos
serveurs DNS.

9. Redirecteurs, zones de stub et délégation : bonnes pratiques

Bien que différents systèmes et méthodes de résolution semblent donner les mêmes résultats, il existe
de subtiles différences entre ces méthodes. L’usage de telle ou telle méthode plutôt qu’une autre
dépendra des circonstances.

Page 64
C’est la raison pour laquelle il est très important de bien voir les différences qui les caractérisent pour
les utiliser de manière appropriée.

Tous ces mécanismes font l’objet de RFCs standard. Par conséquent, vous retrouverez les limites, avantages
et inconvénients de ces différentes méthodes sur les serveurs DNS fonctionnant sous Windows Server 2003
ou Windows Server 2008, et aussi sur les autres plates-formes standard du marché.

Avant de faire votre choix, vous pourrez vous référer au tableau qui suit. Il vous permettra de mieux
appréhender les bonnes pratiques qui se cachent derrière l’utilisation des redirecteurs conditionnels,
l’utilisation des zones de stub et l’utilisation des zones de délégation.

Caractéristiques des mécanismes de résolution DNS entres espaces de noms différents :

Redirecteurs conditionnels Zones de stub Délégations

Tout nom situé au même


Tout nom situé au même
niveau, à un niveau inférieur Limité aux sous-domaines
Espace de résolution niveau ou à un niveau
ou supérieur aux zones des zones locales.
supérieur aux zones locales.
locales.

Le serveur essaie les


Le serveur résout la requête ou passe une référence au client
Requêtes DNSutilisées requêtes itératives puis
pour réaliser une requête itérative (en fonction de la demande).
récursives.

Peut être affecté par les firewalls qui empêchent les clients de
Sécurité et Firewall Supporte les firewalls.
contacter certains serveurs DNS.

Réplication automatique
À déclarer sur chaque Toujours répliquée vers les
Niveau deconfiguration lorsque l’intégration Active
serveur DNS. NS de la zone parent.
Directory est utilisée.

Doit être reconfiguré lorsque Mise à jour automatique Doit être reconfigurée
Reconfigurationnécessaire des serveurs de noms sont lorsque les NS sont ajoutés à lorsque les NS sont ajoutés à
ajoutés aux domaines cibles. la zone cible. la zone cible.

Support de la tolérance de
Peut être tolérant aux pannes
pannes

Pour plus d’informations concernant les choix à réaliser, cherchez "Gestion des serveurs" dans l’aide en ligne
de Windows Server 2008. Vous y trouverez des liens vers les bonnes règles à respecter concernant les
sujets tels que l’utilisation des serveurs primaires et secondaires, la protection du service Serveur DNS,
l’utilisation de serveurs de cache, la modification des paramètres par défaut du serveur, l’utilisation des
redirecteurs, l’envoi de requêtes à l’aide des redirecteurs, la mise à jour des indications de serveurs racine
ainsi que l’administration du serveur à l’aide de la commande Dnscmd des outils de support.

Gestion des noms multihôtes

Page 65
La gestion des noms multihôtes est implémentée grâce à l’activation de la fonction Round Robin intégrée
au DNS. Vous pouvez contrôler l’activation de la fonction Round Robin à l’aide de la console de gestion du
DNS ou à l’aide de la commande dnscmd.

Désactivation/activation de la fonction Round Robin

Page 66
Vieillissement et nettoyage des enregistrements DNS
Les serveurs DNS fonctionnant sous Windows Server 2003 et Windows Server 2008 prennent en charge
les fonctionnalités de vieillissement et de nettoyage. Ces fonctionnalités permettent de réaliser la
suppression des enregistrements de ressources périmés qui peuvent s’accumuler au fil du temps dans les
zones DNS.

Effectivement, avec les mises à jour dynamiques, les enregistrements de ressources sont
automatiquement ajoutés aux zones lors du démarrage des ordinateurs sur le réseau. Cependant, ils ne
sont pas toujours supprimés automatiquement lorsque les ordinateurs quittent le réseau. En effet, si un
ordinateur ayant inscrit son propre enregistrement de ressource de type A est par la suite déconnecté du
réseau de manière incorrecte, l’enre- gistrement de ressource ne sera pas toujours supprimé.

De plus, si le réseau est constitué d’ordinateurs portables, cette situation peut se reproduire
régulièrement et créer une pollution non négligeable des zones.

Les points négatifs suivants peuvent être notés :

 La présence d’enregistrements de ressources anciens dans les zones peut entraîner des
problèmes d’espace disque et surcharger les réplications et autres transferts de zones.
 Les serveurs DNS qui chargent des zones contenant des enregistrements périmés introduisent
le risque d’utiliser des informations obsolètes, ce qui pourra entraîner des problèmes de
résolution de noms sur le réseau.
 L’accumulation d’enregistrements inutiles peut avoir un impact négatif sur les performances du
serveur DNS.

Important : Par défaut, le mécanisme de vieillissement et de nettoyage du serveur DNS est désactivé. Faites
attention au fait qu’à partir du moment où cette fonction serait activée, il est probable qu’un certain nombre
d’enregistrements soient détruits. Cette fonctionnalité ne devrait être activée que sur les serveurs DNS
hébergeant des zones contenant des centaines de milliers d’enregistrements dans l’objectif de procéder à
une épuration des enregistrements périmés.

Si un enregistrement est supprimé par accident, non seulement les utilisateurs ne réussiront pas à
résoudre des requêtes portant sur cet enregistrement, mais en plus, la libération de l’enregistrement fera
que tout utilisateur pourra alors le recréer et s’en déclarer propriétaire. Le serveur utilise une valeur de
datage pour chaque enregistrement de ressource.

Lorsqu’un serveur DNS déclenche une opération de nettoyage, il détermine les enregistrements de
ressources ayant vieilli et les supprime des données de zone. Les serveurs peuvent fonctionner de
manière à effectuer automatiquement les opérations mais vous pourrez aussi lancer l’opération en
agissant sur les propriétés du serveur.

Pour activer le nettoyage des zones DNS, utilisez la console de gestion MMC du DNS. Cochez l’option
Activer le nettoyage automatique des enregistrements obsolètes au niveau de l’onglet Avancé de
l’objet serveur DNS, puis faites de même sur la ou les zones DNS sur lesquelles vous souhaitez activer la
fonction.

Page 67
Cette option précise si oui ou non un nettoyage peut avoir lieu pour le serveur sélectionné. Lorsque cette
option est désactivée, le nettoyage ne peut pas être effectué et les enregistrements ne sont pas
supprimés de la base de données DNS. Ce paramètre s’applique à la fois au nettoyage automatique et
manuel.

Chaque zone DNS dispose de la possibilité d’utiliser les fonctions de nettoyage lorsque les
enregistrements ont vieilli. Le bouton Vieillissement permet d’accéder aux différents réglages.

Page 68
Encore une fois, la fonction n’est par défaut pas activée. Pour information, la zone utilisée dans nos
exemples est la zone _msdcs.corp2003.corporate.net, laquelle gère les contrôleurs de domaine du
domaine racine de la forêt. Il est clair que cette zone ne doit pas utiliser les fonctions de nettoyage des
enregistrements DNS.

La suppression par erreur d’un enregistrement de ressource utilisé par un contrôleur de domaine pourra
avoir des effets négatifs sur les authentifications des clients Active Directory ou aussi, et c’est bien plus
grave, sur les réplications Active Directory.

Pour pouvoir bénéficier des opérations de vieillissement et de nettoyage, les enregistrements de


ressources doivent être ajoutés aux zones DNS de façon dynamique. L’écran ci-après illustre les
différentes actions que vous pouvez déclencher à l’encontre d’un serveur DNS fonctionnant sous Windows
2000 Server, Windows Server 2003 ou Windows Server 2008.

Notez l’action Définir le vieillissement/nettoyage pour toutes les zones... et l’action Nettoyer les
enregistrements de ressources obsolètes.

Page 69
Les propriétés du serveur DNS et nettoyage des enregistrements

Vous avez aussi la possibilité de déclencher l’opération de nettoyage via l’interface de la console de
gestion du DNS ou encore à l’aide de la commande dnscmd/Start-Scavengin.

Options de démarrage du serveur DNS


Un serveur DNS Windows 2000 Server, Windows Server 2003 ou Windows Server 2008 vous permet de
spécifier comment le service serveur DNS devra charger les données de zones au démarrage. L’écran ci-
après illustre comment sélectionner ces options.

Option de chargement : À partir du Registre

Lorsque vous choisissez cette option, le serveur DNS se base sur les paramètres de chargement des
différentes zones stockés dans le registre, comme illustré ci-après.

Option de chargement : À partir d’un fichier

Lorsque vous choisissez cette option le serveur DNS se base sur les paramètres de chargement des
différentes zones stockés dans le registre, mais utilise aussi le fichier BOOT de la même manière que
dans les implémentations de serveurs DNS de type BIND.

La figure qui suit illustre un fichier BOOT.

Page 70
Le fichier contient les déclarations des zones DNS avec leur type ainsi que certains paramètres globaux
du serveur DNS. Ainsi, les mots clés les plus importants sont expliqués ci-après.

forwarders : ce paramètre désigne la ou les adresses IP des serveurs DNS à utiliser comme
redirecteurs.

cache : ce paramètre désigne le nom du fichier qui déclare les serveurs du domaine racine.

primary : ce paramètre désigne le nom d’une zone de type primaire ainsi que le fichier de zone associé.

secondary : ce paramètre désigne le nom d’une zone de type secondaire ainsi que le fichier de zone
associé.

Notez que pour utiliser le mode de démarrage À partir d’un fichier, aucune zone ne doit être intégrée à
l’annuaire Active Directory.

S’il était impératif sur un serveur donné d’utiliser le fichier BOOT et que vous étiez confronté à
ce problème, vous devrez décocher la case Enregistrer la zone dans Active Directory dans les
propriétés de chacune des zones concernées. Cette option est disponible via les propriétés de la zone,
onglet Général puis le bouton permettant de modifier le type de la zone.

Les propriétés d’une zone vous permettent d’en gérer les nombreuses caractéristiques

Option de chargement : À partir de Active Directory et du Registre

Lorsque vous choisissez cette option, le serveur DNS se base sur les paramètres de chargement situés
dans le registre, sachant que le contenu réel des zones sera, lui, stocké dans l’annuaire Active Directory.
Ce choix est automatiquement sélectionné lorsque le serveur DNS est aussi un contrôleur de domaine.
Comme expliqué précédemment, les paramètres des zones sont toujours stockés dans le registre, mais
cette fois-ci, le fichier BOOT n’est plus nécessaire. De fait, si celui-ci existait précédemment, il sera
déplacé dans le répertoire de sauvegarde \dns\backup. Un nouveau fichier d’information nommé boot.txt
le remplacera dans le répertoire \dns.

Page 71
Le fichier d’information boot.txt situé dans le répertoire \system32\dns précise que le fichier BOOT
n’est plus utilisé

Le registre joue toujours son rôle de base de données de configuration des services et autres modules de
Windows. Dans notre cas, vous pouvez constater que pour la zone DNS corporate.net, l’intégration Active
Directory doit être réalisée.

La figure ci-dessous montre cette option.

Le paramétrage DsIntegrated spécifie l’intégration dans Active Directory

Récursivité des serveurs DNS et protection des serveurs


Par défaut, un serveur DNS Windows 2000 Server, Windows Server 2003 ou Windows Server 2008
supporte la récursivité. La récursivité est fondamentale dans la mesure où elle permet à un serveur DNS
d’être capable de résoudre des noms pour lesquels il ne dispose pas de fichiers de zone. L’onglet
Redirecteurs des propriétés du server DNS vous permettra de ne pas utiliser la récursivité pour chacun
des domaines déclarés à faire l’objet d’une redirection. Vous pouvez parfois décider de complètement
refuser l’usage de la récursivité. L’onglet Avancé des propriétés du serveur vous permettra d’y parvenir
via l’option du serveur Désactiver la récursivité (désactiver les redirecteurs également).

1. Blocage des attaques de type Spoofing DNS

Page 72
Les serveurs DNS qui prennent en charge la résolution des requêtes récursives peuvent être victimes
d’attaques de ce type. Ce type d’attaque a pour objet de polluer le cache du serveur DNS. L’attaque est
basée sur la possibilité de prédire le numéro de séquence de la requête DNS. Ainsi, l’attaquant peut
soumettre une demande de résolution pour la machine www.microsoft.com et tandis que le serveur
détermine la réponse à cette requête, l’attaquant trompe votre serveur avec une "mauvaise réponse".
Cette "mauvaise réponse" contiendra bien sûr une "mauvaise adresse IP" et pourquoi pas une durée de
vie (Time To Live) très élevée. Une fois l’attaque détectée, la solution consistera à purger le ou les
enregistrements illégaux du cache du serveur DNS.

Bien sûr, le fait de désactiver les requêtes récursives vous protégera de ce genre d’attaque. Cependant,
vous ne pourrez vous passer des requêtes récursives si des utilisateurs de ce serveur doivent résoudre
des domaines non gérés. En effet, lorsque la récursivité est totalement désactivée, le serveur DNS n’est
plus capable que de résoudre les noms en rapport avec les zones DNS qu’il héberge.

2. Blocage des attaques de type Spoofing DNS sur les serveurs de type
Internet

Il est recommandé de désactiver la récursivité sur les serveurs DNS disponibles sur Internet. De cette
manière, le serveur sera capable de répondre aux requêtes d’autres serveurs DNS mais empêchera les
clients Internet d’utiliser le serveur DNS pour résoudre d’autres noms de domaine sur Internet. Pour
rappel, nous avons aussi vu précédemment qu’un serveur DNS dont la récursivité était désactivée
totalement au niveau du serveur ne pouvait plus utiliser les redirecteurs.

Synthèse des rôles des serveurs DNS


Nous venons de voir que le serveur DNS peut être configuré pour fonctionner de différentes manières et
ainsi être utilisé dans différentes situations. Ces différents rôles sont résumés ci-dessous :

Serveur de cache : le serveur de cache aura uniquement pour effet de réduire le trafic sur un réseau
étendu. Le serveur prend en charge les résolutions des clients et les résout, sans posséder aucune zone,
donc sans aucune surcharge de réplication.

Serveur redirecteur uniquement : un serveur configuré pour utiliser des redirecteurs tente de
résoudre le nom demandé sur la base de son cache local, des zones stockées localement puis à l’aide des
redirecteurs spécifiés. Si aucun de ces moyens ne permet la résolution, alors la récursivité standard sera
utilisée. Vous avez la possibilité de désactiver les résolutions récursives pour éviter ces recherches après
l’échec des redirecteurs. Dans ce cas, le serveur DNS ne peut plus compter que sur son cache, ses zones
et uniquement l’usage de ses redirecteurs.

Le bon usage des redirecteurs consiste bien sûr à permettre aux serveurs DNS de votre espace privé de
résoudre l’espace DNS Internet. Choisissez un de vos serveurs DNS pour faire usage des redirecteurs.
Configurez ensuite votre firewall pour que seul ce serveur soit autorisé à transmettre et recevoir les trafics
DNS Internet (ports TCP et UDP 53).

Serveur redirecteur conditionnel : alors qu’un serveur configuré pour utiliser les redirecteurs pourra
en référer à un ou plusieurs redirecteurs pour résoudre le nom demandé, le redirecteur conditionnel
redirigera les demandes de résolutions en fonction du nom de domaine DNS de la requête.

Comme vu précédemment, la configuration est très simple puisqu’il suffit pour chaque domaine de
résolution redirigé de déclarer la ou les adresses TCP/IP des serveurs DNS qui prendront en charge le
domaine spécifié.

Page 73
Déclaration de redirecteurs spécifiques en fonction des domaines

Commandes de gestion du service DNS


L’estimation des coûts d’administration et de maintenance des serveurs DNS indispensables au bon
fonctionnement de l’annuaire Active Directory est de manière théorique difficilement quantifiable.
Cependant, l’expérience montre que l’usage du service DNS ne nécessite pas de ressources humaines et
matérielles supplémentaires.

Cela ne signifie pas pour autant qu’il n’est pas indispensable de disposer des ressources, compétences et
outils nécessaires à la bonne administration et surveillance de ce service très important. Ainsi, vous
pourrez utiliser les commandes et outils tels que NSLookup, DNSCmd, DNSLint et Netdiag. Ces outils et
leur bon usage sont présentés ci-après.

1. La commande ipconfig

a. Gestion du cache du client DNS et des enregistrements dynamiques

Par rapport aux précédentes versions de cette commande (versions Windows 9x et NT), cet utilitaire
comprend désormais des options de ligne de commande supplémentaires destinées à faciliter la
résolution des problèmes et la prise en charge des clients DNS. Ainsi, en plus des fonctions bien
connues sous Windows NT, vous disposerez de la possibilité de consulter et de réinitialiser le cache de
résolution du module client DNS ainsi que de renouveler l’inscription du client DNS. Ces options de la
commande ipconfig de Windows XP Professionnel et Windows Server 2003 sont listées ci-après.

ipconfig /displaydns

La commande ipconfig /displaydns permet d’afficher le cache de résolutions, lequel est implémenté
au sein du service Client DNS.

Page 74
Le contenu du cache du client DNS inclut les entrées préchargées à partir du fichier
%Systemroot%\System32\Drivers\etc\Hosts de la machine locale, ainsi que tout enregistrement de
ressource récemment obtenu via des requêtes de noms déjà résolues. Ces informations sont ensuite
utilisées par le service Client DNS pour résoudre directement les noms fréquemment recherchés avant
qu’il n’interroge réellement les serveurs DNS configurés.

S’il s’avérait nécessaire d’ajouter par la suite des entrées au sein du fichier Hosts local, ces entrées
seront alors instantanément ajoutées au cache DNS.

Affichage du cache et enregistrements de résolutions négatives

N’oubliez pas non plus que le cache de résolution DNS prend en charge la mise en cache négative des
noms DNS non résolus. Ces entrées négatives sont mises en cache pendant une période de temps de
courte durée afin que le serveur DNS ne soit pas à nouveau interrogé. Cette fonctionnalité a pour
objet de garantir que les serveurs DNS ne puissent recevoir des milliers de requêtes par seconde de la
part d’une application simplement mal écrite, voire malveillante. De cette manière, les résolutions
négatives mises en cache garantissent au mieux la disponibilité du service de résolution tout entier.

La clé de registre suivante vous permettra de configurer le temps (en secondes) pendant lequel une
entrée restera stockée dans le cache DNS :

HKLM\SYSTEM\CurrentControlSet\Services\DnsCache\Parameters\NegativeCacheTime.

Valeur de type REG_DWORD comprise entre 0x0 - 0xFFFFFFFF. La valeur par défaut en production
dans le système est définie à 0x12C, c’est-à-dire 300 secondes, donc 5 minutes. Une fois que la durée
spécifiée arrive à expiration, alors le service Client DNS supprime l’enregistrement du cache.

À propos de la durée de vie des résolutions négatives. La valeur par défaut de la durée de vie des
enregistrements négatifs ne nécessite pas d’être modifiée après coup. De plus, notez que ce paramètre ne
s’applique pas aux enregistrements de type SOA. La valeur de la période de temps pour les enregistrements
de SOA négatifs est déterminée par le paramètre spécifique NegativeSOACacheTime. Par défaut, la valeur
de NegativecacheTime est définie à 0x78, c’est-à-dire 120 secondes, donc 2 minutes.

Il n’est pas nécessaire de disposer du statut d’administrateur pour effectuer cette opération. Par conséquent,
pour des raisons de sécurité, il est recommandé d’exécuter cette tâche en tant que simple utilisateur.

ipconfig /flushdns

La commande ipconfig /flushdns permet de vider et réinitialiser le cache de résolution du client


DNS.

Lorsque ce sera nécessaire, vos investigations concernant la résolution des problèmes DNS pourront
vous amener à utiliser cette commande pour exclure les entrées de cache négatives gênantes.

Attention ! Cette opération vide l’intégralité du cache. Ainsi, toutes les autres entrées ajoutées
dynamiquement seront aussi supprimées. À l’inverse, la réinitialisation du cache n’élimine pas les entrées
préchargées à partir du fichier Hosts. Pour éliminer ces entrées, vous devez directement les supprimer du
fichier Hosts.

La commande ipconfig existe avec les versions antérieures de Windows, les options /displaydns et
/flushdns sont uniquement disponibles pour les ordinateurs exécutant les systèmes d’exploitation Windows
2000, Windows XP, Windows Server 2003 ainsi que Windows Vista et Windows Server 2008.

b. Renouvellement de l’inscription du client DNS

ipconfig /registerdns

Cette commande sera très utile pour renouveler l’inscription du client DNS suite à un changement de
configuration ou aussi pour résoudre un problème d’échec d’inscription ou de mise à jour dynamique
entre un client et un serveur DNS, sans redémarrer l’ordinateur. Cette dernière remarque concerne
particulièrement les serveurs.

Dans la mesure où un ordinateur peut être équipé de multiples cartes réseau, le fait de ne rien
spécifier provoquera l’enregistrement des adresses IP présentes sur toutes les cartes sur le nom
déclaré en tant que nom complet principal de l’ordinateur. Si vous souhaitez enregistrer uniquement

Page 75
une carte en particulier, alors vous pourrez entrer la commande ipconfig /registerdns [carte] où
carte est le nom d’une carte réseau spécifique installée sur l’ordinateur pour lequel vous souhaitez
renouveler ou mettre à jour les inscriptions.

Les noms de toutes les cartes qui peuvent être utilisées sur un ordinateur donné sont affichés lorsque vous
tapez directement la commande ipconfig.

La commande ipconfig /registerdns et les baux DHCP

Nous venons de voir que la commande ipconfig /registerdns permet de lancer manuellement
l’inscription dynamique des noms DNS et adresses IP. Toutefois, sachez que cette commande
rafraîchit aussi tous les baux DHCP.

Sur les ordinateurs exécutant les systèmes d’exploitation Windows 2000, Windows XP, Windows
Server 2003, Windows Vista et Windows Server 2008, c’est le service Client DHCP qui est utilisé pour
effectuer des inscriptions et mises à jour dynamiques et ce, que l’ordinateur utilise un serveur DHCP
ou une configuration TCP/IP statique.

Dans le cas où vous seriez amené à résoudre un problème d’échec d’inscription dynamique DNS pour
un ordinateur et ses noms DNS, vous devrez vérifier que la cause du problème n’est pas l’une des
causes suivantes :

 La zone pour laquelle la mise à jour ou l’inscription du client est demandée n’accepte pas les
mises à jour dynamiques.
 Les serveurs DNS configurés sur le client ne supportent pas le protocole de mise à jour
dynamique DNS.
 Le serveur DNS - primaire ou avec intégration Active Directory - de la zone a refusé la
demande. Généralement, les droits du client sont insuffisants et ne lui permettent pas de
mettre à jour son propre nom.
 Le serveur ou la zone hébergée par le serveur ne sont pas disponibles. Dans ce cas, il
pourra s’agir de divers problèmes tels que l’indisponibilité du système ou du réseau.

À propos des enregistrements dynamiques DNS, mises à jour du cache et services Client DHCP et
Client DNS intégrés au système

Le service Client DHCP est responsable de l’inscription et des mises à jour des adresses IP et des
enregistrements DNS pour l’ordinateur. Aussi, même si un ordinateur est pourvu d’une configuration
TCP/IP statique, ne prenez pas l’initiative de stopper ce service. Dans le cas où ce service serait
arrêté, l’ordinateur connaîtrait deux types de problèmes. D’une part, s’il attend une configuration IP
dynamique, il ne la recevra pas et d’autre part, il ne sera plus capable de réaliser la ou les mises à
jour DNS dynamiques nécessaires. La commande tasklist montre que les deux modules sont très liés.

Processus contenant les services Client DHCP et Client DNS

En effet, les services Client DHCP et Client DNS sont tous les deux contenus dans le même processus.
L’écran suivant montre le problème : le service Client DHCP étant stoppé, l’ordinateur ne parvient
plus à réaliser l’opération d’enregistrement dynamique dans le DNS.

Page 76
Le non fonctionnement du service Client DHCP empêche les mises à jour dynamiques DNS

c. Nouvelles options de la commande ipconfig

Windows Vista et Windows Server 2008 comportent de nouvelles fonctionnalités IP qui ont nécessité
de moderniser l’ensemble des commandes système telles que la commande ipconfig ou la commande
Netsh. Les paramètres relatifs à la commande Ipconfig et leur objet sont listés ci-dessous :

 ipconfig /allcompartments : affiche des informations pour tous les compartiments.


 ipconfig /release : libère l’adresse IPv4 pour la carte spécifiée.
 ipconfig /release6 : libère l’adresse IPv6 pour la carte spécifiée.
 ipconfig /renew : renouvelle l’adresse IPv4 pour la carte spécifiée.
 ipconfig /renew6 : renouvelle l’adresse IPv6 pour la carte spécifiée.

À propos de Compartiments de routage (Routing compartments)

Windows Server 2008 et Windows Vista disposent d’une nouvelle implémentation du protocole TCP/IP
(Next Generation TCP/IP). La pile de protocoles TCP/IP qui équipait précédemment Windows XP et
Windows Server 2003 a été développée au début des années 90 et a subie de nombreuses
modifications pour suivre les évolutions du protocole. Le protocole TCP/IP NextGen est une nouvelle
architecture et un redéveloppement complet de l’ensemble de la pile IPv4 et IPv6. L’une des
nombreuses fonctionnalités implémentée est appelée « compartiments de routage ».

Un compartiment de routage est une combinaison d’un ensemble d’interfaces associées à une session
utilisateur donnée disposant de sa propre table de routage privée. Ainsi, un ordinateur peut avoir de
multiples compartiments de routages, tous isolés les uns des autres, sachant qu’une interface ne peut
appartenir qu’à un seul compartiment. Cette fonctionnalité est très puissante car elle permet d’isoler des
trafics non souhaités entre des interfaces virtuelles telles que les VPN, les sessions de type Terminal Server,
etc.

Pour plus d’informations, recherchez « Next Generation TCP/IP Stack » sur le site Microsoft Technet
ou utilisez le lien suivant : http://technet.microsoft.com/enus/network/bb545475.aspx

2. La commande NSLookup

Utilisation de la commande NSlookup pour vérifier les enregistrements des contrôleurs de


domaine Active Directory

La commande NSLookup est une commande souvent utilisée pour diagnostiquer d’éventuels
problèmes de résolution de noms d’hôtes au sein de l’infrastructure DNS. Elle est particulièrement
puissante pour envoyer vers tel ou tel serveur DNS des demandes de résolution de noms et présenter
en retour des réponses détaillées relatives à ces requêtes. La commande NSLookup présente la
particularité de pouvoir fonctionner en mode interactif ou en mode non interactif.

En mode interactif : lorsque vous utilisez ce mode, vous recevez directement les résultats relatifs à
vos commandes. Bien sûr, ce mode est le plus pratique lorsque vous devez taper de multiples
commandes pour réaliser une suite d’opérations. En mode non interactif : lorsque vous utilisez ce
mode, vous pouvez passer de multiples paramètres sur la même ligne de commande et ainsi réaliser
des opérations qui pourront être ensuite insérées dans un script d’administration. Dans ce cas, le retour

Page 77
en rapport avec la commande passée pourra être redirigé dans un fichier. Par exemple, vous pourrez
utilisez la procédure ci-dessous pour contrôler les enregistrements de contrôleurs de domaines :

 Tapez la commande NSLookup à l’invite de commande.


 Tapez set q=srv.
 Tapez _ldap._tcp.dc._msdcs.Nom_Domaine_Active_Directory.

Le retour de cette commande doit afficher tous les enregistrements de type SRV pour le nom demandé
"_ldap._tcp.dc._msdcs.corp2003.corporate.net", c’est-à-dire tous les contrôleurs du domaine visé. En
fonction du résultat, vous déterminerez ensuite si une action supplémentaire est requise.

Filtrage sur les enregistrements de type SRV

Si tel était le cas, la solution consistera à corriger les enregistrements erronés ou manquants. Pour
rajouter les enregistrements de ressources de type SRV nécessaires à un contrôleur de domaine donné,
ouvrez le fichier Netlogon.dns. Ce fichier est créé automatiquement par l’Assistant Installation d’Active
Directory au moment où le serveur est promu au rôle de contrôleur de domaine. Il est situé à
l’emplacement : \%SystemRoot%\System32\ Config\Netlogon.dns

Les opérations réalisées ont simplement testé la disponibilité ou non des enregistrements recherchés. De
fait, il s’agit d’une opération normale qui ne nécessite pas que vous disposiez d’un statut de type
administrateur. La bonne pratique consiste donc à ce que vous ne preniez pas l’initiative d’emprunter une
telle identité.

Dans certains cas, la procédure précédente renvoie plusieurs délais d’expiration successifs. Ce cas se
produira lorsque les recherches indirectes ne sont pas correctement configurées.

3. La commande DNSCmd

Comme la majorité des outils utilisés par les personnels de support, la commande DNSCmd était
incluse dans les Outils de support de Windows Server 2003. Cette commande prend en charge
directement à la ligne de commande, la plupart des tâches d’administration incluses dans la console de
gestion MMC du DNS.

Aujourd’hui, cette commande importante est intégrée à Windows Server 2008.

Cette commande doit être utilisée lorsqu’une opération particulière est à réaliser vers plusieurs
serveurs DNS. Cette méthode est donc particulièrement efficace pour scripter des tâches
d’administration répétitives vers un ou plusieurs serveurs DNS. Ce pourrait, bien sûr, être le cas d’un
fournisseur de services Internet.

L’utilisation de la commande DNSCmd peut être utilisée de deux manières : soit en administration
locale ou distante, soit dans le cadre de fichiers batchs génériques transférés et exécutés à distance. En
fait, tous les scénarios d’exécution sont possibles et vous permettront de gérer la majorité des cas qui
se présenteront.

La commande DNSCmd s’utilise de la manière suivante :

Page 78
dnscmd Nom_du_Server Commande [Commande Paramètre]

Par exemple, la commande dnscmd booster2003.corp2003.corporate.net /info retournera une page


complète de paramètres tels que ceux concernant les informations générales du serveur, la
configuration des mécanismes DNS, la configuration des options de nettoyage des enregistrements de
ressources, l’usage des redirecteurs, de la récursivité, etc.

Une autre commande utile est la commande dnscmd Nom_du_Server /clearcache.

Vidage du cache DNS en cas de corruption

Le paramètre /clearcache permet de purger intégralement le contenu du cache du serveur DNS et de


supprimer ainsi tout enregistrement non valide.

Ne confondez pas le cache du serveur DNS avec le cache du "Client DNS". Le cache du serveur peut être
purgé à l’aide de la commande dnscmd /clearcache tandis que le cache du client le sera à l’aide de la
commande ipconfig /flushdns.

Dans le même ordre d’idée, les privilèges nécessaires pour ces deux opérations ne sont pas identiques.

Pour effectuer l’effacement du cache du serveur DNS, vous devez être membre du groupe
Administrateurs sur l’ordinateur local ou avoir reçu, par délégation, les autorisations nécessaires. Notez
que si l’ordinateur est membre d’un domaine, les membres du groupe Admins du domaine sont en
mesure d’effectuer cette procédure.

Pour effectuer l’effacement du cache du client DNS, il n’est pas nécessaire que vous disposiez des
privilèges d’administration.

La liste ci-dessous présente les paramètres de la commande DNSCmd les plus couramment utilisés :

/primary /secondary /stub /cache /autocreated : filtrage du type de zone à afficher.

/primary : affiche toutes les zones de type principales ou Active Directory.

/secondary : affiche toutes les zones de types secondaires.

/stub : affiche toutes les zones de stub.

/cache : affiche toutes les zones présentes dans le cache du serveur DNS.

/auto-created : liste les zones créées automatiquement pendant la phase d’installation du serveur
DNS.

/forward /reverse : permet de filtrer l’affichage des zones d’un type donné.

Page 79
Pour afficher les nombreuses commandes et paramètres de DNSCmd, tapez à la ligne de commande
DNSCmd /?.

4. La commande DNSLint

La commande DNSLint est une commande incluse dans les Outils de support de Windows Server 2003.
DNSLint est un outil qui permet de diagnostiquer les problèmes liés à la résolution de noms d’hôtes, des
domaines et délégations de sous-domaines et aussi des aspects concernant l’annuaire Active Directory.

En effet, cette commande dispose des arguments qui vous permettront de vérifier les enregistrements
de ressources utilisés spécifiquement pour la réplication des contrôleurs de domaine Active Directory.

Un avantage supplémentaire par rapport aux autres commandes est que cette commande permet de
produire directement des rapports au format HTML. Vous pouvez ainsi présenter un check-up complet
de l’implémentation du système de résolution DNS au sein d’une forêt Active Directory. Plus encore,
DNSLint vous permettra d’aider à la résolution des problèmes d’authentification des clients au sein d’un
domaine Active Directory en vérifiant les enregistrements de type SRV pour les protocoles LDAP,
Kerberos ainsi que pour les catalogues globaux.

Par exemple, la commande à utiliser pour créer un rapport est :

dnslint /ad <adresse_IP_contrôleur_de_domaine> /s <adresse_IP_serveur_ DNS>

Le paramètre /ad spécifie que les enregistrements spécifiques à l’annuaire Active Directory doivent
être testés, le paramètre /s permettant de solliciter le serveur DNS spécifié. Notez que le paramètre /s
est obligatoire lorsque vous souhaitez faire un test Active Directory avec le paramètre /ad. De plus, le
serveur DNS spécifié via le paramètre /s devra faire autorité pour le sous-domaine
_msdcs.<Racine_de_la_forêt>.

Au cas où vous souhaiteriez tester les enregistrements de ressources DNS nécessaires à l’annuaire
Active Directory sur le serveur local, vous pouvez cumuler le paramètre /ad avec le paramètre
spécifique /localhost.

Ce test permet de vérifier que le serveur local est capable de résoudre les enregistrements nécessaires
aux réplications Active Directory.

En plus des fonctions de tests Active Directory, DNSLint est aussi capable de vérifier le bon
fonctionnement des délégations de domaine et de contrôler un ensemble d’enregistrements de
ressources DNS. Pour réaliser ces deux catégories d’opérations vous pourrez respectivement utiliser les
paramètres /d et /ql.

Pour plus d’informations sur les différents paramètres disponibles avec la commande DNSLint, tapez
DNSLint /?.

Pour télécharger DNSLint ou obtenir plus d’informations sur cette commande, vous pouvez consulter l’article
technique situé à l’adresse suivante : http://support.microsoft.com/kb/321045/en-us. Sur un serveur
fonctionnant sous Windows Server 2008, vous pouvez aussi installer les Outils de Support de Windows
Server 2003 et ainsi disposer de tous les outils de support habituels.

5. La commande Netdiag

La commande Netdiag, disponible dans les Outils de Support de Windows Server 2003, vous aidera à
isoler les problèmes réseau et de connectivité. Netdiag est capable de réaliser une série de tests qui
vous permettra de déterminer l’état précis des communications sur tous les types d’ordinateurs clients
du réseau.

La commande Netdiag est apparue avec les outils de support initialement livrés avec Windows Server 2000.
Avec Windows Server 2008, la plupart de ces outils ont été intégrés, supprimant la nécessité de devoir livrer
un ensemble d’outils annexes. Notez cependant, que la commande Netdiag n’a pas fait l’objet de cette
intégration dans la mesure où la commande Dcdiag incorpore des options de test réseau équivalent.

Attention : l’installation des outils de support de Windows Server 2003 SP2 ou Windows Server 2003 R2
sur un serveur fonctionnant sous Windows Server 2008 provoque un message d’avertissement de la
part du module "Assistant Compatibilité des programmes". Il est en effet signifié que ce programme
présente des problèmes de compatibilité connus.

Page 80
Même si ce message d’avertissement peut être ignoré et l’installation des Outils de support de Windows
Server 2003 être réalisée avec succès, il conviendra alors de s’assurer que les différents outils
fonctionnent correctement (ce qui est le cas pour la majorité d’entre eux, y compris la commande
Netdiag !).

La syntaxe complète de la commande Netdiag prend la forme ci-dessous :

netdiag [/q] [/v] [/l] [/debug] [/d: Nom_du_domaine] [/fix] [/dcaccountenum][/test:


nom_du_test] [/skip: nom_du_test]

Les paramètres détaillés sont listés ci-après :

Le paramètre /q : utilisé pour spécifier une sortie de messages simplifiés ou uniquement afficher les
messages d’erreurs.

Le paramètre /v : utilisé pour exécuter Netdiag en mode détaillé (verbose mode) et afficher tous les
détails relatifs aux actions réalisées.

Le paramètre /l : utilisé pour rediriger la sortie de la commande Netdiag vers un fichier. Ce fichier est
appelé Netdiag.log et sera créé dans le même répertoire que celui où la commande Netdiag est
exécutée.

Le paramètre /debug : utilisé pour exécuter la commande Netdiag en mode debug. Ce paramètre
permet de disposer d’un mode détaillé supérieur au mode obtenu grâce au paramètre /v.

Le paramètre /d: domain_name : utilisé pour localiser un contrôleur de domaine dans le domaine
spécifié.

Le paramètre /fix : utilisé pour que Netdiag solutionne directement les problèmes mineurs.

Le paramètre /dcaccountenum : utilisé pour énumérer les comptes d’ordinateurs de type Contrôleurs
de Domaine.

Vous trouverez ci-après des exemples d’utilisation de cette puissante commande de diagnostic.

 Pour utiliser Netdiag en mode détaillé, tapez netdiag /v.


 Pour utiliser Netdiag pour afficher les informations concernant un contrôleur de domaine de
votre domaine, et écrire toutes les informations dans le journal Netdiag.log, tapez la
commande netdiag /v /l /test:dsgetdc.
 Pour utiliser Netdiag pour afficher l’activité avancée du protocole DNS, tapez la commande
netdiag /test:dns /debug.

Pour plus d’informations sur la commande Netdiag et son usage dans différents scénarios, vous pouvez
vous référer aux articles de la base de connaissances Microsoft dont les numéros sont spécifiés ci-
dessous :

 Q265706 : DCDiag and NetDiag in Windows 2000 Facilitate Domain Join and DC Creation.
 Q257225 : Basic IPSec Troubleshooting in Windows 2000.
 Q216899 : Best Practice Methods for Windows 2000 Domain Controller Setup.
 Q250842 : Troubleshooting Group Policy Application Problems.
 Q219289 : Description of the Netdiag /fix Switch.

Netdiag /fix : lorsque vous utilisez le paramètre /fix, les routines de tests inclues dans la commande
Netdiag vérifient que toutes les entrées contenues dans le fichier Netlogon.dns sont bien présentes dans la
zone DNS. Si certaines entrées sont incorrectes, alors Netdiag corrige ces erreurs. Quand Netdiag exécute
un test de contrôleur de domaine, le paramètre /fix entame une vérification du GUID du domaine caché
localement sur l’ordinateur par rapport au GUID du domaine disponible sur un contrôleur de domaine. Ce
point est très intéressant dans la mesure où ces enregistrements sont essentiels pour le bon fonctionnement
des réplications Active Directory. N’oubliez pas que, par définition, l’Active Directory assigne sur tous les
éléments (objets) qu’il contient et qui le compose un DN, un RON et aussi un GUID. Le GUID (Globally
Unique IDentifier), du domaine référence l’objet domaine lui-même au sein du DIT (Directory Information
Tree) garantissant ainsi son unicité.

Pour plus d’informations concernant la commande Netdiag, vous pouvez faire une recherche dans l’aide en
ligne et suivre le lien Microsoft ou directement installer les Outils de Support de Windows Server 2003 et
ainsi disposer de tous les outils de support habituels.
Page 81
Surveillance du service DNS
Le service DNS doit, comme les autres services importants, être surveillé. Cette surveillance est basée
sur l’utilisation de la console de gestion des performances. Cette console vous permet d’invoquer un
ensemble de compteurs de performances spécialisés dans la surveillance du service serveur DNS.Comme
les serveurs DNS jouent un rôle central dans la plupart des infrastructures, la surveillance des serveurs
DNS vous permettra de réagir de manière proactive à l’aide des éléments suivants :

 La mise à disposition d’une base de performances de référence. Vous pourrez ensuite utiliser
ces informations pour identifier les éventuelles baisses de performances et ainsi estimer
d’éventuelles mises à niveau matérielles ou logicielles pour maintenir ou améliorer le niveau des
performances.
 La mise à disposition de journaux spécialisés pour aider au dépannage et à l’optimisation du
service serveur DNS.

Ces deux points importants sont traités ci-après.

1. Définition d’une base de référence

Le tableau ci-dessous montre les compteurs que vous pouvez - ou devez ! - sélectionner pour pouvoir
surveiller correctement le service serveur DNS.

Compteurs de surveillance du DNS et cadre d’utilisation

Compteurs de
Type de données collectées Évaluation Stratégie de surveillance
Performances

Un nombre important de
refus concernant un serveur Toute augmentation doit
Nombre total de mises à jour
Mises à jour dynamiques DNS sécurisé peut signifier déclencher une analyse
dynamiques refusées par le
refusées que des ordinateurs non détaillée de cette activité
serveur DNS.
autorisés tentent de réaliser douteuse.
des mises à jour dynamiques.

Ce compteur permet de
Nombre moyen de requêtes
surveiller l’activité du Toute variation importante
Requêtes récursives par récursives reçues par le
serveur DNS en terme de doit faire l’objet d’une action
secondes serveur DNS en une
charge de résolution de de contrôle de l’activité.
seconde.
noms.

Le serveur secondaire
Si ce compteur évolue de
hébergeant une zone
manière importante par
Nombre total de demandes secondaire demande des
rapport à la base, il pourra
de transferts de zone transferts de zone. Lorsque
Demandes AXFR envoyées être nécessaire de revoir le
complets envoyées par le ce chiffre est élevé un
nombre de modifications
serveur DNS secondaire. nombre de changements
autorisées ainsi que la
importants est réalisé dans la
méthode utilisée.
zone primaire.

Ces compteurs seront utilisables avec les composants de surveillance et de journalisation habituels de
Windows 2000, Windows Server 2003 et Windows Server 2008.

Page 82
Journal de logging pour la surveillance du service DNS

Vous remarquerez que la console MMC ci-dessus contient deux composants. Le composant System
Monitor Control correspond au traditionnel "Analyseur de performances" tandis que le composant
Gestion de l’ordinateur permet de gérer les journaux et alertes de performances.

Dans cet exemple, le comportement de la machine est surveillé à l’aide du journal par défaut Vue
générale du système ainsi que par un journal dédié à la surveillance du service serveur DNS.

Habituellement, la console pré-formatée Analyseur de performances est directement accessible via le


menu Démarrer - Tous les programmes - Outils d’administration. Cependant, si vous souhaitez
insérer ce logiciel enfichable dans une console personnalisée, vous serez surpris de ne pas le trouver
dans la liste des composants sélectionnables. En fait, ce composant est néanmoins disponible si vous
passez par le choix Contrôle ActiveX.

Ce composant est particulièrement intéressant pour avoir une vue instantanée de l’activité mais surtout
pour analyser les journaux sur une période de temps que vous pourrez spécifier :

Page 83
Sélection de la période d’analyse au sein du journal

D’autres compteurs très intéressants pourront être rajoutés en fonction du cadre d’utilisation du
serveur DNS. Ainsi, vous pourrez par exemple, choisir d’insérer dans votre journal de surveillance, les
compteurs de performances présentés ci-dessous :

 Total des requêtes reçues et Total de requêtes reçues/s ;


 Total de réponses envoyées et Total de réponses envoyées/s ;
 Requêtes récursives et Requêtes récursives/s ;
 Délais expirés d’envois récursifs et Délais expirés d’envois récursifs/s ;
 Échecs de requêtes récursives et Échecs de requêtes récursives/s ;
 Notifications envoyées - Demandes de transfert de zone reçues ;
 Échecs de transferts de zone ;
 Demandes AXFR reçues - AXFR corrects envoyés ;
 Demandes IXFR reçues - IXFR corrects envoyés - Notifications reçues ;
 Demandes de transfert de zone SOA ;
 Mises à jour dynamiques reçues et Mises à jour dynamiques reçues/s ;
 Mises à jour dynamiques refusées ;
 Mises à jour dynamiques en attente ;
 Mises à jour sécurisées reçues et Mises à jour sécurisées reçues/s ;
 Échecs de mise à jour sécurisée.

2. Utilisation de la console Gestionnaire de serveur

Windows Server 2008 introduit la nouvelle console de gestion de serveur MMC Gestionnaire de
serveur. Cette console facilite l’ensemble des taches de gestion et de sécurisation des rôles de serveur
en fournissant un point central pour accéder aux informations système et aux différents statuts de
fonctionnement du serveur. Les grandes fonctionnalités sont rapidement présentées ci-dessous :

 Affichage et changement des rôles et fonctionnalités installés sur le serveur.


 Gestion des services opérationnels.
 Gestion des rôles.

Page 84
 Synthèse des statuts, événements critiques et aide à l’analyse et au dépannage avec l’accès
aux différentes sources d’informations (bonnes pratiques, recommandations, articles Microsoft
Technet).

Surveillance du rôle « Serveur DNS » à l’aide du Gestionnaire de serveur.

La figure suivante illustre la console Gestionnaire de serveur pour mettre en œuvre de la meilleure
façon possible les services DNS de Windows Server 2008. Vous y retrouverez les meilleurs liens pour
appliquer les configurations recommandées, les différentes tâches d’administration ou de maintenance
ainsi que les meilleures pratiques à observer.

Maintenance du rôle « Serveur DNS » à l’aide du Gestionnaire de serveur.

3. Utilisation des journaux d’événements

Par défaut, un ordinateur Windows fonctionnant sous Windows 2000 ou Windows Server 2003 ou
Windows Server 2008 enregistre les événements dans trois types de journaux :

Page 85
 Le journal applications : ce journal contient les événements enregistrés par les applications
ou les programmes.
 Le journal sécurité : ce journal enregistre les événements tels que les tentatives valides et
non valides d’ouverture de session ainsi que les événements liés à l’utilisation d’une
ressource.
 Le journal système : ce journal contient les événements enregistrés par les composants
système de Windows. L’échec du chargement d’un pilote ou d’un autre composant du système
lors du démarrage est consigné dans ce journal.

Cependant, lorsque l’ordinateur est configuré pour héberger certains services additionnels, des
journaux supplémentaires sont disponibles. Ainsi, si l’ordinateur est configuré comme contrôleur de
domaine, deux journaux supplémentaires sont créés :

 Le journal du service d’annuaire : ce journal contient les événements enregistrés par le


service Active Directory de Windows 2000, Windows Server 2003 ou Windows Server 2008.
 Le journal du service de réplication de fichiers : ce journal contient les événements
enregistrés par le service de réplication de fichiers FRS ou NTFRS de Windows.

Lorsque l’ordinateur est également configuré pour accueillir la fonction de serveur DNS, les événements
de ce service sont consignés dans un journal supplémentaire. Le journal du serveur DNS contient
uniquement les événements enregistrés par le service DNS de Windows. La figure suivante illustre ce
journal qui est donc accessible via les outils de gestion des journaux d’événements de Windows, mais
aussi directement à l’aide de la console de gestion MMC du DNS.

Le journal Événements DNS est situé comme les autres journaux dans le répertoire
%Systemroot%\system32\config\ et porte le nom dnsevent.evt. La figure suivante illustre le
niveau de détail des messages consignés dans ce journal.

En effet, dans cet exemple, un enregistrement de ressource non valide se trouve au sein de la zone
DNS corporate.net. Ce problème a pour effet de générer un numéro d’événement 1508, mais surtout
une explication très précise du problème.

Détection d’un enregistrement de ressource DNS non valide dans la zone

Page 86
Effectivement, nous constatons que le problème se situe à ligne 31 du fichier de zone dont le nom est
corporate.net.dns. Généralement, les messages propres à Windows et aux composants intégrés au
système sont relativement explicites. Malheureusement, il y aura des cas où certains messages ne
seront pas toujours aussi clairs que l’exemple ci-dessus. Aussi, il sera parfois nécessaire de chercher
plus de détails sur les circonstances de tel ou tel message. Vous pourrez accéder à la description des
messages Windows en utilisant les ressources spécifiées ci-dessous :

 Connectez-vous sur le site Microsoft Events and Errors Message Center à l’adresse :
http://www.microsoft.com/technet/support/eventserrors.mspx
 Installez le Kit de Ressources Techniques de Windows 2000 ou Windows Server 2003.
 Connectez-vous sur le site http://www.EventID.net.

4. Utilisation des journaux de débogage DNS

Windows Server 2003 et Windows Server 2008 supportent un nouveau mode de journalisation avancé
qui permet de sélectionner les types de messages et opérations spécifiques du service DNS.

Comme cela est le cas avec de nombreux produits, ces journaux ne sont pas activés par défaut pour
éviter une éventuelle surcharge de l’ordinateur. Ils seront donc activés uniquement en cas de besoin,
ou par exemple, à la demande du support Microsoft. Par exemple, l’activation des journaux de
débogage sur un serveur DNS donné aura pour effet de consigner dans le journal DNS.log les types
d’activité que vous aurez au préalable sélectionnés. Vous pouvez activer l’enregistrement de débogage
à l’aide de l’onglet Enregistrement de débogage via les propriétés de l’objet Serveur.

Par défaut, le journal DNS.log est stocké sur la partition système dans le dossier
%Systemroot%\system32\dns. Ce fichier, certes très utile pour aider au diagnostic des incidents DNS,
peut être consommateur d’espace disque, aussi la taille maximale est-elle fixée par défaut à 500 Mo.
Pour contourner d’éventuels problèmes d’espace disque, vous pouvez aussi changer l’emplacement
physique du fichier journal en le plaçant sur un autre disque physique ou sur une autre partition.

Notez que cette taille par défaut permet de consigner assez d’informations sur une période de temps
convenable pour pouvoir aider au diagnostic et à la résolution du problème. N’oubliez pas que
l’enregistrement de débogage ne s’arrêtera que si vous le spécifiez ou si l’espace disque devenait insuffisant
! Tant que la fonction est activée, le journal de débogage reste opérationnel et les entrées les plus anciennes
seront écrasées seulement lorsque la taille limite sera atteinte.

Lecture du journal de débogage DNS.log

Par défaut, le journal de débogage n’est pas activé. Cette fonctionnalité ne devrait être activée que pour
diagnostiquer un problème complexe. En effet, n’oubliez pas que ce mode de débogage peut être
particulièrement consommateur de ressources et ainsi affecter le comportement général de l’ordinateur. Par
conséquent, utilisez cette fonctionnalité temporairement lorsqu’il est nécessaire de disposer d’informations
plus détaillées.

Pour plus d’informations sur la surveillance du service DNS, cherchez "Surveillance et optimisation des
serveurs DNS" dans l’aide en ligne de Windows Server 2008.

Page 87
Restauration des paramètres par défaut
Il se peut qu’à l’issue de la mise en œuvre des nombreux paramètres du serveur DNS de Windows Server
2003 ou Windows Server 2008, certains paramètres n’aient pas été définis convenablement. Pour rétablir
un comportement plus rationnel, vous pourrez être amené à devoir restaurer les paramètres par défaut
de votre serveur DNS. Pour réaliser cette opération à l’aide de la console de gestion MMC du DNS,
effectuez un clic droit sur le serveur DNS approprié, puis Propriétés et sélectionnez l’onglet Avancés.
Cliquez sur Restaurer les paramètres par défaut, puis sur OK.

Restauration des paramètres par défaut du serveur DNS

Les paramètres restaurés respecteront les valeurs correspondant à l’installation par défaut du service
serveur DNS sur la machine. Ces valeurs sont spécifiées ci-dessous :

Désactiver la récursivité

Non sélectionné.

Lier les zones secondaires

Sélectionné.

Échec de chargement si ...

Non sélectionné.

Activer tourniquet (Round Robin)

Sélectionné.

Activer le tri de masques de réseau


Page 88
Sélectionné.

Protéger le cache contre la pollution

Sélectionné.

Vérifier les noms

Sur plusieurs octets (UTF8).

Charger les données de zone ...

Depuis Active Directory et le Registre.

Activer le nettoyage automatique ...

Non sélectionné.

Cette opération nécessite que vous soyez membre du groupe Administrateurs sur l’ordinateur local, ou que
vous ayez reçu par délégation les autorisations nécessaires. Si l’ordinateur est joint à un domaine, les
membres du groupe Admins du domaine peuvent effectuer cette procédure.

Interface NetBIOS et Configuration DNS du client Windows XP


Professionnel

1. À propos de l’interface NetBIOS

a. Interface NetBIOS et Configuration DNS du client Windows XP Professionnel

Les systèmes d’exploitation Microsoft supportent TCP/IP depuis plus d’une quinzaine d’années. Avec
les premières versions de PC/LAN puis avec Microsoft OS/2 Lan Manager et enfin Windows NT 3.1 dès
1993, et, aujourd’hui avec toutes les technologies qui gravitent autour de l’annuaire Active Directory,
les services TCP/IP ont pris de plus en plus d’importance au sein des systèmes et applications
Windows. Cette section présente les concepts et bonnes pratiques de la configuration TCP/IP du poste
de travail Windows XP Professionnel sachant que vous pourrez réappliquer ces principes sur les
machines exploitant Windows 2000, Windows Server 2003 ou Windows Server 2008.

b. Types de noms à prendre en charge

Pour commencer, il convient de rappeler que, par défaut, les systèmes d’exploitation Windows 2000,
Windows XP, Windows Server 2003 et Windows Server 2008 utilisent un espace de noms et un
système de résolution de noms pour associer aux adresses IP des noms d’ordinateurs, de services et
de domaines. Ces noms seront, bien sûr, plus faciles à utiliser que les adresses réelles de ces
éléments.

Bien qu’il ne s’agisse pas des seuls types de noms existants dans les systèmes réseaux, nous pouvons
considérer qu’aujourd’hui, il existe deux grands types de noms :

 Les noms d’hôtes : les noms d’hôtes sont utilisés par des programmes qui utilisent
l’interface de programmation Windows Sockets. Aujourd’hui, la majorité des applications
s’appuie sur cette interface. Par exemple, les applications telles que Microsoft Internet
Explorer ou des outils de gestion TCP/IP comme la commande tracert utilisent cette
interface de programmation réseau.
 Les noms NetBIOS : les noms NetBIOS sont utilisés par des programmes ou services
réseau qui utilisent l’interface de programmation NetBIOS. Par exemple, des applications
telles que le "Client pour les réseaux Microsoft" et le "Partage de fichiers et d’imprimantes
pour les réseaux Microsoft" sont aussi des programmes qui utilisent l’interface NetBIOS.
Bien sûr, cette liste ne s’arrête pas là et nous pouvons aussi citer le service "Affichage des
messages" utilisé à l’aide de la commande net send. Avant que TCP/IP ne s’impose grâce à

Page 89
l’émergence de l’Internet et l’adhésion de leaders tels que IBM, Microsoft et Novell, les
réseaux exploitaient des protocoles de transport tels que IPX/SPX, Decnet, SNA, AppleTalk,
chacun avec ses propres API de développement d’applications réseau. NetBIOS - Network
Basic Input and Output System, fut alors défini pour jouer le rôle d’interface de
programmation générique pour le développement d’applications réseau.

c. Positionnement de l’interface NetBIOS par rapport à TCP/IP

Le protocole NetBIOS existe en tant qu’interface de type session c’est-à-dire au niveau 5 du modèle
OSI. Toutefois, ce protocole existe aussi en tant que véritable transport au niveau 4 du même
modèle. L’implémentation de Microsoft, bien connue sous le nom "NetBEUI - NetBIOS Extended User
Interface", en est la plus performante implémentation. Ce transport rivalisa pendant de nombreuses
années avec Novell Netware et IBM OS/2 Warp Server avec NetBIOS 3.0.

Ne disposant pas de services réseau au niveau 3 du modèle OSI, le protocole NetBEUI n’est bien sûr,
pas routable. Cependant, ce protocole de transport est "source routable" sur Token Ring et peut
traverser les ponts de niveaux 2.

Relation entre le modèle TCP/IP et les Applications

Finalement, la couche Application est la couche la plus importante. C’est elle qui permettra ou non
aux applications du réseau d’utiliser les services de la pile de protocoles TCP/IP toute entière. TCP/IP
propose deux interfaces permettant aux applications réseau d’utiliser ses services.

 L’interface Windows Sockets : cette interface, aussi appelée Winsock, joue le rôle
d’interface standard entre les applications basées sur les Sockets et les protocoles de la
suite TCP/IP. Le concept est le suivant : l’application spécifie le protocole, l’adresse IP et le
port à utiliser vers l’application distante. Les services de l’interface Windows Sockets
permettent de réaliser cette fonction ainsi que l’ouverture et la fermeture des connexions et
l’envoi et la réception des données.
 L’interface NetBIOS over TCP/IP : cette interface, aussi appelée NetBT, joue le rôle
d’interface standard entre les applications NetBIOS. Elle offre des services de noms
complets, des services de livraison de données en mode connecté et déconnecté (c’est-à-
dire en TCP et UDP) ainsi que des services de gestion de sessions.

2. Plate-forme Windows et interface Windows

a. Services NetBIOS et codes de services Microsoft

Dans la mesure où de nombreuses applications continuent d’utiliser l’interface NetBIOS, il est


important de connaître les codes de services utilisés par les composants réseau Microsoft. Ces codes
seront enregistrés sur le réseau local sous la forme de messages de type "limited broadcasts" c’est-à-
dire des messages de diffusion dont l’adresse de destination est limitée au réseau ou au sous-réseau
TCP/IP source. Par exemple, sur le réseau 10.1.0.0 avec un préfixe de 16 bits c’est-à-dire un masque
de sous-réseau de classe B, l’adresse de destination de ces messages de demandes d’enregistrements
sera 10.1.255.255. Bien entendu, comme les routeurs IP ne routent que les messages dirigés
(unicasts), ces messages sont limités au sous-réseau IP local.

Toutes les machines présentes sur le réseau seront ainsi informées et pourront éventuellement
contester la demande d’enregistrement. C’est ce qui se passera si vous démarrez inopinément deux
ordinateurs portant le même nom NetBIOS sur le même réseau. Le dernier ordinateur à démarrer
sera exclu du réseau NetBIOS jusqu’à ce que le problème de conflit soit résolu.

En plus de l’enregistrement des noms NetBIOS via des messages de diffusion, l’implémentation de
NetBIOS sur TCP/IP prévoit l’usage des serveurs NBNS (NetBIOS Name Servers) tels que WINS -
Windows Internet Naming Service. Ces serveurs permettent de centraliser tous les enregistrements
NetBIOS. Bien entendu, ces serveurs d’enregistrement des noms NetBIOS fonctionnent de façon
dynamique et permettent de diminuer de manière substantielle le nombre de messages de diffusion.
La figure suivante montre l’usage de la commande nbtstat qui permet d’afficher les codes des
services d’une machine donnée.

Page 90
Affichage des noms NetBIOS enregistrés par la machine 192.168.0.47.Le code [1B] montre que
la machine joue le rôle de contrôleur de domainemaître d’exploration pour le domaine NetBIOS
CORP2003

La commande nbtstat est une vieille commande NetBIOS. Elle existe depuis les premières
implémentations de Microsoft OS/2 LAN Manager. En plus de contrôler individuellement chaque
machine, vous pourrez accéder à l’ensemble des enregistrements de l’espace de noms NetBIOS en
consultant la ou les bases de données des serveurs WINS.

Les types de noms NetBIOS présentés ci-après sont les plus couramment utilisés dans les réseaux
Microsoft.

nom_ordinateur[00h] : ce nom est enregistré par le service Station de travail sur le client WINS.

nom_ordinateur[03h] : ce nom est enregistré par le service Affichage des messages sur le client
WINS.

nom_ordinateur[06h] : ce nom est enregistré sur le client WINS par le service de routage et
d’accès distant, lorsque ce service est démarré.

nom_domaine[1Bh] : ce nom est enregistré par chaque contrôleur de domaine Windows NT Server
4.0 jouant le rôle d’explorateur principal de domaine (Domain Master Browser). Cet enregistrement
de nom est utilisé pour permettre l’exploration à distance des domaines.

nom_ordinateur[1Fh] : ce nom est enregistré par les services NetDDE (Network Dynamic Data
Exchange). Il ne s’enregistre que si les services NetDDE sont démarrés.

nom_ordinateur[20h] : ce nom est enregistré par le service Serveur sur le client WINS.

nom_ordinateur[21h] : ce nom est enregistré sur le client WINS par le service Client RAS lorsque
ce service est démarré.

nom_ordinateur[BEh] : ce nom est enregistré par l’Agent de surveillance du réseau (Agent


Netmon) et n’apparaîtra que si ce service est démarré sur le client WINS.

nom_ordinateur[BFh] : ce nom est enregistré par l’utilitaire de surveillance du réseau (Analyseur


de trames fourni avec Microsoft Systems Management Server 2.0 ou 2003).

nom_utilisateur[03h] : ce nom est enregistré pour chacun des utilisateurs connectés. Faites
attention : si plusieurs utilisateurs se connectent sous le même nom, seul le premier ordinateur
enregistré sur le réseau, sera en mesure d’enregistrer le nom.

nom_domaine[00h] : il s’agit d’un nom de groupe NetBIOS enregistré par le service Station de
travail de façon à pouvoir recevoir les diffusions d’exploration provenant d’ordinateurs LAN Manager.

nom_domaine[1Ch] : il s’agit d’un nom de groupe NetBIOS utilisé par les contrôleurs de domaine
Windows NT dans le cadre du domaine. Il peut contenir jusqu’à 25 adresses IP. Notez que cet
enregistrement n’est pas utilisé par Active Directory.

nom_domaine[1Dh] : il s’agit d’un nom de groupe NetBIOS utilisé par les explorateurs principaux
de chaque sous-réseau, sachant qu’il ne peut y avoir qu’un seul explorateur principal par sous-réseau.
Les explorateurs de sauvegarde (Backup Browsers) utilisent ce nom pour communiquer avec
Page 91
l’explorateur principal (Master Browser), en extrayant la liste des serveurs disponibles de l’explorateur
principal.

nom_groupe[1Eh] : il s’agit d’un nom de groupe NetBIOS ordinaire. Tout ordinateur configuré en
tant qu’explorateur de réseau peut diffuser vers ce nom, et écouter les diffusions vers ce nom, pour
choisir un explorateur principal. Un nom de groupe mappé statiquement utilise ce nom pour
s’enregistrer sur le réseau. Lorsqu’un serveur WINS reçoit une demande de nom se terminant par
[1E], il renvoie toujours l’adresse de diffusion du réseau local du client qui a émis la demande.

nom_groupe[20h] : il s’agit d’un nom de groupe NetBIOS spécial appelé groupe Internet. Il est
enregistré sur les serveurs WINS pour identifier des groupes d’ordinateurs pour les besoins de
l’administration.

--__MSBROWSE__[01h] : il s’agit d’un nom de groupe NetBIOS enregistré par l’explorateur


principal pour chaque sous-réseau. Lorsqu’un serveur WINS reçoit une demande concernant ce nom,
il renvoie toujours l’adresse de diffusion du réseau local du client qui a émis la demande.

Les codes de services présentés plus haut sont des codes relatifs aux composants réseau Microsoft. De
nombreuses applications non Microsoft continuent d’utiliser du code nécessitant l’interface de
programmation NetBIOS. De fait, le support de cette interface et aussi des serveurs WINS est toujours
nécessaire.

Pour plus de renseignements sur la configuration des serveurs WINS, consultez le Kit de ressources
techniques de Windows Server 2003.

b. Résolution de noms NetBIOS

La résolution de noms NetBIOS signifie qu’il est possible de mettre en correspondance un nom
NetBIOS avec l’adresse IP qui lui est associée. Pour rappel, un nom NetBIOS est une adresse sur 16
octets utilisée pour identifier la ressource NetBIOS au sein du réseau. En fait, les 15 premiers octets
sont disponibles pour le nom tandis que le dernier, le 16ème donc, est réservé au code de service. Par
définition, le nom NetBIOS est soit un nom unique sur l’ensemble du réseau NetBIOS, soit un nom de
groupe qui sera utilisé par tous les membres dudit groupe. Dans ce dernier cas, le nom NetBIOS est
qualifié de nom "NetBIOS non exclusif".

Finalement, lorsqu’un processus NetBIOS communique avec un autre processus NetBIOS situé sur un
ordinateur du réseau, alors le nom unique est utilisé. Par contre, dans le cas de communications d’une
application vers plusieurs processus situés sur plusieurs ordinateurs, alors un nom de groupe NetBIOS
sera utilisé.

Enregistrement des ordinateurs et services dans le réseau NetBIOS

Le service "Partage de fichiers et d’imprimantes pour les réseaux Microsoft" est un exemple de
processus sur un ordinateur exécutant Windows XP Professionnel. Lorsque votre ordinateur démarre,
ce service enregistre un nom NetBIOS unique basé sur le nom de votre ordinateur. Le nom exact
utilisé par le service est le nom limité à 15 caractères. Le 16ème caractère du nom (en hexadécimal,
valeur de 00 à FF) indiquera toujours le type de ressource. Dans notre exemple, le service serveur
déclare le code 0x20. Ce mécanisme d’enregistrement se produira pour chaque application
appartenant à l’espace de noms NetBIOS.

c. Ordre des résolutions NetBIOS

Le mécanisme exact selon lequel les noms NetBIOS sont résolus en adresses IP dépend du type de
nœud NetBIOS configuré sur la machine. Le RFC 1001, "Protocol Standard for a NetBIOS Service on a
TCP/UDP Transport: Concepts and Methods" définit quatre types de nœuds NetBIOS :

Nœud de type B-nœud (diffusion) : le mode B-nœud (Broadcast node) utilise les requêtes de
noms NetBIOS de diffusion pour l’inscription et la résolution de noms. Le B-nœud présente deux
problèmes principaux :

 les diffusions perturbent chaque nœud du réseau local,


 les routeurs ne transmettant pas, par défaut, les messages de diffusion ; par conséquent,
seuls les noms NetBIOS du réseau local peuvent être résolus.

Nœud de type P-nœud (point à point) : le P-nœud (Point to Point node) utilise un serveur de nom
NetBIOS (NBNS) tel qu’un serveur WINS pour résoudre les noms NetBIOS. Le P-nœud n’utilise pas du

Page 92
tout les diffusions. Toutes les résolutions sont dirigées en unicast vers le serveur de noms WINS. Ce
type de nœud est rarement utilisé.

Nœud de type M-nœud (mixte) : le M-nœud (Mixed node) est une combinaison de B-nœud et P-
nœud. Par défaut, un M-nœud fonctionne d’abord comme un B-nœud. Si un M-nœud ne peut pas être
utilisé pour résoudre un nom par diffusion, il demande un NBNS à l’aide du P-nœud. Ce type de nœud
est rarement utilisé.

Nœud de type H-nœud (hybride) : le H-nœud (Hybrid node) est une combinaison de P-nœud et B-
nœud. Par défaut, un H-nœud fonctionne comme un P-nœud. Si un H-nœud ne peut pas être utilisé
pour résoudre un nom via le NBNS, alors il utilise une diffusion pour résoudre le nom. Comme il s’agit
du type de nœud recommandé par Microsoft, il est bien sûr le plus couramment utilisé. Le fait de
déclarer l’utilisation d’un ou plusieurs serveurs WINS pour disposer de bonnes résolutions NetBIOS
configure automatiquement le type H-node. Vous pouvez déterminer le type de nœud à l’aide de la
commande ipconfig /all.

d. Ordre de résolution d’un poste de travail de type H-node

La résolution de noms NetBIOS pour les clients WINS est directement dépendante du module NetBT
qui implémente l’interface NetBIOS sur TCP/IP. La méthode réelle de résolution de noms est
heureusement transparente pour les applications et les utilisateurs.

Pour Windows 2000 et Windows XP Professionnel, les clients WINS utilisent la séquence suivante pour
résoudre un nom :

 Si le nom demandé comporte plus de 15 caractères ou s’il a la forme d’un nom pleinement
qualifié (FQDN contenant des points "."), alors la requête est directement transmise au
système de résolution DNS.
 Sinon, l’ordinateur contrôle si le nom est présent dans le cache de noms distants du client.
Vous pouvez le consulter à l’aide de la commande nbtstat -c.
 Sinon, une requête de résolution de nom NetBIOS est envoyée vers les serveurs WINS
configurés.
 Sinon, un message de diffusion est envoyé vers l’adresse IP du sous-réseau.
 Sinon, le fichier LMHOSTS est vérifié à condition que l’option Activer la recherche de
LMHOSTS soit activée dans les propriétés Protocole Internet (TCP/IP) de la connexion,
onglet WINS. Par défaut, cette option est activée.
 Sinon, le fichier HOSTS est vérifié.
 Enfin, les résolutions DNS sont invoquées. Dans un premier temps, le cache de noms DNS
sera consulté, puis un ou plusieurs serveurs DNS seront finalement interrogés.

Pour plus de renseignements sur les résolutions de noms et un organigramme précis de ce processus
lorsque l’ordinateur est équipé de plusieurs cartes réseaux configurées avec des paramètres TCP/IP
spécifiques, consultez le Kit de ressources techniques Microsoft Windows Server 2003.

Déclaration des adresses des serveurs WINS, sélection du type de nœud NetBIOS et
nombre de serveurs WINS déclarés

Avec les versions antérieures de Windows (Windows NT et Windows 9x), il était possible de configurer
manuellement les clients afin qu’ils utilisent uniquement, au minimum un serveur WINS principal et,
au mieux, un serveur secondaire additionnel. Ce dernier était alors utilisable en cas de défaillance du
premier. La figure ci-après montre l’onglet WINS regroupant l’ensemble des paramètres relatifs à
l’interface et au support de NetBIOS.

Page 93
Paramètres de serveurs WINS et utilisation de la recherche LMHOSTS

Une fois déclarées, les adresses des serveurs WINS seront sollicitées dans l’ordre où elles
apparaissent dans la liste. Notez que vous avez la possibilité de réorganiser cette liste à l’aide des
flèches situées sur la droite.

Sous Windows 9x et Windows NT, les serveurs WINS déclarés étaient au nombre de deux (le serveur WINS
principal et le serveur WINS secondaire) et figuraient sur la fenêtre principale des paramètres TCP/IP. Sur
les systèmes Windows 2000 et Windows XP, l’interface NetBIOS devient moins obligatoire. De fait, les
paramètres WINS ont été déplacés vers ce nouvel emplacement.

Même si les systèmes d’exploitation Windows 2000, Windows XP Professionnel, Windows Server 2003,
Windows Vista et Windows Server 2008 ne nécessitent pas l’interface NetBIOS pour leur fonctionnement
interne, cette interface devrait toujours être présente pour assurer l’interopérabilité nécessaire avec les
systèmes et applications antérieurs. C’est la raison pour laquelle, il n’est pas recommandé de désactiver
l’interface NetBIOS.

Avec Windows Server 2003 et Windows Server 2008 vous pouvez configurer les clients WINS pour
qu’ils utilisent jusqu’à douze serveurs WINS. Vous pourrez gérer cette liste de deux façons :

 De façon statique via les propriétés du protocole TCP/IP.

Page 94
Déclaration de la liste des serveurs WINS à l’aide des paramètres TCP/IP et de l’onglet WINS

 De façon dynamique à l’aide du protocole DHCP en configurant l’option DHCP 44.

Déclaration de la liste des serveurs WINS à l’aide de l’option 44 du protocole DHCP

La déclaration de deux serveurs WINS est nécessaire et suffisante dans la majorité des cas.
Cependant, cette limitation a été mise en avant à plusieurs reprises par certains clients.

En effet, il n’est pas rare qu’il soit nécessaire de disposer de deux serveurs WINS par site. Dans le cas
d’une défaillance des deux serveurs WINS du site, par exemple suite à corruption des deux serveurs
WINS locaux ou d’une indisponibilité de cette partie du réseau, il serait souhaitable de pouvoir être
secouru par un serveur WINS situé sur un site distant. Ce type de limitation n’existe pas concernant
les paramètres de serveurs DNS. Microsoft a donc procédé à cette modification. Finalement, une liste
plus conséquente de serveurs WINS offre aux clients une meilleure tolérance de pannes lorsque leurs
serveurs WINS principal et secondaire ne sont pas disponibles.

Windows 2000, Windows XP Professionnel, Windows Server 2003 et Windows Server 2008 supportent
désormais jusqu’à douze serveurs WINS déclarés. Néanmoins, notez que seules les deux premiers serveurs
déclarés pourront être utilisés pour réaliser l’enregistrement dynamique des clients. Les deux serveurs situés
au plus haut de la liste sont donc équivalents au serveur WINS principal et au serveur WINS secondaire que
nous connaissions sur les machines fonctionnant sous Windows 9x et Windows NT.

Vous pourrez encore utiliser la commande ipconfig /all. Celle-ci affiche correctement les paramètres
de WINS principal et secondaire ainsi que les éventuels autres serveurs supplémentaires.

e. Interface et noms NetBIOS, résolutions WINS et domaines Active Directory

Il est fortement conseillé de configurer vos ordinateurs Windows avec l’adresse IP d’au moins deux
serveurs WINS de telle sorte qu’il soit possible de résoudre des noms NetBIOS distants.

Dans l’absolu, les ordinateurs Windows 2000 ou ultérieur membres d’un domaine Active Directory
n’ont pas besoin de recourir aux services de résolutions NetBIOS pour inter-opérer avec l’annuaire
Active Directory. Cependant, ce pourrait être malgré tout nécessaire si des applications NetBIOS
Page 95
manipulaient des noms NetBIOS à résoudre par les clients. A fortiori, il sera indispensable de
configurer les ordinateurs clients Active Directory fonctionnant sous Windows 2000 ou Windows XP
Professionnel avec l’adresse IP d’un ou plusieurs serveurs WINS s’ils doivent communiquer avec
d’autres ordinateurs exécutant une quelconque version de Windows qui ne serait pas dans un
environnement Active Directory.

3. Configuration d’un poste client Active Directory

a. À propos des Clients Active Directory

Les seuls véritables clients Active Directory sont les systèmes fonctionnant sous Windows 2000,
Windows XP Professionnel, Windows Server 2003, Windows Vista et Windows Server 2008.
Évidemment, ce sera aussi le cas des prochaines versions de Windows.

Les modules clients qui supportent les protocoles et mécanismes fondamentaux sont directement
intégrés dans le système d’exploitation. Pour rappel, ces composants fondamentaux sont le système
de localisation principal basé sur le DNS, les protocoles LDAP, NTP et Kerberos ainsi que les services
de gestion des configurations offerts par la technologie Microsoft IntelliMirror. Ainsi, aucune action
supplémentaire n’est à réaliser sur les ordinateurs clients "intelligents" lorsqu’un domaine Windows NT
4.0 est mis à niveau vers l’annuaire Active Directory. Les postes de travail activeront lors du prochain
redémarrage les modules nécessaires à leur fonctionnement avec le domaine Active Directory.
Comme toujours, la condition sine qua non, c’est que les postes de travail puissent "découvrir" le
domaine Active Directory à l’aide des serveurs DNS de l’entreprise.

Microsoft n’a pas pour autant - complètement - laissé de côté les anciens systèmes. C’est pour cette
raison que le client Active Directory a été développé. Le Client Active Directory est donc un module
additionnel que vous trouverez sur le CD-Rom de Windows Server 2003 et en téléchargement sur le
site de Microsoft. Ainsi, de nombreuses fonctionnalités Active Directory réservées à Windows 2000 ou
Windows XP Professionnel sont disponibles sur les ordinateurs d’anciennes technologies tels que ceux
fonctionnant sous Windows 9x ou Windows NT 4.0.

Le Client Active Directory n’est plus livré sur le CD-Rom de Windows Server 2008. Pour télécharger ce
composant additionnel ou obtenir plus d’informations techniques, consultez l’article 288358 de la base de
connaissances Microsoft How to install the Active Directory Client Extension.

Les fonctionnalités ci-dessous sont supportées par le module Client Active Directory :

Support de la reconnaissance des sites Active Directory : le module Client Active Directory
permet une ouverture de session à partir du contrôleur de domaine le plus proche du client. La
sélection des contrôleurs de domaines est traitée au chapitre suivant.

Support de l’interface ADSI (Active Directory Service Interfaces) : le module Client Active
Directory permet l’usage de scripts en interaction avec le domaine Active Directory. L’interface ADSI a
pour objet d’offrir aux développeurs une interface de programmation commune pour manipuler tous
les services d’annuaires.

L’interface ADSI permet de réaliser des opérations sur les systèmes d’annuaires tels que Windows NT, la
NDS (Netware Directory Services) de Novell, Exchange Server 5.5 et bien sûr, l’annuaire Active Directory.

Support du système de fichiers distribué DFS (Distributed File System) : le module Client
Active Directory permet aux utilisateurs d’accéder à des ressources hébergées au sein d’une racine
DFS autonome ou intégrée à l’annuaire Active Directory prise en charge par des serveurs exécutant
Windows 2000 ou Windows Server 2003.

À propos du service "Système de Fichiers Distribués" : les serveurs Windows 2000 et Windows
Server 2003 Standard Edition ne supportent qu’une seule racine DFS par serveur. Cette contrainte a
été supprimée sur les serveurs DFS fonctionnant sous Windows Server 2003 Enterprise Edition et
Windows Server 2008.

Support des authentifications de type NTLM version 2 : le module Client Active Directory permet
de réhausser le niveau des authentifications vers le domaine Windows. Ainsi, les authentifications
NTLM version 2 qui étaient jusque-là réservées à Windows NT sont elles disponibles aussi pour des
ordinateurs clients fonctionnant sous Windows 9x.

La modernisation d’une ancienne infrastructure vers l’annuaire Active Directory peut avoir été justifiée
par la prévision de nouveaux besoins et aussi de nouvelles contraintes à court ou moyen termes.

Page 96
Parmi ces nouvelles contraintes, nous retrouverons de nouvelles exigences en matière de sécurité et
d’authentification. Notez que :

 Les postes Windows 2000 et ultérieurs supportent le plus haut niveau d’authentification
possible via l’usage du protocole Kerberos version 5 et des certificats X.509v3 pour les
authentifications basées sur les certificats ou via une carte à puce (Smart Logon).
 Les postes Windows NT supportent au mieux les authentifications NTLM version 1 et version
2.
 Les postes Windows 9x supportent au mieux les authentifications LM (LAN Manager).

À la différence de Windows 9x (c’est-à-dire Windows 95 et Windows 98), les postes Windows ME (Millennium
Edition) supportent de base l’authentification NTLM version 2.

Sur les contrôleurs de domaine Windows Server 2003 et Windows Server 2008, les authentifications
de type Lan Manager sont désactivées par défaut. Par conséquent, dans le cas où une demande
d’ouverture de session de domaine serait prise en charge par un contrôleur de domaine Windows
Server 2003, les clients Windows 9x pourront être en échec d’ouverture de session. Pour solutionner
ce problème causé par ces nouveaux paramètres de sécurité renforcée, vous pourrez opter pour une
des solutions proposées ci-dessous :

 Mettre à niveau les ordinateurs Windows 9x vers Windows XP Professionnel. Il s’agit bien
entendu de la meilleure alternative.
 Installer le module "Client Active Directory" sur les postes Windows 9x. Ce choix permet de
planifier le renouvellement du matériel ultérieurement tout en progressant en terme de
contrôle des accès au niveau du domaine.

Le fait d’installer le module "Client Active Directory" ne renforce pas la sécurité du poste de travail Windows
9x ou Windows NT. Cependant, l’utilisation du protocole NTLM version 2 en lieu et place de l’authentification
Lan Manager, renforcera le niveau de sécurité des opérations réseau entre l’ordinateur client et le domaine
Windows Active Directory dans sa totalité.

Pour plus d’informations sur l’activation des authentifications, consultez l’article de la Base de
connaissances Microsoft Q239869.

Réactiver le support du protocole d’authentification LAN Manager

Cette opération n’est pas recommandée. Cependant, si le nombre de postes Windows 9x est encore
important, vous pouvez décider d’attendre le renouvellement des machines et donc, de ne pas
installer le module "Client Active Directory".

Vous pouvez configurer ce paramètre de sécurité en ouvrant la stratégie de sécurité du contrôleur de


domaine que vous trouverez dans le groupe de programmes Outils d’Administration du contrôleur de
domaine.

Page 97
Modification des paramètres de sécurité d’un contrôleur de domaine

Une fois la stratégie de sécurité chargée, développez l’arborescence de la console et placez-vous à


l’emplacement Paramètres de sécurité\Stratégies locales\Options de sécurité\.

Le temps de chargement des paramètres de stratégies est fonction de la puissance de la machine et des
informations à charger. Par conséquent, ce temps est très variable et peut être compris entre quelques
secondes et une minute.

Paramètres par défaut du niveau d’authentification Lan Manager

L’écran précédent montre que le contrôleur de domaine ne gère que des réponses de type NTLM. En
fait, la documentation précise que dans ce cas, les clients utiliseront seulement l’authentification NTLM
et la sécurité de session NTLMv2, si le serveur la prend en charge.

Pour obtenir plus de renseignements sur l’ensemble des paramètres de stratégie de sécurité,
consultez "Description des paramètres de sécurité" dans l’aide en ligne.

Attention à la manipulation des stratégies de sécurité des contrôleurs de domaine Windows Server 2003 et
Windows Server 2008 ! Avant toutes modifications, il est fortement recommandé de consulter l’article
823659 intitulé « Client, service, and program incompatibilities that may occur when you modify security
settings and user rights assignments » disponible à l’adresse ci-dessous :
http://support.microsoft.com/kb/823659/en-us

Propriétés du Carnet d’adresses Windows (WAB, Windows Address Book) de Active


Directory

Le module Client Active Directory permet aux utilisateurs authentifiés dans le domaine Active
Directory d’accéder à leurs informations personnelles. Le bouton Propriétés permet ensuite à
l’utilisateur de consulter et éventuellement de modifier les informations présentées.

De cette manière, tout utilisateur peut atteindre et modifier des propriétés qu’il "maîtrise" bien. Ce
sera le cas de son numéro de téléphone ou de son adresse personnelle.

Page 98
Propriétés de l’utilisateur Bob Durand au sein du domaine Active Directory

Si vous souhaitez qu’un utilisateur donné ait la possibilité de modifier un attribut d’un autre objet
utilisateur, il vous suffit d’affecter les permissions nécessaires sur l’objet et sur l’attribut concernés.
Ce principe, appelé "Principe de délégation des droits", est un point très important relatif à l’usage
"général" que les entreprises souhaitent faire de leur(s) annuaire(s). Les concepts de délégation et la
mise en œuvre d’une stratégie de délégation sont présentés plus loin.

La recherche dans Active Directory

Le module Client Active Directory étend les options de recherches disponibles à partir du menu
Démarrer. Les utilisateurs peuvent ainsi rechercher des imprimantes, des personnes, des ordinateurs
dans un domaine Active Directory.

À propos des recherches sur les objets de type "imprimantes", pour que les imprimantes puissent être
localisées, elles doivent être publiées. Pour plus d’informations sur la publication d’imprimantes dans Active
Directory, consultez l’article Q234619, "Publishing a Printer in Windows 2000 Active Directory", de la Base
de connaissances Microsoft.

Fonctions non supportées par le module Client Active Directory

Les systèmes d’exploitation Windows 2000 et Windows XP Professionnel disposent de fonctionnalités


dont le Client Active Directory, de Windows 9x et Windows NT 4.0, est dépourvu.

Ainsi le Client Active Directory ne prend pas en charge le protocole d’authentification Kerberos v5
(mais seulement NTLM version 2), ni les Stratégies de groupe et la technologie IntelliMirror, ni les
suffixes UPN (User Principal Names) et SPN (Service Principal Names), ni l’authentification mutuelle.
Le seul moyen de bénéficier de ces fonctionnalités importantes est de réaliser une mise à niveau vers
Windows 2000, Windows XP Professionnel ou Windows Vista.

b. Postes de travail Windows XP et paramètres DNS nécessaires aux environnements de


domaines Active Directory

Les clients Active Directory tels que Windows 2000, Windows XP Professionnel ou Windows Server
2003 ou 2008, utilisent les services DNS comme service de localisation principal et exclusif. Les
détections réalisées grâce aux résolutions DNS permettront ainsi de résoudre les éléments importants
que sont les noms de domaines, de sites et de services Active Directory.

Au cours de l’installation de l’annuaire Active Directory, la zone DNS relative au domaine Active
Directory ainsi que la zone du domaine racine de la forêt sont mises à jour dynamiquement avec les
enregistrements de ressources (SRV, A et CNAME) des nouveaux contrôleurs de domaine.
Page 99
Le processus détaillé de recherche et de sélection des contrôleurs de domaines est détaillé (cf.
Chapitre Localisation des services Active Directory et services DNS).

Les paramètres concernant la configuration DNS impliquent donc une validation technique de la part
des équipes réseau et Active Directory. Une fois validés, ces paramètres devront être appliqués avec
rigueur pour garantir un fonctionnement normal des ordinateurs membres du domaine au sein de
celui-ci.

La liste des points relatifs à la configuration des propriétés TCP/IP pour chaque ordinateur membre
d’un domaine Active Directory est spécifiée ci-après.

Définition d’un nom d’ordinateur et d’hôte DNS pour chaque ordinateur

Par exemple, dans le domaine DNS dont le nom complet (FQDN) est eu.company. com, le nom
d’ordinateur DNS complet pourra être pc-marketing-1.eu.company.com. Ce nom d’hôte aura comme
conséquence que le nom NetBIOS de l’ordinateur, appelé depuis de nombreuses années "computer
name", sera PC-MARKETING-1. Ce nom de 14 caractères est conforme puisqu’il n’atteint pas la limite
des 15 caractères autorisés par l’interface NetBIOS.

Héritage du nom d’hôte TCP/IP sur le nom NetBIOS de l’ordinateur

Cependant, un tel nommage empêcherait d’utiliser un nom tel que pc-marketing-100. Il serait
automatiquement tronqué et indexé en cas de conflits. Par conséquent, il serait judicieux dans cet
exemple de nommer les ordinateurs de ce département avec un nommage plus court tel que pc-
market-xxx.

Microsoft recommande de faire en sorte que le nom d’hôte et le nom NetBIOS soient identiques.

Définition d’un suffixe DNS principal pour l’ordinateur

Vous devez définir et approuver le nom de domaine DNS qui est placé après le nom d’ordinateur ou
d’hôte, lequel formera le nom complet de l’ordinateur (FQDN). Dans l’exemple précédent, le suffixe
DNS principal est eu.company.com. La case à cocher Modifier le suffixe DNS principal lorsque les
adhésions au domaine sont modifiées permet la mise à jour automatique du suffixe DNS principal
en fonction de l’appartenance au domaine Active Directory.

Bien que cette valeur ne produise aucun effet sur l’appartenance réelle de l’ordinateur au domaine, la
modification du suffixe DNS pourra générer les problèmes suivants :

 Les autres utilisateurs du réseau pourront avoir des difficultés à trouver l’ordinateur et
réaliser un contrôle d’accès à son encontre.
 L’ordinateur ne pourra réellement fonctionner dans le domaine Active Directory que si le
domaine autorise les ordinateurs membres du domaine à utiliser un suffixe DNS principal
différent des noms de domaines DNS Active Directory.

Par défaut, le suffixe DNS principal de l’ordinateur doit obligatoirement correspondre au nom du
domaine Active Directory auquel appartient l’ordinateur. Pour autoriser un ou plusieurs suffixes DNS
principaux différents, l’administrateur du domaine doit déclarer manuellement une liste de suffixes
autorisés en créant l’attribut msDS-AllowedDNSSuffixes dans le conteneur d’objet du domaine.

Page 100
Utilisation d’ADSIEdit pour modifier l’attribut msDs-AllowedDNSSuffixes sur l’objet de classe
domainDNS dont le DN est DC=Corp2003,DC=Corporate, DC=net

Un nom d’ordinateur complet est composé du nom d’ordinateur et du suffixe DNS principal dont la
longueur peut atteindre 255 caractères au maximum. Cette limite comprend les points nécessaires
pour délimiter les différents domaines ainsi que le nom d’hôte. Notez que la longueur du nom d’hôte
ne peut excéder 63 caractères. Microsoft recommande que le suffixe DNS principal par défaut soit
utilisé.

Définition d’une liste de serveurs DNS

Vous devez définir pour chaque site géographique, quels sont les serveurs DNS pour les clients lors de
la résolution des noms DNS, tels qu’un serveur DNS préféré, et les serveurs DNS secondaires à
utiliser lorsque le serveur principal n’est pas disponible.

Serveur DNS préféré et auxiliaire d’un ordinateur Windows 2000, Windows XP, Windows Server
2003 ou Windows Server 2008

La figure précédente montre le cas particulier des paramètres DNS d’un contrôleur de domaine Active
Directory. Dans la mesure où il est recommandé que chaque site dispose d’un contrôleur de domaine
et d’un serveur DNS, il est clair que ces deux rôles majeurs sont fréquemment assurés par la même
machine. Par conséquent, le contrôleur de domaine est souvent client DNS de lui-même. Il sera aussi
client d’un serveur DNS auxiliaire, lequel sera de préférence situé sur le même site. Dans le cas où il
n’y aurait qu’un seul serveur DNS sur le site, alors on pourra sélectionner un serveur DNS additionnel
situé sur un site distant.

La génération des demandes de résolution DNS est une part importante du travail à réaliser côté
client. C’est pour cette raison que se trouvent sur l’onglet DNS, les paramètres avancés qui
permettent de déterminer comment la partie "client DNS" traitera les noms qui ne sont pas
pleinement qualifiés. Les paramètres DNS que vous devez définir sont présentés ci-après.

Page 101
Paramètres avancés du client DNS (DNR, Domain Name Resolver)

Déclaration de multiples serveurs DNS et ordre de sélection

Si plusieurs serveurs DNS sont renseignés et que le client DNS ne parvient pas à recevoir de réponse
du serveur DNS actuel, alors le serveur DNS suivant est sélectionné. Cependant, qu’en est-il d’une
configuration qui comprendrait plusieurs cartes réseaux et plusieurs serveurs DNS par carte réseau ?
Le schéma suivant explique la manière dont le DNR sélectionne puis distribue les requêtes de
résolution DNS lorsque celles-ci n’aboutissent pas.

Page 102
Distribution des requêtes DNS sur un ordinateur multicartes et multiserveurs DNS

La séquence des demandes de résolution de noms est composée des étapes ci-dessous :

1.
La requête DNS est envoyée vers le serveur DNS préféré de la première carte réseau. Si la requête ne peut
être prise en charge (de manière positive ou négative), alors on passe à l’étape 2.
2.
La requête DNS est envoyée vers le serveur DNS préféré de chacune des cartes. Dans notre exemple, les
premiers serveurs DNS de chacune des cartes sont alors sollicités simultanément. Si la réponse à la requête
est à nouveau négative, alors on passe à l’étape 3.
3.
La requête DNS est envoyée à tous les serveurs DNS de toutes les cartes.
Résolution de noms non qualifiés

La résolution des noms non qualifiés signifie qu’il s’agit de résolutions faites sur la base d’un nom qui
n’a pas la forme d’un FQDN. Pour répondre à cette problématique, vous avez la possibilité de
configurer les paramètres DNS pour que le client DNS prenne à sa charge la clarification de la
requête. Les choix suivants vous sont proposés :

 ajouter les suffixes DNS principaux et spécifiques à la connexion au nom non qualifié pour
les requêtes DNS ;
 ajouter une série de suffixes DNS configurés au nom non qualifié pour les requêtes DNS ;
 suffixes DNS spécifiques à la connexion.

Chaque connexion réseau peut être configurée de façon qu’elle ait son propre suffixe DNS en plus du
suffixe DNS principal issu des propriétés de l’ordinateur.

Comportement des mises à jour dynamiques DNS

Par défaut, chaque connexion réseau dispose d’une gestion complètement autonome. De cette
manière, il est possible de garder un grand contrôle du comportement de la machine dans les
environnement complexes composés de multiples interfaces réseau. Si vous configurez un suffixe DNS
spécifique à la connexion, vous pouvez également activer la mise à jour dynamique DNS du nom de
domaine et les adresses IP de la connexion.

Page 103
Contrôle des enregistrements et du suffixe DNS de chaque connexion

La première option Enregistrer les adresses de cette connexion dans le système DNS signifie
que l’adresse ou les adresses IP de la connexion sont enregistrées en rapport avec le nom complet de
l’ordinateur tel que spécifié dans les propriétés d’identification de l’ordinateur. Dans notre exemple,
cela signifie que l’enregistrement concernant le nom d’hôte xp-clientx sera enregistré dans le
domaine corp2003.corporate.net avec les adresses IP de la connexion concernée. Par défaut, cette
option est activée et permet d’enregistrer le nom de l’ordinateur en considérant le suffixe principal de
l’ordinateur, c’est-à-dire le nom le plus significatif. La deuxième option Utiliser le suffixe DNS de
cette connexion pour l’enregistrement DNS signifie que l’enregistrement concernant le nom
d’hôte xp-clientx sera enregistré dans le domaine eni.fr. Notez que cette option n’est pas active par
défaut. Si vous ne souhaitez pas utiliser les fonctionnalités d’enregistrement dynamique DNS, vous
pouvez tout de même désactiver complètement ces mises à jour. Pour cela, désactivez les cases à
cocher Enregistrer les adresses de cette connexion dans le système DNS et Utiliser le suffixe
DNS de cette connexion pour l’enregistrement DNS pour toutes les connexions réseau de
l’ordinateur.

Pour effectuer cette procédure, vous devez être membre du groupe Administrateurs ou du groupe
Opérateurs de configuration réseau sur l’ordinateur local.

Définition d’une méthode de gestion des suffixes DNS

Nous venons de voir que les suffixes DNS permettent d’aider à obtenir une meilleure résolution des
noms DNS lorsque ceux-ci ne sont pas pleinement qualifiés. Nous avons aussi constaté que l’ordre de
ces déclarations pouvait avoir une incidence notable sur la pertinence des résolutions. Finalement, il
est clair qu’il serait judicieux de garantir une uniformité de ces paramètres au niveau de toute
l’entreprise ou des différents services qui la composent. La meilleure solution consiste à implémenter
les paramètres que vous avez définis à l’aide d’une stratégie de groupe adaptée.

Il est rare qu’un poste de travail dispose de plus d’une interface réseau mais avec la banalisation des
ordinateurs portables, il est de plus en plus fréquent de disposer d’une connexion intégrée Wi-Fi ou
pourquoi pas, d’une interface iEEE 1394 (Firewire). Sur les ordinateurs de type serveurs, les
configurations multicartes sont plus habituelles et devront être configurées spécifiquement.

Lorsqu’une machine est équipée de plus d’une carte réseau, on parle d’une machine de type "multihomed".
Ce terme signifie que la machine existe plusieurs fois sur le même ou sur différents réseaux. Par contre, si
les cartes réseau sont connectées sur le même réseau local, alors on parlera de connexions de type
"multinets".

La figure suivante illustre l’ensemble des paramètres généraux spécifiques au service DNS, lesquels
sont rapidement présentés ci-dessous :

 Les adresses des serveurs DNS sont listées en fonction de leur ordre. Dans cet exemple,
l’adresse 192.168.0.1 est celle du serveur DNS préféré, tandis que l’adresse 192.168.0.2
correspond à l’adresse du serveur auxiliaire.
 Tel que cela est spécifié dans l’interface, les trois paramètres suivants sont communs à
toutes les connexions réseau de l’ordinateur pour lesquelles le protocole TCP/IP est activé.
Ces paramètres sont Ajouter des suffixes DNS principaux et spécifiques aux
connexions ; ils vous permettent de spécifier si les suffixes parents du suffixe DNS
principal sont utilisés ou non. Enfin, le dernier choix concerne la possibilité de spécifier vos
propres suffixes grâce à l’option Ajouter ces suffixes DNS (dans l’ordre).

Ces trois paramètres concernent toutes les cartes liées au protocole TCP/IP.

 La déclaration du paramètre Suffixe DNS pour cette connexion permet de spécifier un


autre nom de domaine DNS qui pourra être enregistré, si nécessaire.

Page 104
 La case à cocher Enregistrer les adresses de cette connexion dans le système DNS
permet de faire en sorte que les adresses IP de cette connexion soient bien toutes
enregistrées pour le nom DNS correspondant au nom principal de l’ordinateur. Pour rappel,
le nom principal de l’ordinateur est visible à l’aide de la commande ipconfig /all et dépend
directement de l’appartenance au domaine Active Directory via l’icône Poste de
travail/Propriétés/Nom de l’ordinateur.

Le dernier paramètre Utiliser le suffixe DNS de cette connexion pour l’enregistrement DNS
vous permettra d’enregistrer en dynamique le nom complètement qualifié de l’ordinateur sur la base
du suffixe de la connexion. Dans ce cas, la machine existe deux fois. Une première fois dans la zone
qui correspond au nom de domaine d’appartenance de l’ordinateur et une deuxième fois dans la zone
spécifiée en tant que suffixe pour la dite connexion. Bien sûr, il faut que cette zone existe et autorise
les mises à jour dynamiques.

Gestion manuelle des suffixes DNS

Configuration des paramètres de suffixes DNS à l’aide des stratégies de groupe

La gestion des paramètres TCP/IP peut s’avérer longue et fastidieuse, provoquant d’inéluctables
erreurs humaines. Cet état de fait aura sans aucun doute participé à l’essor fulgurant du protocole
DHCP (Dynamic Host Configuration Protocol) pour aider à la bonne configuration des ordinateurs du
réseau.

S’il est vrai que le protocole DHCP prend en charge les paramètres indispensables au protocole IP et
aussi à la partie cliente du service de résolution DNS, les stratégies de groupe permettent de contrôler
finement et de distribuer vos "meilleurs" paramètres sur l’ensemble de votre réseau.Vous trouverez
les paramètres les plus intéressants à l’emplacement ci-dessous :Configuration Ordinateur\Modèles
d’administration\Réseau\Client DNS

Les paramètres les plus importants sont listés ci-dessous :

Suffixe DNS principal : ce paramètre spécifie le suffixe DNS principal de tous les ordinateurs
affectés par la stratégie. Le suffixe DNS principal est utilisé pour l’inscription de nom DNS et la
résolution de nom DNS. Ce paramètre vous permet de spécifier un suffixe DNS principal pour un
groupe d’ordinateurs et empêche les utilisateurs, y compris les administrateurs, de le modifier. Si
Page 105
vous désactivez ce paramètre ou ne le configurez pas, chaque ordinateur utilise son suffixe DNS
principal local, qui est habituellement le nom DNS du domaine Active Directory auquel il est joint.
Cependant, les administrateurs peuvent utiliser l’icône Système du panneau de configuration pour
modifier le suffixe DNS principal d’un ordinateur.

Ce paramètre ne désactive pas la boîte de dialogue Suffixe DNS et nom d’ordinateur NetBIOS que les
administrateurs utilisent pour modifier le suffixe DNS principal d’un ordinateur. Cependant, si les
administrateurs entrent un suffixe, ce suffixe est ignoré tant que ce paramètre est activé.

Pour que les modifications apportées à ce paramètre prennent effet, le système devra être redémarré.

Mise à jour dynamique : ce paramètre détermine si la mise à jour automatique est activée. Les
ordinateurs configurés pour permettre la mise à jour automatique inscrivent et mettent à jour leurs
enregistrements de ressources DNS avec un serveur DNS. Si vous activez ce paramètre, les
ordinateurs auxquels ce paramètre est appliqué peuvent utiliser l’enregistrement DNS dynamique
pour chacune de leurs connexions réseau, selon la configuration de chaque connexion réseau
individuelle. Pour activer l’enregistrement DNS dynamique sur une connexion réseau spécifique, il est
nécessaire que les configurations spécifiques à la connexion et spécifiques à l’ordinateur autorisent
l’enregistrement DNS dynamique.

Ce paramètre contrôle la propriété spécifique à l’ordinateur contrôlant l’enregistrement DNS


dynamique. Si vous activez ce paramètre, vous permettez à la mise à jour automatique d’être définie
individuellement sur chacune des connexions réseau.

Si vous désactivez ce paramètre, les ordinateurs auxquels ce paramètre est appliqué ne peuvent pas
utiliser l’enregistrement DNS dynamique pour toutes leurs connexions réseau, quelle que soit la
configuration des connexions réseau individuelles.

Liste de recherche de suffixes DNS : ce paramètre détermine les suffixes DNS à attacher à un
nom simple non qualifié avant de soumettre une demande DNS pour ce nom. Un nom simple non
qualifié ne contient pas de points, il s’agit donc d’un nom court et donc différent d’un nom de domaine
pleinement qualifié, tel que "europe.corporate.com".

Si vous activez ce paramètre, vous pouvez spécifier les suffixes DNS à attacher avant de soumettre
une demande pour un nom simple non qualifié. Les valeurs des suffixes DNS dans ce paramètre
peuvent être définies en utilisant des chaînes séparées par des virgules, telles que microsoft.com,
office.microsoft.com. Un suffixe DNS est attaché pour chaque soumission d’une demande. Si une
demande ne réussit pas, un nouveau suffixe DNS est ajouté à la place du suffixe en erreur et cette
nouvelle demande est soumise. Les valeurs sont utilisées dans l’ordre dans lesquelles elles
apparaissent dans la chaîne, en commençant par la valeur la plus à gauche et en continuant vers la
droite.

Niveau de sécurité des mises à jour : ce paramètre spécifie si les ordinateurs auxquels ce
paramètre est appliqué utilisent la mise à jour dynamique sécurisée ou la mise à jour dynamique
standard pour l’inscription des enregistrements DNS. Pour activer ce paramètre, cliquez sur Activer
et choisissez une des valeurs suivantes :

 Non sécurisé suivi de sécurisé : si cette option est choisie, les ordinateurs envoient des
mises à jour dynamiques sécurisées uniquement quand des mises à jour dynamiques non
sécurisées sont refusées.
 Non sécurisé uniquement : si cette option est choisie, les ordinateurs envoient
uniquement des mises à jour dynamiques non sécurisées.
 Sécurisé uniquement : si cette option est choisie, les ordinateurs envoient uniquement
des mises à jour dynamiques sécurisées.
 Intervalle d’actualisation de l’enregistrement : ce paramètre spécifie l’intervalle
d’actualisation des enregistrements de ressources A et PTR pour les ordinateurs auxquels ce
paramètre est appliqué. Ce paramètre peut être appliqué uniquement à des ordinateurs
utilisant des mises à jour dynamiques.

Les ordinateurs Windows 2000 Professionnel, Windows XP Professionnel et Windows Vista configurés
pour effectuer des enregistrements DNS dynamiques d’enregistrement de ressources A et PTR,
réenregistrent de manière périodique leurs enregistrements avec des serveurs DNS, et ce, même si
leurs données d’enregistrement n’ont pas changé. Ce réenregistrement est requis pour indiquer à des
serveurs DNS configurés pour supprimer automatiquement des enregistrements obsolètes, que ces
enregistrements sont actuels et devraient être conservés dans la base de données.

Page 106
Si les enregistrements de ressources DNS sont enregistrés dans des zones où le nettoyage est activé,
la valeur de ce paramètre ne devrait pas être plus longue que l’intervalle d’actualisation configuré
pour ces zones.

Paramétrez l’intervalle d’actualisation d’enregistrement pour être plus long que l’intervalle
d’actualisation des zones DNS pourrait entraîner la suppression non désirée des enregistrements de
ressources A et PTR. Notez que la valeur par défaut déclare 1800 secondes, ce qui correspond à 30
minutes.

4. Demandes de résolutions DNS et NetBIOS : Processus de sélection de


la méthode

Lorsqu’un ordinateur Windows XP Professionnel tente de résoudre un nom en adresse IP, le module de
résolution transmet en priorité la demande de résolution au système de résolution DNS. Ce point est
particulièrement important puisqu’il s’agit d’un changement radical sur les systèmes Windows 2000,
Windows XP Professionnel et Windows Vista par rapport à Windows NT et Windows 9x.

Dans le cas où la demande de résolution DNS échouerait, le module de résolution contrôlera la longueur
du nom demandé. Si la longueur est supérieure à 15 octets c’est-à-dire 15 caractères, alors elle ne
peut pas être transmise à l’interface NetBIOS et la résolution échoue. Si par contre, le nom demandé
est d’une longueur inférieure à 15 caractères alors le module de résolution vérifie que l’interface de
résolution NetBIOS est bien active. Si ce point est vérifié, alors le module de résolution transmet la
demande à l’interface NetBIOS.

Windows XP Professionnel et Windows Vista supporte de multiples méthodes de résolution de noms


telles que le DNS, WINS, les fichiers Hosts et Lmhosts et les messages de diffusion (broadcasts). En
général, un ordinateur Windows XP invoque une combinaison de ces différentes méthodes de
résolution.

5. Test d’intégration de l’ordinateur dans le domaine Active Directory

Vous pouvez utiliser DCdiag.exe et Netdiag.exe pour résoudre les problèmes des ordinateurs clients qui
ne peuvent pas localiser un contrôleur de domaine. Ces outils peuvent vous aider à déterminer les
mauvaises configurations DNS tant côté client que côté serveur.

Nous avons déjà présenté en détail la commande Netdiag dans le cadre des commandes de gestion et
de surveillance des services DNS.

Concernant les environnements Active Directory, la commande DCdiag vous permettra d’avancer à
grands pas lorsqu’il sera question de diagnostiquer d’éventuels problèmes de fonctionnement des
ordinateurs spécifiques que sont les contrôleurs de domaine Active Directory.

La commande DCdiag permet de vérifier le fonctionnement des fonctions vitales Active Directory en
vous proposant de manipuler une série de tests adaptés à chaque situation critique. Ainsi vous aurez,
par exemple, la possibilité de sélectionner le ou les contrôleurs de domaine à tester ainsi que
différentes catégories de tests.

Ces tests sont classés dans les trois catégories ci-dessous et sont ensuite détaillés plus bas :

 les tests obligatoires de contrôleurs de domaine qui ne peuvent donc pas être désactivés.
 les tests non obligatoires de contrôleurs de domaine que vous pouvez donc sélectionner à
votre convenance.
 les tests de machines non contrôleurs de domaine.

Les tests obligatoires de la commande DCdiag comprennent le contrôle des enregistrements DNS des
contrôleurs, la possibilité de les contacter, ainsi que la vérification du bon fonctionnement de la
connectivité LDAP et RPC.

Tous les tests spécifiés plus haut ne peuvent être réalisés que sur des contrôleurs de domaine Windows
2000, Windows Server 2003 ou Windows Server 2008 à l’exception des tests DcPromo et RegisterInDNS qui
ne peuvent être exécutés que sur des machines non contrôleurs de domaine.

Pour obtenir plus d’informations sur l’intégration des ordinateurs dans les domaines Active Directory
ainsi que sur la création des contrôleurs de domaine, consultez l’article F265706 "DCDiag et NetDiag

Page 107
pour faciliter la jonction de domaines et la création de contrôleurs de domaine" dans la Base de
connaissances Microsoft.

Nouveautés des services DNS de Windows Server 2008

1. Introduction

Windows Server 2008 implémente désormais les services de résolution et de gestion de domaines DNS
sous la forme d’un nouveau rôle de serveur. Les services DNS de Windows Server 2008 apportent les
nouvelles fonctionnalités ci-dessous :

 Le chargement des zones en arrière plan : La disponibilité des serveurs DNS est améliorée
lors du redémarrage du service DNS en chargeant les données de zones directement en tâche
de fond.
 Support du protocole IPv6 : Les services DNS supportent entièrement la spécification finale
IPv6 et les adresses sur 128 bits.
 Support des RODC : Les services DNS supportent une nouvelle notion qui permet de
supporter les services DNS dynamiques sur des RODC. Ces zones sont appelées zones
primaires en lecture seule - RODC Read-only zones.
 Zones de type GNZ : Ce nouveau type de zone DNS - GNZ, Global Naming Zone, assure le
support des noms globaux - Global single names. Les zones GNZ permettent la résolution de
noms de type simples - single-label name resolution, pour les entreprises qui ne souhaitent
pas déployer les services WINS - Windows Internet Name Service ou lorsqu’il n’est pas
pratique de spécifier des noms DNS complets.

Ces nouvelles fonctionnalités sont détaillées ci-dessous.

2. Chargement des zones en arrière-plan

Les grandes entreprises peuvent être amenées à gérer des zones DNS extrêmement volumineuses.
Lorsque ces zones sont stockées dans Active Directory et que le contrôleur de domaine doit être
redémarré, le temps de démarrage des services Active Directory puis du chargement des données des
zones pouvaient rendre les services DNS indisponibles pour les clients du réseau pendant un temps
parfois égale à trente voir soixante minutes.

Les serveurs DNS Windows Server 2008 peuvent désormais charger les données DNS en tâche de fond
dans l’ordre suivant :

 L’ensemble des zones à charger sont déterminées.


 Les indicateurs de racines sont chargés à partir du fichier Cache.dns ou du stockage Active
Directory.
 Chargement des données des zones stockées dans des fichiers de zones.
 Démarrage des fonctions de réponses DNS et du support RPC.
 Lancement des fonctions de chargement des zones stockées dans des partitions Active
Directory.

À ce stade les zones DNS Active Directory sont chargées en parallèle à l’aide de multiples threads de
telle sorte que le service DNS puisse répondre aux demandes de résolutions des clients pendant le
chargement.

Lorsque des demandes de résolutions ne peuvent être résolues car non présentes en mémoire, le service
DNS recherche directement les données à partir de la base de données Active Directory, tandis que le
chargement se poursuit. Cette fonctionnalité accélère encore le chargement.

3. Support des adresses IPv6

Les adresses IPv6, à la différence des adresses IPv4 qui sont formatées sur 32 bits, sont formatées sur
128 bits. Désormais, les services DNS de Windows Server 2008 supportent entièrement la spécification
finale IPv6 et les adresses sur 128 bits. Il en est de même pour la commande dnscmd qui accepte les
adresses IP dans les deux formats. Le serveur DNS peut utiliser des redirecteurs dont les adresses sont
dans les deux formats.
Page 108
Enfin, les zones de recherches inversées spécifiques aux adresses IPv6 sont supportées via la zone
inversée ip6.arpa.

Le support du protocole IPv6 par les services DNS de Windows Server 2008 n’est pas, à ce jour, d’une
importance capitale. Mais, il est clair que cela pourrait l’être dans les années à venir suite au
développement du réseau Internet.

À propos du support IPv6 : Comme les serveurs DNS peuvent aujourd’hui répondre aux demandes de
résolutions des clients en utilisant des adresses IPv4 (A) mais aussi des adresses IPv6 (AAAA), il est
nécessaire de s’assurer que la partie cliente DNS des postes de travail supporte ces réponses.

4. Support DNS des contrôleurs de domaine en lecture seule

L’objectif principal des contrôleurs de domaine en lecture seule est de renforcer la sécurité de ces
contrôleurs de domaine en autorisant ceux-ci à recevoir des données, uniquement d’un autre contrôleur
de domaine, et en aucune façon, directement. De cette manière, les sources en écritures sont connues
et contrôlées, et le contrôleur est beaucoup moins vulnérable aux attaques.

Pour assurer un bon fonctionnement des services DNS sur de tels serveurs, disponibles uniquement en
lecture seule, Windows Server 2008 introduit un nouveau type de zones appelées Zones primaires en
lecture seule.

Ces zones sont parfois appelées « Branch Office Zones ».

Lors de l’installation d’un contrôleur de domaine en lecture seule, le nouveau contrôleur reçoit une
réplication complète en lecture seule (RO) de la partition de domaine, de la partition de schéma, de la
partition de configuration, et bien entendu, de toutes les partitions ForestDNSZones/DomainDNSZones
utilisées par les services DNS. Ensuite, les inscriptions et autres mises à jour dynamiques sont pris en
charge de la manière suivante :

 Le serveur DNS n’accepte pas la mise à jour des clients directement.


 Les demandes d’écriture DNS des clients sont renvoyées vers un serveur DNS faisant autorité.
 Les données mises à jour sont reçues via la réplication depuis un DNS faisant autorité.

Le support « détourné » des inscriptions et mises à jour dynamiques sur les contrôleurs de type RODC
est une fonctionnalité importante car elle permet de déployer ce type de contrôleurs sans en affaiblir la
sécurité, ni introduire de limitations fonctionnelles dans l’infrastructure DNS dynamique.

5. Support des zones de type GlobalNames

La majorité des réseaux Windows utilisent aujourd’hui les systèmes de nommage DNS, les systèmes de
résolutions de noms DNS mais aussi les mécanismes de résolution WINS - Windows Internet Naming
Service.

Aujourd’hui, fort est de constaté que les noms IP-DNS sont largement utilisés même si certaines
applications utilisent encore l’interface NetBIOS et les mécanismes de résolution DNS et/ou WINS.

Attention ! Il ne faut pas confondre l’interface NetBIOS, au sens programmation du terme, et un système
d’enregistrement et de résolution des noms NetBIOS tel que le service WINS.

Pour des raisons historiques tout à fait acceptables, et aussi des raisons techniques inhérentes aux
plates-formes Windows NT parfois encore en production, il est fréquent que les entreprises continuent
de déployer WINS dans leurs réseaux. Dans de tels cas, WINS est considéré comme second système de
résolution, juste derrière les services DNS.

Outre le fait que l’interface NetBIOS, les noms NetBIOS et les mécanismes propres au système de résolution
WINS soient proches de l’obsolescence, il n’en demeure pas moins que certains principes soient encore fort
appréciés des administrateurs Windows notamment la facilité à déclarer des noms statiques simples et à les
rendre globalement disponibles à l’échelle d’une entreprise.

Pour répondre à ces problématiques, les services DNS de Windows Server 2008 permettent aux
entreprises d’envisager une transition totale de l’environnement WINS existant vers un environnement
Page 109
complètement DNS tout en continuant de supporter des noms plats de type simple label au sein de la
nouvelle zone DNS GlobalNames.

Un nom de type simple label est à opposer aux noms de composé de multiples labels. Par exemple,
wssportalaccess est un nom simple label, tandis que wss2008portal1.corpx.xnet est un nom multilabels.

Contenu de la zone GlobalNames

En général, les noms simples contenus dans une zone de type GlobalNames devraient être contenus
dans une zone Active Directory répliquée à l’échelle de la forêt. De cette manière, une étendue de
résolution unique peut être offerte globalement. Notez qu’il est aussi possible de publier un
enregistrement DNS de type SRV pour déclarer l’existence de plusieurs zones GlobalNames contenues
dans plusieurs forêts Active Directory.

À la différence des services WINS, les zones DNS GlobalNames devraient être utilisées uniquement pour
permettre au DNS de résoudre un ensemble limité de noms de type simple label. Il peut s’agir de
certains serveurs dont les noms sont gérés de manière très centralisée ou aussi de serveurs Web
intranet.

Attention ! Microsoft recommande de ne pas utiliser la zone GlobalNames en lieu et place des résolutions
habituelles. Notez aussi que les mises à jour dynamiques ne sont pas supportées sur la zone GlobalNames.
Par comparaison aux opérations d’administration de WINS, la zone GlobalNames devrait contenir l’équivalent
des enregistrements statiques WINS.

Lorsqu’une zone de type GlobalNames est déployée, une résolution de type simple label est réalisée de
la manière suivante :

 Une demande de résolution basée sur un nom court, c’est-à-dire de type simple label, est
initiée.
 Le suffixe principal du poste de travail est ajouté au nom court et la requête est transmise au
serveur DNS.
 Si la requête basée sur un FQDN n’aboutie pas, alors le client génère d’autres requêtes basées
sur les suffixes DNS additionnels, déclarés localement ou via GPO.
 Si ces requêtes n’aboutissent pas alors le client réalise une requête basée sur le nom court.
 Si le nom court demandé apparaît dans la zone GlobalNames, le nom est résolu.
 Si le nom court demandé n’apparaît dans la zone GlobalNames, alors la demande de
résolution est transmise à WINS.

Aucune mise à jour particulière n’est requise sur les postes clients pour qu’ils puissent résoudre les noms de
la zone GlobalNames. Le suffixe DNS principal, les suffixes DNS spécifiques aux connexions et la liste de
recherche de suffixe DNS continuent de fonctionner normalement.

Les mises à jour dynamiques ne sont pas prises en charge sur la zone GlobalNames. Cependant, il
convient de noter que les mises à jour dynamiques envoyées à un serveur DNS sont d’abord comparées
aux données de zone GlobalNames avant d’être comparées aux données de zone locale. Ce contrôle
permet de garantir l’unicité des noms présents dans la zone GlobalNames.

Page 110
6. Évolutions de la partie Client DNS de Windows Vista et Windows
Server 2008

Nous venons de voir que les services DNS de Windows Server 2008 supportent de nouvelles
fonctionnalités pour répondre à de nouvelles problématiques. Bien que cela n’ait pas de conséquences
directes en termes d’infrastructure, il convient de faire remarquer que Windows Vista et Windows
Server 2008 incorporent aussi quelques changements au niveau de la partie cliente DNS.

Windows Vista et Windows Server 2008 supportent LLMNR - Link-Local Multicast Name Resolution : Il
est désormais possible à cette nouvelle évolution du client DNS de résoudre des noms DNS en utilisant
un message réseau de type demande de résolution en multicast local. Cette méthode, aussi appelée
mDNS, multicast DNS, permet aux clients supportant cette fonctionnalité, de résoudre les noms DNS
d’un réseau local lorsque le ou les serveurs DNS habituels ne sont pas disponibles. Une fois les services
DNS à nouveau disponibles, les mécanismes de résolution habituels reprennent normalement.

Le support du protocole LLMNR offre une nouvelle méthode pour minimiser les effets de bord des
défaillances des services DNS. Notez qu’il peut aussi s’agir d’une méthode de résolution pour des
réseaux ad hoc tels que des salles de conférences, des zones en libre accès, etc.

7. Sélection des contrôleurs de domaine avec Windows Vista et Windows


Server 2008

Windows Vista et Windows Server 2008 incorporent des modifications concernant la sélection des
contrôleurs de domaine de manière à moins impacter les performances du réseau.

Sur un système fonctionnant sous Windows XP ou Windows Server 2003, le système conserve le
contrôleur de domaine sélectionné jusqu’à ce qu’un événement le force à découvrir un nouveau
contrôleur de domaine.

Les systèmes Windows Vista ou Windows Server 2008 rafraîchissent régulièrement les informations
relatives aux contrôleurs de domaine de leur domaine d’appartenance. Cette nouvelle méthode permet
de parer aux problèmes qui peuvent se produire lorsqu’un poste client tente de localiser son contrôleur
de domaine favori, lorsque le réseau ou certaines circonstances ne le permettent pas. Le fait de
renouveler périodiquement l’association permet au poste client de minimiser la probabilité d’être
associé à un contrôleur de domaine inapproprié en disposant du contrôleur le mieux adapté à la
situation.

La figure ci-après illustre la mise en œuvre de ce paramètre à l’aide du paramètre Forcer l’intervalle
de recherche disponible pour les systèmes Windows Vista et Windows Server 2008.

Nouveau paramètre « Forcer l’intervalle de recherche »

Pour s’adapter aux changements de conditions du réseau, le localisateur de contrôleurs de domaine


exécute par défaut une recherche forcée en fonction d’un intervalle spécifié. Il assure aussi l’équilibrage
de la charge des clients sur l’ensemble des contrôleurs disponibles dans les domaines ou forêts.
L’intervalle par défaut de la recherche forcée par le localisateur est de douze heures. La recherche
forcée peut également être déclenchée si un appel au localisateur de contrôleurs de domaine utilise
l’indicateur DS_FORCE_REDISCOVERY.

Si ce paramètre de stratégie est activé, le localisateur de contrôleurs de domaine pour l’ordinateur


exécute une recherche forcée régulièrement en fonction de l’intervalle configuré.
Page 111
L’intervalle minimal est de 3 600 secondes (1 heure) pour éviter le trafic réseau excessif dû à la recherche.
L’intervalle maximal autorisé est de 4 294 967 200 secondes, et toute valeur supérieure à 4 294 967
secondes (~49 jours) est traitée comme un nombre infini. Si ce paramètre de stratégie est désactivé,
l’option Forcer l’intervalle de recherche est utilisée par défaut pour l’ordinateur toutes les douze heures.
Si ce paramètre de stratégie n’est pas configuré, l’option Forcer la recherche est utilisée par défaut pour
l’ordinateur toutes les douze heures, sauf si la valeur du paramètre de l’ordinateur local dans le Registre est
différente.

Validation des acquis : questions/réponses


1. Questions

Si l’état de vos connaissances sur ce chapitre vous semble suffisant, répondez aux questions ci-après :

1 Quel rôle joue le protocole DNS au sein des services de domaine Active Directory ?

2 Quel service du système d’exploitation Windows permet de résoudre un nom tel que
corpnet.corporate.com ?

3 Quel fichier peut être manuellement configuré pour prendre en charge la résolution des noms d’hôtes ?
Dans quel répertoire est-il situé sur un serveur fonctionnant sous Windows Server 2003 ou Windows Server
2008 ?

4 Quel est le principal avantage des mises à jour dynamiques d’une zone DNS ?

5 Comment installer le service serveur DNS de Windows Server 2003 et Windows Server 2008?

6 Comment devez-vous procéder pour profiter des nouvelles fonctionnalités offertes par les serveurs DNS
fonctionnant sous Windows Server 2008 sur d’anciens serveurs DNS fonctionnant sous Windows 2000 ou
Windows Server 2003 ?

7 Quel type d’enregistrement standard est utilisé par les services DNS Microsoft pour aider les utilisateurs et
les applications à localiser les services de l’Active Directory ?

8 Quels sont les différents types de zones prises en charge sur un serveur DNS fonctionnant sous Windows
Server 2003 et Windows Server 2008 ?

9 Quels sont les différents types de zones prises en charge sur un serveur DNS fonctionnant sous Windows
2000 Server ?

10 Qu’appelle-t-on un transfert de zone de type AXFR et un transfert de zone IXFR ?

11 Quelle est la différence entre une requête DNS récursive et une requête DNS itérative ?

12 Quelle est la différence entre une zone de recherche directe et une zone de recherche inversée ?

13 Quels sont les avantages apportés par la délégation des zones DNS ?

14 Quels types de transferts de zone sont supportés par Windows Server 2003 et Windows Server 2008 ?

15 Qu’est-ce qu’une zone de stub ?

16 Quels sont les différents outils qui vous permettent de vérifier le bon fonctionnement d’un serveur DNS
fonctionnant sous Windows Server 2003 ou Windows Server 2008 ?

17 De quel type d’enregistrement de ressources DNS doit-on disposer pour localiser un service inscrit dans
l’annuaire Active Directory ?

18 Quel type d’enregistrement de ressources DNS doit-on créer pour déclarer l’existence d’un connecteur de
messagerie utilisant le protocole SMTP de livraison des messages ?

19 Comment pouvez-vous orienter le choix de tel contrôleur de domaine plutôt qu’un autre concernant les
recherches LDAP dans un domaine donné ?

20 Quels sont les trois types d’enregistrements SRV les plus utilisés dans les domaines Active Directory ?

21 Dans quel type de configuration utiliserez-vous les redirecteurs ?

22 En quoi l’implémentation des redirecteurs sous Windows Server 2003 ou Windows Server 2008 est-elle
plus intéressante que celle réalisée sur les serveurs fonctionnant sous Windows 2000 Server ?

Page 112
23 Expliquez le rôle exact des nouvelles zones GlobalNames offertes par les serveurs DNS fonctionnant sous
Windows Server 2008 ?

24 Comment active-t-on cette fonctionnalité sur un serveur DNS fonctionnant sous Windows Server 2008 ?

25 Que signifie l’acronyme LLMNR ? Quel est le rôle de ce nouveau protocole avec Windows Vista et
Windows Server 2008 ?

26 Quel est le rôle de la fonction de Negative Caching ? Comment peut-on la configurer ?

2. Résultats

Référez-vous aux pages suivantes pour contrôler vos réponses. Pour chacune de vos bonnes réponses,
comptez un point.

Nombre de points /26

Pour ce chapitre, votre score minimum doit être de 20 sur 26.

3. Réponses

1 Quel rôle joue le protocole DNS au sein des services de domaine Active Directory ?

Le protocole DNS joue un rôle essentiel. Le service de résolution DNS est le système de résolution de noms
principal pour tous les mécanismes propres aux recherches de noms et aux recherches de services entre un
client Active Directory et l’infrastructure Active Directory.

2 Quel service du système d’exploitation Windows permet de résoudre un nom tel que
corpnet.corporate.com ?

Le service de résolution DNS à l’aide du service Client DNS vers un serveur DNS Windows ou non Windows.

3 Quel fichier peut être manuellement configuré pour prendre en charge la résolution des noms d’hôtes ?
Dans quel répertoire est-il situé sur un serveur fonctionnant sous Windows Server 2003 ou Windows Server
2008 ?

Il s’agit du fichier HOSTS lequel est situé dans le répertoire %Systemroot%\System32\Drivers\etc

4 Quel est le principal avantage des mises à jour dynamiques d’une zone DNS ?

Les mises à jour DNS dynamiques garantissent la cohérence des enregistrements en supprimant totalement
les erreurs humaines. Elles permettent aussi de réduire les coûts en minimisant au strict minimum les
opérations de support. Il faut se rappeler que jusqu’alors, les réseaux NT reposaient sur les services WINS,
lesquels sont — par nature — dynamiques.

5 Comment installer le service serveur DNS de Windows Server 2003 et Windows Server 2008 ?

Ouvrez une session en tant qu’administrateur local de la machine. Menu démarrer/Outils d’administration
puis lancez Assistant Configurer votre serveur. Sur un serveur fonctionnant sous Windows Server 2003, vous
pouvez aussi utiliser le Panneau de configuration/Ajout/Suppression de programmes/ Ajouter ou supprimer
des composants Windows/Services de mise en réseau.

Sur un serveur fonctionnant sous Windows Server 2008, utilisez la fonction Ajouter des rôles du
Gestionnaire de serveur de Windows Server 2008. Vous pouvez aussi passer par Panneau de
configuration/Programme et fonctionnalités/Activer ou désactiver des fonctionnalités Windows. Cette
opération vous renvoie vers le Gestionnaire de serveur de Windows Server 2008.

6 Comment devez-vous procéder pour profiter des nouvelles fonctionnalités offertes par les serveurs DNS
fonctionnant sous Windows Server 2008 sur d’anciens serveurs DNS fonctionnant sous Windows 2000 Server
ou Windows Server 2003 ?

Vous pouvez réaliser une mise à niveau « sur place » du serveur s’il fonctionne sous Windows Server 2003
SP1 ou ultérieur. Les services Windows 2000 Server ne peuvent pas faire l’objet d’une mise à niveau. Au

Page 113
préalable, il est nécessaire de passer par une mise à niveau de Windows 2000 Server vers Windows Server
2003.

7 Quel type d’enregistrement standard est utilisé par les services DNS Microsoft pour aider les utilisateurs et
les applications à localiser les services des services de domaine Active Directory ?

Il s’agit des enregistrements de SRV définis dans le RFC 2052 remplacé par le RFC 2782.

8 Quels sont les différents types de zones prises en charge sur un serveur DNS fonctionnant sous Windows
Server 2003 et Windows Server 2008 ?

Les serveurs DNS fonctionnant sous Windows Server 2003 supportent les zones principales, les zones
secondaires et les zones de stub. Ces zones existent en tant que zones de recherches directes et zones de
recherches inversées. Les serveurs DNS fonctionnant sous Windows Server 2008 supportent, en plus, les
nouvelles zones DNS GlobalNames.

9 Quels sont les différents types de zones prises en charge sur un serveur DNS fonctionnant sous Windows
2000 Server ?

Les serveurs DNS fonctionnant sous Windows 2000 Server supportent les mêmes types de zones que les
serveurs Windows Server 2003 excepté les zones de stub.

10 Qu’appelle-t-on un transfert de zone de type AXFR et un transfert de zone IXFR ?

Les transferts de zone AXFR transfèrent les zones entièrement (A pour All), tandis que les transferts de zone
IXFR transfèrent uniquement les modifications (I pour Incremental).

11 Quelle est la différence entre une requête DNS récursive et une requête DNS itérative ?

Une requête récursive attend une réponse à une requête de résolution de noms. Par contre, une requête
itérative aura pour réponse la réponse à la requête émise ou bien une référence vers un autre serveur DNS.

12 Quelle est la différence entre une zone de recherche directe et une zone de recherche inversée ?

La première résoud le nom complet en adresse IP, la seconde l’adresse IP en nom complet.

13 Quels sont les avantages apportés par la délégation des zones DNS ?

La délégation d’une zone permet d’en déléguer la gestion à un tiers approuvé et de répartir l’espace de
nommage DNS en plusieurs fichiers de bases de données de zones afin de répartir ou distribuer l’espace en
plusieurs points.

14 Quels types de transferts de zone sont supportés par Windows Server 2003 et Windows Server 2008?

Les serveurs DNS fonctionnant sous Windows Server 2003 supportent les transferts de zone incrémentiels
(IXFR) lesquels ne transmettent que les modifications ainsi que les traditionnels transferts de zone complets
(AXFR).

15 Qu’est-ce qu’une zone de stub ?

Une zone de stub est une copie d’une zone qui contient uniquement les enregistrements de ressources
nécessaires pour identifier les serveurs DNS faisant autorité pour cette zone. Une zone de stub permet à ce
qu’un serveur DNS hébergeant une zone parent sache quels serveurs DNS font autorité sur sa zone enfant.
De cette manière, l’efficacité des résolutions DNS est préservée.

16 Quels sont les différents outils qui vous permettent de vérifier le bon fonctionnement d’un serveur DNS
fonctionnant sous Windows Server 2003 ou Windows Server 2008 ?

Vous pouvez utiliser l’enregistrement des événements dans le journal DNS, activer le journal de débogage et
utiliser les commandes ipconfig, ping, nslookup, dnscmd, netdiag et dcdiag. Sur les serveurs Windows
Server 2008, vous pouvez utiliser le nouveau Gestionnaire de serveur et consulter le Résumé des rôles.

Page 114
17 De quel type d’enregistrement de ressources DNS doit-on disposer pour localiser un service inscrit dans
l’annuaire Active Directory ?

Vous devez disposer d’enregistrements de type SRV. Ils sont utilisés par les services Active Directory mais
aussi par des produits tels que Microsoft OCS 2007, ou le gestionnaire de licences en volume KMS - Key
Management Service - de Windows Vista et Windows Server 2008.

18 Quel type d’enregistrement de ressources DNS doit-on créer pour déclarer l’existence d’un connecteur de
messagerie utilisant le protocole SMTP de livraison des messages ?

Vous devez créer un enregistrement de ressource de type MX.

19 Comment pouvez-vous orienter le choix de tel contrôleur de domaine plutôt qu’un autre concernant les
recherches LDAP dans un domaine donné ?

Changez la valeur de l’enregistrement de ressources _ldap._tcp.votre_domaineDNS en diminuant la valeur


de l’attribut Priorité. Plus la valeur est faible et plus ce choix sera favorisé.

20 Quels sont les trois types d’enregistrements SRV les plus utilisés dans les domaines Active Directory ?

Les enregistrements les plus utilisés sont les enregistrements des services Ldap (_ldap.xxx), des services
Kerberos (_kerberos.xxx) et des services de catalogues globaux (_gc.xxx).

21 Dans quel type de configuration utiliserez-vous les redirecteurs ?

Utilisez les redirecteurs lorsque vous devez faire en sorte que vos serveurs DNS privés soient capables de
résoudre un autre espace de résolution DNS. Ce sera le cas si vous souhaitez résoudre l’espace DNS
Internet. Vous pouvez aussi les utiliser comme une optimisation pour décaler les demandes de résolutions
vers un autre serveur DNS situé derrière une connexion lente ou surchargée.

22 En quoi l’implémentation des redirecteurs sous Windows Server 2003 ou Windows Server 2008 est-elle
plus intéressante que celle réalisée sur les serveurs fonctionnant sous Windows 2000 Server ?

Les serveurs Windows Server 2003 et Windows Server 2008 gèrent les redirecteurs conditionnels. Les
serveurs DNS sont sélectionnés en fonction de la requête. Par exemple, toutes les requêtes pour le domaine
*.intra*.net sont redirigées vers le serveur DNS 10.1.1.1 et toutes les requêtes pour
*.corpnet.company.com vers le serveur DNS 172.16.10.1.

23 Expliquez le rôle exact des nouvelles zones GlobalNames offertes par les serveurs DNS fonctionnant sous
Windows Server 2008 ?

Ce nouveau type de zone permet de stocker les noms DNS de type « single label ». Il ne s’agit pas du tout
d’un palliatif au système de résolution WINS mais de l’utilisation qui est faite de ce dernier par les
administrateurs Windows pour créer des noms courts disponibles pour l’ensemble du réseau
(enregistrements statiques). Avec ce nouveau type de zone, les administrateurs peuvent créer des alias
courts (CNAMES) qui pointent vers des noms longs (FQDN).

24 Comment active-t-on cette fonctionnalité sur un serveur DNS fonctionnant sous Windows Server 2008 ?

La 1ère étape consiste à activer la fonctionnalité à l’aide de la commande Dnscmd ServerName /config
/Enableglobalnamessupport 1.

La 2ème étape consiste à créer une zone GlobalNames. Microsoft recommande que cette zone soit intégrée à
Active Directory à l’échelle de la forêt et que les mises à jour dynamiques ne soient pas autorisées.

25 Que signifie l’acronyme LLMNR ? Quel est le rôle de ce nouveau protocole avec Windows Vista et
Windows Server 2008 ?

LLMNR signifie, en anglais, Link Local Multicast Name Resolution. Ce protocole est aussi appelé mDNS ou
encore Multicast DNS. Il permet de résoudre les noms d’un réseau local lorsque les services DNS ne sont
plus disponibles.

Page 115
26 Quel est le rôle de la fonction de Negative Caching ? Comment peut-on la configurer ?

Cette fonction permet de réduire de manière importante les trafics générés vers les serveurs DNS lors de
recherches infructueuses initiées par les clients. Cette option est configurable dans le registre sous Windows
2000, Windows XP, Windows Server 2003, Windows Vista et aussi Windows Server 2008.

Travaux pratiques
1. Installation du service DNS en vue d’installer Active Directory

Le principal objectif de ce TP consiste à installer un nouveau serveur DNS en vue de l’installation des
services d’annuaire Active Directory.

Configuration du paramètre de suffixe DNS

1.
Ouvrez les propriétés du poste de travail.
2.
Sur l’onglet Nom de l’ordinateur, sélectionnez le bouton Modifier.
3.
Déclarez le nom de domaine complet du domaine Active Directory. Le nom du domaine racine de la forêt
pourra prendre la forme domaineinterne. domainednsinternet.com, ainsi pour l’entreprise company.com, le
domaine à créer pourrait être corpnet.company.fr.

Installation du service serveur DNS

Pour procéder à l’installation du service DNS, procédez comme suit :

1.
Connectez-vous sur l’ordinateur en tant qu’administrateur local de l’ordinateur.
2.
Ouvrez le Panneau de configuration.
3.
À l’aide du Gestionnaire de serveur, via Rôles - Ajouter des rôles, sélectionnez le rôle Serveur DNS à
l’aide de l’assistant.

2. Configuration du service DNS

Le principal objectif de ce TP consiste à configurer la ou les zones de recherche inversée, la zone


principale de recherche directe pour le domaine corpnet.company. com ainsi qu’une zone principale de
recherche inversée. Dans un deuxième temps, une zone secondaire sera aussi créée.

Création d’une zone de recherche inversée

1.
Ouvrez la console DNS située dans le groupe de programmes des Outils d’administration ou utilisez le
Gestionnaire de serveur.
2.
Clic droit sur le nom de votre serveur puis sélectionnez l’option Configurer un serveur DNS.
3.
Dans l’assistant Configuration d’un serveur DNS, faites Suivant puis sélectionnez Créer des zones de
recherche directe et inversée pour les grands réseaux.
4.
À la question Voulez-vous créer une zone de recherche directe maintenant ? sélectionnez Oui.
5.
Sur la fenêtre Type de zone, sélectionnez ensuite le type de zone que vous devez créer. Choisissez Zone
principale.
6.
Déclarez le nom de la zone, par exemple : corpnet.company.com.
7.
Acceptez Créer un nouveau fichier nommé : corpnet.company.com.dns, puis faites Suivant.
8.
Page 116
Pour le moment, acceptez le choix Ne pas autoriser les mises à jour dynamiques, puis faites Suivant.
9.
À la question Voulez-vous créer une zone de recherche inversée maintenant ? acceptez le choix Oui,
créer une zone de recherche maintenant, puis faites Suivant.
10.
Sur la fenêtre Type de zone, sélectionnez ensuite le type de zone que vous devez créer. Choisissez Zone
principale, puis faites Suivant.
11.
Déclarez le numéro de réseau (ID réseau) utilisé : 192.168.0, puis faites Suivant.
12.
Acceptez Créer un nouveau fichier nommé : 0.168.192.in-addr.arpa.dns, puis faites Suivant.
13.
Pour le moment, acceptez le choix Ne pas autoriser les mises à jour dynamiques puis faites Suivant.
14.
Sur la fenêtre Redirecteurs, à la question Ce serveur doit-il rediriger des requêtes ? acceptez le choix
Non, il ne doit pas rediriger les requêtes puis faites Suivant.
15.
Sur la fenêtre Fin de l’assistant Configuration d’un serveur DNS, sélectionnez Terminer.

Vous venez de configurer en mode Assistant, un serveur DNS. Ce serveur DNS contient une zone
principale de recherche directe, une zone principale de recherche inversée, il n’utilise pas les
redirecteurs et il utilise les indications de racines par défaut. Pour le moment, les deux zones créées ne
sont pas dynamiques.

Création d’une zone de recherche directe standard

Ce TP va vous permettre de créer une zone de recherche directe.

Pour ajouter une zone de recherche directe, procédez de la manière suivante :

1.
Ouvrez la console de gestion du DNS ou utilisez le Gestionnaire de serveur de Windows Server 2008.
2.
Dans l’arborescence de la console, cliquez avec le bouton droit sur un serveur DNS puis cliquez sur
Nouvelle zone afin d’ouvrir l’Assistant Nouvelle zone.
3.
Choisissez le type de zone : Principale.
4.
Suivez les instructions pour créer une nouvelle zone principale.

Pour effectuer cette procédure, vous devez être membre du groupe Administrateurs sur l’ordinateur local, ou
avoir reçu par délégation les autorisations nécessaires. Si l’ordinateur est joint à un domaine, les membres
du groupe Admins du domaine peuvent être en mesure d’effectuer cette procédure.

Pour réaliser la même opération en ligne de commande, procédez comme suit :

1.
Ouvrez l’invite de commandes.
2.
Tapez la commande :
dnscmd NomServeur /ZoneAdd NomZone {/Primary|/DsPrimary|/
Secondary|/ Stub|/DsStub} [/file NomFichier] [/load]
[/a AdminEmail] [/DP FQDN]

Le paramètre /ZoneAdd ainsi que le nom complet de la zone sont obligatoires. Ils permettent de
spécifier l’ajout de la zone souhaitée.

Pour afficher la syntaxe complète de cette commande, à l’invite de commandes, tapez : dnscmd
/ZoneAdd /help

3. Configuration des zones DNS en mode dynamique

Ce TP va vous permettre d’activer le mode d’inscription dynamique des enregistrements DNS.

Pour autoriser les mises à jour dynamiques, procédez de la manière suivante :


Page 117
1.
Ouvrez la console de gestion du DNS.
2.
Dans l’arborescence de la console, cliquez avec le bouton droit sur la zone appropriée puis cliquez sur
Propriétés.
3.
Sous l’onglet Général, vérifiez que la zone est de type Principale ou Intégrée à Active Directory.
4.
Dans Mises à jour dynamiques, cliquez sur Non sécurisé et sécurisé.

Pour effectuer cette procédure, vous devez être membre du groupe Administrateurs sur l’ordinateur local, ou
avoir reçu par délégation les autorisations nécessaires. Si l’ordinateur est joint à un domaine, les membres
du groupe Admins du domaine peuvent être en mesure d’effectuer cette procédure.

Pour réaliser la même opération en ligne de commande, procédez comme suit :

1.
Ouvrez l’invite de commandes.
2.
Tapez : dnscmd NomServeur /Config {NomZone|..AllZones} /AllowUpdate {1|0}

Pour configurer toutes les zones hébergées sur le serveur DNS spécifié en vue de mises à jour
dynamiques, tapez AllZones.

Le paramètre /AllowUpdate est bien sûr obligatoire. Il spécifie la commande d’autorisation de mise à
jour. Si vous voulez autoriser les mises à jour dynamiques, entrez la valeur 1, sinon entrez la valeur 0.

Pour effectuer cette procédure, vous devez être membre du groupe Administrateurs sur l’ordinateur local ou
avoir reçu, par délégation, les autorisations nécessaires. Si l’ordinateur est joint à un domaine, les membres
du groupe Admins du domaine peuvent être en mesure d’effectuer cette procédure.

Pour afficher la syntaxe complète de cette commande, tapez :dnscmd /RecordAdd /help

4. Test de bon fonctionnement du service DNS à l’aide de Nslookup

Ce TP va vous permettre de vérifier le bon fonctionnement du service DNS.

1.
Ouvrez l’invite de commandes et tapez nslookup.
2.
À l’issue de la commande précédente, à l’invite nslookup («> »), tapez ce qui suit : set q=srv
3.
À l’issue de la commande précédente, tapez ce qui suit :
_ldap._tcp.dc._msdcs.Nom_Domaine_Active_Directory
4.
Consultez la sortie de la requête d’emplacement du service (SRV) précédente et déterminez si une action
supplémentaire est requise en fonction de l’échec ou du succès de la requête précédente.
5.
En cas de succès de la requête, consultez les enregistrements de ressources SRV renvoyés dans la requête
pour déterminer si tous les contrôleurs de domaine de votre domaine Active Directory sont inclus et inscrits
à l’aide d’adresses IP valides.
6.
En cas d’échec de la requête, poursuivez la résolution des problèmes de mise à jour dynamique ou de
serveur DNS pour déterminer la cause exacte du problème.

_ldap._tcp.dc._msdcs.votre_domaine_Active_Directory correspond au nom DNS configuré pour être


utilisé avec votre domaine Active Directory et tout contrôleur de domaine qui lui est associé. Par exemple, si
le nom de domaine DNS de votre domaine Active Directory est corpnet.company.com, tapez ce qui suit :
_ldap._tcp.dc._msdcs. corpnet.company.com.

Page 118
Pour ajouter les enregistrements de ressources d’emplacement du service (SRV) qui ont été créés pour un
contrôleur de domaine, ouvrez et affichez le fichier Netlogon.dns, créé par l’Assistant Installation de Active
Directory, situé à l’emplacement suivant : %Systemroot%\System32\Config\Netlogon.dns

5. Création des enregistrements de A et PTR

Enregistrement de type A

Ce TP va vous permettre de créer un enregistrement de type A au sein de votre zone DNS.

1.
Ouvrez la console DNS. Par exemple, pour y parvenir cliquez sur Démarrer, sur Panneau de
configuration, double cliquez sur Outils d’administration, puis sur DNS.
2.
Dans l’arborescence de la console, cliquez avec le bouton droit sur la zone de recherche directe applicable,
puis cliquez sur Nouvel hôte.
3.
Dans la zone de texte Nom, tapez le nom d’ordinateur DNS du nouvel hôte.
4.
Dans la zone de texte Adresse IP, tapez l’adresse IP du nouvel hôte.
5.
Vous avez la possibilité d’activer la case à cocher Créer un pointeur d’enregistrement PTR associé pour
créer un enregistrement pointeur supplémentaire dans une zone indirecte pour cet hôte, sur la base des
informations spécifiées dans les zones Nom et Adresse IP.
6.
Cliquez sur Ajouter un hôte pour ajouter le nouvel enregistrement d’hôte à la zone.

Pour effectuer cette procédure, vous devez être membre du groupe Administrateurs sur l’ordinateur local ou
avoir reçu, par délégation, les autorisations nécessaires. Pour ouvrir DNS, cliquez sur Démarrer, sur Outils
d’administration, puis sur DNS.

Les enregistrements de ressources PTR créés automatiquement lors de l’ajout d’un enregistrement de
ressource A dans une zone, seront automatiquement supprimés si l’enregistrement de ressource A
correspondant l’est aussi.

Pour réaliser la même opération à la ligne de commande, procédez comme suit :

1.
Ouvrez l’invite de commandes.
2.
Tapez dnscmd NomServeur /RecordAdd NomZone NomN_ud [/Aging] [/OpenAcl] [Ttl] A AdresseIP

Pour plus d’informations sur les paramètres ci-dessous, utilisez la commande : dnscmd /? ou la
commande dnscmd /RecordAdd /help.

Pour effectuer cette procédure, vous devez être membre du groupe Administrateurs sur l’ordinateur local ou
avoir reçu, par délégation, les autorisations nécessaires. Si l’ordinateur est joint à un domaine, les membres
du groupe Admins du domaine peuvent être en mesure d’effectuer cette procédure.

Enregistrement de type PTR

Ce TP va vous permettre de créer un enregistrement de pointeur (PTR) dans votre zone de recherche
inversée.

1.
Ouvrez la console DNS. Pour y parvenir, vous pouvez, par exemple, cliquer sur Démarrer, Outils
d’administration, puis sur DNS.
2.
Dans l’arborescence de la console, cliquez avec le bouton droit sur la zone de recherche indirecte applicable.
3.
Dans le menu Action, cliquez sur Nouveau pointeur.
4.

Page 119
Dans la zone de texte Numéro IP de l’hôte, tapez le numéro en octets de l’adresse IP de l’hôte.
5.
Dans la zone de texte Nom de l’hôte, tapez le nom de domaine complet de l’ordinateur hôte DNS pour
lequel cet enregistrement de pointeur doit être utilisé en vue d’assurer la recherche indirecte (résolution de
l’adresse en nom).
6.
Vous avez la possibilité de cliquer sur Parcourir pour rechercher dans l’espace de noms DNS les hôtes de ce
domaine dont les enregistrements de ressource A (adresse d’hôte) sont déjà définis.
7.
Cliquez sur OK pour ajouter le nouvel enregistrement à la zone.

Pour effectuer cette procédure, vous devez être membre du groupe Administrateurs sur l’ordinateur local, ou
avoir reçu par délégation les autorisations nécessaires. Si l’ordinateur est joint à un domaine, les membres
du groupe Admins du domaine peuvent être en mesure d’effectuer cette procédure.

Pour réaliser la même opération à la ligne de commande, procédez comme suit :

1.
Ouvrez l’invite de commandes.
2.
Tapez : dnscmd NomServeur /RecordAdd NomZone NomN_ud [/Aging] [/OpenAcl] [Ttl] PTR
NomHôte|NomDomaine

Pour afficher la syntaxe complète de cette commande, à l’invite de commandes, tapez : dnscmd
/RecordAdd /help

Les enregistrements de ressources PTR sont automatiquement supprimés si l’enregistrement de ressource A


correspondant est supprimé.

6. Création d’un nouveau sous-domaine

Ce TP va vous permettre de créer un nouveau sous-domaine au sein d’une zone déjà existante.

Pour créer un nouveau sous-domaine, procédez tel que cela est spécifié ci-dessous :

1.
Ouvrez la console DNS. Par exemple, pour y parvenir cliquez sur Démarrer, Outils d’administration, puis
sur DNS.
2.
Dans l’arborescence de la console, cliquez avec le bouton droit sur la zone de recherche directe souhaitée.
Vous pouvez, par exemple, sélectionner la zone corpnet.company.com.
3.
Faites un clic droit, Nouveau domaine....
4.
Dans la fenêtre Entrez le nouveau nom de domaine DNS, tapez : europe et validez à l’aide du bouton
OK.
5.
Vérifiez que le nom de sous-domaine apparaît bien.

Vous pouvez aussi créer un enregistrement de type A, à l’intérieur du sous-domaine précédemment


créé. Notez que tant que le sous-domaine ne contient aucun enregistrement, aucune modification n’est
apportée au fichier de zone "contenant" le sous-domaine.

7. Création d’un nouveau sous-domaine en tant que nouvelle zone

Ce TP va vous permettre de créer un nouveau sous-domaine au sein d’une nouvelle zone. Cette
procédure revient à créer un nouveau domaine grâce à la création d’un nouveau fichier de zone.

Par exemple, si vous disposez du domaine DNS corpnet.company.com via le fichier de zone nommé
corpnet.company.com.dns alors, pour créer le sous-domaine europe. corpnet.company.com, procédez à
la création d’une nouvelle zone.

Pour créer une nouvelle zone de recherche directe, procédez de la manière suivante :
Page 120
1.
Ouvrez la console de gestion du DNS.
2.
Dans l’arborescence de la console, cliquez avec le bouton droit sur un serveur DNS puis cliquez sur
Nouvelle zone afin d’ouvrir l’Assistant Nouvelle zone.
3.
Choisissez le type de zone : Principale.
4.
Déclarez le nom de domaine tel que souhaité - europe.corpnet.company.com, puis suivez les instructions
jusqu’à la fin de l’assistant.

8. Configuration d’une zone secondaire et du transfert de zones

Création d’une zone secondaire

Ce TP va vous permettre de créer une zone secondaire.

La création d’une zone secondaire vous permet de profiter de la disponibilité d’une zone sur un site
donné. Cette opération aura pour effet de disposer sur le serveur en question d’une version de la zone.

1.
Ouvrez la console de gestion du DNS.
2.
Dans l’arborescence de la console, cliquez sur le serveur DNS souhaité.
3.
Dans le menu Action, cliquez sur Nouvelle zone.
4.
Suivez les instructions qui s’affichent dans l’Assistant Nouvelle zone. Dans notre cas, sélectionnez Zone
secondaire. Remarquez que la case à cocher Enregistrer la zone dans Active Directory est grisée.
5.
Déclarez le nom de la zone DNS que vous souhaitez rendre disponible en tant que zone secondaire sur le
serveur.
6.
Spécifiez le ou les serveurs DNS à partir desquels vous souhaitez copier la zone. Pensez à ordonner les
serveurs dans l’ordre de préférence de la sélection.
7.
Sur la fenêtre Fin de l’assistant Nouvelle zone, cliquez sur Terminer.

Pour effectuer cette procédure, vous devez être membre du groupe Administrateurs sur l’ordinateur local ou
avoir reçu, par délégation, les autorisations nécessaires. Si l’ordinateur est joint à un domaine, les membres
du groupe Admins du domaine peuvent être en mesure d’effectuer cette procédure. Pour des raisons de
sécurité, il est recommandé d’utiliser Exécuter en tant que pour effectuer cette procédure.

Pour ajouter un serveur secondaire pour une zone existante, vous devez disposer d’un accès réseau au
serveur agissant comme le serveur maître de ce serveur et son utilisation de la zone. Le serveur maître agit
comme la source des données de zone. Il est contacté régulièrement pour participer au renouvellement de la
zone et transférer les mises à jour de zone lorsque cela est nécessaire en fonction des notifications de
modifications de la zone maître et des paramètres de l’enregistrement de SOA.

Pour réaliser la même opération à la ligne de commande, procédez comme suit :

1.
Ouvrez l’invite de commandes, puis tapez dnscmd NomServeur /ZoneAdd NomZone /Secondary
AdresseIPMaître...[/file NomFichier]

Les paramètres /ZoneAdd, NomZone et /Secondary sont obligatoires. Pour afficher la syntaxe complète
de cette commande, tapez à partir de l’invite de commandes, la commande : dnscmd /ZoneAdd /help

Configuration des options de transfert de zones

Ce TP va vous permettre d’autoriser les transferts de zones entre votre serveur DNS et un autre
serveur DNS.

Pour modifier les paramètres de transfert de zone DNS, procédez comme suit :
Page 121
1.
Ouvrez la console de gestion du DNS.
2.
Cliquez avec le bouton droit sur une zone DNS, puis cliquez sur Propriétés.
3.
Dans l’onglet Transfert de fichiers, effectuez l’une des actions suivantes :
 Pour désactiver les transferts de zone, désactivez la case à cocher Autoriser les transferts
de zone.
 Pour activer les transferts de zone, activez la case à cocher Autoriser les transferts de
zone.

Si vous avez autorisé les transferts de zone, effectuez l’une des actions suivantes :

 Pour autoriser les transferts de zone vers n’importe quel serveur, cliquez sur Vers n’importe
quel serveur.
 Pour autoriser les transferts de zone uniquement vers les serveurs DNS énumérés sous
l’onglet Serveurs de noms, cliquez sur Uniquement vers les serveurs listés dans
l’onglet Serveurs de noms.
 Pour autoriser les transferts de zones uniquement vers des serveurs DNS spécifiques, cliquez
sur Uniquement vers les serveurs suivants, puis ajoutez l’adresse IP d’un ou plusieurs
serveurs DNS.

Pour effectuer cette procédure, vous devez être membre du groupe Administrateurs sur l’ordinateur local, ou
avoir reçu par délégation les autorisations nécessaires. Si l’ordinateur est joint à un domaine, les membres
du groupe Admins du domaine peuvent être en mesure d’effectuer cette procédure.

Pour réaliser la même opération à la ligne de commandes, procédez comme suit :

1.
Ouvrez l’invite de commandes, puis tapez la commande suivante :
dnscmd NomServeur /ZoneResetSecondaries NomZone
{/NoXfr | /NonSecure |
/SecureNs | /SecureList [AdresseIPSecondaire...]}

Pour effectuer cette procédure, vous devez être membre du groupe Administrateurs sur l’ordinateur local, ou
avoir reçu par délégation les autorisations nécessaires. Si l’ordinateur est joint à un domaine, les membres
du groupe Admins du domaine peuvent être en mesure d’effectuer cette procédure.

Cette procédure nécessite l’outil de support Windows Dnscmd. Pour afficher la syntaxe complète de cette
commande, tapez à partir de l’invite de commandes :dnscmd /ZoneResetSecondaries /?

9. Création d’une nouvelle zone DNS mise en délégation

Ce TP a pour objet la création d’une nouvelle zone mise en délégation sur un autre serveur.

Pour créer une délégation de zone, procédez comme suit :

1.
Ouvrez la console de gestion du DNS.
2.
Dans l’arborescence de la console, cliquez avec le bouton droit sur le sous-domaine approprié, par exemple
corpnet.company.com, puis cliquez sur Nouvelle délégation.
3.
Suivez les instructions affichées par l’Assistant Nouvelle délégation pour terminer la création du nouveau
domaine délégué tel que précisé ci-dessous.
4.
Dans la fenêtre Spécifier le nom de domaine que vous voulez déléguer, entrez le nom du domaine à
mettre en délégation. Par exemple, entrez le nom "support".
Vérifiez que le nom de domaine pleinement qualifié est bien conforme. Par exemple, il pourra s’agir du
domaine support.corpnet.company.com.
5.
Page 122
Dans la fenêtre Serveurs de noms, déclarer le ou les serveurs de noms DNS faisant autorité pour la zone
DNS mise en délégation. Chaque serveur déclaré doit faire l’objet d’un enregistrement pleinement qualifié
(FQDN) ainsi que de l’adresse IP associée.
6.
Faites Suivant, puis Terminer pour conclure la mise en délégation de la zone
support.corpnet.company.com.

Pour effectuer cette procédure, vous devez être membre du groupe Administrateurs sur l’ordinateur local, ou
avoir reçu par délégation les autorisations nécessaires. Si l’ordinateur est joint à un domaine, les membres
du groupe Admins du domaine peuvent être en mesure d’effectuer cette procédure.

Pour réaliser la même opération à la ligne de commande, procédez comme suit :

1.
Ouvrez l’invite de commandes, puis tapez la commande suivante :
dnscmd NomServeur /RecordAdd NomZone NomNœud
[/Aging] [/OpenAcl] [Ttl] NS {NomHôte|FQDN}

Le paramètre /RecordAdd suivi du nom de zone (FQDN, Fully Qualified Domain Name) de la zone à
ajouter sont obligatoires. Pour afficher la syntaxe complète de cette commande, à l’invite de
commandes, tapez : dnscmd /RecordAdd /help

10. Création d’une nouvelle zone DNS de stub

Ce TP a pour objet de créer une nouvelle zone DNS de type stub.

Pour ajouter une zone de stub, procédez de la manière suivante :

1.
Ouvrez la console de gestion du DNS.
2.
Dans l’arborescence de la console, cliquez avec le bouton droit sur un serveur DNS puis cliquez sur
Nouvelle zone afin d’ouvrir l’Assistant Nouvelle zone.
3.
Suivez les instructions à l’écran pour créer une zone de stub tel que précisé ci-dessous.
4.
Sur la fenêtre Quel est le nom de la nouvelle zone ?, renseignez le nom de la zone de stub à créer. Dans
notre exemple, tapez vente.corpnet.company.com.
5.
Dans la fenêtre Fichier de zone, acceptez Créer un nouveau fichier nommé.
6.
Dans la fenêtre Serveurs DNS maîtres, déclarez la ou les adresses IP des serveurs DNS possédant la zone.
7.
Sur la fenêtre Fin de l’assistant Nouvelle zone, cliquez sur Terminer.

Pour effectuer cette procédure, vous devez être membre du groupe Administrateurs sur l’ordinateur local, ou
avoir reçu par délégation les autorisations nécessaires. Si l’ordinateur est joint à un domaine, les membres
du groupe Admins du domaine peuvent être en mesure d’effectuer cette procédure. Pour des raisons de
sécurité, il est recommandé d’utiliser Exécuter en tant que pour effectuer cette procédure.

Attention : la zone de stub ne peut pas être hébergée sur un serveur DNS faisant autorité pour la même
zone.

Si vous choisissez d’intégrer la zone de stub dans Active Directory (en utilisant Active Directory comme
méthode de stockage de la zone de stub), vous avez la possibilité de spécifier que le serveur DNS
hébergeant la zone de stub utilise une liste locale de serveurs maîtres lors de la mise à jour des
enregistrements de ressources de la zone de stub plutôt que la liste de serveurs maîtres de Active Directory.
Si vous voulez utiliser une liste locale de serveurs maîtres, vous aurez besoin des adresses IP des serveurs
maîtres locaux.

Pour réaliser la même opération à la ligne de commande, procédez comme suit :

Page 123
1.
Ouvrez une invite de commandes puis tapez :
dnscmd NomServeur /ZoneAdd NomZone {/Stub|/DsStub}
AdresseIP_Maître... [/file NomFichier] [/load] [/DP FQDN]

Les paramètres /ZoneAdd, et nomZone sont obligatoires. Le type de la zone est spécifié à l’aide du
paramètre /Stub ou /DsStub, si le stockage Active Diretory est souhaité.

Pour effectuer cette procédure, vous devez être membre du groupe Administrateurs sur l’ordinateur local, ou
avoir reçu par délégation les autorisations nécessaires. Si l’ordinateur est joint à un domaine, les membres
du groupe Admins du domaine peuvent être en mesure d’effectuer cette procédure. Pour afficher la syntaxe
complète de cette commande, à l’invite de commandes, tapez : dnscmd /ZoneAdd /help

11. Création des indications de racines DNS

Ce TP a pour objet de déclarer les serveurs racine d’un serveur DNS.

Pour gérer les enregistrements de racines DNS qui permettent de localiser d’autres serveurs DNS situés
au niveau de la racine DNS sur le réseau, procédez de la manière suivante :

1.
Ouvrez la console de gestion du DNS.
2.
Dans l’arborescence de la console, cliquez avec le bouton droit sur le serveur DNS concerné.
3.
Dans la page de propriétés du serveur DNS, sélectionnez l’onglet Indications de racine.
Par défaut, les indications de racines contenues dans le fichier Cache.dns sont au nombre de 13 et
correspondent aux serveurs DNS de la racine Internet. Chaque serveur est nommé a.root-servers.net
jusqu’à i.root-servers.net.
Si vous souhaitez que ce serveur soit capable d’en référer aux serveurs de la racine Internet, assurez-vous
que ces déclarations sont correctes et que le firewall qui vous permet de communiquer avec Internet est
configuré pour autoriser le passage des résolutions DNS (ports TCP et UDP 53) vers les dits serveurs.
4.
Si les enregistrements ne sont pas corrects, vous pouvez par exemple, utilisez le bouton Copier à partir du
serveur, déclarer l’adresse IP du serveur source contenant les indications de racines correctes, puis valider
par OK. Vous pouvez aussi transférer le fichier Cache.dns situé dans le dossier %Systemroot\System32\dns.
5.
Si vous ne souhaitez pas que le serveur DNS puisse "tenter" des résolutions vers des serveurs de type
racine, supprimez tous les enregistrements à l’aide du bouton Supprimer.

12. Configuration des redirecteurs conditionnels

Ce TP va vous permettre de déclarer l’usage des redirecteurs conditionnels.

Pour configurer un serveur DNS pour qu’il utilise des redirecteurs, procédez comme suit :

1.
Ouvrez la console de gestion du DNS.
2.
Dans l’arborescence de la console, cliquez sur le serveur DNS sur lequel vous souhaitez gérer les fonctions
de redirecteurs.
3.
Cliquez sur Propriétés.
4.
Sous l’onglet Redirecteurs, déclarez le ou les noms de domaines à rediriger.
5.
Pour chaque domaine déclaré, ajoutez la ou les adresses IP correspondantes, à l’aide du bouton Ajouter.

Vous ne pouvez pas utiliser un nom de domaine dans un redirecteur conditionnel si le serveur DNS héberge
une zone principale, secondaire ou de stub pour ce nom de domaine.

Pour réaliser la même opération à la ligne de commande, procédez comme suit :

Page 124
1.
Ouvrez une invite de commandes puis tapez
dnscmd NomServeur /ZoneAdd NomZone /Forwarder
AdresseIPMaître _ [/TimeOut Heure] [/Slave]

Les paramètres /ZoneAdd et NomZone sont obligatoires. Le nom de domaine doit respecter un format
FQDN. Le paramètre /Forwarder est aussi obligatoire.

Lors de la configuration de redirecteurs sur des serveurs DNS exécutant des contrôleurs de domaine
Active Directory, vous devez utiliser /DsForwarder à la place de /Forwarder. Le paramètre
/DsForwarder réplique les paramètres du redirecteur vers tous les serveurs DNS exécutés sur des
contrôleurs de domaines du domaine Active Directory.

Vous pouvez aussi afficher une zone qui a été ajoutée pour servir de redirecteur conditionnel
uniquement en utilisant la commande ci-dessous :
dnscmd NomServeur /ZoneInfo NomZone

Dans le cas où vous souhaiteriez réinitialiser les adresses IP des redirecteurs pour un nom de domaine
redirigé donné, vous pourrez taper la commande ci-dessous :
dnscmd NomServeur /ZoneResetMasters NomZone [/Local]
[IPServeur]

Le paramètre /Local définit la liste des serveurs maîtres pour les redirecteurs intégrés de Active
Directory, tandis que le paramètre IPServeur correspond à la liste d’une ou plusieurs adresses IP de
serveurs maîtres dans la zone.

13. Affichage du cache du serveur DNS

Ce TP va vous permettre de procéder à la visualisation du cache du serveur DNS.

Pour afficher le cache des résolutions DNS du serveur DNS, à ne pas confondre avec le cache des
clients DNS géré par le service DNSCache, utilisez la procédure ci-dessous :

1.
Ouvrez la console de gestion du DNS.
2.
Dans l’arborescence de la console, cliquez sur le serveur DNS sur lequel vous souhaitez afficher le cache de
résolution du serveur DNS.
3.
Cliquez sur Propriétés.
4.
Dans le menu Affichage, sélectionnez Affichage détaillé.
5.
Le dossier intitulé Recherches mises en cache apparaît et vous permet de gérer le contenu du cache du
serveur DNS.

De cette manière, vous pouvez par exemple, supprimer un enregistrement obsolète contenu dans le
cache.

Page 125
Intégration des zones DNS dans Active Directory

Pré-requis et objectifs
1. Pré-requis

Notions fondamentales sur le protocole TCP/IP et les services de résolution de noms DNS.

2. Objectifs

À la fin de ce chapitre, vous serez en mesure de :

Comprendre comment les zones DNS peuvent être stockées sur les serveurs DNS Windows 2000 Server,
Windows Server 2003 et Windows Server 2008.

Comprendre et gérer les possibilités d’intégration des zones DNS avec Windows 2000 Server, Windows
Server 2003 et Windows Server 2008.

Comprendre et gérer la sécurisation des mises à jour dynamiques des enregistrements.

Considérer les éventuels problèmes de compatibilité entre les serveurs DNS fonctionnant sous Windows
Server le les serveurs DNS non Windows.

L’annuaire Active Directory dépend fortement des services de résolution de noms DNS (Domain Name
System) pour localiser ses propres services. Il ne faut pas non plus oublier tous les composants ou
applications qui s’appuieraient sur les mêmes principes.

À titre d’exemple, et concernant des produits Microsoft, ce sera le cas de produits comme Exchange
Server ou Systems Management Server 2003, pour ne citer que deux grandes applications.

La majorité des principes utilisés par les services de domaine Active Directory possèdent un caractère
générique. L’intégration des applications dans l’Active Directory vous amènera à constater que ces mêmes
principes sont, eux aussi, utilisés de manière générique par de nombreuses applications tierces. L’idée est
que les services fondamentaux de l’Active Directory soient disponibles et utilisables de manière standard et
globale.

Concernant le service DNS et son rôle essentiel pour l’ensemble des services réseau Windows et pour
l’Active Directory lui-même, il paraît évident qu’il devient indispensable que ce service soit hautement
disponible.

Ce chapitre présente les principes, fonctionnalités et bonnes pratiques qui vous permettront de garantir
un bon fonctionnement des services DNS dans le cadre de l’intégration des zones DNS au sein de
l’annuaire Active Directory.

Stockage des zones DNS et réplication Active Directory


Nous venons de voir que les zones DNS standard existent sous la forme de fichiers lesquels sont
habituellement stockés dans \System32\dns. L’idée consiste à abandonner ce stockage pour utiliser le
système de stockage de l’Active Directory. Il convient de faire remarquer que l’Active Directory et le DNS
manipulent des noms qui peuvent être identiques mais que ces noms appartiennent à des espaces
différents.

Page 126
Le tableau suivant montre le parallèle qui existe entre les éléments qui appartiennent au DNS et ceux qui
appartiennent à l’Active Directory.

Éléments du DNS Éléments et objets de l’annuaire Active Directory

Stockage de type fichier Stockage de type base de données

Fichiers de zones dans \System32\dns Objets containers de type dnsZone

Enregistrements de ressources Objet de type dnsNode

Ainsi, on peut dire que l’espace DNS est composé de zones et d’enregistrements de ressources dans les
zones, tandis que l’espace Active Directory est composé de domaines et d’objets au sein de ces
domaines.

Les objets et attributs Active Directory utilisés dans le cadre du service DNS sont listés ci-dessous :

DnsZone : il s’agit d’un objet container créé au moment où une zone est créée dans l’Active Directory.

DnsNode : il s’agit d’un objet utilisé pour mapper un nom vers un enregistrement contenant de
multiples données.

DnsRecord : il s’agit d’un attribut de type multivaleurs associé à la classe d’objet dnsNode. Il est utilisé
pour stocker les enregistrements de ressources à l’objet dnsNode.

DnsProperty : il s’agit d’un attribut de type multivaleurs associé à la classe d’objet dnsNode. Il est
utilisé pour stocker les informations de configuration de la zone.

Finalement, chaque zone intégrée à l’annuaire sera stockée dans un objet container de type dnsZone,
lequel est identifié par le nom attribué à la zone au moment de sa création.

1. Objets ordinateurs Active Directory et nommages

Chaque ordinateur membre d’un domaine Windows Active Directory existe sous la forme d’un objet de
type Computer. La figure ci-après montre un ordinateur appartenant au domaine à l’aide de l’outil ADSI
Edit.

Le composant logiciel enfichable ADSI Edit est intégré de base à Windows Server 2008. Vous pouvez y
accéder en exécutant Adsiedit.msc. Notez que cet outil faisait partie des outils de support livrés sur le CD-
Rom de Windows Server 2003 et Windows 2000 Server.

L’ordinateur XP1 dans le container Computers du domaine Corp2003.Corporate.net

En tant qu’objet existant au sein de l’annuaire Active Directory, les propriétés existent sous la forme
d’attributs. Ainsi, ces attributs seront manipulés par l’annuaire lui-même, les applications ou bien toute
entité habilitée à le faire. La figure suivante montre la fenêtre permettant d’afficher ou de modifier les
attributs de l’objet, toujours avec ADSI Edit.

Page 127
Propriétés de l’objet XP1 et valeur de l’attribut dNSHostName

Le tableau donne les différents attributs d’un objet appartenant à la classe computer et étant en
relation avec la problématique de nommage.

Attributs de l’objet computer XP1 Désignation et valeur de l’attribut

Représente le nom canonique Active Directory de l’objet


canonicalName
Corp2003.Corporate.net/Computers/XP1.

cn Représente le nom commun LDAP de l’objet XP1.

displayName Représente le nom d’affichage LDAP de l’objet XP1$.

Représente le nom distinct complet

distinguishedName CN=XP1,CN=Computers,
DC=Corp2003,DC=Corporate,DC=net.

Représente le nom DNS sous la forme d’un FQDN


dNSHostName
xp1.Corp2003.Corporate.net.

name Représente le nom XP1.

Représente le nom SAM (Security Account Manager) de


sAMAccountName
l’ordinateur XP1$.

Représente les noms des identités (SPN, Security Principal


servicePrincipalName
Names) HOST/XP1 HOST/xp1.Corp2003.Corporate.net.

Page 128
Comme expliqué précédemment, ce tableau montre qu’un ordinateur au sein du domaine Windows
existe dans plusieurs espaces de nommages distincts. Les attributs les plus importants en termes de
sécurité sont le sAMAccountName et le servicePrincipalName, lequel peut d’ailleurs être contrôlé à
l’aide la commande SetSPN.exe.

Bien entendu, de nombreux autres attributs enrichiront l’annuaire d’informations dont l’usage sera plus
perceptible.

Quelques exemples d’attributs sont présentés ci-après :

Attributs de l’objet computer XP1 Désignation et valeur de l’attribut

CN=Computer,CN=Schema,CN=Configuration,DC=Corp2003,
objectCategory
DC=Corporate,DC=net.

operatingSystem Windows XP Professional.

operatingSystemServicePack Service Pack 2, v.2120.

operatingSystemVersion 5.1 (2600).

2. Avantages de l’intégration des zones DNS dans Active Directory

Les contrôleurs de domaine Windows 2000, Windows Server 2003 et Windows Server 2008 permettent
au service DNS de profiter des nombreuses avancées technologiques apportées par l’Active Directory.
Ces avantages sont présentés ci-dessous :

a. Mise à jour en mode multimaîtres (ou maîtres multiples)

Dans le modèle habituel de stockage des zones DNS, les mises à jour ne sont possibles que vers le
serveur primaire pour la zone. De fait, un seul et unique serveur DNS servant de référence pour la
zone est disponible en lecture et écriture. Il s’agit là d’une énorme limitation lorsque l’on souhaite
profiter des mises à jour DNS en mode dynamique.

Un autre inconvénient majeur du modèle DNS est que toute la disponibilité en écriture de la zone
repose sur le seul serveur principal. Si ce serveur n’est pas disponible, les requêtes de mise à jour
formulées par des clients DNS ne sont pas traitées pour toute la zone. De plus, lorsque la zone arrive
à expiration en fonction de la valeur fixée sur l’enregistrement de SOA, celle-ci passe au statut
d’expirée et plus aucune demande de résolution DNS n’est traitée.

À l’inverse, lorsqu’une zone DNS est intégrée à l’Active Directory et que la zone est configurée pour
supporter les mises à jour dynamiques, alors ces mises à jour peuvent aussi être prises en charge en
mode multimaîtres. En fait, tout serveur DNS de type NS et contrôleur de domaine devient une source
principale pour la zone. Par conséquent, la zone peut être mise à jour par les serveurs DNS
fonctionnant sur tout contrôleur de domaine du domaine. Un tel concept permet d’offrir une
disponibilité totale, pourvu que l’on dispose de plusieurs contrôleurs de domaine fonctionnant en tant
que serveurs DNS.

b. Sécurité avancée des contrôles d’accès sur la zone et les enregistrements

Chaque enregistrement de ressource DNS est un objet Active Directory de type dnsNode. À ce titre il
existe et profite, comme tous les objets de l’annuaire, des services de sécurité Active Directory. Dans
notre cas, il s’agira des authentifications mutuelles Kerberos v5 et de l’usage des SPN. Le support des
listes de contrôles d’accès vous permet de contrôler qui peut faire quoi sur chaque objet, c’est-à-dire
sur chaque enregistrement DNS.

Vous pouvez, par exemple, accéder aux fonctions des ACL (Access Control List) pour sécuriser un
conteneur dnsZone dans l’arborescence Active Directory. La granularité d’administration est très fine
puisque vous pourrez, si nécessaire, gérer chaque zone et chaque enregistrement au sein d’une zone.

Le groupe intégré Utilisateurs authentifiés dispose d’une autorisation de type Créer tous les
objets enfants. Cet ACL permet à tous les ordinateurs Windows 2000 Professionnel, Windows XP
Professionnel, Windows Vista, Windows Server 2003 ou 2008 d’être authentifiés.

Page 129
Le groupe de sécurité Utilisateurs authentifiés considère toutes les entités susceptibles d’être contrôlées
qu’il s’agisse d’objets utilisateurs, de groupes ou d’objets de type ordinateurs.

Une liste de contrôle d’accès par défaut sécurise chaque nouvel enregistrement. La figure ci-après
montre les autorisations sur l’enregistrement qui concerne l’ordinateur nommé XP1, membre du
domaine Corp2003.Corporate. net.

Le groupe ENTERPRISE DOMAIN CONTROLLERS dispose de l’autorisation d’écriture sur l’objet


xp1

Vous constatez donc qu’au départ, toutes les machines authentifiées - via le protocole Kerberos -
pourront créer dynamiquement leur propre enregistrement. Une fois l’objet créé, les contrôleurs de
domaine de l’entreprise pourront modifier l’enregistrement, toujours pour le compte du client. Dans le
cas d’un environnement réseau particulièrement sécurisé, vous pouvez spécifier vos propres
autorisations de sorte que les mises à jour dynamiques ne soient autorisées que pour un ordinateur
client spécifique. Ce pourrait aussi être le cas pour un groupe de sécurité particulier, lequel pourra
contenir des utilisateurs et/ou des ordinateurs. Notez aussi que, les listes de contrôle d’accès que
vous spécifiez sur des objets Active Directory via la console MMC de gestion du DNS, ne concernent
que le service client DNS.

Les fonctionnalités de contrôle d’accès ne sont pas disponibles avec les zones principales standard mais
seulement pour des zones DNS intégrées dans l’Active Directory.

Page 130
Sélection des mises à jour dynamiques sécurisées pour la zone Corp2003.Corporate.net

Lorsqu’une zone est intégrée à l’annuaire, le paramètre par défaut de mise à jour de la zone est
modifié de manière à autoriser uniquement les mises à jour sécurisées.

La tolérance de panne est maximum. Les zones sont automatiquement répliquées et synchronisées
sur les nouveaux contrôleurs de domaine dès qu’ils sont ajoutés à un domaine Active Directory.

Les zones intégrées à l’annuaire sont par défaut stockées sur chaque contrôleur de domaine. Le
stockage et la gestion de zone ne constituent donc pas une ressource supplémentaire. De plus, les
méthodes utilisées pour synchroniser les informations stockées dans l’annuaire offrent de meilleures
performances par rapport aux méthodes standard de mise à jour des zones, qui exigent une
configuration manuelle et parfois le transfert complet de la zone.

Les performances des réplications des zones intégrées à Active Directory sont directement liées au
fait que le moteur de réplication de l’annuaire réplique avec une granularité très fine. En effet, les
réplications sont réalisées indépendamment pour chaque objet, pour chaque attribut d’objet et pour
chaque valeur d’attribut d’objet.

Concernant les réplications, celles-ci sont compressées sur les liens inter-sites. En intégrant le
stockage de vos bases de données de zones DNS dans Active Directory, vous pouvez donc simplifier la
réplication des zones DNS à l’échelle de tout le réseau de l’entreprise.

La suppression du service DNS d’un contrôleur de domaine ne supprime pas les données contenues dans la
base de données Active Directory.

Si vous utilisez des zones DNS en mode standard et aussi en mode intégré à Active Directory, ces
deux types de zones sont forcément stockées et répliquées séparément. Dans ce cas, vous devez bien
sûr les administrer séparément. Il faudra alors implémenter et gérer deux topologies de réplication
distinctes. Une topologie de réplication sera nécessaire pour les données stockées dans l’annuaire et
une autre topologie sera nécessaire pour répliquer les fichiers de zones entre les serveurs DNS
standard. Une telle configuration n’en sera que plus complexe à maintenir et à faire évoluer, même
s’il n’y a pas de difficultés techniques particulières.

Page 131
Avec l’intégration des zones DNS dans l’annuaire, tous les problèmes de réplication et de gestion du
stockage qui se posent pour DNS et pour Active Directory sont fusionnés en une seule entité
administrative.

La réplication d’annuaire est plus rapide et plus efficace que la réplication DNS standard et profite aux
zones DNS particulièrement volumineuses.

Dans la mesure où la réplication Active Directory ne concerne que les éléments ajoutés, supprimés ou
modifiés (objets, attributs ou valeurs d’attributs) seules les modifications essentielles sont propagées.
Ces optimisations permettent de minimiser les opérations LDAP ainsi que les flux de réplication entre
les contrôleurs de domaines.

Les zones secondaires ne peuvent pas être stockées dans l’annuaire, seules les zones principales Active
Directory peuvent l’être. À partir du moment où les serveurs DNS sont des serveurs Windows qui tirent
partie du modèle de réplication multimaîtres Active Directory, il n’y a plus d’intérêt à conserver de zones
secondaires.

3. Partitions par défaut disponibles sous Windows 2000

Les contrôleurs de domaine Windows 2000 disposent de plusieurs espaces de stockage appelés
partitions. Une partition, aussi appelée contexte de nommage (en anglais, naming context), est une
structure de stockage de données située à l’intérieur de l’annuaire Active Directory. Elle permet à
l’annuaire de distinguer plusieurs topologies de réplication. Plus simplement, vous pouvez imaginer que
l’annuaire Active Directory existe sous la forme d’une base de donnée unique, laquelle est composée de
plusieurs parties qui appartiennent à des topologies de réplication distinctes.

Dans l’environnement Windows 2000, la base de données Active Directory contient uniquement, pour
notre domaine de test Corp2003.Corporate.net, les trois partitions présentées ci-après :

 La partition du Domaine dont le nom complet est : DC=Corp2003,DC=Corporate,DC=Net

Cette partition contient tous les objets de types utilisateurs, groupes d’utilisateurs,
ordinateurs, stratégies de groupes, etc.

 La partition de la Configuration de l’Entreprise dont le nom complet est :


CN=Configuration,DC=Corp2003,DC=Corporate,DC=Net

Cette partition contient tous les objets de configuration de l’annuaire Active Directory et aussi
de certaines applications intégrées à l’Active Directory.

 La partition du Schéma de l’Entreprise dont le nom complet est :


CN=Schema,CN=Configuration,DC=Corp2003,DC=Corporate,DC=Net

Cette partition contient toutes les classes et attributs qui formalisent les objets gérables par
l’annuaire.

La configuration de l’Active Directory montre les trois partitions

Page 132
La figure ci-dessus montre très clairement les trois partitions par défaut créées automatiquement au
moment de l’installation de l’Active Directory à l’aide de l’Assistant d’Installation dcpromo. L’arbre
affiché par ADSI Edit montre les contextes de nommage du domaine, de la configuration et du schéma.

Vous pouvez aussi constater que la partition de configuration dont le nom LDAP est
CN=Configuration,DC=Corp2003,DC=Corporate,DC=net contient, au niveau de l’objet CN=Partitions, la
déclaration des trois partitions présentées.

Nous verrons plus loin que lorsqu’un contrôleur de domaine joue le rôle de catalogue global et que
l’infrastructure de forêt de l’Active Directory contient plus d’un domaine, alors le contrôleur de domaine
catalogue global accueillera aussi les partitions de domaine du ou des autres domaines membres de la forêt.

Vous aurez aussi la possibilité de manipuler les partitions Active Directory à l’aide de la commande
NTDSutil. Cet outil est livré de base dans le système Windows 2000 ou Windows Server 2003.

La commande NTDSutil est l’outil Active Directory qui vous permettra de réaliser l’essentiel des tâches
de maintenance et/ou de configuration de l’Active Directory.

4. Intégration des zones DNS dans Active Directory avec Windows 2000

Concernant le cas des contrôleurs de domaine Windows 2000, l’intégration des zones au sein de
l’annuaire Active Directory consiste à accueillir les dites zones au sein de la partition du domaine. Notez
que seule cette partition peut être utilisée. La figure suivante montre que cette option est proposée sur
un contrôleur Windows Server 2003 lorsque le domaine comporte à la fois des contrôleurs Windows
2000 et Windows Server 2003.

Paramètres de Type et de Réplication pour la zone en cours

En fonction de vos besoins, vous avez toute la liberté de choisir le type de chaque zone ainsi que les
détails concernant le stockage des zones répliquées dans l’annuaire Active Directory.

La figure ci-après montre que dans notre exemple la zone sera stockée et donc répliquée Vers tous les
contrôleurs de domaines du domaine Active Directory.

Page 133
Comme cela est précisé, cette option sera choisie si la zone doit être chargée par des serveurs DNS
Windows 2000 s’exécutant sur les contrôleurs de domaine présents au sein du même domaine.

Les quatre étendues de réplication proposées par Windows Server 2003

Le schéma qui suit illustre ce cas de figure. Le domaine est composé de contrôleurs de domaine
Windows 2000 et éventuellement de contrôleurs de domaine Windows Server 2003 et/ou Windows
Server 2008. Ces contrôleurs de domaine exécutent aussi le service serveur DNS de Windows lequel
héberge la zone DNS du domaine Active Directory corp2003.corporate.net - ou toute autre zone
nécessaire à l’environnement de production.

Intégration de type Windows 2000 des zones DNS dans Active Directory

L’intégration des zones DNS représentées sur ce schéma met en évidence les points suivants :

 Les trois contrôleurs de domaines Windows sont aussi des serveurs DNS. Ils sont tous
disponibles en lecture et en écriture pour toute zone dont les mises à jour sont dynamiques.
 Les enregistrements de ressources DNS existent en tant qu’objets Active Directory et sont
donc répliqués et sécurisés en tant que tels.

Page 134
À propos de la sécurité des enregistrements dans les zones DNS Active Directory. Microsoft recommande
fortement que les mises à jour dynamiques fonctionnent en mode "sécurisé uniquement". Dans ce cas,
seules les machines Windows membres du domaine Active Directory et authentifiées à l’aide du protocole
Kerberos version 5.0 auront la possibilité de réaliser des mises à jours dynamiques.

 Les clients DNS dynamiques tels que Windows 2000, Windows XP ou Windows Vista ont la
possibilité de s’enregistrer sur n’importe quels serveurs DNS dynamiques.
 Les anciens serveurs existant avant la mise en œuvre des nouveaux serveurs Windows Server
2003 ou Windows 2008 peuvent toujours participer en tant que serveurs DNS abritant des
zones secondaires pendant toute la période de transition. Comme les zones secondaires
standard sont disponibles uniquement en lecture seule, ces serveurs ne pourront pas
supporter les mises à jour dynamiques.

La mise en œuvre d’un réseau Windows Active Directory est souvent réalisée de manière progressive. Dans
ce cas, il convient de marier au mieux les postes de travail modernes avec les nouveaux serveurs jouant le
rôle de contrôleurs de domaine et de serveurs DNS. L’objectif est de faire en sorte que les postes de travail
les plus modernes puissent tirer partie le plus rapidement possible des services Active Directory (localisation
des contrôleurs, authentifications Kerberos, stratégies de groupes, services de certificats, etc.).

5. Intégration des zones DNS dans Active Directory avec Windows Server
2003 et Windows Server 2008

Les contrôleurs de domaine Windows Server 2003 et Windows Server 2008 disposent, pour jouer leur
rôle de contrôleurs de domaine, des mêmes partitions d’annuaire que les serveurs fonctionnant sous
Windows 2000. Pour rappel, il s’agit de la partition de schéma, de la partition de configuration, de la
partition du domaine courant, et des partitions des autres domaines de la forêt lorsque le contrôleur
joue aussi le rôle de catalogue global.

Une des nouveautés importantes apparue avec Windows Server 2003 et toujours d’actualité avec
Windows Server 2008 concerne les partitions de l’annuaire d’applications. Une partition de l’annuaire
d’applications est une partition Active Directory d’un nouveau type. Cette partition sera répliquée
uniquement vers un ou plusieurs contrôleurs Windows Server 2003 ou Windows Server 2008. Ainsi, un
contrôleur participant à la réplication d’une partition hébergera un réplica de cette même partition. Les
applications et les services pourront alors utiliser ce nouveau type de partition comme zone de stockage
de données spécifiques aux applications.

Pour illustrer ce principe, les services TAPI de Windows Server 2003 (Telephony Application
Programming Interface) peuvent être configurés pour stocker des données spécifiques aux applications
TAPI 3.1 dans une partition de l’annuaire d’applications.

À propos des partitions MS-TAPI de l’annuaire d’application : l’assistant Configurer votre serveur fournit
un emplacement central à partir duquel vous pouvez installer les nombreux services inclus dans Windows
Server 2003. Si vous installez l’annuaire Active Directory à l’aide de cet assistant, il en profitera pour créer
automatiquement une partition nommée par défaut MsTapi.nomdudomaine. Dans le cas où le contrôleur de
domaine serait installé sans passer par cet assistant, c’est-à-dire en utilisant directement la commande
dcpromo.exe, vous pourrez installer la partition de l’annuaire d’applications MSTAPI à l’aide de la
commande tapicfg.exe. Cette commande permet de réaliser les opérations de gestion spécifiques aux
services TAPI. Les deux commandes ci-dessous vous permettent respectivement d’afficher la configuration
TAPI et de créer la partition de l’annuaire d’applications suivantes : tapicfg show et tapicfg install
/directory:mstapi31.Corp2003.Corporate.net

L’outil de ligne de commande Ntdsutil vous permet aussi de manipuler les partitions gérées par Active
Directory. Cependant, à la différence d’un outil comme la commande tapicfg spécifiquement conçu pour
réaliser une série d’opérations de configuration spécifiques à TAPI, la commande ntdsutil vous permettra
uniquement de prendre en charge les opérations spécifiques à l’annuaire Active Directory.

Notez néanmoins qu’une partition de l’annuaire d’applications peut contenir tout type d’objet à
l’exception d’objets disposant d’identificateurs de sécurité (SID). L’idée est que la sécurité soit toujours
stockée dans les partitions "habituelles" de l’Active Directory et pas ailleurs. Il n’est donc pas possible
d’y créer des principes de sécurité tels que des objets de type utilisateurs, groupes de sécurité ou
ordinateurs. D’un point de vue de la gestion des partitions, il convient de spécifier que, quel que soit le
type de partition, seuls les membres du groupe Administrateurs de l’entreprise peuvent créer ou gérer

Page 135
manuellement les partitions de l’annuaire d’applications. D’un point de vue du stockage, l’avantage de
stocker des données d’applications - telles que celles qui concernent le DNS - dans une partition de
l’annuaire d’applications plutôt que dans une partition de l’annuaire de domaine est que vous profiterez
d’un plus grand contrôle des trafics de réplication. En effet, les données concernées seront uniquement
répliquées vers des contrôleurs de domaine choisis. Le tableau ci-après décrit les étendues de
réplication de zone disponibles pour les données de zone DNS intégrées à Active Directory.

Étendue de réplication Implémentation Windows

Réplique les données de la zone vers tous les serveurs DNS


Tous les serveurs DNS dans la forêt Active Directory : une
exécutés sur des contrôleurs de domaine dans la forêt Active
partition de l’annuaire d’application sera créée au niveau de la
Directory. Il s’agit généralement de l’étendue de réplication la
forêt.
plus importante.

Réplique les données de la zone vers tous les serveurs DNS


Tous les serveurs DNS dans le domaine Active Directory : une exécutés sur des contrôleurs de domaine du domaine Active
partition de l’annuaire d’application sera créée au niveau du Directory. Cette option constitue le paramètre par défaut de la
domaine. réplication de zone DNS intégrée à Active Directory dans la
famille Windows Server 2003 et Windows Server 2008.

Tous les serveurs DNS dans le domaine Active Directory : il Réplique les données de la zone vers tous les contrôleurs de
n’est pas nécessaire de créer une partition de l’annuaire domaine du domaine Active Directory. Ce choix est nécessaire
d’application. La zone sera créée au sein de la partition pour supporter le chargement d’une zone Active Directory par
existante dans le domaine. des serveurs DNS Windows 2000.

Réplique les données de la zone en fonction de l’étendue de


Tous les contrôleurs de domaine dans une partition de réplication de la partition de répertoire d’application spécifiée.
répertoire d’application spécifiée : une partition de l’annuaire Pour qu’une zone soit stockée dans la partition de répertoire
d’application devra être spécifiquement créée et répliquée vers d’application spécifiée, il faut que le serveur DNS qui héberge
les serveurs spécifiquement désignés. la zone soit inscrit dans la partition de répertoire d’application
spécifiée.

Ainsi, lorsqu’un nouveau domaine Active Directory est mise en œuvre sur la base d’un contrôleur de
domaine fonctionnant sous Windows Server 2003 ou Windows Server 2008, l’assistant d’installation
d’Active Directory prend l’initiative de créer les zones relatives au domaine Active Directory aux
emplacements spécifiés ci-après.

a. ForestDnsZones.NomForêtDns

Cette partition est créée par défaut et permet un stockage au niveau de l’ensemble de la forêt. Elle
est disponible sur tous les serveurs DNS fonctionnant sur les contrôleurs de domaine de la forêt. Par
conséquent, toute zone DNS stockée dans cette partition de l’annuaire d’applications sera répliquée
vers tous les serveurs DNS exécutés sur les contrôleurs de domaine de la forêt.

Bien évidemment, cette option est particulièrement importante pour garantir une grande disponibilité
des enregistrements critiques qui concernent l’infrastructure même de la forêt. Par défaut, l’Assistant
d’installation de Active Directory y stockera la zone contenant tous les contrôleurs de domaine de la
forêt.

Cette zone, très importante pour la forêt toute entière, est stockée à l’emplacement désigné ci-après :
_msdcs.NomdeDomaineDnsRacinedelaForêt. Dans notre exemple, il s’agira du domaine
_msdcs.Corp2003.Corporate.net.

b. DomainDnsZones.NomdeDomaineDns

Cette partition de l’annuaire d’applications est créée par défaut pour accueillir chaque domaine de la
forêt. Les zones DNS stockées dans cette partition de l’annuaire d’applications sont répliquées vers
tous les serveurs DNS fonctionnant sur les contrôleurs de domaine dudit domaine.

Ce choix ressemble à ce qui est aussi réalisé par défaut sur les contrôleurs de domaine Windows 2000.
Cependant une nuance importante existe. Sur les contrôleurs de domaine Windows 2000, les zones stockées
au niveau du domaine Active Directory utilisent la partition du domaine elle-même. Sur un serveur DNS

Page 136
contrôleur de domaine Windows Server 2003 ou Windows Server 2008, une zone stockée au niveau du
domaine pourra disposer de sa propre partition indépendante.

Outre la création des zones, si vous sélectionnez l’Assistant d’installation d’Active Directory pour
installer et configurer automatiquement un serveur DNS sur le contrôleur de domaine local, le serveur
DNS est installé sur l’ordinateur sur lequel s’exécute l’assistant. De plus, le paramètre du serveur DNS
préféré de l’ordinateur est configuré pour utiliser le nouveau serveur DNS local sur la base de
l’adresse de bouclage TCP/IP 127.0.0.1. Ainsi, le premier contrôleur de domaine est-il client de son
propre serveur DNS.

Le deuxième contrôleur à être installé dans le domaine devra alors utiliser le premier comme serveur
DNS préféré. Au final, plusieurs serveurs DNS contrôleurs de domaine hébergeront les zones du
domaine Active Directory et les autres ordinateurs (clients et serveurs) qui se joindront au domaine
devront utiliser au moins deux de ces serveurs DNS. Le fait qu’un client DNS puisse disposer de deux
serveurs DNS offrira une bonne tolérance de panne vis-à-vis d’un dysfonctionnement d’un serveur
DNS.

c. Utilisation d’autres partitions de l’annuaire d’applications

Vous avez aussi la possibilité d’utiliser vos propres partitions de l’annuaire d’applications Active
Directory. La figure suivante montre la console MMC de gestion du DNS offrant la possibilité de
sélectionner la partition à utiliser. Ainsi, la partition emeadns.Corp2003.Corporate.net pourra être
utilisée comme espace de stockage pour la zone EMEA (Europe Middle East and Africa).

Choix de l’étendue de la partition de l’annuaire d’applications

Lorsque vous choisissez une option de réplication, n’oubliez pas que plus la portée d’une réplication
est étendue, plus le trafic causé par la réplication sur le réseau sera dense. Par exemple, si vous
choisissez de répliquer les données d’une zone DNS vers tous les serveurs DNS de la forêt, le trafic
réseau produit sera plus dense que si vous répliquiez les données de la zone DNS vers tous les
serveurs DNS d’un seul domaine Active Directory de cette forêt.

Quels que soient vos choix initiaux, il est toujours possible de modifier après coup la manière dont les
données des zones devraient être répliquées. Cependant, le changement d’emplacement nécessitera
une réplication complète du contenu vers le ou les nouveaux emplacements.

d. Création d’une partition dans l’annuaire d’applications Active Directory

Pour créer une partition capable d’accueillir une zone DNS, vous devrez utiliser la commande ntdsutil
de la manière suivante :

1. À l’invite de commande, lancez ntdsutil. L’invite de commande ntdsutil s’affiche.

2. Tapez : domain management

3. Tapez : connections

Page 137
4. Tapez : connect to server FQDN-de-votre-contrôleur

5. Tapez : quit

6. Pour créer une partition d’annuaire d’applications, tapez la commande ci-après : create nc DN-
PartitionAnnuaireApp FQDN-ContrôleurDomaine. Ainsi, pour notre domaine de tests, il faudra
entrer la commande suivante : create nc dc=emeadns,dc=corp2003,dc=corporate,dc=net
booster2003.

La commande ntdsutil dispose d’une aide rudimentaire mais assez claire. Comme cela est souvent le
cas, les noms d’objets Active Directory devront être libellés en spécifiant le DN LDAP tandis que les
noms de serveurs devront utiliser le FQDN ou le hostname.

Une fois la partition de l’annuaire d’applications créée, il faut déclarer les différents contrôleurs de
domaines en tant que réplica de la nouvelle partition à l’aide de la commande : add nc replica DN-
PartitionAnnuaireApp FQDN du contrôleur de domaine visé par l’opération.

Automatisation des commandes Ntdsutil

Bien que les fonctions offertes par Ntdsutil soient pour la plupart des opérations critiques, il se peut
que vous souhaitiez automatiser certaines tâches en créant des scripts contenant une série de
commandes Ntdsutil. De nombreuses fonctions Ntdsutil exécutant des modifications, ouvrent un
message qui demande à l’utilisateur s’il souhaite vraiment exécuter l’opération particulière.
Évidemment, lorsque ces messages apparaissent, Ntdsutil attend une entrée clavier de la part de
l’utilisateur.

Les commandes popups off et popups on vous permettent respectivement de désactiver et d’activer
ces messages lorsque vous exécutez Ntdsutil à partir d’un fichier de commandes ou d’un script.

Les opérations prises en charge par ntdsutil peuvent être dangereuses pour le bon fonctionnement de
l’annuaire Active Directory. Il est donc recommandé de ne désactiver les messages de confirmation que
lorsque vous réalisez certains types de scripts. Une fois une opération réalisée à l’aide d’un script en mode
popups off n’oubliez pas de réactiver les confirmations à l’aide de la commande popups on.

La suppression d’une partition d’annuaire d’applications est tout aussi simple que la création. Toujours
à l’aide de ntdsutil, vous pouvez utiliser la même logique en spécifiant la commande : delete nc DN-
PartitionAnnuaire-App FQDN du contrôleur de domaine visé par l’opération.

La suppression du dernier réplica d’une partition de l’annuaire d’applications entraîne la perte définitive de
toutes les données stockées dans cette partition.

Pour effectuer ces opérations, vous devez être membre du groupe Admins du domaine ou du groupe
Administrateurs de l’entreprise dans Active Directory, ou avoir reçu par délégation les autorisations
nécessaires.

e. Réplication des partitions du répertoire d’applications et cas des catalogues globaux

Les données d’une zone DNS intégrée à Active Directory, stockées dans une partition de répertoire
d’applications ne sont pas répliquées dans le ou les catalogues globaux de la forêt. S’il est vrai qu’un
contrôleur de domaine qui contient le catalogue global peut également héberger des partitions de
répertoire d’applications, notez qu’il ne répliquera pas ces données dans le catalogue global.

Cependant, lorsque les données d’une zone DNS intégrée à Active Directory sont stockées dans une
partition de domaine, une partie de ces données est stockée dans le catalogue global. Ces
informations minimes sont nécessaires pour assurer une prise en charge des serveurs DNS
fonctionnant sous Windows 2000.

f. Stockage des zones, partitions d’applications et réplications

L’étendue de réplication d’une partition de répertoire d’applications respecte l’infrastructure de sites


Active Directory. Ainsi, comme cela est le cas sous Windows 2000, les paramètres de réplication
s’appliquent à l’ensemble des partitions connues. Par conséquent, la réplication de ces partitions se
produira avec le même calendrier de réplication inter-sites que celui déjà défini au niveau de
l’infrastructure de sites.

Page 138
g. Zones DNS intégrées dans Active Directory et partitions d’annuaire ADAM

Les serveurs Windows Server 2003 peuvent jouer le rôle de serveurs d’annuaire LDAP v2 et v3
standard sans pour autant nécessiter l’installation de la fonction de contrôleur de domaine Active
Directory.

Ce composant additionnel appelé ADAM pour Active Directory/Application Mode est disponible en
téléchargement sur le site Microsoft dans la catégorie "Features Packs" de Windows Server 2003.
Notez que ADAM est dans la littérature informatique parfois libellé AD/AM. Il permet la mise en œuvre
de multiples partitions d’annuaire ainsi que le support de plusieurs instances ADAM sur le même
serveur. Cette fonctionnalité permet d’accueillir sur le même serveur plusieurs schémas puisque
chaque instance doit disposer de son propre schéma. ADAM est particulièrement intéressant pour les
applications devant s’appuyer sur LDAP mais ne nécessitant pas une relation directe avec l’annuaire
Active Directory. Ainsi, la figure ci-après montre que les services et données globales sont stockés
dans l’Active Directory tandis que des données locales spécifiques à des applications seraient stockées
dans des partitions prises en charges par ADAM, c’est-à-dire sur des machines non contrôleurs de
domaine.

Sur les serveurs fonctionnant sous Windows Server 2008, les services AD LDS (pour Active Directory
Lightweight Directory Services) remplacent les services ADAM de Windows Server 2003. Notez qu’il s’agit
d’une évolution mineure nécessaire pour assurer un bon fonctionnement de ces services sur les plates-
formes Windows Server 2008.

Annuaire Active Directory et partitions d’annuaire de type ADAM

Les caractéristiques principales offertes par ADAM sont présentées ci-dessous :

 Les partitions prises en charge par ADAM sont similaires aux partitions de l’annuaire
d’applications de Windows Server 2003. Cependant, ces partitions ne nécessitent pas le
support du rôle de contrôleur de domaine.
 ADAM fonctionne sur Windows Server 2003 Standard Edition, Windows Server 2003
Enterprise Edition et Windows Server 2003 Datacenter Edition.
 ADAM ne peut pas être installé sur Windows Server 2003 Web Edition.
 ADAM fonctionne aussi sous Windows XP Professionnel. Cette configuration concerne en
principe les développeurs, sachant que Microsoft recommande de développer sur une plate-
forme système proche du système de production. La recommandation sera donc de réaliser
les développements sur une plate-forme de type Windows Server 2003.
 Une instance ADAM peut accueillir plus d’une partition.
 ADAM support les espaces de nommages X500 et DNS.
 La réplication des partitions ADAM respecte le même modèle que celui utilisé par Active
Directory. Chaque instance ADAM dispose de sa propre stratégie de réplication.

Page 139
 Les instances ADAM peuvent fonctionner sur des serveurs Windows Server 2003 membres
d’un domaine Active Directory mais aussi sur des serveurs autonomes.
 Chaque instance dispose de ses propres exécutables et de ses propres paramètres TCP/IP
(adresses, ports). Il est donc possible qu’un serveur héberge plusieurs instances ADAM de
différentes versions.
 Comme cela est le cas avec les contrôleurs de domaine Active Directory, la sauvegarde et la
restauration des instances ADAM sont directement prises en charge par les outils intégrés au
système Windows Server 2003.
 Vous pouvez administrer et supporter les instances ADAM à l’aide des mêmes outils que
ceux que vous utilisez déjà avec l’annuaire Active Directory. Vous pouvez ainsi continuer
d’utiliser LDP, ADSIEdit, Replmon, NTDSUtil et l’analyseur de performances pour le
monitoring de chaque instance.
 ADAM utilise les services de sécurité offerts par l’infrastructure Windows disponible. Ainsi,
vous pouvez implémenter des contrôles d’accès sur la base des principes de sécurité issus
de l’annuaire Active Directory, des domaines Windows NT 4.0, des comptes de l’ordinateur
local. Vous avez aussi la possibilité de créer des utilisateurs directement dans ADAM. Dans
ce cas, seules les authentifications LDAP de type "Simple Bind" seront supportées.
 Les comptes créés au sein de l’annuaire ADAM ne sont pas des principes de sécurité
Windows. Ils ne possèdent donc pas de SID.
 Le serveur ADAM n’est pas un serveur d’authentification Windows supportant le protocole
Kerberos v5. Cependant, ADAM peut utiliser des comptes situés dans un domaine Active
Directory et dans ce cas, utiliser des authentifications basées sur le protocole Kerberos v5.
 ADAM ne peut pas être directement utilisé par Exchange Server. Microsoft Exchange Server
nécessite obligatoirement des contrôles de sécurité basés sur les SID ainsi que le support du
protocole MAPI (Messaging API).

Microsoft précise que les concepts utilisés par ADAM, notamment ceux qui concernent l’isolation et la
virtualisation, sont intéressants à plus d’un titre. Par exemple, le rôle "Server EDGE" disponible avec
Microsoft Exchange Server 2007 utilise une instance ADAM jouant le rôle de serveur LDAP pour les services
Exchange sur une machine ne faisant pas partie du Domaine Active Directory. Le serveur ainsi "isolé"
dispose d’un niveau de sécurité plus élevé.

 Le composant principal ADAM est implémenté via DSAMain.exe. Sur un contrôleur de


domaine Active Directory, le serveur LDAP, le moteur de réplication DRS (Directory
Replication System), le centre de distribution des clés Kerberos ainsi que le support de la
SAM sont intégrés dans le module LSASS (Local Security Authority SubSystem).
 Les instances virtuelles ADAM sont implémentées sous la forme de services Windows.
 Le moteur LDAP ADAM reprend l’intégralité du code Active Directory.
 ADAM ne nécessite pas forcément l’usage du DNS pour localiser les serveurs ADAM. Les
applications peuvent être configurées pour interroger spécifiquement n’importe quel serveur.
 ADAM ne supporte pas les anciennes interfaces Microsoft comme la SAM.
 ADAM ne supporte aucune intégration avec le service de réplication de fichiers FRS (File
Replication Service).
 ADAM peut être utile lorsqu’il est nécessaire de disposer d’un serveur LDAP standard. Cette
solution sera aussi très intéressante lorsque vous souhaiterez implémenter une application
LDAP "à côté d’un annuaire déjà présent".

Une partition ADAM ne peut stocker aucun principe de sécurité. En fait, l’utilisation de l’annuaire ADAM dans
un environnement Microsoft signifie que l’annuaire Active Directory reste le fédérateur de tout ce qui
concerne les authentifications Kerberos et autres services globaux concernant l’infrastructure.

Les instances ADAM utilisent la sécurité de l’Active Directory.

Notez aussi que les partitions gérées par ADAM ne permettent pas de stocker des zones DNS de type Active
Directory. Comme nous le verrons plus loin, seuls des contrôleurs de domaine Windows 2000 ou Windows
Server 2003 peuvent héberger des partitions capables de contenir des zones DNS intégrées dans l’annuaire
Active Directory.

En résumé, ADAM est une solution complémentaire à l’annuaire Active Directory qui répondra aux
besoins exprimés par de nombreux développeurs Windows et non Windows. Cependant, notez que
Page 140
l’annuaire ADAM ne diminuera pas la nécessité qu’ont les entreprises de disposer d’une "Infrastructure
de services d’annuaire Active Directory".

Pour plus d’informations sur ADAM, consultez les adresses du site Microsoft :

http://www.microsoft.com/adam

http://www.microsoft.com/ad

Les services ADAM de Windows Server 2003 sont remplacés par les services AD LDS sur les systèmes
fonctionnant sous Windows Server 2008. Les principes fonctionnels, possibilités, limites et recommandations
relatives aux services AD LDS sont présentés au chapitre Composants de la structure logique.

h. Conditions nécessaires pour réaliser un changement de stockage

Pour pouvoir changer le stockage d’une zone à partir de la partition de domaine vers une partition de
l’annuaire d’applications, le contrôleur de domaine qui détient le rôle de maître d’attribution de noms
de domaines (en anglais, le Domain Naming Master FSMO) doit fonctionner sous Windows Server
2003 ou Windows Server 2008. Si tel n’est pas le cas, vous ne pourrez pas créer de partitions de
l’annuaire d’applications pour héberger la zone DNS.

Transfert du rôle de "Maître d’attribution de noms de domaines". Pour solutionner ce problème, il suffira de
transférer le rôle de maître d’attribution de noms de domaine à un contrôleur de domaine exécutant
Windows Server 2003 ou Windows Server 2008 puis de réitérer l’opération. Ce problème peut être dû à la
mise à niveau d’un contrôleur de domaine Windows 2000 existant.

i. Indications de racines

Lorsque le niveau fonctionnel de domaine est "Windows Server 2003" ou "Windows Server 2008",
alors les indications de racine qui permettent au serveur DNS d’en référer aux serveurs DNS du
domaine racine de l’espace DNS, sont stockées dans la partition de répertoire d’applications au niveau
du domaine.

Par contre, si le niveau fonctionnel de domaine est de type "Windows 2000 mode mixte" ou "Windows
2000 mode natif", alors les indications de racine sont stockées dans la partition du domaine. Notez
que cela était déjà le cas sur les contrôleurs de domaine fonctionnant sous Windows 2000.

La figure suivante montre les indications de racines par défaut au sein de la partition de domaine, du
domaine Corp2003.Corporate.net.

Indications de racines stockées dans le container System de la partition du domaine avec


Windows 2000

Le container CN=MicrosoftDNS,CN=System,DC=Corp2003,DC=Corporate,DC=net contient les


différents containers, chacun accueillant le contenu d’une zone donnée. Les enregistrements A des
serveurs racines existent ensuite sous la forme d’objets de type dnsNode au sein du container
RootDNSServers.

Page 141
j. Stockage des zones dans Active Directory et enregistrements dynamiques des
contrôleurs de domaines Windows 2000, Windows Server 2003 et Windows Server
2008

Par défaut, le service "Ouverture de session réseau" en anglais "Net Logon", enregistre les
enregistrements de ressources DNS du localisateur de contrôleur de domaine pour la partition de
répertoire d’application hébergée sur un contrôleur de domaine, de la même manière qu’il enregistre
les enregistrements de ressources d’un contrôleur de domaine pour le domaine hébergé sur un
contrôleur de domaine.

Dans la mesure où ces enregistrements de ressources sont critiques pour les réplications Active
Directory ainsi que pour la localisation des contrôleurs de domaines par les ordinateurs clients, le
service "Ouverture de session réseau" d’un contrôleur de domaine inscrit toutes les 24 heures, les
enregistrements DNS nécessaires. En cas d’absence ou d’incohérences de ces enregistrements, vous
pouvez aussi forcer la réinscription de ces enregistrements en redémarrant le service "Ouverture de
session réseau".

Cette opération peut être réalisée à l’aide des commandes suivantes :

 net stop "net logon"


 net start "net logon"

6. Sécurisation des mises à jour dynamiques

La protection des zones DNS est un point particulièrement important pour garantir l’intégrité des
enregistrements. Cette remarque vaut bien entendu pour tous les types d’enregistrements, sachant que
nous porterons une attention toute spécifique aux données DNS nécessaires pour garantir le bon
fonctionnement de l’annuaire Active Directory.

Les serveurs DNS fonctionnant sous Windows 2000, Windows Server 2003 et Windows Server 2008
vous permettent de déclarer indépendamment au niveau de chaque zone la manière dont la sécurité
des zones est gérée. De fait, ces paramètres auront forcément des implications au niveau de la sécurité
des zones DNS standard ou directement intégrées dans Active Directory.

a. Configurer les mises à jour dynamiques sécurisées

Par défaut, le paramètre Mises à jour dynamiques n’est pas configuré pour autoriser les mises à
jour dynamiques. Il s’agit du paramètre le plus sûr puisqu’il rend impossible la mise à jour des zones
DNS.

Données enregistrées dans Active Directory et mises à jour dynamiques sécurisées

Le problème est que ce choix vous empêchera de profiter des nombreux avantages apportés par les
mises à jour dynamiques. Parmi ces avantages, nous pouvons signaler la possibilité de disposer
d’enregistrements DNS à jour en toutes circonstances et une charge liée à l’administration des
enregistrements devenue presque nulle.

Page 142
Pour profiter de l’inscription automatique en toute sécurité, il convient de faire en sorte que les
ordinateurs mettent à jour les données DNS de manière sécurisée. Vous y parviendrez en stockant les
zones DNS dans l’annuaire Active Directory et en utilisant la fonctionnalité de mise à jour dynamique
sécurisée.

Ce choix permet aux seuls ordinateurs authentifiés et appartenant au même domaine Active Directory
que le serveur DNS, de réaliser des mises à jour dans la zone.

Il est aussi possible de gérer très spécifiquement la liste des contrôles d’accès sur les zones DNS
stockées dans Active Directory. Ces permissions vous permettent de contrôler quels utilisateurs et
groupes de l’Active Directory sont habilités à manipuler les zones DNS.

Groupes spéciaux et Permissions par défaut d’une zone sécurisée intégrée dans Active Directory

Par défaut, seules les entités authentifiées peuvent créer des enregistrements et les mettre à jour
après coup en cas de changement. Le tableau ci-dessous énumère les autorisations définies par
défaut pour les zones DNS sécurisées stockées dans l’annuaire Active Directory.

Droits sur les Zones Implémentation Windows

Autoriser : Lire, Écrire, Créer tous les objets enfants,


Administrateurs
Autorisations spéciales

Utilisateurs authentifiés Autoriser : Créer tous les objets enfants

Propriétaire créateur Autorisations spéciales

Autoriser : Écriture complète, Lire, Écrire, Créer tous les objets


DNSAdmins
enfants, Supprimer les objets enfants, Autorisations spéciales

Autoriser : Écriture complète, Lire, Écrire, Créer tous les objets


Admins du domaine
enfants, Supprimer les objets enfants, Autorisations spéciales

Page 143
Droits sur les Zones Implémentation Windows

Autoriser : Écriture complète, Lire, Écrire, Créer tous les objets


Administrateurs de l’entreprise
enfants, Supprimer les objets enfants, Autorisations spéciales

Autoriser : Écriture complète, Lire, Écrire, Créer tous les objets


ENTERPRISE DOMAIN CONTROLLERS
enfants, Supprimer les objets enfants, Autorisations spéciales

Tout le monde Autoriser : Lire, Autorisations spéciales

Accès compatible pré-Windows 2000 Autoriser : Autorisations spéciales

Autoriser : Écriture complète, Lire, Écrire, Créer tous les objets


SYSTEM
enfants, Supprimer les objets enfants, Autorisations spéciales

Certains groupes disposent de permissions spéciales directement héritées de l’objet serveur DNS lui-
même. Ces permissions sont nécessaires pour assurer le bon fonctionnement, dans les meilleures
conditions de sécurité de la zone. En résumé, les droits sur les zones sécurisées DNS peuvent être
classés de la manière suivante :

 Le groupe Tout le monde dispose uniquement d’un droit de lecture. Ce droit permet
d’obtenir uniquement un accès en lecture sur le contenu de la zone.
 Les groupes à caractère administratif permettent d’administrer les différentes fonctions
disponibles sur un objet de type zone DNS.
 Le groupe Utilisateurs authentifiés permet de réaliser les contrôles d’accès qui
permettront ou non la mise à jour dynamique des enregistrements de ressources DNS.

Ces listes de contrôles d’accès permettent de bénéficier d’un haut niveau de sécurité de base. De fait,
Microsoft recommande de manipuler ces permissions avec précaution.

7. Mises à jour sécurisées et enregistrements DNS réalisés via DHCP

Les serveurs DHCP exécutant Windows 2000, Windows Server 2003 ou Windows Server peuvent
participer aux mises à jour dynamiques dans l’espace de noms DNS pour chacun des clients prenant en
charge les opérations de mises à jour dynamiques.

De fait, les questions des contrôles d’accès aux zones DNS ainsi que la propriété des enregistrements
de ces zones se posent-elles.

Le fonctionnement du processus de mise à jour des zones DNS par le service serveur DHCP est décrit
ci-dessous. Le premier problème qui se pose est qu’il est bien sûr nécessaire que le serveur DHCP ait
connaissance du nom complet de l’ordinateur client DHCP. Donc, pour qu’il puisse réussir à inscrire et
mettre à jour les enregistrements de ressources pointeur (PTR) et d’hôte (A) pour le compte de ses
clients DHCP, il sera nécessaire de faire remonter cette information, des clients vers le serveur DHCP.

L’option de nom de domaine complet du client, appelée Option 81, permet au client de fournir au
serveur DHCP son nom de domaine complet (FQDN, Fully Qualified Domain Name). Optionnellement, le
client pourra spécifier au serveur DHCP la façon dont il souhaite que le serveur traite l’opération.

Ainsi, lorsque l’option 81 est émise par un client DHCP de type Windows 2000, Windows XP ou Windows
Vista, le serveur DHCP réagit et détermine l’opération qu’il faudra ou non réaliser en procédant tel que
cela est présenté ci-dessous :

 Le serveur DHCP met à jour les enregistrements A et PTR DNS si les clients en font la
demande à l’aide de l’option 81.

Paramètres DNS dynamique d’un client Windows 2000 ou Windows XP


Page 144
La figure ci-dessus montre que le poste de travail effectuera son enregistrement de ressource de type A
dans le DNS en utilisant son suffixe principal. Pour rappel, le suffixe principal est directement issu de
l’appartenance au domaine et peut aussi être complété par un suffixe DNS additionnel au niveau de
chaque connexion réseau :

 Le serveur DHCP met à jour les enregistrements A et PTR DNS, que le client en fasse la
demande ou non.

Dans ce cas, le serveur DHCP prendra l’initiative de procéder aux enregistrements pour le compte des
clients sachant que les opérations nécessaires seront fonction de la nature des clients DHCP.

Le premier cas de figure concerne le principe des mises à jour DHCP/DNS pour les clients DHCP
modernes fonctionnant sous Windows 2000, Windows XP ou Windows Vista. Dans ce cas, les opérations
ci-dessous sont réalisées :

 Le client envoie une requête DHCP (DHCPREQUEST) au serveur en y incluant l’option DHCP
81. Par défaut, le client demande à ce que le serveur DHCP inscrive l’enregistrement DNS de
type PTR, tandis que le client inscrit lui-même son propre enregistrement DNS de type A.
 Le serveur renvoie au client un accusé de réception DHCP (DHCPACK) en attribuant un bail
d’adresse IP et en incluant l’option DHCP 81. Les paramètres par défaut du serveur DHCP
(Mettre à jour les enregistrements PTR et A DNS uniquement si des clients DHCP le
demandent), utilisent l’option 81 indiquant au client que le serveur DHCP prendra en charge
l’opération concernant l’enregistrement DNS de type PTR et que le client inscrira
l’enregistrement DNS de type A.

Les opérations d’inscription réalisées par d’une part le client et, d’autre part, le serveur DHCP sont réalisées
de manière totalement asynchrone. Ainsi, le client inscrit son enregistrement de type A de manière séparée
du serveur DHCP qui prend en charge l’enregistrement de type PTR.

Le deuxième cas de figure concerne le principe des mises à jour DHCP/DNS pour les clients DHCP
anciens fonctionnant sous Windows NT 4.0 et les versions antérieures. Ces versions de clients
DHCP/DNS ne prennent pas directement en charge le processus de mise à jour dynamique DNS. De
fait, il n’est pas possible d’imaginer un quelconque niveau de communication entre les clients et le
serveur DNS. Pour ces clients, les opérations ci-dessous sont alors réalisées :

 Le client DHCP envoie une requête DHCP (DHCPREQUEST) au serveur. La demande n’inclut
pas l’option DHCP 81 puisque celle-ci n’est pas supportée sur ces clients anciens.
 Le serveur DHCP renvoie au client un accusé de réception DHCP (DHCPACK), en attribuant un
bail d’adresse IP, sans l’option DHCP 81.
 Le serveur DHCP envoie ensuite au serveur DNS les mises à jour de l’enregistrement de
ressource hôte de type A. Le serveur envoie également des mises à jour de l’enregistrement
de ressource de type pointeur (PTR).

Page 145
Valeurs par défaut de la configuration des mises à jour automatiques des enregistrements de type
A et PTR vers les zones DNS dynamiques pour une étendue DHCP

Les paramètres de la figure ci-dessus sont disponibles globalement sur l’objet serveur DHCP lui-même
et aussi, de manière indépendante, au niveau de chaque étendue DHCP. Le comportement des
enregistrements dynamiques est donc configurable très finement.

Maintenant que nous savons quels sont les opérations réalisées par les clients DNS et les serveurs
DHCP pour mettre à jour les enregistrements de ressources DNS, il nous faut considérer la
problématique de ces mises à jour faites par procuration via les serveurs DHCP Windows 2000,
Windows Server 2003 ou Windows Server 2008.

En fait, si un serveur DHCP réalise la première opération de mise à jour dynamique pour un
enregistrement de ressources donné, alors ce serveur DHCP devient le propriétaire de l’enregistrement.
De fait, il est le seul à pouvoir maintenir cet enregistrement.

Bien sûr, cela peut poser un problème dans un certain nombre de cas. Le cas le plus traditionnel
concerne la possibilité qu’aurait un serveur DHCP de secours de pouvoir maintenir les enregistrements
dans le cas d’une défaillance du serveur DHCP par défaut. Comme nous venons de le voir, si le premier
serveur DHCP est l’unique propriétaire des enregistrements, il est bien sûr le seul à pouvoir les
modifier.

Un autre effet de bord concerne la mise à niveau des clients anciens vers Windows 2000, Windows XP
ou Windows Vista. Nous savons que pour assurer une prise en charge des postes Windows NT, il sera
nécessaire que le serveur DHCP réalise la mise à jour en mode dynamique vers le serveur DNS. Par
conséquent, il sera aussi le seul à disposer des droits nécessaires sur les enregistrements et rendra
toutes mises à jour ultérieures impossibles, notamment après que les ordinateurs Windows NT aient été
mis à niveau vers Windows XP ou Windows Vista.

a. Utilisation du groupe spécial DNSUpdateProxy pour réaliser les mises à jour


dynamiques des zones DNS sécurisées

Pour qu’un ou plusieurs serveurs DHCP soient autorisés à mettre à jour des enregistrements DNS
contenus dans une zone sécurisée pour laquelle ils ne disposeraient pas des droits nécessaires, vous
pouvez ajouter au groupe DNSUpdateProxy les serveurs devant disposer de ces droits.

Page 146
Dans ce cas, le prochain objet qui inscrira le même enregistrement de noms dans la zone DNS
deviendra le nouveau propriétaire de l’enregistrement.

Attention au fait que les objets qui sont créés par les membres du groupe DnsUpdate Proxy ne sont pas
sécurisés par défaut. C’est ainsi que le premier utilisateur non membre du groupe DnsUpdateProxy qui
réalisera une opération de modification d’un de ces enregistrements, en deviendra le nouveau propriétaire.
C’est ainsi que lorsque des clients Windows NT ou Windows 9x sont mis à niveau vers une version ultérieure,
ils peuvent s’approprier leur propre enregistrement sur le serveur DNS. Le groupe DNSUpdateProxy permet
donc de résoudre les problèmes présentés plus haut.

b. Sécurisation des enregistrements lors de l’utilisation du groupe DnsUpdateProxy

Le fait que les enregistrements DNS créés par les membres du groupe DnsUpdateProxy ne soient pas
sécurisés expose potentiellement ces enregistrements à toutes sortes d’attaques. De plus, ce groupe
est difficilement utilisable de manière efficace lorsque les opérations d’enregistrement concernent des
zones intégrées à Active Directory, qui fonctionnent en mode "Mises à jour dynamiques sécurisées
uniquement".

En fait, il faudra obligatoirement ajouter les permissions adéquates pour autoriser les enregistrements
créés par les membres du groupe à être sécurisés.

Pour protéger les enregistrements non sécurisés ou autoriser les membres du groupe DnsUpdateProxy
à inscrire des enregistrements dans des zones qui n’autorisent que des mises à jour dynamiques
sécurisées, vous pouvez créer un compte d’utilisateur dédié et configurer les serveurs DHCP pour
qu’ils effectuent les mises à jour dynamiques DNS sur la base de cette identification.

En fonction des contraintes de sécurité imposées, vous pourrez aussi utiliser un ou plusieurs comptes
d’utilisateurs pour contrôler les accès vers un ou plusieurs serveurs DHCP.

Ce compte d’utilisateur spécifique est un compte d’utilisateur dont le seul objectif est de fournir aux
serveurs DHCP les informations d’authentification minimum pour réaliser avec succès des mises à jour
DNS en mode dynamique. Lorsque vous créez un compte réservé à cet usage et configurez des
serveurs DHCP avec le dit compte utilisateur, chaque serveur DHCP fournit ces informations lors de
l’enregistrement des noms pour le compte des clients DHCP. Une fois l’opération réalisée, le prochain
élément qui inscrira le même enregistrement de noms dans la zone DNS deviendra, comme expliqué
plus haut, propriétaire de l’enregistrement.

À propos de l’emplacement du compte d’identification DHCP : le compte d’utilisateur utilisé pour


l’authentification du serveur DHCP doit être créé dans la forêt où réside le serveur DNS principal de la zone à
mettre à jour. Ce compte peut aussi résider dans une autre forêt, à condition que celle-ci possède une
approbation de forêt établie avec la forêt contenant le serveur DNS principal de la zone à mettre à jour.
Notez qu’il ne peut s’agir d’un domaine approuvé situé dans une autre forêt, mais uniquement d’un domaine
dans une forêt approuvée. Ce dernier point nécessite que les deux forêts fonctionnent en mode "Forêt
Windows Server 2003" ou ultérieur.

c. Sécurisation des zones DNS et pouvoir du service serveur DHCP sur les contrôleurs
de domaine Active Directory

Lorsque le service Serveur DHCP est installé sur un contrôleur de domaine, le service serveur DHCP
possède et utilise l’autorité du contrôleur de domaine pour mettre à jour ou supprimer tout
enregistrement DNS inscrit dans une zone intégrée à Active Directory. Pour empêcher le serveur
DHCP de faire une utilisation incorrecte ou illégale des pouvoirs du contrôleur de domaine, vous
pouvez configurer le serveur DHCP pour qu’il s’authentifie de manière spécifique.

Page 147
Informations d’identification du serveur DHCP Windows Server 2003

Notez que cette option n’est disponible que sur les serveurs DHCP fonctionnant sous Windows Server
2003 ou Windows Server 2008 au niveau de l’objet serveur DHCP. Par conséquent, ce peut être une
bonne raison pour justifier la mise à niveau de serveurs DHCP Windows 2000 vers Windows Server
2003 ou Windows Server 2008 en attendant que toutes les machines Windows NT et Windows 9x
aient été mises à niveau vers Windows XP ou Windows Vista.

Cette problématique importante concerne tous les enregistrements y compris les enregistrements
inscrits de manière sécurisée par des ordinateurs contrôleurs de domaine fonctionnant sous Windows
2000, Windows Server 2003 ou Windows Server 2008. La possibilité qu’aurait un serveur DHCP de
manipuler ce qu’il ne devrait pas avoir le droit de manipuler est donc un sujet particulièrement
préoccupant qui pourra être solutionné de deux manières :

 La recommandation la plus évidente est d’éviter d’installer le service serveur DHCP sur un
contrôleur de domaine Windows 2000, Windows Server 2003 ou Windows Server 2008.

L’article Q255134 de la base de connaissances Microsoft Technet intitulé "Installing Dynamic Host
Configuration Protocol (DHCP) and Domain Name System (DNS) on a Domain Controller" fait état de cette
problématique.

 Dans le cas où il ne serait pas possible d’appliquer cette première recommandation, il sera
toujours possible d’implémenter l’authentification du serveur DHCP disponible avec les
serveurs Windows Server 2003 et les serveurs Windows Server 2008.

Page 148
Déclaration des informations d’identification sur le serveur DHCP Windows Server

Bien entendu, la solution idéale consiste à accélérer le processus de migration des anciens ordinateurs
vers Windows 2000, Windows XP ou Windows Vista. Cette dernière alternative est la meilleure
recommandation que nous puissions faire.

En effet, dans ce cas chaque ordinateur est authentifié à l’aide du protocole Kerberos v5 pour pouvoir
créer et maintenir par la suite son propre enregistrement. Les serveurs DHCP ne sont donc plus
impliqués pour le compte des clients.

d. Commande Netsh et déclaration de l’authentification du serveur DHCP

Vous pouvez configurer vos serveurs DHCP avec les informations du compte d’identification à utiliser à
l’aide de la console MMC de gestion du service DHCP. Dans le cas où vous souhaiteriez automatiser
cette opération, vous pouvez utiliser la commande de contexte Netsh. Cette commande peut être
manipuler en mode shell, comme spécifié ci-dessous :

1.
Pour entrer dans le shell réseau, tapez : netsh
2.
Pour entrer dans le contexte DHCP, tapez : dhcp
3.
Pour accéder à votre serveur local, tapez : server
4.
Pour déclarer les paramètres d’authentification du serveur DHCP, tapez la commande : set dnscredentials
NomUtilisateur NomDomaine MotDePasse

Dans le cas où il serait nécessaire de modifier cette déclaration sur de nombreux serveurs, vous
pouvez aussi l’utiliser en passant tous les paramètres nécessaires sur la même ligne de commande ou
via un fichier de script.

Déclaration à l’aide de netsh du compte DHCPAccess du domaine Corp2003 pour le serveur DHCP
en cours

Page 149
Le caractère * permet de déclarer le mot de passe lors de l’exécution de la commande. Dans le cas
d’un script qui contiendrait le mot de passe, veillez à ce que le script soit contenu dans un répertoire
crypté.

Pour plus d’informations sur la configuration des informations d’identification à l’aide de la console
DHCP, consultez le Kit de Ressources Techniques de Windows Server 2003.

8. Conflits de gestion des autorisations sur les zones DNS

Le service Serveur DNS qui s’exécute sur un contrôleur de domaine possédant des zones stockées dans
Active Directory stocke ses données de zone sur la base des objets fournis par l’annuaire lui-même,
c’est-à-dire des objets et attributs Active Directory.

Configurer la liste des autorisations d’accès sur les objets Active Directory de type DNS revient donc à
configurer la liste des autorisations sur les zones DNS en utilisant la console de gestion du DNS.

Dans la mesure où ces données spécifiques au DNS ne sont finalement que des données Active
Directory, il sera judicieux de faire en sorte que les administrateurs de la sécurité des objets Active
Directory et les administrateurs de la sécurité des objets de type DNS soient en contact, afin d’éviter
toute erreur de configuration ou de mise en place de paramètres de sécurité contradictoires.

Les objets et attributs Active Directory utilisés par les données des zones DNS stockées dans Active
Directory sont décrits ci-dessous :

 L’élément DnsZone est un objet de type conteneur créé lorsqu’une zone est stockée dans
Active Directory.
 L’élément DnsNode est un objet de type nœud utilisé pour mapper et associer un nom dans
la zone à des données de ressources.
 L’élément DnsRecord est un attribut à valeurs multiples d’un objet de type dnsNode. Il est
utilisé pour stocker les enregistrements de ressources associés à l’objet de nœud nommé.
 L’élément DnsProperty est un attribut à valeurs multiples d’un objet dnsZone utilisé pour
stocker les informations de configuration d’une zone.

Pour plus d’informations sur l’ensemble des classes et attributs d’objets de l’Active Directory, consultez
le site Microsoft MSDN à l’adresse http://msdn.microsoft.com et rechercher les informations qui
décrivent le contenu du schéma de l’annuaire Active Directory.

Intégration des serveurs DNS Windows avec l’existant


Par voie de conséquence, les familles de systèmes d’exploitation réseau Windows 2000, Windows Server
2003 et bien sûr Windows Server 2008 disposent d’un service serveur DNS totalement interopérable avec
les autres serveurs DNS de type BIND. Les serveurs DNS exécutant Windows Server 2003 sont donc
compatibles avec la plupart des spécifications RFC (Request for Comments) utilisées pour définir
l’implémentation et le bon fonctionnement des services DNS. Cela offre des avantages importants pour
l’exploitation des serveurs DNS dans les environnements mixtes ou hétérogènes.

1. À propos des RFC pris en charge par le service DNS de Windows


Server 2003 et Windows Server 2008

Les documents RFC (Request for Comments) sont une série de rapports, propositions de protocoles et
normes de protocoles, en cours d’évolution, utilisés par la communauté Internet. Les spécifications des
services DNS (Domain Name System) sont basées sur des RFC approuvées et publiées par l’IETF
(Internet Engineering Task Force) auxquels participent aussi d’autres groupes de travail.

Les RFC ci-dessous contiennent les spécifications utilisées pour concevoir et implémenter les services
Serveur et Client DNS dans un environnement Windows Server 2003 :

RFC Titre

1034 Domain Names Concepts and Facilities

Page 150
RFC Titre

1035 Domain Names Implementation and Specification

1123 Requirements for Internet Hosts Application and Support

1886 DNS Extensions to Support IP Version 6

1995 Incremental Zone Transfer in DNS

A Mechanism for Prompt Notification of Zone Changes (DNS


1996
NOTIFY)

Dynamic Updates in the Domain Name System (DNS


2136
UPDATE)

2181 Clarifications to the DNS specification

2308 Negative Caching of DNS Queries (DNS NCACHE)

2535 Domain Name System Security Extensions (DNSSEC)

2671 Extension Mechanisms for DNS (EDNS0)

2782 A DNS RR for specifying the location of services (DNS SRV)

2. À propos des RFC 1034 et 1035

Ces deux RFCs décrivent le protocole standard original DNS pour la prise en charge des services de
noms de domaine dans un environnement TCP/IP. Ces informations expliquent les protocoles de façon
détaillée, en mettant en évidence les idées et techniques sous-jacentes utilisées dans la majorité des
implémentations DNS. Vous pourrez aussi rechercher sur le Web les documents spécifiés ci-après. Ces
documents contiennent les spécifications utilisées pour concevoir et implémenter les services Serveur et
Client DNS :

Nom du fichier (en anglais) Titre

Draft-skwan-utf8-dns-02.txt Using the UTF-8 Character Set in the Domain Name System

Draft-ietf-dhc-dhcp-dns-08.txt Interaction between DHCP and DNS

Draft-ietf-dnsind-tsig-11.txt Secret Key Transaction Signatures for DNS (TSIG)

Draft-ietf-dnsind-tkey-00.txt Secret Key Establishment for DNS (TKEY RR)

Draft-skwan-gss-tsig-04.txt GSS Algorithm for TSIG (GSS-TSIG)

af-saa-0069.000.doc ATM Name System Specification version 1.0

3. Consultation des RFC sur le Web

Vous pouvez obtenir l’ensemble des RFC à partir du site Web RFC Editor (en anglais). Les RFC sont
ordonnées en fonction des critères ci-dessous : normes Internet approuvées, normes Internet
proposées (propositions soumises pour examen), méthodes conseillées pour Internet ou documents de
type FYI (For Your Information). Vous y trouverez aussi d’autres documents appelés documents

Page 151
d’assistance en ligne. Ces documents proposent de nouvelles spécifications qui n’en sont qu’au stade de
propositions. De fait, ces documents ne possèdent pas de numéro RFC. http://www.rfc-editor.org/

4. Interopérabilité des services DNS de Windows Server 2003 et 2008

Dans la mesure où l’Internet repose intégralement sur le système de nommage et de résolution des
noms DNS, et où aussi, l’annuaire Active Directory l’utilise de manière naturelle et sophistiquée, il est
clair qu’il ne peut y avoir, pour une entreprise donnée, aucune incompatibilité majeure entre l’espace
privé de domaines Active Directory et l’espace public Internet. Les principaux avantages d’une telle
interopérabilité sont les suivants :

 Interopérabilité complète vers les autres serveurs DNS qui respectent les RFC en matière de
service de nom DNS, et vice versa.
 Utilisation de serveurs DNS Windows 2000, Windows Server 2003 ou Windows Server 2008
sur Internet.

Pour éprouver l’interopérabilité des différents serveurs DNS entre eux, Microsoft a testé le service
Serveur et Client DNS de Windows Server 2003 (et Windows 2000) avec les implémentations suivantes
de BIND (Berkeley Internet Name Domain) :

 BIND 4.9.7 ;
 BIND 8.1.2 et BIND 8.2 ;
 BIND 9.1.0.

Les problèmes éventuels de comptabilité et/ou de configuration liés à l’utilisation du service DNS de
Windows Server 2003 dans des environnements particuliers, ou avec des serveurs DNS sur Internet,
sont présentés ci-après.

5. Problème de compatibilité et recherches directe et inversée WINS

Depuis NT 4.0, le service serveur DNS permet de transmettre les demandes de résolution non
satisfaites vers un serveur WINS. Cette opération de recherche supplémentaire, appelée "WINS
Forwarding" est prise en charge pour les zones de recherche directe et inversée, et peut être activée ou
non au niveau de chaque zone.

Il est important de noter que l’activation des recherches WINS sur une zone DNS créera un
enregistrement de ressource de type WINS dans le zone DNS. De fait, cette option ne devra pas être
utilisée si la zone doit être répliquée vers des serveurs dotés d’autres implémentations DNS ne
reconnaissant pas les enregistrements de ressources WINS.

6. Spécificité du DNS de Windows 2000 Server, Windows Server 2003 et


Windows Server 2008 et intégration dynamique aux serveurs DHCP

Dans DNS Windows Server 2003 et Windows Server 2008, le service DHCP offre une prise en charge
par défaut de l’enregistrement et de la mise à jour des informations pour les clients DHCP hérités dans
les zones DNS. Les clients hérités incluent généralement d’autres ordinateurs client Microsoft TCP/IP
antérieurs à Windows 2000. L’intégration entre DNS et DHCP fournie par Windows Server 2003 et
Windows Server 2008 permet au client DHCP incapable de mettre à jour dynamiquement des
enregistrements de ressources DNS, de disposer de ces informations mises à jour dans les zones de
recherche directe et inversée DNS via le serveur DHCP.

L’intégration dynamique au service DHCP n’est disponible que sur les serveurs DNS exécutant Windows 2000
Server, Windows Server 2003 et Windows Server 2008 et pas sur les serveurs DHCP NT 4.0 ou les versions
antérieures.

7. Autorisations des transferts de zones

Par défaut, les accès aux zones sont sécurisés. Ainsi, un serveur DNS Windows Server 2003 ou
Windows Server 2008 n’autorise les transferts de zones que vers les serveurs DNS spécifiés en tant que
serveurs de noms (enregistrements de type NS) au niveau de l’onglet Serveurs de noms. Les
transferts devront ensuite être autorisés via l’onglet Transferts de zone.
Page 152
Validation des acquis :
questions/réponses
1. Questions

Si l’état de vos connaissances sur ce chapitre vous semble suffisant, répondez aux questions ci-après.

1 Quelles sont les conditions requises pour que les données d’une zone DNS soient stockées dans Active
Directory ?

2 Où sont stockées les informations qui caractérisent une zone DNS intégrée à Active Directory ?

3 Où sont stockées les informations qui caractérisent une zone DNS non intégrée à Active Directory ?

4 Où sont stockées les zones intégrées à Active Directory lorsque l’étendue de réplication de la zone est
fixée sur "Vers tous les serveurs DNS de la forêt" ?

5 Où sont stockées les zones intégrées à Active Directory lorsque l’étendue de réplication de la zone est
fixée sur "Vers tous les serveurs DNS du domaine" ?

6 Dans quel cas est-il intéressant de créer sa propre partition de l’annuaire d’application pour stocker les
zones DNS ?

7 Quel est le rôle de la zone _msdcs.Domaine_Racine_dela_Forêt.com ?

8 Sous Windows 2000, la zone _msdcs.Domaine_Racine_dela_Forêt.com est à l’intérieur du domaine


Domaine_Racine_dela_Forêt.com. Sous Windows Server 2003 et Windows Server 2008, la zone
_msdcs.Domaine_Racine_dela_Forêt.com existe séparement. Pourquoi ?

9 Vous venez de réaliser la migration d’un contrôleur de domaine Windows 2000 Server vers Windows
Server 2003. Cependant, vous ne disposez pas des nouvelles partitions de l’annuaire d’applications
utilisables par le service serveur DNS. Que devez-vous faire ?

10 Quel est le nom du service Windows responsable de l’inscription automatique des services de KDC, GC et
serveur LDAP ?

11 Sur un serveur DNS fonctionnant sous Windows Server 2003 ou sous Windows Server 2008, vous
souhaitez créer une zone intégrée à Active Directory. Malheureusement, l’option vous permettant ce choix
n’est pas sélectionnable. Pourquoi ?

12 Comment les enregistrements de ressources DNS sont-ils protégés au sein des zones intégrées à Active
Directory ?

2. Résultats

Reférez-vous aux pages suivantes pour contrôler vos réponses. Pour chacune de vos bonnes réponses,
comptez un point.

Nombre de points /12

Pour ce chapitre, votre score minimum doit être de 9 sur 12.

3. Réponses

1 Quelles sont les conditions requises pour que les données d’une zone DNS soient stockées dans Active
Directory ?

Vous devez utiliser un serveur DNS fonctionnant sous Windows 2000 Server, sous Windows Server 2003 ou
sous Windows Server 2008. De plus, le serveur DNS en question doit impérativement être un contrôleur de
domaine.

2 Où sont stockées les informations qui caractérisent une zone DNS intégrée à Active Directory ?

Page 153
Les zones existent en tant qu’objets de l’annuaire. Une zone est un objet de la classe dnsZone et un
enregistrement DNS un objet de la classe dnsNode.

3 Où sont stockées les informations qui caractérisent une zone DNS non intégrée à Active Directory ?

Les informations de zone sont stockées dans un fichier de base de données de zone dans le répertoire
%Systemroot%\System32\dns.

4 Où sont stockées les zones intégrées à Active Directory lorsque l’étendue de réplication de la zone est
fixée sur "Vers tous les serveurs DNS de la forêt" ?

Le contenu des zones DNS intégrées à Active Directory au niveau de la forêt est stocké dans une partition de
l’annuaire d’application. Pour la forêt, il s’agit de la partition
DC=ForestDnsZones,DC=Domaine_Racine_dela_Forêt,DC=com

5 Où sont stockées les zones intégrées à Active Directory lorsque l’étendue de réplication de la zone est
fixée sur "Vers tous les serveurs DNS du domaine" ?

Le contenu des zones DNS intégrées à Active Directory au niveau d’un domaine donné est stocké dans une
partition de l’annuaire d’application. Pour le domaine, il s’agit de la partition
DC=DomainDnsZones,DC=votre_domaine,DC=com

6 Dans quel cas est-il intéressant de créer sa propre partition de l’annuaire d’application pour stocker les
zones DNS ?

Cette technique est intéressante si vous souhaitez sélectionner les contrôleurs qui seront impliqués dans la
réplication de telle ou telle zone intégrée à Active Directory et ce, quels que soient les domaines Active
Directory.

7 Quel est le rôle de la zone _msdcs.Domaine_Racine_dela_Forêt.com ?

Cette zone est vitale car elle permet la sélection des contrôleurs de domaine sur la base de leur rôle et des
sites Active Directory. Tous les contrôleurs de tous les domaines de la forêt y sont représentés grâce à un
enregistrement de CNAME correspondant au GUID du contrôleur.

8 Sous Windows 2000, la zone _msdcs.Domaine_Racine_dela_Forêt.com est à l’intérieur du domaine


Domaine_ Racine_dela_Forêt.com. Sous Windows Server 2003 et Windows Server 2008, la zone
_msdcs.Domaine_ Racine_dela_Forêt.com existe séparément. Pourquoi ?

Tous les enregistrements vitaux nécessaires au bon fonctionnement de la réplication de l’annuaire sont
stockés dans la zone _msdcs.Domaine_Racine_dela_Forêt.com. Le fait de répliquer cette zone
automatiquement sur tous les contrôleurs permet à tout contrôleur d’avoir accès à la zone DNS et ainsi de
toujours être capable de résoudre le domaine racine, c’est-à-dire tous les contrôleurs de tous les domaines
de la forêt.

9 Vous venez de réaliser la migration d’un contrôleur de domaine Windows 2000 Server vers Windows
Server 2003. Cependant, vous ne disposez pas des nouvelles partitions de l’annuaire d’applications
utilisables par le service serveur DNS. Que devez-vous faire ?

Il suffit de créer les deux partitions de l’annuaire d’applications dédiées à cet usage à l’aide de la commande
Dnscmd /CreateBuiltinDirectoryPartitions ou de l’option du menu dans la console MMC du DNS "Créer les
partitions de l’annuaire d’applications par défaut". Notez qu’il n’est pas possible de migrer « In place » de
Windows 2000 Server à Windows Server 2008.

10 Quel est le nom du service Windows responsable de l’inscription automatique des services de KDC, GC et
serveur LDAP ?

Le service responsable est le service Ouverture de session réseau (Let Login).

11 Sur un serveur DNS fonctionnant sous Windows Server 2003 ou sous Windows Server 2008, vous
souhaitez créer une zone intégrée à Active Directory. Malheureusement, l’option vous permettant ce choix
n’est pas sélectionnable. Pourquoi ?

Page 154
Que ce soit sous Windows 2000 Server ou Windows Server 2003, le serveur doit être un contrôleur de
domaine. Vous devez donc au préalable promouvoir le serveur au rôle de contrôleur en lançant la commande
Dcpromo.

12 Comment les enregistrements de ressources DNS sont-ils protégés au sein des zones intégrées à Active
Directory ?

La sécurisation des zones et des enregistrements de ressources utilise le protocole Kerberos. Les machines
doivent donc être membres du domaine Active Directory et fonctionner sous Windows 2000, Windows XP,
Windows Server 2003, Windows Vista et Windows Server 2008. Pour s’enregistrer, une machine s’authentifie
et crée son enregistrement. Ensuite, celui-ci sera maintenu par les contrôleurs de domaine. C’est pourquoi,
le groupe ENTERPRISE DOMAIN CONTROLLERS dispose de la permission Contrôle total.

Travaux pratiques
1. Création des partitions de l’annuaire d’applications DNS par défaut

Ce TP va vous permettre de créer des partitions de l’annuaire d’applications.

La création des partitions de l’annuaire d’applications DNS par défaut n’est nécessaire que dans le cas
où les partitions créées à l’origine par Dcpromo lors de l’installation de l’annuaire Active Directory
auraient été détruites. Ce pourra aussi être le cas lors de la migration des contrôleurs de domaine
Windows 2000 Server vers Windows Server 2003 ou vers Windows Server 2008.

Pour créer les partitions de l’annuaire d’applications DNS par défaut, procédez tel que cela est précisé
ci-dessous :

1.
Ouvrez la console de gestion du DNS.
2.
Dans l’arborescence de la console, cliquez avec le bouton droit sur le serveur DNS souhaité.
3.
Cliquez sur l’option Créer des partitions de l’annuaire d’applications par défaut.

Par défaut, seuls les membres du groupe Administrateurs de l’entreprise peuvent créer une partition de
l’annuaire d’applications DNS. Si les partitions de l’annuaire d’applications DNS par défaut sont déjà
disponibles dans l’Active Directory, l’option permettant de créer les partitions est grisée.

Pour réaliser la même opération à la ligne de commande, procédez comme suit :

 Ouvrez une invite de commandes puis tapez : dnscmd


NomServeur/CreateBuiltinDirectoryPartitions{/Domain|/Forest|/AllDomains}

Le paramètre /CreateBuiltinDirectoryPartitions est bien sûr obligatoire. Ensuite, le paramètre


/Domain ou /Forest ou /AllDomains vous permet de choisir quelle partition vous souhaiter créer.
Ces paramètres sont expliqués ci-dessous :

 Le paramètre /Domain vous permet de créer une partition de l’annuaire d’applications DNS
par défaut au niveau du domaine.
 Le paramètre /Forest vous permet de créer une partition de l’annuaire d’applications DNS
par défaut au niveau de la forêt, pour la forêt Active Directory sur laquelle se situe le serveur
DNS spécifié.
 Pour créer les deux partitions par défaut (au niveau du domaine et au niveau de la forêt),
tapez /AllDomains.

Pour afficher la syntaxe complète de cette commande, à l’invite de commandes, tapez dnscmd
/CreateDirectoryPartition /?

2. Stockage d’une zone vers tous les serveurs DNS de la forêt

Page 155
Ce TP va vous permettre de spécifier le stockage physique d’une zone DNS vers tous les serveurs DNS
du domaine Active Directory lorsqu’il s’agit de contrôleurs de domaine Windows Server 2003 ou
Windows Server 2008.

Pour modifier l’étendue de la réplication d’une zone DNS, procédez de la façon suivante :

1.
Ouvrez la console de gestion du DNS.
2.
Dans l’arborescence de la console, cliquez avec le bouton droit sur la zone appropriée, puis cliquez sur
Propriétés.
3.
Sous l’onglet Général, notez le type de réplication de zone actuel, puis cliquez sur Modifier.
4.
Pour faire en sorte que la zone en cours de modification soit désormais stockée vers tous les serveurs DNS
de la forêt, sélectionnez l’option Vers tous les serveurs DNS de la forêt Active Directory.
5.
Validez votre choix à l’aide du bouton OK.

Pour exécuter cette procédure, vous devez être membre du groupe Administrateurs ou du groupe Admins du
domaine dans Active Directory ou bien l’autorité nécessaire doit vous avoir été déléguée sur l’ordinateur
local.

Seules les zones de recherche directe (principales et de stub) intégrées à Active Directory peuvent modifier
leur étendue de réplication. Les zones secondaires de recherche directe ne peuvent pas modifier l’étendue
de leur réplication.

3. Stockage d’une zone vers tous les serveurs DNS du domaine Active
Directory

Ce TP va vous permettre de spécifier le stockage physique d’une zone DNS vers tous les serveurs DNS
du domaine Active Directory lorsqu’il s’agit de contrôleurs de domaine Windows Server 2003 ou
Windows Server 2008.

Pour modifier l’étendue de la réplication d’une zone DNS, procédez de la façon suivante :

1.
Ouvrez la console de gestion du DNS.
2.
Dans l’arborescence de la console, cliquez avec le bouton droit sur la zone appropriée, puis cliquez sur
Propriétés.
3.
Sous l’onglet Général, notez le type de réplication de zone actuel, puis cliquez sur Modifier.
4.
Pour faire en sorte que la zone en cours de modification soit désormais stockée vers tous les serveurs DNS
fonctionnant sur des contrôleurs de domaine Windows Server 2003 ou Windows Server 2008 du domaine
considéré, sélectionnez l’option Vers tous les serveurs DNS du domaine Active Directory.
5.
Validez votre choix à l’aide du bouton OK.

4. Stockage d’une zone vers tous les contrôleurs de domaine du domaine


Active Directory

Ce TP va vous permettre de spécifier le stockage physique d’une zone DNS vers tous les contrôleurs de
domaine du domaine Active Directory lorsqu’il s’agit de contrôleurs de domaine fonctionnant sous
Windows 2000 Server (ou aussi Windows Server 2003 ou Windows Server 2008).

Pour modifier l’étendue de la réplication d’une zone DNS, procédez de la façon suivante :

1.
Ouvrez la console de gestion du DNS.

Page 156
2.
Dans l’arborescence de la console, cliquez avec le bouton droit sur la zone appropriée, puis cliquez sur
Propriétés.
3.
Sous l’onglet Général, notez le type de réplication de zone actuel, puis cliquez sur Modifier.
4.
Pour faire en sorte que la zone en cours de modification soit désormais stockée vers tous les serveurs DNS
fonctionnant sur des contrôleurs de domaine Windows 2000 Server, Windows Server 2003 ou Windows
Server 2008 dans le domaine considéré, sélectionnez l’option Vers tous les contrôleurs de domaine du
domaine Active Directory.
5.
Validez votre choix à l’aide du bouton OK.

5. Stockage d’une zone dans une partition de répertoire d’application


spécifique

Ce TP va vous permettre de stocker une ou plusieurs zones DNS dans une partition spécifique de
l’annuaire d’applications Active Directory.

Création manuelle d’une partition de l’annuaire d’applications

La commande DNSCmd est disponible sous Windows Server 2008. Elle vous permet de créer une
partition de répertoire d’application DNS. Notez que la commande DNSCmd n’était pas incluse avec
Windows Server 2003. Elle faisait partie des Outils de support de Windows Server 2003. Pour réaliser
cette opération, procédez comme suit :

 Ouvrez l’invite de commandes.


 Tapez la commande : dnscmd NomServeur /CreateDirectoryPartition FQDN

Le paramètre NomServeur est obligatoire et spécifie le nom d’hôte DNS du serveur DNS. Vous pouvez
aussi taper l’adresse IP ou simplement un point (.)

Le paramètre /CreateDirectoryPartition vous permet de créer une partition, laquelle devra utiliser
un nom de domaine complet (FQDN).

Comme il s’agit de modifier la structure du DIT (Directory Information Tree), seuls les membres du groupe
Administrateurs de l’entreprise peuvent créer une partition de répertoire d’application DNS.

Inscription d’un serveur DNS supplémentaire dans une partition spécifique

Un fois l’étape précédente réalisée avec succès, vous pourrez procéder à l’enregistrement d’un serveur
DNS donné pour qu’il participe à la réplication de la dite partition.

Pour réaliser cette opération, procédez comme suit :

 Ouvrez l’invite de commandes puis tapez la commande ci-dessous : dnscmd NomServeur


/EnlistDirectoryPartition FQDN

Les paramètres NomServeur et /EnlistDirectoryPartition sont obligatoires. Il en est de même pour


le nom de domaine complet de la partition à spécifier.

Pour exécuter cette procédure, vous devez être membre du groupe Administrateurs ou du groupe Admins du
domaine dans Active Directory. Pour afficher la syntaxe complète de cette commande, à l’invite de
commandes, tapez : dnscmd /EnlistDirectoryPartition /?

Notez que cette opération n’est pas nécessaire pour le serveur qui a réalisé l’opération de création de
partition. Ce serveur est automatiquement enrôlé par défaut pour détenir la dite partition.

Stocker une zone DNS dans une partition spécifique de l’annuaire

Ce TP va vous permettre de spécifier l’emplacement de stockage d’une zone DNS vers une partition
spécifique de l’annuaire Active Directory.

Page 157
Un fois l’étape précédente réalisée avec succès, vous pourrez procéder à la modification ou la création
d’une zone afin de changer l’emplacement de stockage de cette-ci.

Pour cela, procédez comme suit :

1. Ouvrez la console de gestion du DNS.


2. Dans l’arborescence de la console, positionnez-vous sur la zone dont vous souhaitez changer
l’emplacement de stockage.
3. Cliquez avec le bouton droit sur la zone, puis cliquez sur Propriétés.
4. Sur l’onglet Général, modifiez le type de la zone, assurez-vous qu’il s’agit bien d’une zone principale et
que l’option Enregistrer la zone dans Active Directory est bien activée.
5. Sur l’onglet Général, modifiez la réplication de la zone et sélectionnez la partition précédemment créée
en la sélectionnant à l’aide de l’option Vers tous les contrôleurs de domaine spécifiés dans l’étendue
de la partition de l’annuaire d’applications.
6. Validez à l’aide du bouton OK.

6. Autorisations des mises à jour dynamiques sécurisées

À l’issue de la conversion d’une zone standard en une zone intégrée à l’annuaire Active Directory, vous
avez la possibilité d’activer la mise à jour dynamique sécurisée puis de modifier après coup les
permissions sur la zone concernée.

1. Ouvrez la console de gestion du DNS.


2. Dans l’arborescence de la console, positionnez-vous sur la zone concernée et sélectionnez le choix Mises
à jour dynamiques : Sécurisées uniquement.
3. Validez à l’aide de la touche OK.
4. Cliquez avec le bouton droit sur la zone concernée puis cliquez sur Propriétés.
5. Sur l’onglet Sécurité, modifiez la liste des contrôles d’accès en fonction de vos propres contraintes de
sécurité. Pour que tous les ordinateurs aient la possibilité d’inscrire dans la zone des enregistrements
dynamiques de manière sécurisée, assurez-vous que la permission Utilisateurs authentifiés/Créer des
objets enfants est bien présente. Vous devriez aussi vous assurer que les groupes Admins du domaine et
ENTERPRISE DOMAIN CONTROLLERS et SYSTEM disposent bien de la permission Contrôle total. Le groupe
Tout le monde devrait disposer de la permission Lire.

7. Activation des fonctions de vieillissement et de nettoyage sur le


serveur DNS

La procédure ci-dessous va vous permettre de définir les propriétés de vieillissement/nettoyage pour


votre serveur DNS.

1. Ouvrez la console de gestion du DNS.


2. Dans l’arborescence de la console, cliquez avec le bouton droit sur le serveur DNS souhaité, puis cliquez
sur Définir le vieillissement/nettoyage pour toutes les zones.
3. Activez la case à cocher Nettoyer les enregistrements de ressources périmées.

Une fois que vous avez appliqué des modifications aux paramètres de vieillissement/nettoyage du serveur,
la console DNS vous invite à les confirmer. Vous pouvez alors appliquer ces modifications uniquement aux
nouvelles zones intégrées à Active Directory.

Page 158
Localisation des services Active Directory et services
DNS

Pré-requis et objectifs
1. Pré-requis

Concepts fondamentaux du protocole TCP/IP (adressage, réseaux et sous-réseaux).

Concepts fondamentaux des services de résolution et de noms DNS.

Concepts fondamentaux des services d’annuaires Microsoft Active Directory.

2. Objectifs
À la fin de ce chapitre vous serez en mesure de :

Comprendre l’importance du service DNS nécessaire au bon fonctionnement de l’Active Directory.

Décrire les éléments et les grands principes de localisation des services Active Directory tels que :

 Le rôle du service de localisation DNS.


 Les enregistrements de ressources enregistrés par les contrôleurs de domaine Active
Directory.
 Le processus de localisation des contrôleurs de domaine par les postes de travail clients.
 L’importance des paramètres de configuration DNS des postes de travail clients.
 La surveillance du rôle "Serveur DNS" à l’aide du Gestionnaire de serveur de Windows Server
2008.

Contrôler et corriger les enregistrements de ressources des contrôleurs de domaine.

Gérer la transition des anciens contrôleurs Windows NT vers les nouveaux contrôleurs de domaine Active
Directory.

Page 159
Introduction
Les éléments principaux impliqués dans une infrastructure de services distribués et de services de
sécurité Active Directory nécessitent une configuration des services DNS appropriée. Ainsi, avec une
configuration réalisée dans les règles de l’art, les ordinateurs fonctionnant sous Windows 2000, Windows
XP, Windows Vista ou une version ultérieure seront capables d’interroger le système de résolution DNS
pour localiser les ordinateurs jouant le rôle de contrôleur de domaine au sein de l’infrastructure de
services de domaine Active Directory. Cet état de fait signifie aussi que, à l’inverse, l’annuaire Active
Directory ne pourra fonctionner normalement ni offrir ses services d’une manière convenable, s’il ne
dispose pas d’une configuration DNS adaptée !

Les méthodes changent fondamentalement ! En effet, dans les environnements de domaines Windows NT,
lesquels sont basés sur l’interface de programmation et les noms NetBIOS, le domaine enregistre son nom
sur le code de service NetBIOS [1C]. Cet enregistrement de groupe est utilisé par les clients Windows 9x,
Windows ME et Windows NT pour localiser les contrôleurs de domaine Windows NT. Cette entrée peut
contenir vingt cinq contrôleurs de domaines NT via leurs adresses IP respectives et concerne aussi les
contrôleurs de domaine Active Directory puisque ces contrôleurs sont compatibles NT vis-à-vis de ces
anciens systèmes d’exploitation. Par conséquent, l’enregistrement de groupe [1C] pourra contenir des
contrôleurs de domaine fonctionnant tant sous Windows NT que sous Windows 2000 Server, Windows Server
2003 ou Windows Server 2008. Notez que vous pouvez visualiser cet enregistrement NetBIOS sur un
serveur fonctionnant sous Windows Server 2003 à l’aide de la commande nbtstat -n.

Service de Localisation DNS et sélection des contrôleurs de


domaine
Le processus d’ouverture de session intégré aux ordinateurs Windows 2000, Windows XP ou Windows
Vista est utilisé pour localiser le contrôleur de domaine le plus proche de l’ordinateur.
Ce service système appelé Ouverture de session réseau, en anglais "Net Logon" fonctionne à l’identique
sur les ordinateurs Windows 9x et Windows NT équipés du Client Active Directory. Notez que dans le cas
où des ordinateurs Windows 9x ou Windows NT ne disposeraient pas du logiciel "Client Active Directory"
alors, ils n’utiliseront pas les mécanismes de localisation basés sur le DNS, mais l’ancien système de
sélection basé sur l’interface NetBIOS, le code de service [1C] et le service de résolution WINS - Windows
Internet Naming System.
NetBIOS et les enregistrements de domaine [1C] et [1D] : vous ne devez pas confondre l’enregistrement
de nom de domaine NetBIOS [1C] avec l’enregistrement de nom de domaine [1D]. En effet, le code [1D]
est destiné au bon fonctionnement des fonctions d’exploration réseau. Il est enregistré pour les
explorateurs principaux. Pour rappel, il existe un explorateur principal, Master Browser, par sous-réseau
TCP/IP. Les explorateurs de sauvegarde, Backup Browsers, utilisent ce nom pour communiquer avec
l’explorateur principal en rapatriant la liste des serveurs disponibles de cet explorateur principal. De plus,
notez que les serveurs WINS sont conçus pour renvoyer une réponse d’enregistrement positive pour le
nom nom_domaine[1D] et ce, bien que le serveur WINS n’enregistre pas ce nom dans sa base de
données. Cela a pour effet de forcer une demande de type diffusion de la part du client. En effet, comme
le nom D n’est pas enregistré dans la base WINS, si le nom_domaine[1D] est demandé au serveur WINS,
ce dernier renvoie une réponse négative. De fait, cette réponse négative forcera le client à envoyer un
message de diffusion sur le sous-réseau local.

À propos du service Explorateur d’ordinateurs sur les serveurs Windows Server 2008 : L’enregistrement
NetBIOS est un enregistrement utilisé par les postes clients pour accéder au Master Browser, sachant qu’il
n’existe qu’un seul Master Browser par sous-réseau IP donné. L’enregistrement NetBIOS <1E> est un
enregistrement de type Normal Group que les explorateurs d’ordinateurs peuvent résoudre via diffusion ou
sur lequel ils peuvent être à l’écoute pour participer aux élections de machine Master Browser. Sur les
serveurs Windows Server 2008, le service Explorateur d’ordinateurs est désactivé. Ce service n’est pas
nécessaire dans la mesure où Windows Server 2008 peut utiliser une autre méthode de découverte - non
NetBIOS, beaucoup plus moderne appelée WSD - Web Service Discovery protocol. Le fait que le service
Explorateur d’ordinateurs soit désactivé ne nécessite pas la déclaration des enregistrements NetBIOS et
<1E>.

À propos des méthodes de découverte : Windows Vista et Windows Server 2008 disposent d’une pile réseau
totalement réécrite. Celle-ci intègre de nombreuses améliorations dans le domaine de la découverte réseau
et de la détection des emplacements réseau. La découverte réseau a ainsi été améliorée dans Windows Vista

Page 160
et Windows Server 2008 via l’ajout des protocoles LLTD (Link Layer Topology Discovery), FD (Function
Discovery) et WSD (Web Services for Devices).
Il n’est pas nécessaire de déclarer un contrôleur de domaine préféré pour qu’un ordinateur Windows 2000
ou Windows XP Professionnel soit capable de "bien" choisir un contrôleur de domaine. Si vous disposez
d’un réseau étendu et que vous souhaitez que les ordinateurs clients sélectionnent un contrôleur de
domaine proche d’eux, alors vous devrez structurer votre infrastructure physique Active Directory sur la
base de plusieurs zones géographiques, lesquelles sont appelées "sites Active Directory".
La notion de site Active Directory permet aux clients Active Directory de localiser l’emplacement des
services recherchés et aux contrôleurs de domaine de mieux répliquer les informations les concernant.
Généralement, les sites sont mis en place lorsque cela s’avère nécessaire, c’est-à-dire principalement
lorsque plusieurs zones géographiques sont reliées par des liens de communications réseau lents.

Notez que si vous souhaitez, malgré une connexion rapide, disposer d’une bonne sélection des contrôleurs
de domaine, vous devrez créer des sites Active Directory.
Au même titre qu’un contrôleur de domaine Windows NT enregistre son rôle à l’aide de codes de services
NetBIOS, les contrôleurs de domaine Windows 2000 Server, Windows Server 2003 et Windows Server
2008 enregistrent aussi leurs enregistrements de services de type SRV sur la base de l’infrastructure
physique Active Directory et de leur site d’appartenance respectif.
Les services DNS, disponibles sur les contrôleurs de domaine, jouent un rôle important en retournant aux
clients les références qui leur permettront de sélectionner un contrôleur de domaine local qui sera utilisé
à des fins d’authentifications Kerberos et de recherches LDAP. Chaque site Active Directory étant associé
à un ou plusieurs réseaux ou sous-réseaux IP, les contrôleurs de domaine peuvent facilement utiliser
l’adresse IP source des ordinateurs clients pour déterminer le meilleur site qu’ils devraient utiliser pour
diriger leurs recherches DNS. Le scénario ci-dessous prend pour exemple le cas d’un ordinateur portable
qui serait utilisé sur un site différent de son site habituel :
1.
Le client obtient une configuration TCP/IP valide à partir d’un serveur DHCP. À cet instant, l’ordinateur client
utilise son ancien site d’appartenance et, de fait, envoie des requêtes DNS pour rechercher un contrôleur de
domaine sur l’ancien site.

Le fait que l’ordinateur utilise le protocole DHCP pour obtenir sa configuration IP n’est pas une condition
nécessaire. Simplement, le protocole DHCP est aujourd’hui utilisé dans plus de 80% des cas et sera bien sûr,
particulièrement intéressant dans le cas des ordinateurs portables.
2.
Le serveur DNS répond avec les enregistrements de ressources de type SRV. L’ordinateur client utilise alors
ces réponses pour diriger une série de "ping LDP" vers les contrôleurs de son ancien site d’appartenance.
3.
Le premier contrôleur de domaine situé sur l’ancien site d’appartenance du client compare l’adresse IP
source du client à la sienne et constate que le client se trouve sur un site Active Directory différent. Cette
opération est très facile à réaliser pour le contrôleur sollicité puisque tous les sites gérés sont connus, tous
les réseaux et sous-réseaux IP sont déclarés et respectivement associés au site Active Directory adéquat.
4.
Le contrôleur informe alors le client qu’il ne se trouve plus sur l’ancien site, et lui transmet une référence qui
lui permet de savoir que, désormais, il se trouve sur un autre site.
5.
Le client dirige alors ses requêtes DNS sur des enregistrements de type SRV pour rechercher un contrôleur
de domaine appartenant à son nouveau site connu.
6.
Un contrôleur de domaine du nouveau site d’appartenance est sélectionné et répond au client. À partir de ce
moment, le client ajuste ses informations de localisation et considère le nouveau site comme son site
d’appartenance.
Lorsque l’utilisateur retournera sur son site d’origine ou pourquoi pas sur un autre site, ce processus se
déroulera à nouveau pour remettre à jour les informations de localisation de l’ordinateur client.

Les clients Active Directory Windows 2000, Windows XP Professionnel, les systèmes d’exploitation de la
famille Windows Server 2003 et Windows Server 2008 cachent leurs informations de site dans le registre à
la clé suivante : HKLM \ System \ CurrentControlSet \ Services \ Netlogon \ Parameters — Valeur :
DynamicSiteName — Donnée : Déclarez le nom court du contrôleur de domaine, par exemple, booster-
paris, ayant authentifié le client sur le site.

Page 161
La méthode de recherche de contrôleurs de domaine par les ordinateurs clients part du principe que
chaque site géographique est connu ainsi que ses réseaux IP associés. Ensuite, le site est censé accueillir
un ou plusieurs contrôleurs de domaine.
Usage des enregistrements SRV et processus de sélection lié à la recherche des serveurs
d’annuaires LDAP
Lorsqu’un utilisateur initie une action qui nécessite une recherche Active Directory, le client Active
Directory envoie une requête DNS portant sur un enregistrement de type SRV correspondant aux
serveurs actifs sur le port LDAP TCP 389. La première requête est toujours dirigée sur le site Active
Directory local du client dans la mesure où le client a réussi à déterminer son site d’appartenance avec la
méthode précédemment expliquée. Ce principe a bien sûr pour principal avantage, d’éviter les trafics au
travers du réseau étendu. Par contre, s’il n’y a aucun contrôleur de domaine disponible sur le site du
client, alors le client initiera une requête de résolution sur tous les enregistrements SRV indépendamment
du site d’appartenance.
Couverture des sites Active Directory ne disposant plus ou pas de contrôleur de domaine Active
Directory
Le site ne contenant pas de contrôleur où disposant d’un contrôleur non répondant sera automatiquement
secouru par l’infrastructure Active Directory via le KCC - Knowledge Consistency Checker, et l’ISTG - Inter
Site Topology Generator. En fait, le premier contrôleur de domaine installé sur un site joue le rôle d’ISTG
et prend à sa charge la création des objets connexions vers les autres sites. L’ISTG est lui aussi surveillé
de part son rôle important dans la construction de la topologie de réplication et donc des communications
inter-sites.
Toutes les 30 minutes, l’ISTG prouvera son existence en mettant à jour l’attribut
InterSiteTopologyGenerator de l’objet "NTDS Settings". Cet attribut et sa valeur seront ensuite
répliqués et les contrôleurs pourront vérifier toutes les 60 minutes la présence correcte de l’ISTG de
chacun des sites. Cette opération consistera à aider le site orphelin en mettant à jour les zones DNS du
site avec les enregistrements de ressources de contrôleurs du site le plus "proche".
De cette manière, les contrôleurs du site A peuvent prendre en charge les demandes d’authentification du
site B lorsque le site B ne dispose pas d’au moins un contrôleur de domaine opérationnel.

Ce comportement est expliqué plus loin en détails.


Compatibilité entre les ordinateurs Clients et les domaines Windows 2000, Windows Server 2003
et Windows Server 2008
Les domaines Active Directory utilisant des contrôleurs de domaine Windows Server 2003 ou Windows
2000 Server sont compatibles à 100% avec tous les types de clients Windows. Cette compatibilité est
aussi présente avec les systèmes utilisant la version 3.0 (ou supérieure) de Samba.

Samba est un ensemble de services et d’utilitaires qui permet à des ordinateurs fonctionnant sous Linux,
Unix, Apple ou d’autres systèmes de se connecter et de partager des ressources de types fichiers et
imprimantes. Les versions récentes de Samba peuvent aussi jouer le rôle de contrôleur de domaine principal
NT4 mais sont plutôt intégrées au sein d’un domaine en tant que serveur membre. De multiples
configurations permettent de supporter les services suivants : les utilisateurs Windows peuvent disposer de
fichiers partagés par des ordinateurs fonctionnant sur un système non Windows tel que Linux, en toute
transparence. L’inverse peut aussi être réalisé et les utilisateurs Windows peuvent accéder aux imprimantes
partagées par des ordinateurs fonctionnant sur un système non Windows tel que Linux, en toute
transparence. L’inverse peut aussi être réalisé.

La dernière version de Samba publiée en janvier 2008 et datant de décembre 2007 est le build 3.0.28. Une
nouvelle version majeure est en chantier mais n’est pas encore finalisée. En septembre 2007, une version
Alpha de Samba 4 a été publiée sur le site http://us1.samba.org/ samba/. Les nouveautés de cette nouvelle
version sont ici brièvement présentées : l’implémentation des protocoles nécessaires à Active Directory
(Kerberos et DNS), la suppression de nmbd maintenant intégrée à smbd, l’introduction d’une base de
données type LDAP pour le stockage des données permanentes, l’intégration du centre de distribution de
clés Kerberos (KDC) pour supporter les connexions Active Directory, la gestion basique des Objets stratégies
de groupe, la prise en charge de la console MMC Utilisateurs et ordinateurs Active Directory et
l’implémentation de Winbind (authentification Unix dans Active Directory).

Samba Team Receives Microsoft Protocol Docs : Le 20 Décembre 2007, l’organisme PFIF (Protocol Freedom
Information Foundation), un organisme sans but lucratif créé par le Software Freedom Law Center, a signé

Page 162
un accord avec Microsoft Corp. afin de recevoir la documentation technique des protocoles nécessaires à une
pleine interopérabilité entre les serveurs Microsoft Windows Server et des logiciels libres tels que Samba.
Cette news est stratégique pour assurer dans le futur une parfaite interopérabilité entre les systèmes
Windows et les systèmes non-Windows. Elle est consultable sur le site Samba à l’adresse ci-dessous :
http://samba.org/samba/PFIF/

Les droits d’accès sont spécifiés en fonction de l’appartenance aux groupes hébergés sur la machine Linux et
vice versa.
La compatibilité inverse est aussi vraie. Ainsi, les ordinateurs Windows Server 2003 ou Windows XP
Professionnel peuvent fonctionner dans tous les schémas d’infrastructure que nous connaissons depuis de
nombreuses années. Par exemple, ces systèmes peuvent fonctionner dans des domaines Windows NT,
Windows 2000 ou Windows 2003 et aussi des groupes de travail.

Seules les versions Microsoft Windows XP Edition Familiale, Windows XP MediaCenter Edition ou les éditions
Familiales de Windows Vista, ne peuvent être membre d’un quelconque domaine.

Structure DNS et intégration dans l’annuaire Active Directory


La localisation des services Active Directory par les clients intelligents est dépendante de la disponibilité
de la zone. C’est pour cette raison que Windows Server 2003 et Windows Server 2008 dispose de moyens
plus sophistiqués pour assurer une grande disponibilité de tous les types de zones et, en particulier, de la
zone DNS correspondant à la racine de la forêt Active Directory.
Nous savons que l’annuaire Active Directory peut intégrer les zones et enregistrements de ressources
(RR) en tant qu’objets de l’annuaire (objets dnsZone et dnsNode). En effet, les informations DNS devant
être protégées ne peuvent se contenter d’un simple stockage de type fichier texte. Ce point est
particulièrement important concernant la protection des zones DNS dynamiques et, de fait, il est
fortement recommandé de parvenir à une intégration des zones au sein de l’annuaire Active Directory.
Les zones DNS stockées dans l’annuaire Active Directory sont répliquées vers des contrôleurs de
domaines Active Directory en fonction de différentes étendues. Les serveurs DNS fonctionnant sous
Windows 2000 Server répliquent leurs zones en utilisant la réplication Active directory au sein du même
domaine. Cela signifie que la zone est créée dans le contexte de nommage (NC, Naming Context) du
domaine, dans le container System du domaine courant.
L’utilisation de Windows Server 2003 ou Windows Server 2008 permet d’utiliser les partitions de
l’annuaire d’applications et ainsi, de pouvoir stocker toute zone DNS vers des étendues de réplication
différentes. Ces différentes étendues de réplications sont présentées ci-après :

Étendues de réplication d’une zone avec Windows Server 2003


Vers tous les serveurs DNS de la forêt Active Directory : cette option permet de stocker la zone
DNS dans une partition de l’annuaire d’applications. La zone sera répliquée vers tous les serveurs DNS

Page 163
fonctionnant sur des contrôleurs de domaine fonctionnant sous Windows Server 2003 ou Windows Server
2008 dans toute la forêt.

Cette partition de l’annuaire d’applications est créée lors de l’installation du service serveur DNS sur le
premier contrôleur de domaine Windows Server 2003 de la forêt.
Vers tous les serveurs DNS du domaine Active Directory : cette option permet de stocker les zones
DNS vers les serveurs DNS fonctionnant sur des contrôleurs de domaine Windows Server 2003 ou
Windows Server 2008 dans tout le domaine.

Dans le cas du domaine racine de la forêt, cette partition de l’annuaire d’applications est créée lors de
l’installation du service serveur DNS sur le premier contrôleur de domaine Windows Server 2003 ou Windows
Server 2008 de la forêt. Ensuite, pour chaque nouveau domaine créé dans la forêt, une nouvelle partition de
l’annuaire d’applications est créée lors de l’installation du service serveur DNS sur un contrôleur de domaine
fonctionnant sous Windows Server 2003 ou Windows Server 2008.
Vers tous les contrôleurs de domaines du domaine Active Directory : cette option permet de
stocker les zones DNS dans la partition du domaine, pour chaque domaine de la forêt. Dans ce cas, les
zones DNS sont répliquées vers tous les contrôleurs de domaine du domaine.

Notez que c’est la seule option de stockage possible lorsque vous disposez de contrôleurs de domaine
fonctionnant sous Windows 2000 Server.
Vers tous les contrôleurs de domaine spécifiés dans l’étendue de la partition de l’annuaire
d’applications suivante : cette option permet de stocker les zones DNS dans une partition de l’annuaire
d’applications créée au préalable. Les zones DNS qui seraient stockées dans une partition de l’annuaire
d’applications sont répliquées vers tous les serveurs DNS fonctionnant sur des contrôleurs de domaine
concernés par cette partition.
Nous avons vu précédemment que les enregistrements de ressources utilisés par le service de localisation
principal pour un domaine Active Directory donné sont stockés dans le sous-domaine
_msdcs.NomdeDomaineDns. Avec Windows Server 2003, lorsque le domaine racine de la forêt est
créé, une zone DNS est automatiquement mise en œuvre pour le domaine _msdcs. NomdeForêt dans la
partition de l’annuaire d’applications dédiée aux zones DNS de type forêt. Ces partitions disposent d’un
stockage devant porter sur toute l’étendue de la forêt et sont répliquées vers tous les contrôleurs de
domaine Windows Server 2003 ou Windows Server 2008 de la forêt exécutant le service DNS de Windows
Server.

Les zones DNS stockées dans les partitions de l’annuaire d’applications ne peuvent pas être accédées par
des contrôleurs Windows 2000 Server. Ce point est logique car les contrôleurs Windows 2000 Server ne
reconnaissent que les partitions de schéma, de configuration et de domaine(s). Les partitions de l’annuaire
d’applications n’étant reconnues que par Windows Server 2003 et Windows Server 2008, un contrôleur
Windows 2000 Server ne peut accepter de répliquer ce contexte de nommage.

Enregistrements DNS "Emplacement du service" des


contrôleurs de domaine
Les clients Active Directory utilisent exclusivement le système de résolution DNS pour localiser les
contrôleurs de domaine Active Directory. Cette opération fondamentale est initiée par le client via des
demandes de résolution d’enregistrements de ressource de type SRV (Service Locator Resource Record)
définis dans le cadre du RFC 2782, successeur du RFC 2052.
Ces enregistrements sont utilisés pour localiser l’emplacement des services correspondant aux
ordinateurs, ports et protocoles recherchés par le client. Parmi les services localisés, il est clair que nous
allons retrouver les services d’annuaire LDAP, les services d’authentification Kerberos et les services de
catalogage offerts par les contrôleurs de domaine de type catalogues globaux. L’idée est que les
contrôleurs de domaine organisent les enregistrements de ressources de type SRV de manière structurée
de telle sorte que les clients Active Directory puissent localiser le contrôleur fournissant le services
recherché à l’intérieur d’un domaine ou sur un Site Active Directory donné.

1. Structure d’accueil de la zone DNS pour les enregistrements de


ressources de type SRV
Page 164
La structure DNS utilisée pour héberger les enregistrements nécessaires au service de localisation des
contrôleurs de domaine est basée sur une hiérarchie de dossiers (on devrait plutôt appeler cela des
sous-domaines).

La figure ci-dessus illustre la structure des quatre sous-domaines techniques DNS en rapport avec
un domaine Active Directory
Ces différents sous-domaines regroupent les enregistrements en fonction de la nature des recherches à
réaliser, tel que présenté ci-dessous :
_MSDCS : ce sous-domaine contient un ensemble d’enregistrements de type SRV. Ces enregistrements
sont fonction du statut des contrôleurs de domaine, du type de sollicitations et aussi des rôles de
catalogue global et contrôleur de domaine primaire. Les contrôleurs de domaine et catalogues globaux
sont ensuite répartis par sites. De cette manière, les clients Active Directory sont capables de localiser
quasi instantanément les services "proches" d’eux.
_SITES : ce sous-domaine contient le ou les sites Active Directory déclarés dans l’infrastructure
physique sur la base des sous-réseaux IP associés. Le fait de recenser les contrôleurs de domaine en
fonction de leur appartenance aux sites permet aux clients Active Directory de facilement localiser les
contrôleurs de domaine en fonction des services qu’ils assurent et de leur emplacement. Cette méthode
permet d’éviter de multiples recherches LDAP au travers de liaisons lentes. Notez que les contrôleurs
disposés sur les sites utilisent pour les requêtes standard LDAP, le port TCP 389, tandis que les
machines de type catalogues globaux utilisent le port TCP 3268.
_TCP : ce sous-domaine contient tous les contrôleurs de domaine de la zone DNS. Le fait de regrouper
tous les contrôleurs de domaine par protocole sera utile aux clients qui ne parviendraient pas à localiser
un contrôleur disponible sur leur site local. Dans ce cas, les clients Active Directory sélectionneront un
contrôleur de domaine à un quelconque emplacement du réseau.
_UDP : ce sous-domaine recense les services Kerberos v5 disponibles en mode non connecté via le
protocole de transport UDP. Ces opérations sont réalisées de la même manière qu’avec le transport TCP.
Ainsi, les opérations de demandes de tickets utilisent le port UDP 88 tandis que les opérations de
changement de mots de passe utilisent le port UDP 464.

a. À propos de l’enregistrement de ressources DNS de type SRV

L’enregistrement de ressources de type SRV (Service Locator Resource Record) est défini tel que décrit
dans le RFC 2782 et contient les informations particulières affichées sur la figure ci-dessous :

Page 165
Enregistrement de SRV pour spécifier que le serveur booster2003.corp2003.corporate.net joue le
rôle de serveur Kerberos (V5) sur le port TCP 88
Les différents paramètres d’un enregistrement de ressources de type SRV sont présentés dans le
tableau suivant.

Composants de l’enregistrement SRV Exemples de valeurs Commentaires

_gc
Identifie le service à localiser au sein de
Service _kerberos
l’espace de nom DNS.
_ldap

_tcp Déclaration du protocole de transport à


Protocole
_udp utiliser.

Représente le nom du domaine DNS


Nom Corporate.net
contenant l’enregistrement.

Représente la durée de vie de


TTL 10 minutes l’enregistrement en secondes (600
secondes.)

Déclare le type d’enregistrement en tant


Classe IN qu’enregistrement standard de type DNS
Internet.

Déclare le type d’enregistrement en tant


Enregistrement de ressource SRV qu’enregistrement de ressource de type
localisation de services "SRV".

Priorité 0 Identifie la priorité de l’enregistrement.


Lorsque plusieurs enregistrements

Page 166
Composants de l’enregistrement SRV Exemples de valeurs Commentaires
existent pour le même service, le client
sélectionne l’enregistrement possédant la
valeur de priorité la plus faible.

Permet la gestion des fonctions de


répartition de charge. S’il existe pour le
même service plusieurs enregistrements
Poids 100
de SRV de même priorité, les clients
sélectionnent le ou les enregistrements de
poids forts.

3268 pour _gc


Identifie le numéro de port sur lequel le
Port 88 pour _kerberos
service demandé est disponible.
389 pour _ldap

Booster2003. Représente le nom complet de la


Cible machine fournissant le service identifié
Corporate.net par l’enregistrement.

Utilisation des caractères "underscore"


Vous remarquerez que le format des enregistrements de ressources SRV fait largement appel au
caractère underscore (_). En effet, le RFC 2782 fait état de l’utilisation du caractère (_) pour résoudre
le problème d’une éventuelle collision avec un nom identique.

En 1996 RFC 2052, en 2000 du RFC 2782 : les premières implémentations du service DNS pour localiser les
services Active Directory ont été réalisées dès les premiers builds Beta de NT 5.0, courant 1997. Microsoft
s’appuya sur les premières recommandations publiées dans le RFC 2052 datant de 1996. C’est bien plus
tard, en février 2000, date de la sortie officielle de Windows 2000, que ce RFC passera du statut de "Draft"
au statut de "Proposed Standard". Il fera l’objet d’un nouvel enregistrement de la part de l’IETF, via le
numéro 2782, et remplacera le RFC 2052. Mr Levon ESIBOV, Program Manager chez Microsoft Corp,
participera à ce RFC fondamental pour la recherche et la localisation des services Active Directory.

Pour en savoir plus sur le contenu de ces RFC, consultez le site http://www.rfc-editor.org. Sur Internet, de
multiples sites contiennent les RFC, mais peu d’entre eux sont à jour ! Ce site est un site officiel de l’Internet
Society. Il a pour objet de maintenir l’ensemble des documents RFC pour l’ensemble de la communauté
Internet.
Les enregistrements de ressources enregistrés par les contrôleurs de domaine sont décrits plus loin.
Avant de rentrer dans les détails de ces enregistrements, rappelez-vous que ces enregistrements SRV
et A sont vitaux ! La commande DNSLint pourra être d’une aide précieuse pour les vérifier.
Notez aussi qu’un contrôleur de domaine enregistre au minimum quinze enregistrements de ressources
et vingt lorsqu’il joue le rôle de Catalogue Global.
En cas de nécessité, consultez le fichier %SystemRoot%\system32\config\Netlogon.dns. Ce
fichier est maintenu par chaque contrôleur de domaine et sera automatiquement mis à jour afin de
refléter la structure physique de la forêt.

Microsoft recommande que les serveurs DNS faisant autorité sur les zones techniques nécessaires au bon
fonctionnement de l’annuaire Active Directory fonctionnent sur des serveurs Windows Server 2003 ou
Windows Server 2008. De cette manière, les zones seront maintenues dynamiquement par Active Directory
avec le maximum de sécurité et en supprimant totalement les éventuelles erreurs d’administration.

b. Enregistrements SRV inscrits par le service "Ouverture de session réseau"

Pour répondre à la problématique de la localisation d’un service au sein d’une infrastructure Active
Directory, de multiples enregistrements de type SRV sont nécessaires.
Les enregistrements DNS de type SRV correspondant aux différents services Active Directory et leur
cadre d’utilisation sont listés ci-après :
_ldap._tcp.NomdeDomaine.
Page 167
Permet à un client de localiser un serveur LDAP dans le domaine nommé NomdeDomaine. Notez que
le serveur n’est pas forcément un contrôleur de domaine. En fait, le point important est qu’il supporte
les API LDAP. Tous les contrôleurs de domaines enregistrent cet enregistrement.

_ldap._tcp.NomdeSite.
_sites.NomdeDomaine.

Permet à un client de localiser un serveur LDAP dans le domaine nommé NomdeDomaine et dans le
site nommé NomdeSite. NomdeSite correspond au RDN (Relative Distinguished Name) de l’objet site
stocké dans la configuration Active Directory. Tous les contrôleurs de domaines enregistrent cet
enregistrement.

_ldap._tcp.dc._msdcs.NomdeDomaine.

Permet à un client de localiser un contrôleur de domaine (dc) du domaine nommé NomdeDomaine.


Tous les contrôleurs de domaines enregistrent cet enregistrement.

_ldap._tcp.NomdeSite.
_sites.dc._msdcs.NomdeDomaine.

Permet à un client de localiser un contrôleur de domaine dans le domaine nommé NomdeDomaine et


dans le site nommé NomdeSite. Tous les contrôleurs de domaines enregistrent cet enregistrement.

_ldap._tcp.pdc._msdcs.NomdeDomaine.

Permet à un client de localiser le serveur PDC Emulator dans le domaine nommé Nomdedomaine
fonctionnant en mode mixte. Seul le PDCE FSMO (Flexible Single Master Operations) enregistre cet
enregistrement.

_ldap._tcp.gc._msdcs.NomdeForêt.

Permet à un client de localiser un catalogue global (gc) pour la forêt. Seuls les contrôleurs de
domaines agissant en tant que GC enregistrent cet enregistrement.

_ldap._tcp.NomdeSite.
_sites.gc._msdcs.NomdeForêt.

Permet à un client de localiser un catalogue global (gc) au sein de la forêt. Seuls les contrôleurs de
domaines agissant en tant que GC enregistrent cet enregistrement.

_gc._tcp.NomdeForêt.

Permet à un client de localiser un catalogue global (gc) dans le domaine racine de la forêt. Ce serveur
n’est pas forcément un contrôleur de domaine. Il suffit que le protocole LDAP soit opérationnel et que
le serveur soit opérationnel en tant que GC. D’autres implémentations de services d’annuaires peuvent
aussi enregistrer des serveurs d’annuaires en tant que GC.

_gc._tcp.NomdeSite.
_sites.NomdeForêt.

Permet à un client de localiser un catalogue global (gc) pour la forêt dans le site nommé NomdeSite.
Le serveur n’est pas obligatoirement un contrôleur de domaine. Seuls les serveurs agissant en tant que
serveurs LDAP et GC enregistrent cet enregistrement.

_ldap._tcp.DomainGuid.
domains._msdcs.NomdeForêt.

Permet à un client de localiser un contrôleur de domaine dans un domaine à l’aide du GUID (Globally
Unique IDentifier) de ce dernier. Le GUID est une valeur sur 128 bits générée automatiquement au
Page 168
moment de création du domaine et utilisée rarement. En fait, cette information n’est utilisée que
lorsque le nom de domaine aurait changé mais que le domaine racine reste connu. Tous les contrôleurs
de domaine enregistrent cet enregistrement.

_kerberos._tcp.NomdeDomaine.

Permet à un client de localiser un KDC Kerberos dans le domaine nommé par NomdeDomaine. Le
serveur n’est pas obligatoirement un contrôleur de domaine. Tous les serveurs fonctionnant sous
Windows Server (2000, 2003 ou 2008) jouant le rôle de KDC Kerberos respectant le RFC 1510
enregistrent cet enregistrement de ressource.

_kerberos._udp.NomdeDomaine.

Cet enregistrement permet le même traitement que _kerberos._tcp.NomdeDomaine, mais sur la


base du protocole de transport UDP.

_kerberos._tcp.NomdeSite.
_sites.NomdeDomaine.

Permet à un client de localiser un KDC Kerberos pour le domaine nommé NomdeDomaine au sein du
site nommé NomdeSite. Le serveur n’est pas obligatoirement un contrôleur de domaine. Tous les
serveurs fonctionnant sous Windows Server (2000, 2003 ou 2008) jouant le rôle de KDC Kerberos
respectant le RFC 1510 enregistrent cet enregistrement de ressource.

_kerberos._tcp.dc._msdcs.NomdeDomaine.

Permet à un client de localiser un contrôleur de domaine accueillant l’implémentation Windows Server


2003 du service KDC Kerberos dans le domaine nommé NomdeDomaine. Tous les contrôleurs de
domaine Windows Server (2000, 2003 ou 2008) exécutant le service KDC enregistrent cet
enregistrement de ressource SRV. Ces serveurs implémentent une extension de type "clés publiques"
au protocole Kerberos v5 nommée sous-protocole "Authentication Service Exchange" (subprotocol) et
enregistrent cet enregistrement de SRV.

_kerberos.tcp.NomdeSite.
_sites.dc._msdcs.NomdeDomaine.

Permet à un client de localiser un contrôleur de domaine accueillant l’implémentation Windows Server


(2000, 2003 ou 2008) du service KDC Kerberos dans le domaine nommé NomdeDomaine et dans le
site nommé NomdeSite. Tous les contrôleurs de domaine Windows Server (2000, 2003 ou 2008)
exécutant le service KDC enregistrent cet enregistrement de ressource SRV. Ces serveurs
implémentent une extension de type "clés publiques" au protocole Kerberos v5 nommée sous-
protocole "Authentication Service Exchange" (subprotocol) et enregistrent cet enregistrement de SRV.

_kpasswd._tcp.NomdeDomaine.

Permet à un client de localiser un serveur de changement de mot de passe Kerberos pour le domaine
spécifié. Tous les contrôleurs de domaine Windows enregistrent cet enregistrement. Ce serveur doit
supporter le protocole de changement de mot de passe Kerberos. Ce serveur n’est pas forcément un
contrôleur de domaine. Tous les contrôleurs de domaine Windows Server (2000, 2003 ou 2008)
exécutant le service KDC Kerberos respectant le RFC 1510 enregistrent cet enregistrement de
ressource.

_kpasswd._udp.NomdeDomaine.

Cet enregistrement permet le même traitement que _kpasswd._tcp.NomdeDomaine, mais sur la


base du protocole de transport UDP.

DsaGuid._msdcs.NomdeForêt

Le service d’accès réseau (Net Logon) enregistre aussi un alias (CNAME) utilisé pour la réplication
Active Directory. Le système de localisation de contrôleurs n’utilise pas directement cet enregistrement

Page 169
vital pour l’infrastructure. Tous les contrôleurs de domaine de tous les domaines de la forêt
s’enregistrent directement dans le domaine racine de la forêt dans _msdcs.NomdeForêt.

c. À propos de l’enregistrement DsaGuid._msdcs.NomdeForêt

L’enregistrement de ressource DsaGuid._msdcs.NomdeForêt permet la localisation de n’importe


quel contrôleur de domaine membre de la forêt. Il correspond à la valeur du GUID du contrôleur de
domaine qui est finalement la valeur de l’objet DSA (Directory System Agent).
Il est utilisé dans le cadre de la réplication des contrôleurs de domaine sur la base de la configuration
de la topologie de réplication. Microsoft précise que cet enregistrement est aussi utilisé pour les
opérations de renommage des ordinateurs contrôleurs de domaine dans un domaine fonctionnant dans
le niveau fonctionnel (mode) Windows Server 2003 ou Windows Server 2008.
La valeur de DSAGuid est égale à la valeur de l’attribut objectDSA du container NTDS Settings de
l’objet serveur correspondant au contrôleur de domaine.

d. Enregistrements de ressources pour les clients non compatibles avec les


enregistrements SRV

Le service "Net Logon - Service Ouverture de session réseau" enregistre des enregistrements de type
A pour les clients LDAP ne supportant pas les enregistrements de SRV conformes au RFC 2782. Par
conséquent, ces enregistrements ne concernent pas la méthode de sélection présentée précédemment.
L’enregistrement A correspondant au NomdeDomaine permet à un client non compatible avec les
enregistrements SRV de localiser un contrôleur de domaine dans le domaine sur la base de cet
enregistrement.
L’enregistrement A correspondant à gc._msdcs.NomdeForêt permet à un client non compatible avec
les enregistrements SRV de localiser un contrôleur de domaine catalogue global dans la forêt.

2. Serveurs DNS non dynamiques et enregistrements dynamiques des


contrôleurs de domaines

Habituellement, les zones DNS utilisées dans le cadre de l’annuaire Active Directory sont prises en
charge par des serveurs DNS fonctionnant sous Windows 2000 Server, Windows Server 2003 ou
Windows Server 2008 à l’aide de zones DNS fonctionnant en mode dynamique sécurisé.
Cependant, s’il s’avérait nécessaire d’utiliser des serveurs DNS non Windows et que dans ce cas, vous
choisissiez d’utiliser des zones DNS non dynamiques, alors vous pourrez interdire l’enregistrement de
tout ou partie des enregistrements de type SRV enregistrés par les contrôleurs de domaine.
Cette configuration est directement réalisable à l’aide d’une stratégie de groupe à l’emplacement
spécifié ci-dessous :
Configuration de l’ordinateur/Modèles d’administration/Système/Ouverture de session réseau
/Enregistrements DNS du localisateur de contrôleurs de domaine/Enregistrements DNS du localisateur
de contrôleurs de domaine non inscrit par les contrôleurs de domaine.
Pour activer ce paramètre, sélectionnez l’option puis spécifiez une liste de mnémoniques (instructions)
délimités par des espaces pour les enregistrements DNS du localisateur de contrôleurs de domaine qui
ne seront pas enregistrés par les contrôleurs de domaine auquel ce paramètre est appliqué.
La liste des mots clés que vous pouvez utiliser est spécifiée ci-après sous le format mot clé / Type
d’enregistrement / nom

Page 170
Par défaut, ce paramètre est désactivé. De fait, les contrôleurs de domaine, configurés pour effectuer
une inscription dynamique des enregistrements DNS du localisateur de contrôleurs de domaine,
enregistrent tous les enregistrements de ressource DNS du localisateur de contrôleur de domaine vers
une zone DNS dynamique.

3. À propos de la zone DNS du domaine racine de la forêt

Dans une forêt composée de plusieurs domaines, il est important de porter une attention toute
particulière au domaine racine de la forêt. Pour illustrer ce besoin, les points ci-dessous pourront vous
servir de guide :

 Parmi les erreurs à éviter, ne confondez pas le domaine racine de la forêt avec le domaine
racine d’un arbre de la forêt. Rappelez-vous que le domaine racine de la forêt est toujours le
premier domaine créé.
 Le domaine racine de la forêt "rattache" les autres domaines DNS vers le domaine racine. Bien
entendu, seul le premier domaine d’une forêt pourra jouer ce rôle. Dans le cas où un domaine
supplémentaire existerait au sein de la forêt, les machines jouant le role de Catalogue Global
continueront d’enregistrer leurs enregistrements de ressources SRV dans la zone
_msdcs.root.dns.

Tous les enregistrements nécessaires à la localisation des contrôleurs de domaine jouant le rôle de
Catalogue Global sont enregistrés dans le domaine racine de la forêt. Ce point est très logique car s’il est
vrai qu’un contrôleur de domaine d’un domaine donné offre ces services à ce domaine, il est encore plus vrai
que la fonction d’un Catalogue Global consiste à offrir ses services à l’ensemble de la forêt.

Contraintes et problèmes potentiels


La nécessité de disposer de services DNS correctement configurés est telle que nous pouvons d’ores et
déjà, faire apparaître deux types de contraintes et problèmes potentiels :

 Le premier type de contraintes concerne l’annuaire Active Directory, les contrôleurs de domaines
et autres composants ou applications concernés par l’usage de l’annuaire, tel que spécifié ci-
dessous. Si les services DNS ne permettent pas d’aider à la résolution des recherches
nécessaires aux contrôleurs de domaine, un dysfonctionnement grave, voire total, des
réplications Active Directory entre contrôleurs de domaine, pourra avoir lieu. Dans le même
ordre d’idées, nous pouvons citer par exemple des applications d’entreprises telles que Microsoft
Exchange ou Microsoft Systems Management Server 2003. Comme ces applications disposent
d’un niveau important d’intégration à l’annuaire Active Directory, elles pourront, elles aussi, se
retrouver plus ou moins paralysées en cas de défaillance des serveurs DNS.

Page 171
 Le deuxième type de contraintes DNS concerne les postes de travail et serveurs membres du
domaine. Dans le cas des ordinateurs "clients Active Directory" d’un domaine Active Directory,
les éventuelles défaillances des services DNS pourront être moins dramatiques. En effet,
l’absence de services DNS aura pour principal effet d’augmenter le temps de recherche d’un
contrôleur fonctionnant sous Windows Server (2000, 2003 ou 2008) pour finalement choisir un
ancien contrôleur de domaine Windows NT 4.0, dans le cas où il en existerait encore au sein du
domaine.

Notez que seuls les ordinateurs Windows 2000, Windows XP Professionnel, Windows Vista ou les postes
Windows 9x disposant du client Active Directory utilisent le système de résolution DNS pour localiser les
contrôleurs de domaine d’un domaine Active Directory.
Dans le cas où une situation de repli vers un contrôleur Windows NT se produirait, alors les "anciens
mécanismes de types résolutions WINS/interface NetBIOS et authentifications NTLM" seraient utilisés au
détriment de ceux offerts par l’annuaire Active Directory.

Infrastructure Windows Active Directory et défaillances DNS : le système DNS est aujourd’hui le système de
résolution et de localisation préféré tant de l’infrastructure Windows elle-même que des applications qui y
demeurent. Par conséquent, soyez sensibilisé au fait qu’une défaillance ou erreur de configuration au niveau
des services DNS pourra avoir des effets sur l’infrastructure Windows toute entière et, aussi, sur les
applications qui y seraient hébergées.

Contrôle rapide des enregistrements de ressources


La détection d’un problème de localisation d’un ou de plusieurs contrôleurs de domaine sera
généralement assez rapide. En effet, l’indisponibilité d’un contrôleur de domaine sur un site donné est
souvent synonyme de ralentissements des connexions au réseau, voire de l’indisponibilité d’une
application importante.
Par conséquent, si l’incident génère rapidement un problème, il est indispensable que vous puissiez réagir
encore plus rapidement pour solutionner le dit problème.

1. Tests des enregistrements DNS

Pour tester la configuration de vos enregistrements, vous pouvez utiliser les outils ci-dessous :
NSLookup : vous pourrez, par exemple, tester le bon enregistrement des enregistrements de
Catalogues Globaux. La première commande set type=SRV vous permet de demander en retour les
détails relatifs à un enregistrement de ressource de type SRV RR.

C:\Documents and Settings\Administrateur.CORP2003>nslookup


Serveur par défaut : booster2003.corp2003.corporate.net
Address: 192.168.0.222
> set type=SRV
> _gc._tcp.corp2003.corporate.net
Serveur : booster2003.corp2003.corporate.net
Address: 192.168.0.222
_gc._tcp.corp2003.corporate.net SRV service location:
priority = 0
weight = 100
port = 3268
svr hostname = booster2003.corp2003.corporate.net
booster2003.corp2003.corporate.net internet address = 192.168.0.222
>

DCDiag : vous pourrez utiliser la commande DCDiag (Domain Controller Diagnostics) pour contrôler les
enregistrements DNS des partenaires de réplication.

Page 172
NetDiag : vous pourrez utiliser la commande NetDiag pour vérifier les enregistrements DNS relatifs à
un contrôleur de domaine spécifique. Pour cela, vous pourrez utiliser la commande suivante sur le
contrôleur de domaine à tester : Netdiag /test:DNS /v
NLTests : vous pourrez utiliser la commande NLTest (Net Logon Test) pour tester l’ensemble des
fonctions prises en charge par le service "Ouverture de session réseau/Net Logon". Cette commande est
très complète car elle intègre la vérification des canaux sécurisés (Secure Channel), la sélection des
contrôleurs, des serveurs de temps, des sites Active Directory et la vérification et la réinitialisation des
relations d’approbation inter-domaines. Vous pourrez l’utiliser aussi pour tester les enregistrements DNS
à l’aide de la commande NLTest /DSQUERYDNS.

La commande NLTest est une commande des Outils de Support de Windows Server 2003. Comme cela a
déjà été précisé, veillez à ce que tout serveur Windows 2000 Server ou Windows Server 2003 dispose des
Outils de Support. Notez que sur les serveurs Windows Server 2008, cette commande est disponible par
défaut.

Notez que cette commande teste les zones impliquées dans le fonctionnement de l’Active Directory mais ne
teste pas les zones relatives aux partitions de l’annuaire d’applications.
Réenregistrements des enregistrements de type SRV des contrôleurs de domaine
Vous pourrez utiliser les commandes suivantes pour forcer la réinscription des enregistrements DNS
nécessaires au bon fonctionnement des ordinateurs contrôleurs de domaine.
IPConfig : utilisez la commande IPConfig/registerdns. Notez que cette commande ne prend pas en
charge les partitions de l’annuaire d’applications.
NetDiag : utilisez la commande NetDiag /fix.
Service "Ouverture de session réseau" : redémarrez le service "Ouverture de session réseau" sur le
contrôleur de domaine dont les enregistrements DNS doivent être réinscrits.
NLTest : utilisez la commande NLTest /dsregdns pour forcer le réenregistrement de tous les
enregistrements de ressources nécessaires au contrôleur de domaine.
Cette commande fonctionne aussi au travers du réseau. Ainsi pour forcer la réinscription des
enregistrements d’un serveur distant vous pourrez entrer la commande
NLTest/server:nom_du_serveur /DSREGDNS.

Notez que la commande NL Test, très complète, permet aussi de redémarrer un serveur à distance et aussi
d’annuler une procédure d’arrêt distant en cours de traitement. Pour cela vous pourrez utiliser les
commandes suivantes : NLTest /server :nom_du_serveur /SHUTDOWN:<Raison>
[<nb_de_secondes>] et
Désenregistrement des enregistrements de type SRV des contrôleurs de domaine
Il se peut que vous souhaitiez supprimer les enregistrements de ressource de type SRV relatifs à un
ancien contrôleur de domaine. Cette opération est louable puisqu’elle aura pour effet d’éviter
d’infructueuses tentatives de connexion sur un contrôleur de domaine inexistant.
Pour réaliser cette opération, vous pouvez utiliser encore une fois la commande NLTest à l’aide des
paramètres spécifiés ci-dessous : NLTest /DSDEREGDNS:FQDN_du_serveur
Vous pourrez aussi spécifier le ou les types d’enregistrements Active Directory à supprimer en spécifiant
les paramètres /DOM:, /DOMGUID:, /DSAGUID:.
/DOM : le paramètre /DOM:nom_du_domaine_DNS spécifie le nom DNS du domaine à utiliser pour
rechercher l’enregistrement. Si ce paramètre n’est pas spécifié, le suffixe utilisé avec le paramètre
/DSDEREGDNS est utilisé.
/DOMGUID : ce paramètre permet de supprimer les enregistrements DNS basés sur des GUID.
/DSAGUID : ce paramètre permet de supprimer les enregistrements DNS de type DSA basés sur des
GUID.
Nettoyage des caches du système de résolution DNS
Les différents outils que nous venons de voir vous permettront d’identifier très rapidement et de
résoudre les problèmes relatifs aux enregistrements de ressources nécessaires aux contrôleurs de
domaine d’une forêt Active Directory.

Page 173
Notez cependant que ces outils respectent les mécanismes de résolutions et méthodes configurées.
Cela signifie que vous devrez vous assurer que :

 Le cache du ou des serveurs DNS impliqués ne contient plus d’anciens enregistrements


inadéquats. Pour cela, vous devrez par exemple utiliser la commande DNSCmd
nom_du_serveur /clearcache.
 Le cache de la partie cliente DNS (c’est-à-dire le module DNR - Domain Name Resolver) ne
contient pas d’enregistrements mis en cache négativement. Pour cela vous devrez, par
exemple, utiliser la commande IPConfig /flushdns.
 Les zones DNS à mettre à jour autorisent la mise à jour dynamique des enregistrements.

Gestion du problème de la transition des contrôleurs de


domaines NT vers Active Directory
La période de transition d’un domaine Windows NT vers l’annuaire Active Directory est une phase qui peut
varier dans le temps en fonction de l’environnement technique et des contraintes de temps et de budget.
Généralement, les migrations se déroulent rapidement. Cependant, dans certains cas, la période de
transition peut laisser apparaître quelques problèmes comme celui évoqué ci-après.
Lorsque des ordinateurs fonctionnant sous Windows 2000 ou une version ultérieure s’authentifient dans
un domaine Windows NT, alors ils utilisent les authentifications Windows NT de type NTLM Challenge
Response (v1 ou v2) puisque, bien entendu, il n’est pas possible d’utiliser l’authentification Kerberos v5
disponible grâce aux contrôleurs de domaine Active Directory.
Cela signifie évidemment que ces postes de travail peuvent se connecter au réseau en sollicitant les
contrôleurs de domaine secondaire fonctionnant sous Windows NT 4.0.
Cependant quand un domaine fait l’objet d’une mise à niveau vers l’annuaire Active Directory, un client
Kerberos tel que Windows 2000, Windows XP ou Windows Vista désactive automatiquement
l’authentification NTLM pour ne plus être capable que de réaliser des authentifications Kerberos. D’un
point de vue de la qualité du niveau de sécurité offert, il est clair que ce point est positif !
Néanmoins, que se passerait-il si le domaine Windows NT contenait plusieurs centaines ou milliers
d’ordinateurs fonctionnant sous Windows 2000 juste après la migration du PDC NT vers Windows Server
2003 ou Windows 2000 Server ?
La réponse est claire : tous ces ordinateurs ne dépendront exclusivement que d’un seul et unique
contrôleur de domaine Active Directory ! De plus, même en cas d’absence du ou des contrôleurs de
domaine Active Directory, ces ordinateurs ne sélectionneront pas de contrôleurs Windows NT. À la place,
ils utiliseront les informations de compte mises en cache.

Vous pouvez configurer la valeur du nombre d’informations de mise en cache en modifiant ce paramètre de
sécurité dans la stratégie de sécurité concernée. Il pourra s’agir d’une stratégie locale ou bien d’une
stratégie de groupe dans Active Directory. Une fois ouverte, développez l’arborescence de la console comme
suit : allez dans Configuration de l’ordinateur\Paramètres Windows\Paramètres de
sécurité\Stratégies locales\Options de sécurité\ et modifiez la valeur du paramètre Informations de
mise en cache. Par défaut, la valeur est égale à 10. La valeur 0 désactive la mise en cache de l’ouverture de
session, sachant que le nombre maximum d’informations d’ouvertures de session mises en cache ne peut
excéder cinquante mises en cache.
Outre d’éventuels problèmes de contrôles d’accès vers des ressources du réseau, des problèmes de
performances pourront alors apparaître si le ou les contrôleurs Active Directory ne sont joignables que par
des connexions lentes.
Forçage des contrôleurs Active Directory en pseudo contrôleurs NT
Le contournement de ce problème est supporté à partir de Windows 2000 SP2 et intégré de base dans
Windows Server 2003 et Windows Server 2008. Le concept est présenté ci-dessous.
Pour pouvoir résoudre le problème, il faut leurrer les ordinateurs "intelligents" fonctionnant sous Windows
2000 ou une version ultérieure en leur faisant croire que le contrôleur Windows NT 4.0 migré vers
Windows Server (2000, 2003 ou 2008) est en fait un contrôleur NT4 !
Une fois qu’un nombre suffisant de contrôleurs NT 4.0 auront été mis à niveau vers Windows Server 2003
ou Windows 2000 Server pour pouvoir prendre en charge les demandes d’ouverture de sessions, vous
pourrez retirer le paramètre. Les "ordinateurs intelligents" fonctionnant sous Windows 2000 ou Windows

Page 174
XP Professionnel choisiront alors le meilleur contrôleur Active Directory et utiliseront les authentifications
Kerberos.
L’idée est donc qu’un contrôleur Active Directory récemment mis à niveau se comporte comme un simple
contrôleur NT, du moins en terme d’authentification ! Vous pourrez contrôler la mise en place de ce
comportement exceptionnel à l’aide de la clé de registre ci-dessous :
HKLM \ System \ CurrentControlSet \ Services \ Netlogon \ Parameters, Nom de la clé :
NT4Emulator et Valeur de type REG_DWORD égale à 1

Il est primordial que cette clé soit renseignée sur le ou les contrôleurs de domaine NT avant que vous ne
procédiez à la mise à niveau des ordinateurs vers Windows Server (2000, 2003, 2008). Le fait de déclarer
cette clé avant la mise à niveau forcera les contrôleurs de domaine concernés à répondre à l’aide du
protocole NTLM au lieu du protocole Kerberos dès le redémarrage.

Notez que ce paramètre n’interfère en aucune façon avec les autres fonctionnalités Active Directory qui sont
donc toujours actives et opérationnelles.
Cadre d’utilisation du paramètre NT4Emulator et restrictions
Ce paramètre est donc particulièrement utile dans le cas où le nombre de postes de travail Windows
2000, Windows XP ou Windows Vista est important et où la période de mise à niveau des contrôleurs NT
vers Active Directory est prévue pour être relativement longue.
Durant la période de transition où le paramètre NT4Emulator sera opérationnel, les ordinateurs
n’utiliseront pas le protocole Kerberos v5. Par conséquent, vous devrez considérer les limitations
suivantes :

 Les clients Windows 2000, Windows XP ou Windows Vista ne pourront pas accéder et
implémenter les paramètres stockés dans les stratégies de groupe. Ce point est particulièrement
important et tend à mettre en avant le fait qu’il est recommandé de disposer assez rapidement,
d’un minimum de contrôleurs Active Directory, pour raccourcir au minimum la phase d’utilisation
du paramètre NT4Emulator.
 Il ne sera pas possible sur ces ordinateurs d’utiliser les outils d’administration Active Directory.
En effet, pour pouvoir accéder aux données stockées dans l’annuaire Active Directory, il faut que
les outils tels que "Utilisateurs et Ordinateurs Active Directory" établissent une connexion LDAP
sécurisée, laquelle exige le protocole Kerberos.
 Pour la même raison, vous ne pourrez pas non plus réaliser la promotion d’un serveur membre
en tant que contrôleur de domaine, ni créer un nouveau domaine dans la forêt. Cette dernière
limitation ne sera vraie que si vous avez activé le paramètre NT4Emulator sur les contrôleurs de
domaine du domaine racine de la forêt.

Limitation de la portée du paramètre NT4Emulator


Vous pouvez constater que le fait que le paramètre NT4Emulator soit un paramètre qui réside sur les
contrôleurs de domaine en fait un paramètre global. De fait, il concerne tous les ordinateurs clients du
domaine concerné.
Dans le cas où il serait nécessaire que certains ordinateurs ne respectent pas la consigne que vous avez
fixée à l’aide du paramètre NT4Emulator, vous pourrez forcer les postes concernés à utiliser malgré tout
le protocole Kerberos.
Cette fois-ci, vous devrez déclarer le paramètre sur le ou les ordinateurs clients à la clé de registre
spécifiée ci-dessous :
HKLM \ System \ CurrentControlSet \ Services \ Netlogon \ Parameters, Nom de la clé :
NeutralizeNT4Emulator et Valeur de type REG_DWORD égale à 1
Le paramètre NeutralizeNT4Emulator est un paramètre qui est pris en charge dynamiquement lors de
l’ouverture de session. Pour être certain que l’authentification Kerberos est bien utilisée, vous pourrez
consulter les journaux d’événements et vérifier que les stratégies de groupe se sont bien appliquées à
l’ouverture de session. La commande gpupdate /force pourra aussi être utilisée pour forcer
dynamiquement le rafraîchissement et l’application des paramètres de l’ordinateur et de l’utilisateur.
L’utilitaire Kerberos Kerbtray disponible dans le kit de Ressources Techniques de Windows Server 2003
peut aussi être utilisé aussi bien sur les serveurs Windows 2000 Server que sur les serveurs Windows
Server 2003 ou Windows Server 2008. Il permet de visualiser les tickets Kerberos actuellement

Page 175
disponibles. De cette façon, vous serez certain que l’ordinateur utilise désormais le protocole Kerberos
malgré la présence du paramètre NT4Emulator fixé sur le contrôleur de domaine.
Retour au fonctionnement normal des contrôleurs Active Directory
Une fois que vous aurez déployé un nombre suffisant de contrôleurs de domaine Active Directory pour
prendre en charge le volume d’authentification souhaité ainsi que la mise à disposition des stratégies de
groupe, vous pourrez annuler l’activation du paramètre NT4Emulator en fixant sa valeur à 0. Une fois la
valeur fixée, procédez au redémarrage des contrôleurs de domaine concernés.
À partir de cet instant, le contrôleur utilisera en priorité le protocole Kerberos et NTLM v2 si nécessaire.

Pour être sûr que tous les postes sont capables de profiter de l’authentification sécurisée Kerberos v5 et de
l’application des stratégies de groupe, assurez-vous que le paramètre est bien supprimé de tous les
contrôleurs Active Directory.

Pour plus de détails sur ces paramètres, vous pouvez consulter l’article 298713 « How to prevent
overloading on the first domain controller during domain upgrade » disponible à l’adresse : http://support.
microsoft.com/kb/298713/en-us.

Validation des acquis : questions/réponses


1. Questions

Si l’état de vos connaissances sur ce chapitre vous semble suffisant, répondez aux questions ci-après.
1 Quelle différence fondamentale faites-vous entre la recherche des contrôleurs de domaine Windows NT et
la recherche des contrôleurs de domaine Active Directory ?
2 Quelle différence faites-vous entre un nom DNS et un nom NetBIOS ?
3 Les services de résolution DNS peuvent-ils être invoqués dans le cadre des résolutions NetBIOS ?
4 Le code de service NetBIOS [1D] correspond-il au code de service d’un domaine NT ?
5 Quel est le code de service NetBIOS utilisé par les clients Windows pour localiser les contrôleurs de
domaine Windows NT ?
6 Quel service sur les serveurs fonctionnant sous Windows Server 2008, Windows Server 2003 ou Windows
2000 Server est utilisé pour localiser les contrôleurs de domaine Active Directory ?
7 Qu’appelle-t-on un Ping LDAP ? Dans quel cas est utilisée cette fonction ?
8 Quels types d’enregistrements critiques Active Directory doivent être présents pour aider à la localisation
et la sélection de chaque contrôleur de domaine Active Directory ?
9 Quelle fonctionnalité de Windows Server 2003 et Windows Server 2008 permet de garantir la disponibilité
totale de la zone racine de la forêt _msdcs.racine ?
10 Vers quels serveurs DNS la zone racine de la forêt _msdcs.racine est-elle répliquée ?
11 Quels sont les RFC qu’il est indispensable de supporter pour que les services de localisation des services
Active Directory soient opérationnels ?
12 Quelles commandes de diagnostics pouvez-vous utiliser pour vérifier les enregistrements de ressources
des contrôleurs de domaine Active Directory ?
13 Quelle commande pouvez-vous utiliser pour purger le cache de résolutions lorsque le problème se situe
du côté du client DNS ?
14 Quelle commande pouvez-vous utiliser pour purger le cache de résolutions lorsque le problème se situe
côté du serveur DNS ?
15 Dans le cadre de la période de transition des contrôleurs de domaine NT vers Windows Server 2003 ou
Windows Server 2008, est-il possible de faire croire aux postes clients que le nouveau contrôleur Windows
est un contrôleur Windows NT ?
16 Expliquez le rôle exact des nouvelles zones GlobalNames offertes par les serveurs DNS fonctionnant sous
Windows Server 2008 ?

Page 176
2. Résultats

Référez-vous aux pages suivantes pour contrôler vos réponses. Pour chacune de vos bonnes réponses,
comptez un point.
Nombre de points /16
Pour ce chapitre, votre score minimum doit être de 12 sur 16.

3. Réponses

1 Quelle différence fondamentale faites-vous entre la recherche des contrôleurs de domaine Windows NT et
la recherche des contrôleurs de domaine Active Directory ?

Dans les domaines NT, la recherche des services est basée sur l’interface NetBIOS et le service de résolution
WINS. Dans les domaines Active Directory, les contrôleurs sont localisés grâce au système de résolution
DNS.

2 Quelle différence faites-vous entre un nom DNS et un nom NetBIOS ?

Ces deux types de noms appartiennent à des espaces de nommage distincts.

3 Les services de résolution DNS peuvent-ils être invoqués dans le cadre des résolutions NetBIOS ?

Oui, comme cela est le cas sous Windows NT, Windows 2000, Windows XP Professionnel, Windows Vista et
aussi Windows Server 2003 et Windows Server 2008.

4 Le code de service NetBIOS [1D] correspond-il au code de service d’un domaine NT ?

Non. Le code [1D] est utilisé par les fonctions d’exploration du voisinage réseau.

5 Quel est le code de service NetBIOS utilisé par les clients Windows pour localiser les contrôleurs de
domaine Windows NT ?

Le domaine NT enregistre son nom sur le code de service NetBIOS [1C]. Cet enregistrement de groupe est
utilisé par les clients Windows pour localiser les contrôleurs de domaine Windows NT.

6 Quel service sur les serveurs fonctionnant sous Windows Server 2008, Windows Server 2003 ou Windows
2000 Server est utilisé pour localiser les contrôleurs de domaine Active Directory ?

Le service Ouverture de session réseau (Net Logon).

7 Qu’appelle-t-on un Ping LDAP ? Dans quel cas est utilisée cette fonction ?

Il s’agit d’un message réseau permettant de tester la présence d’un serveur LDAP. Le protocole de transport
utilisé n’est pas TCP sur le port 389 mais UDP sur le port 389.

8 Quels types d’enregistrements critiques Active Directory doivent être présents pour aider à la localisation
et la sélection de chaque contrôleur de domaine Active Directory ?

Chaque contrôleur de domaine nécessite 13 enregistrements de ressources de types SRV et CNAME.

9 Quelle fonctionnalité de Windows Server 2003 et Windows Server 2008 permet de garantir la disponibilité
totale de la zone racine de la forêt _msdcs.racine ?

Les partitions de l’annuaire d’applications.

10 Vers quels serveurs DNS la zone racine de la forêt _msdcs.racine est-elle répliquée ?

Cette zone est répliquée vers tous les serveurs DNS contrôleurs de domaines de la forêt.

Page 177
11 Quels sont les RFC qu’il est indispensable de supporter pour que les services de localisation des services
Active Directory soient opérationnels ?

Il faut respecter le RFC Draft 2052, lequel a été mis à jour par le RFC 2782 de type Proposed Standard.

12 Quelles commandes de diagnostics pouvez-vous utiliser pour vérifier les enregistrements de ressources
des contrôleurs de domaine Active Directory ?

Dcdiag, Netdiag, Nltest.

13 Quelle commande pouvez-vous utiliser pour purger le cache de résolutions lorsque le problème se situe
du côté du client DNS ?

Utilisez la commande "IPConfig /flushdns".

14 Quelle commande pouvez-vous utiliser pour purger le cache de résolutions lorsque le problème se situe
côté du serveur DNS ?

Utilisez la commande "DNSCmd nom_du_serveur /clearcache".

15 Dans le cadre de la période de transition des contrôleurs de domaine NT vers Windows Server 2003 ou
Windows Server 2008, est-il possible de faire croire aux postes clients que le nouveau contrôleur Windows
est un contrôleur Windows NT ?

Oui. Il suffit de déclarer la valeur NT4Emulator de type REG_DWORD égale à 1 à la clé HKLM \ System \
CurrentControlSet \ Services \ Netlogon \ Parameters.

16 Expliquez le rôle exact des nouvelles zones GlobalNames offertes par les serveurs DNS fonctionnant sous
Windows Server 2008 ?

Ce nouveau type de zones DNS permet de stocker les noms DNS appelés noms simples en une seule partie.
Cette nouvelle fonctionnalité permet aux administrateurs de migrer l’ensemble des systèmes de résolutions
vers DNS. Il est ainsi possible de disposer de noms globaux statiques en une seule partie sans dépendre du
service Wins. Notez tout de même que ces "noms simples" pris en charge par les zones DNS GlobalNames
ne remplacent pas totalement les services WINS.

Travaux pratiques
1. Inscription manuelle des enregistrements SRV du service Ouverture
de session réseau

Ce TP a pour objectif d’aider au bon enregistrement des enregistrements de services des contrôleurs de
domaine Windows 2000 Server, Windows Server 2003 et Windows Server 2008, dans le cas où les
serveurs seraient "mal" inscrits dans les zones DNS.
Pour réaliser cette opération, procédez tel que cela est précisé ci-dessous.
1. Ouvrez une invite de commandes.
2. Tapez la commande : nltest /dsregdns
Pour obtenir tous les détails de la syntaxe de la commande NLTEST, tapez nltest /?
Vous pouvez aussi procéder au redémarrage du service "Ouverture de session réseau".
Pour réaliser cette opération, procédez tel que cela est précisé ci-dessous :
1. Ouvrez une invite de commandes.
2. Tapez la commande ci-dessous : net stop netlogon, puis validez par [Entrée], net start netlogon, puis
validez par [Entrée].
3. Attendez quelques secondes que le service "Ouverture de session réseau" procède au réenregistrement
de tous les enregistrements de type SRV de l’ordinateur concerné.
Ce TP vous a permis de maintenir de manière efficace les enregistrements critiques des services Active
Directory.

Page 178
2. Désenregistrements des enregistrements SRV

Ce TP a pour objectif d’aider au nettoyage des zones DNS contenant les enregistrements de service
utilisés par les contrôleurs de domaine Windows 2000 Server, Windows Server 2003 et Windows Server
2008 obsolètes mais encore connus au sein des zones DNS.
Pour réaliser cette opération, procédez tel que cela est précisé ci-dessous.
1. Ouvrez une invite de commandes.
2. Tapez la commande : nltest [/server:servername] /dsderegdns:srv-paris /dom:eu.corpnet.net
où le paramètre servername représente le serveur sollicité. Si le paramètre n’est pas spécifié, alors la
commande considère l’ordinateur local.
Pour procéder à l’opération de désenregistrement des enregistrements de services souhaités, utilisez le
paramètre /dsderegdns:DnsHostName. Le paramètre DnsHostName représente le nom à
supprimer. Terminez cette commande avec le paramètre /DOM:Nom_du_domaine visé.
Pour obtenir tous les détails de la syntaxe de la commande NLTEST, tapez nltest /?

3. Réinitialisation du cache de résolution client à l’aide de la commande


ipconfig

Ce TP vous permettra de résoudre nombre de problèmes de résolution de noms DNS en vidant le cache
de résolution du client DNS.
Pour réaliser cette opération, procédez tel que cela est spécifié ci-dessous :
1. Ouvrez l’invite de commandes.
2. Tapez la commande suivante : ipconfig /flushdns
Le paramètre /flushdns vous permet de vider et réinitialiser le cache de résolution client.

Il n’est pas nécessaire de disposer d’informations d’identification d’administration pour effectuer cette tâche.
La réinitialisation du cache n’élimine pas les entrées préchargées à partir du fichier local Hosts. Pour
éliminer ces entrées du cache, vous devez les supprimer de ce fichier.
Bien que la commande ipconfig soit fournie pour les versions antérieures de Windows, l’option
/flushdns est uniquement disponible pour les ordinateurs exécutant les systèmes d’exploitation
Windows 2000 et ultérieur.

4. Effacement du contenu du cache des noms de serveurs DNS

Ce TP vous permettra de purger le contenu du cache des noms du serveur DNS.


Pour réaliser cette opération, procédez tel que cela est précisé ci-dessous :
1. Ouvrez la console de gestion du DNS.
2. Dans l’arborescence de la console, cliquez sur le serveur DNS sur lequel vous souhaitez réaliser
l’opération.
3. Dans le menu Action, cliquez sur Effacer le cache.

Pour effectuer cette procédure, vous devez être membre du groupe Administrateurs sur l’ordinateur local, ou
avoir reçu par délégation les autorisations nécessaires. Si l’ordinateur est joint à un domaine, les membres
du groupe Admins du domaine peuvent être en mesure d’effectuer cette procédure.
Pour réaliser la même opération à la ligne de commande, procédez comme suit : Ouvrez une invite de
commandes puis tapez : dnscmd NomServeur /clearcache

Page 179
Annuaires, opérations LDAP et services de domaine Active Directory

À propos des annuaires


Nous sommes familiers et habitués à utiliser différents types d’annuaires dans notre vie quotidienne. À
titre d’exemple, nous pouvons citer les annuaires téléphoniques publiques et professionnels et tout ce qui
ressemble de près ou de loin à un catalogue. Ce pourrait être le cas d’un programme de spectacle ou
encore d’un catalogue de vente de produits sur un site de commerce électronique.
La fonction première de tout service d’annuaire est donc d’aider les utilisateurs de ces services à trouver
toutes sortes d’éléments en fonction de leur description et diverses caractéristiques.
Dans la mesure où les utilisateurs n’interagissent pas directement avec l’annuaire, il est dit que ces types
d’annuaires fonctionnent en mode "déconnecté".
L’implémentation des services d’annuaires au sein des réseaux informatiques reprend ces mêmes
concepts mais étend de manière importante leur fonctionnalités. À l’inverse des premiers, les annuaires
informatiques fonctionnent en mode "connecté" et disposent ainsi des caractéristiques suivantes :

 L’annuaire est sécurisé : ce point signifie que l’annuaire peut être utilisé pour implémenter un
contrôle d’accès global aux objets. Dans la mesure où l’annuaire doit centraliser des
informations "intéressantes", il est indispensable qu’il dispose de mécanismes d’authentification
modernes et standards capables de gérer l’identité des clients.
 L’annuaire est dynamique : ce point signifie que le contenu de l’annuaire peut être mis à jour
de manière très rapide et ce, quel que soit le nombre de serveurs d’annuaires concernés. Les
informations offertes par l’annuaire sont donc "stables" car disponibles de manière cohérente en
tout point du réseau.
 L’annuaire est flexible : ce point signifie que le contenu de l’annuaire peut être personnalisé
via l’ajout de nouvelles structures de données sans pour autant nécessiter une réorganisation de
l’annuaire, ni de surcoûts importants. Une telle flexibilité permettra aussi de réorganiser de
manière dynamique l’annuaire lorsque cela sera nécessaire. Les opérations de réorganisation
peuvent permettre une plus grande efficacité des services de recherches de l’annuaire et aussi
de s’adapter à une évolution du modèle organisationnel.

Bases de données et Systèmes de Fichiers : ce qu’un système d’annuaire ne fera pas !


L’annuaire joue le rôle d’une base de données sécurisée globalement disponible car répliquée en de
nombreux points du réseau. Cependant, les services et le rôle de l’annuaire ne peuvent être comparés
aux services fournis par un système de base de données SQL ou un système de fichier tel que NTFS ou
autre.
Concernant la comparaison par rapport aux moteurs de bases de données SQL, il convient de constater
que les annuaires sont utilisés à 90% en lecture et donc très peu en écriture. Si le volume des écritures
augmente ou si les requêtes sont complexes, alors l’avantage sera donné à un moteur de bases de
données SQL. Si par contre, la sécurité et la disponibilité sont privilégiées, alors l’avantage serait donné à
un annuaire.
Concernant la comparaison par rapport aux systèmes de fichiers - comme par exemple NTFS - il convient
de faire remarquer que les annuaires n’apprécient guère les objets "volumineux". Les annuaires sont en
fait optimisés pour être excellents en recherches et en lectures d’attributs et ce, sur un grand volume
d’objets (généralement des millions d’objets). À la différence des systèmes de fichiers, les annuaires ne
disposent pas de fonctions de lecture anticipées (Read Ahead) ou de lecture brute (RAW).
Les annuaires sont donc orientés "attributs et valeurs d’attributs" tandis que les systèmes de fichiers sont
clairement orientés stockage des données. Si les annuaires sont pris en défaut sur leur capacité à assurer
un service performant au niveau des données brutes, on peut aussi remarquer qu’il en sera de même
pour les systèmes de fichiers concernant la gestion des attributs et les services de recherche intégrés.

Page 180
Un peu d’Histoire
En 1988, l’ISO (International Organization for Standardization) et l’ITU (International Telecommunications
Union) fusionnent leurs travaux et approuvent la première version du standard X.500, laquelle sera
officiellement publiée par l’ITU en 1990.
En fait, X.500 est constitué d’un ensemble de protocoles standards, tous issus des travaux de l’ISO. Afin
de donner un bref aperçu de l’étendue des services offerts par le protocole X.500, ces différentes
recommandations et protocoles sont brièvement rappelés ci-dessous :

 Spécification X.501 : Description des concepts X.500 ;


 Spécification X.509 : Description des mécanismes d’authentification X.500 ;
 Spécification X.511 : Description des fonctions de recherches et manipulations d’objets ;
 Spécification X.518 : Description des services distribués ;
 Spécification X.519 : Description des protocoles X.500 tels que DAP, DSP, DOP et DISP ;
 Spécification X.520 : Description des attributs et classes X.500 ;
 Spécification X.525 : Description des mécanismes de réplication X.500 ;
 Spécification X.530 : Description des services d’administration des annuaires X.500.

Comme vous pouvez le constater, le protocole X.500 a été conçu dès le départ pour offrir aux services
d’annuaires des services complets et sophistiqués. Cependant, ce cahier des charges énorme sera la
cause des nombreux problèmes de fonctionnement et des faibles performances des premières versions
d’annuaires X.500.
De plus, le principal inconvénient viendra du fait que seuls les protocoles ISO étaient supportés. Au
commencement de l’Internet, certains disent même que le "rêve secret" des architectes de l’OSI aurait
été que X.500 supplante TCP/IP ! En fait cela n’arrivera pas et, bien au contraire, les implémentations
X.500 les plus modernes seront petit à petit adaptées pour supporter TCP/IP.

LDAPv2 & LDAPv3


Les méthodes d’accès aux annuaires basés sur X.500 étaient bien trop complexes. C’est ainsi qu’après
plusieurs méthodes "plus simples" permettant l’accès aux annuaires X.500, l’OSI et l’IETF (Internet
Engineering Task Force) décidèrent de se regrouper pour formaliser un protocole allégé capable d’accéder
aux annuaires X.500. Ces différentes évolutions sont rappelées ci-dessous :

 La première spécification a été publiée en 1993 sous le RFC 1487.


 La spécification LDAPv2 publiée sous le RFC 1777 sera la première version approuvée par
l’industrie.
 Le RFC 1778 (String Representation of Standard Attribute Syntaxes) et le RFC 1779 (String
Representation of Distinguished Names) participent aussi à la clarification des syntaxes
supportées.
 La spécification LDAPv3 est publiée en 1997 sous le RFC 2251. Cette version améliorera de
manière significative LDAPv2 dans les domaines ci-dessous :
 Extensibilité plus importante : le protocole LDAPv3 peut être étendu pour supporter de
nouvelles opérations à l’aide de nouveaux contrôles. De cette manière, les services
LDAP peuvent être étendus au fur et à mesure que cela est nécessaire.
 Découverte des fonctionnalités et du schéma disponible : les serveurs LDAPv3
disposent d’une nouvelle entrée dans l’annuaire appelée RootDSE (pour Root Directory
Server Specific Entry). Ce nouvel élément permet la publication de nombreuses
informations spécifiques telles que, par exemple, les informations de schéma ou les
contrôles disponibles. Cette fonctionnalité permet aux clients LDAP de mieux négocier
les fonctionnalités et services disponibles par tel ou tel serveur d’annuaire LDAP.
 Meilleure gestion des authentifications : LDAPv3 implémente le support de SASL
(Simple Authentication and Security Layer) et de TLS (Transport Layer Security).
 Gestion des références : LDAPv3 implémente un mécanisme de gestion des références
qui permet aux serveurs LDAP de renvoyer des références vers d’autres serveurs
LDAP.
 Support des jeux de caractères Unicode : le support du jeu de caractères UTF-8
permet au protocole LDAP de manipuler des données quel que soit le langage utilisé.

Comme pour LDAPv2, le protocole LDAPv3 nécessite un certain nombre de clarifications lesquelles sont
publiées dans les RFC suivants :

Page 181
 RFC 2252 : Attribute Syntax Definitions
 RFC 2253 : UTF-8 String Representation of Distinguished Names
 RFC 2254 : String Representation of LDAP Search Filters
 RFC 2255 : The LDAP URL Format
 RFC 2256 : A Summary of X.500(96) User Schema for use with LDAPv3
 RFC 2829 : Authentication Methods for LDAP
 RFC 2830 : Extensions for Transport Layer Security
 Conformité LDAP de Windows 2000
 La famille des systèmes d’exploitation Windows 2000 Server est majeure sur de nombreux plans.
Nous pouvons rapidement citer les performances du système, les services de cluster, les services
réseaux, les services de certificats X509 v3, le support des authentifications par cartes à puce, les
services IIS, les services transactionnels MTS et les services de streaming multimédia WMS. Cette
liste n’est bien sûr, pas exhaustive.
 Cependant, ces services, même s’ils sont fondamentaux à plus d’un titre, ne furent pas la raison
pour laquelle Microsoft monopolisa pendant plus de deux ans la quasi-totalité de ses développeurs
sur le développement de Windows 2000 ! Le problème était d’arriver au bout du cahier des charges
qui avait été défini dans le cadre des services distribués.
 L’ensemble de ces services devait être basé sur des technologies standard telles que TCP/IP, DNS,
NTP, Kerberos, LDAPv2 et LDAPv3 et de nombreuses extensions autour de ces standards pour que
soit possible le déploiement d’une Infrastructure de Services Distribués. Il fallait aussi être capable
de répondre aux besoins d’entreprises très différentes et de tailles variables.
 C’est ainsi que la première implémentation de l’Active Directory fut rapidement capable d’accueillir
différents types de données et de services. Pour que ce soit possible, Microsoft s’est engagé très tôt
à supporter le protocole d’annuaire LDAP. De fait, l’implémentation Windows 2000 de l’annuaire
Microsoft Active Directory est parfaitement conforme aux RFC disponibles au moment de la
disponibilité de Windows 2000.
 Le tableau ci-dessous liste les différents RFC LDAP supportés par l’implémentation Windows 2000 de
l’annuaire Active Directory.

RFC RFC LDAP principaux État des RFC

Lightweight Directory Access Protocol


2251 Proposed
(v3)

Les alias et les DN de type multivaleurs ne sont à ce jour pas supportés.

Lightweight Directory Access Protocol


2252 Proposed
(v3): Attribute Syntax Definitions

Certaines syntaxes Unix ne sont pas à ce jour supportées.

Lightweight Directory Access Protocol


2253 (v3): UTF-8 String Representation of Proposed
Distinguished Names

The String Representation of LDAP


2254 Proposed
Search Filters

2255 The LDAP URL Format Proposed

A Summary of the X.500(96) User


2256 Proposed
Schema for use with LDAPv3

2829 Authentication Methods for LDAP Proposed

Lightweight Directory Access Protocol


2830 (v3): Extension for Transport Layer Proposed
Security

RFC RFC LDAP additionnels

LDAP Control Extension for Simple


2696 Proposed
Paged Results Manipulation

Page 182
RFC RFC LDAP principaux État des RFC

Using Domains in LDAP/X.500


2247 Proposed
Distinguished Names

Conformité LDAP de Windows Server 2003 et Windows Server


2008
Windows Server 2003 reprend la base apportée par Windows 2000 Server et apporte de nouvelles
fonctionnalités qui intéresseront tant les développeurs que les ingénieurs et architectes systèmes. Notez
que ces fonctionnalités font toutes l’objet de RFC.
Les fonctionnalités les plus importantes sont spécifiées ci-dessous :

 Support des entrées dynamiques : l’annuaire Active Directory peut stocker les valeurs d’entrées
dynamiques en leur assignant une durée de vie (TTL - Time to Live). De cette manière, ces
valeurs peuvent être automatiquement détruites lorsque le TTL expire.
 Support du protocole TLS - Transport Layer Security : les connexions vers l’Active Directory via
le protocole LDAP peuvent désormais être cryptées et authentifiées à l’aide du protocole TLS.
 Support des authentifications DIGEST-MD5 : les connexions vers l’Active Directory via le
protocole LDAP peuvent désormais être authentifiées à l’aide du mécanisme d’authentification
SASL - DIGEST-MD5 Simple Authentication and Security Layer. L’interface Windows Digest SSPI
(pour Security Support Provider Interface) permet d’utiliser des authentifications de type
DIGEST-MD5 en tant que méthode de type SASL.
 Support des vues virtuelles : il s’agit d’une optimisation du traitement des réponses aux
requêtes LDAP. Par exemple, lorsqu’une requête doit retourner vers le client un résultat trop
volumineux, l’idée consiste à lui retourner seulement le contenu d’une "fenêtre" de valeurs
plutôt que l’intégralité de la réponse. De cette manière, le client "voit" le résultat
instantanément et la charge sur le réseau est mieux contrôlée.
 Bind LDAP multiples : cette fonctionnalité permet à un client de réaliser plusieurs Bind LDAP au
travers de la même connexion pour pouvoir authentifier les utilisateurs.

Le tableau ci-dessous liste les différents RFC LDAP supportés par l’implémentation Windows Server 2003
de l’annuaire Active Directory.

RFC RFC LDAP principaux État des RFC

L’ensemble des RFC supportés par l’implémentation LDAP de Windows 2000 sont supportés sous Windows Server 2003.

RFC LDAP additionnels supportés par


RFC Windows Server 2003 et Windows État des RFC
Server 2008

LDAP Protocol (v3): Extensions for


2589 Proposed
Dynamic Directory Services

Definition of the inetOrgPerson LDAP


2798 Proposed
Object Class

Using Digest Authentication as an SASL


2831 Proposed
Mechanism

LDAP Control Extension for Server Side


2891 Proposed
Sorting of Search Results

LDAP Protocol (v3): Extensions for


2589 Proposed
Dynamic Directory Services

Nous venons de voir que Microsoft s’est clairement engagé dans le support des technologies d’annuaires
notamment via le support inconditionnel du protocole LDAP et une participation active au sein des
différents groupes de travail de l’IETF.
Page 183
Cependant nous savons bien que les technologies passent par des étapes intermédiaires nécessaires,
lesquelles génèrent souvent des problèmes de compatibilité. C’est ce que nous allons constater avec les
problèmes générés par la classe inetOrg-Person définie dans le RFC 2798.

Compatibilité LDAP et support de la classe inetOrgPerson


De nombreuses critiques ont été faites concernant la pseudo compatibilité de l’annuaire Active Directory
en terme d’annuaire respectant les recommandations de l’IETF et tout particulièrement la conformité
LDAPv3. Le grand reproche était le non support de la classe inetOrgPerson.
En fait, plusieurs points sont à considérer :

 L’annuaire Active Directory respecte tous les RFC fondamentaux traitant du protocole LDAP et
tout particulièrement le RFC 3377 qui définit les spécifications du protocole LDAPv3.
 La classe inetOrgPerson est définie dans le RFC 2798, lequel est considéré comme une extension
de LDAPv3 et de fait, n’est donc pas incluse dans le RFC 3377 qui décrit les spécifications
LDAPv3.
 La classe inetOrgPerson définie dans le RFC 2798 n’a été publiée par l’IETF qu’en avril 2000,
alors que Windows 2000 n’était livré qu’en février de la même année. Il n’était donc pas
humainement possible de supporter cette classe.
 En cas de nécessité, il a toujours été possible d’étendre le schéma de l’Active Directory pour y
ajouter cette nouvelle classe.
 Microsoft a livré quelques temps après la sortie de Windows 2000 un additif capable d’intégrer
cette nouvelle classe dans le schéma Active Directory. Ce kit appelé "Windows 2000
inetOrgPerson Kit" est disponible gratuitement sur le site de Microsoft.
 Le schéma Active Directory de Windows Server 2003 intègre la définition complète de la classe
inetOrgPerson ainsi que l’intégralité des fonctions d’administration relatives à cette classe.

Finalement, cette classe a toujours été supportée dans l’environnement Windows 2000, mais elle ne sera
vraiment intégrée de base qu’avec Windows Server 2003.
Problème de mise à jour du schéma Active Directory vers Windows Server 2003 et Windows
Server 2008
La mise à niveau du schéma Active Directory sera un passage obligé dans le processus de mise à jour des
contrôleurs de domaine Windows 2000 et Windows Server 2003 vers la nouvelle version Windows Server
2008. Pour ce faire, la commande ADprep située sur le CD-Rom d’installation de Windows Server 2008,
vous permettra de mettre à niveau votre schéma Active Directory avec les nouvelles classes et attributs
apportés par cette nouvelle version. Cependant, si votre schéma Windows 2000 a été étendu par
Exchange 2000, il est probable que vous serez confronté à un problème de conflit sur des attributs
identiques à ceux déclarés dans le RFC 2798.
Ce problème, déjà connu dans le cadre de la mise à niveau du schéma vers la version Windows Server
2003, est dû à l’implémentation par Microsoft de l’une des premières versions de la classe inetOrgPerson
avec Exchange 2000 Server. La version implémentée était une version "RFC Draft" datée du 20 novembre
2001.
Attention : la mise à jour du schéma Windows 2000 nécessite que le contrôleur de domaine maître de
schéma fonctionne sous Windows 2000 SP4.
Si un tel cas se produit, le programme d’installation renommera le ldapDisplayName de ces attributs pour
permettre la mise à jour.
Cette opération pourra avoir pour effet de générer deux objets portant le même nom ce qui provoquera
un conflit de réplication et le renommage de la classe avec un préfixe de type Dup au début du nom.
Pour résoudre ce problème, récupérez les fichiers Inetorgpersonfix.LDF et Inetorgpersonfix.DOC du fichier
Support.cab contenu dans les Outils de Support de Windows Server 2003.
Le fichier Inetorgpersonfix.doc décrit en détail l’opération à réaliser. En résumé, le renommage des
éléments conflictuels devra être réalisé dans le schéma à l’aide de la commande ldifde et du fichier de
paramètres inetorgpersonfix.ldf.
Vous pouvez aussi faire référence à l’article Technet 314649 disponible via le lien ci-après :
http//support.microsoft.com/kb/314649
Ce fichier contient les modifications à apporter à l’aide de la commande suivante : Ldifde /i /f
inetOrgPersonFix.ldf /c "DC=X" "DC=Corpnet,DC=Corporate,DC=net"

Page 184
Le paramètre /c remplace toutes les occurrences de "DC=X" dans le fichier LDF inetorgperson.ldf par
"DC=Corpnet,DC=Corporate,DC=net"

Pour pouvoir réaliser cette opération vous devez être membre des groupes suivants dans le domaine racine
de la forêt Active Directory : Administrateur du Domaine, Administrateurs de l’Entreprise et Administrateurs
de Schéma.
Le conflit pourra avoir lieu pour le LdapDisplayName des attributes secretary, labeledURI ou
houseIdentifier. Le fichier inetorgpersonfix.ldf réalise les modifications sur ces attributs ainsi que pour les
attributs Exchange suivants :

 Pour l’attribut CN=ms-Exch-Assistant-Name,CN=Schema,CN=Configuration,DC=X le


lDAPDisplay Name sera renommé en msExchAssistantName.
 CN=ms-Exch-LabeledURI,CN=Schema,CN=Configuration,DC=X le lDAPDisplayName sera
renommé en msExchLabeledURI.
 CN=ms-Exch-House-Identifier,CN=Schema,CN=Configuration,DC=X le lDAPDisplayName sera
renommé en msExchHouseIdentifier.

Le fichier de modifications contient donc six modifications : trois pour les attributs généraux et trois pour
des attributs utilisés par Microsoft Exchange.

Consultation LDAP Display Name à l’aide de la console de gestion du schéma


La figure précédente montre la valeur du LDAPDisplayName pour l’attribut ms-Exch-Assistant-Name dont
le nom complet est CN=ms-Exch-Assistant-Name,CN=Schema,
CN=Configuration,DC=Corpnet,DC=Corporate,DC=net.
Le problème de déclaration des attributs de la classe inetOrgPerson illustre parfaitement la problématique
de la structure interne de l’annuaire.
Le fait est que tout annuaire disposera d’un schéma de base plus ou moins riche en fonction des
possibilités de celui-ci. Ensuite, chaque application devra y déclarer, si nécessaire, ses propres attributs
et/ou classes additionnelles sachant que vous devrez gérer la possibilité d’un conflit éventuel.

Page 185
Vous pourrez alors, comme le fait Microsoft pour la mise à jour du schéma Windows 2000 vers le schéma
Windows Server 2003, utiliser la commande LDIFDE.
Opérations LDAP
Ce chapitre explique les concepts de base et opérations élémentaires du protocole LDAP. Il vous
permettra de mieux entrevoir les opérations qui existent entre un client Windows et un contrôleur de
domaine Windows 2000, Windows Server 2003 ou Windows Server 2008.
Les points ci-dessous caractérisent le protocole LDAP :
Client/Serveur : le protocole LDAP est basé sur un mécanisme client/serveur qui minimise les
opérations et la charge côté client en implémentant côté serveur les opérations les plus complexes. Le
serveur est responsable, du traitement des requêtes initiées par les clients. Une fois que le serveur a
traité la demande d’un client, il lui retourne une réponse positive ou négative (dans ce cas, une erreur).
Messages : le protocole LDAP est capable de générer plusieurs messages au cours de la même session.
Le serveur sollicité devra donc, dans ce cas, prendre en charge l’ensemble de ces requêtes. Un client
LDAP peut aussi prendre en charge plusieurs sessions. De cette manière, il est possible au client de
solliciter plusieurs serveurs LDAP simultanément.
LDAP s’appuie sur TCP/IP : le protocole LDAP utilise le transport TCP sur le port 389. Le protocole TCP
est connu et reconnu pour ses qualités de détection et gestion des erreurs de transport. Cependant, il est
aussi consommateur de ressources. Le fait que LDAP soit capable de réaliser de manière simultanée de
multiples opérations vers le même serveur permet de préserver les ressources réseaux.
La séquence ci-dessous décrit les différentes opérations entre un client et un serveur LDAP. Cette
séquence est illustrée avec la commande ldp disponible avec les outils de support de Windows Server
2003 :
1. Le client se connecte sur un serveur.

Connexion au serveur local via LDP


Cette opération indispensable permet au client de recevoir des informations telles que l’heure système,
les noms des différents NC (naming contexts), les contrôles supportés par l’annuaire, les niveaux de
version de protocole LDAP supportés ainsi que les différents protocoles d’authentification disponibles.

Page 186
2. Le client fait une demande de BIND. Cette opération a pour objet d’authentifier l’utilisateur vers
l’annuaire LDAP et de maintenir un contexte de sécurité, lequel sera utilisable pour les opérations
suivantes. Notez que, comme sur la plupart des systèmes sécurisés, il est possible de s’authentifier de
manière anonyme, à condition toutefois que ce type de session soit autorisé.

Demande d’authentification

Réponse positive du serveur d’annuaire

Page 187
3. Le client authentifié peut désormais interagir avec l’annuaire sur la base des verbes disponibles via le
protocole LDAP. L’exemple ci-dessous initie une recherche sur tous les objets appartenant à la classe
inetOrgPerson.

Demande de recherche LDAP sur les objets inetOrgPerson dans le domaine Windows
corp2003.corporate.net
4. Le serveur retourne une réponse positive composée d’un message contenant les entrées d’annuaire
relatives à la recherche. Notez que lorsque la requête ne donne aucun résultat, aucune entrée n’est
retournée au client.

Le résultat de la requête est qu’il existe une entrée dans l’annuaire


5. Le serveur LDAP renvoie au client un code de retour relatif à la demande du client.
6. Le client LDAP demande une opération de Unbind pour fermer sa session.
7. Le serveur LDAP renvoie au client un code de retour relatif à la demande du client puis ferme la
connexion.
L’exemple précédent a illustré les concepts LDAP en prenant pour exemple une recherche, opération qui
concerne plus de 90% des opérations réalisées vers un serveur d’annuaire LDAP.
Les autres fonctions LDAP - elles sont au nombre de 10 - sont brièvement présentées ci-dessous :
Bind (Lier) : cette fonction est utilisée pour réaliser une authentification et maintenir le contexte de
sécurité de la session.
Search (Rechercher) : cette fonction est utilisée pour réaliser une recherche.
Compare (Comparer) : cette fonction est utilisée pour vérifier que l’information proposée par le client
est bien celle qui est présente dans l’annuaire. La fonction search pourrait être utilisée à la place, à ceci
près que la fonction compare retournera un code d’erreur spécifique si l’attribut à comparer n’est pas
présent au niveau de l’entrée d’annuaire à vérifier. Notez que la fonction compare nécessite de déclarer
trois paramètres : le DN de l’objet à comparer, le type d’attribut à comparer ainsi que la valeur de
l’attribut à comparer.
Add (Ajouter) : cette fonction est utilisée pour créer une nouvelle entrée dans l’annuaire. Pour pouvoir
ajouter une nouvelle entrée dans l’annuaire, il est indispensable de spécifier la classe d’objet à ajouter
ainsi que tous les attributs de type obligatoire sur la dite classe. Vous devrez vous assurer aussi que le
container de l’objet que vous souhaitez créer existe et que dans ce container, un objet du même nom
n’existe pas déjà. Une nouvelle entrée dans l’annuaire nécessitera donc un nouveau DN (Distinguished
Name) ainsi que les différents attributs et valeurs obligatoires et facultatifs.
Delete (Supprimer) : cette fonction est utilisée pour supprimer une entrée de l’annuaire.

Page 188
Modify (Modifier) : cette fonction est utilisée pour modifier les attributs d’une entrée, supprimer des
valeurs d’attributs ou ajouter une valeur à un ou plusieurs attributs. Pour pouvoir aboutir, l’opération doit
concerner un attribut existant. Dans le cas où l’opération de modification porterait sur plusieurs attributs,
l’opération ne pourra aboutir que si tous les attributs ont pu être modifiés. Dans le cas contraire,
l’opération n’aura pas lieu et de cette manière, les entrées de l’annuaire ne seront pas inconsistantes.
Rename (Renommer) : cette fonction - aussi appelée ModifyRDN - est utilisée pour renommer une
entrée de l’annuaire.
Unbind (Délier) : cette fonction est utilisée pour fermer une session LDAP, sachant que la connexion ne
sera pas terminée. Dans le cas où d’autres opérations LDAP seraient initiées, alors elles seraient
considérées comme appartenant à un contexte de type session anonyme. Notez que dans le cas où le
client LDAP terminerait sa session sans réaliser une opération de unbind, alors un paramètre de timeout
sera utilisé côté serveur pour libérer les sessions inactives.
Abandon (Abandonner) : cette fonction est utilisée pour abandonner une opération précédente.
Extended (Étendue) : cette fonction est utilisée pour étendre les fonctionnalités de l’annuaire LDAP. En
fait, une extension est une entrée comme les autres qui possédera ses propres paramètres. Notez
toutefois que ces extensions doivent être déclarées au niveau de l’objet RootDSE sur l’attribut
supportedExtension.

Objet RootDSE et extensions LDAPv3


À peine le groupe de travail LDAP de l’IETF (Internet Engineering Task Force) terminait-il les
spécifications du protocole LDAPv2, que les travaux commençaient pour définir les améliorations qui
seraient intégrées à LDAPv3. C’est dans ce contexte d’évolutions permanentes que l’IETF décida de
réfléchir à une méthode générique qui permette au protocole LDAP d’évoluer en douceur sans recourir à
de multiples refontes et autres processus de certifications trop lourds pour l’industrie.
Pour y parvenir, les architectes du protocole LDAP décidèrent de rendre possible l’évolution de LDAPv3 en
permettant l’usage des éléments suivants :

 Les contrôles : ces extensions agissent comme des éléments qui améliorent de manière
considérable certaines opérations LDAP. Par exemple, le contrôle appelé "Server-Side Sorting"
modifie le comportement des opérations de recherches en triant les résultats avant de les
envoyer au client. Notez que chaque contrôle sera déclaré via un OID (Object Identifier) et un
flag indiquant le caractère critique ou non du contrôle. Le contrôle précédemment cité fait l’objet
du RFC 2891, LDAP Control Extension for Server Side Sorting of Search Results, et est supporté
par Windows Server 2003.
 Les opérations étendues : ces extensions agissent comme des éléments qui ajoutent de
nouvelles fonctionnalités au moteur LDAP. Ces opérations étendues peuvent bien sûr être
composées de multiples contrôles.
 Les mécanismes SASL : ces extensions permettent au client de négocier avec le serveur la
méthode d’authentification la mieux adaptée. Chaque extension fait l’objet d’un RFC particulier.
Par exemple, le RFC 2831 décrit les mécanismes qui permettent le support des authentifications
DIGEST-MD5.

Une fois ces éléments d’extensions définis, il fallut faire en sorte que les clients LDAP aient la possibilité
d’interroger les serveurs LDAP sur leurs possibilités. Ce sera chose faite grâce à une entrée spéciale
appelée Root DSE - Root Directory Specific Entry, laquelle contient tous les paramètres opérationnels qui
caractérisent de manière particulière le serveur LDAP. Ainsi, l’objet RootDSE contient une liste de tous les
contrôles, opérations et mécanismes SASL supportés. Vous pouvez consulter les paramètres retournés
par l’objet Root DSE en utilisant la commande ldp, suivie de l’option Connexion. Vous pouvez aussi
utiliser le composant logiciel enfichable ADSIEdit pour accéder graphiquement au RootDSE. Une fois la
console lancée, sélectionnez Se connecter à.

Page 189
Choisissez l’option Sélectionnez un contexte d’attribution de noms connu.

Visualisation des propriétés des attributs de l’objet RootDSE

Authentifications LDAP et SASL


Nous venons de voir que les serveurs LDAPv3 supportent de nombreuses extensions dont les mécanismes
SASL qui permettent une prise en charge additionnelle de certains mécanismes d’authentification.

Page 190
Il est important de faire remarquer que le protocole LDAPv2 était particulièrement démuni puisque la
méthode la plus couramment utilisée consistait à envoyer le DN de l’utilisateur suivi de son mot de passe
- non crypté ! - sur le réseau. L’approche de l’IETF a consisté, comme ce fut le cas pour les autres
extensions fonctionnelles, à implémenter une interface de gestion des mécanismes d’authentification
plutôt que d’implémenter directement telle ou telle méthode plutôt qu’une autre.
Cette interface appelée SASL - Simple Authentication and Security Layer - permet l’implémentation de
plusieurs protocoles d’authentification sur le serveur LDAPv3 et fait l’objet du RFC 2222.
Le RFC 2829 définit le support des authentifications :

 DIGEST-MD5 : ce protocole permet de crypter le mot de passe de l’utilisateur sur la base d’un
challenge de type MD5.
 EXTERNAL : ce protocole permet de réutiliser une authentification de type TLS ou SSL en vue
de son utilisation vers le serveur LDAP.

Les serveurs contrôleurs de domaine Windows Server 2003 et Windows Server 2008 supportent les
mécanismes d’authentifications listés ci-dessous :

 GSSAPI : support de Kerberos.


 GSS-SPNEGO : support des Global Security Services.
 EXTERNAL : support des authentifications de type SSL et TLS.
 DIGEST-MD5 : support des challenges de type MD5.

Références LDAP
Pour obtenir plus d’informations concernant le protocole LDAP, Windows Server 2003 et Windows Server
2008, consultez les liens ci-dessous.

 Site web des Groupes de travail LDAPv3 de l’IETF : http://www.ietf.org/html.charters/ldapbis-


charter.html
 Forums des Groupes de travail LDAPv3 de l’IETF : http://www.openldap.org/lists/ietf-ldapbis/
 Spécification LDAPv3 : ftp://ftp.rfc-editor.org/in-notes/rfc3377.txt
 The Open Group’s VSLDAP compliance testing suite overview
http://www.opengroup.org/directory/mats/ldap2000/dsvsldap.pdf
 Forum sur l’interopérabilité des services d’annuaires (DIF - Directory Intero- perability Forum) :
http://www.opengroup.org/directory/
 Références MSDN sur l’interface ADSI
http://msdn.microsoft.com/library/default.asp?url=/downloads/list/directorysrv.asp
 Site Microsoft dédié à Active Directory : http://www.microsoft.com/ad
 Site Microsoft dédié à ADAM - Active Directory Application Mode
http://www.microsoft.com/windowsserver2003/adam/default.mspx

 Validation des acquis : questions/réponses


 1. Questions
 Si l’état de vos connaissances sur ce chapitre vous semble suffisant, répondez aux questions ci-
après.
 1 Quelle est la fonction première de tout service d’annuaire ?
 2 Que signifie le fait que certains systèmes d’annuaires fonctionnent en mode déconnecté ?
 3 Est-il important que l’annuaire Active Directory offre une information la plus à jour possible ?
 4 Quelles sont les évolutions de LDAPv3 par rapport à LDAPv2 ?
 5 Qu’est-ce que la classe inetOrgPerson ?
 6 Comment procédez-vous à la mise à jour du schéma d’une forêt Windows 2000 en vue
d’installer votre premier contrôleur de domaine Windows Server 2008 ou Windows Server 2003
dans la forêt Windows 2000 ?
 7 En cas de problème de mise à jour du schéma Windows 2000 vers la version Windows Server
2003 ou la version Windows Server 2008, comment pouvez-vous supprimer les conflits d’attributs
possibles sur la classe inetOrgPerson ?
 8 Quel outil livré avec les Outils de support de Windows Server 2003 pouvez-vous utiliser pour
tester la connectivité et les opérations LDAP d’un contrôleur fonctionnant sous Windows 2000
Server, Windows Server 2003, ou Windows Server 2008 ? Cet outil est désormais disponible de
base avec Windows Server 2008.
 9 Citez quelques unes des grandes fonctions comprises dans le protocole LDAP.
Page 191
 10 Quel outil graphique vous permet de parcourir les contextes de nommage LDAP d’un contrôleur
de domaine Active Directory ?
 2. Résultats
 Reférez-vous aux pages suivantes pour contrôler vos réponses. Pour chacune de vos bonnes
réponses, comptez un point.
 Nombre de points /10
 Pour ce chapitre, votre score minimum doit être de 8 sur 10.
 3. Réponses
 1 Quelle est la fonction première de tout service d’annuaire ?
 La fonction première de tout service d’annuaire est d’aider les utilisateurs, applications et services
de l’entreprise à localiser l’emplacement de différents types (classes) d’objets en fonction de leur
description ou d’autres caractéristiques plus spécifiques.
 2 Que signifie le fait que certains systèmes d’annuaires fonctionnent en mode déconnecté ?
 Dans la mesure où les utilisateurs n’interagissent pas directement avec l’annuaire, il est dit que ces
types d’annuaires fonctionnent en mode "déconnecté".
 3 Est-il important que l’annuaire Active Directory offre une information la plus à jour possible ?
 Oui, car l’Active Directory est au coeur de la plupart des systèmes de sécurité. La sécurité doit être
garantie en tout point du réseau.
 4 Quelles sont les évolutions de LDAPv3 par rapport à LDAPv2 ?
 Le protocole peut être étendu avec peu de contraintes. L’attribut RootDSE permet la publication des
particularités du serveur LDAP, ce qui permet aux clients LDAP une meilleure négociation. Le
support des fonctionnalités de cryptage TLS est aussi pris en charge.
 5 Qu’est-ce que la classe inetOrgPerson ?
 La classe inetOrgPerson est définie dans le RFC 2798, lequel est considéré comme une extension de
LDAPv3 et de fait n’est donc pas incluse dans le RFC 3377 qui décrit les spécifications LDAPv3. Cette
classe a été standardisée après la sortie de Windows 2000 et son support a été inclus de base dans
Windows Server 2003 et Windows Server 2008.
 6 Comment procédez-vous à la mise à jour du schéma d’une forêt Windows 2000 en vue d’installer
votre premier contrôleur de domaine Windows Server 2008 ou Windows Server 2003 dans la forêt
Windows 2000 ?
 À partir du maître d’opérations de schéma fonctionnant sous Windows 2000 ou sous Windows
Server 2003 et en utilisant le CD-Rom d’installation de Windows Server 2008, utilisez la commande
Adprep /forestprep puis Adprep /domainprep. Une fois le schéma correctement mis à niveau et
répliqué, vous devrez préparer le domaine dans lequel vous prévoyez de déployer des contrôleurs
de domaine Windows Server 2008. Vous ouvrirez une session sur le contrôleur de domaine maître
d’opérations d’infrastructure en tant qu’administrateur du domaine et vous lancerez la commande
Adprep/domainprep/ gpprep.
 7 En cas de problème de mise à jour du schéma Windows 2000 vers la version Windows Server
2003 ou la version Windows Server 2008, comment pouvez-vous supprimer les conflits d’attributs
possibles sur la classe inetOrgPerson ?
 Référez-vous à la documentation livrée dans les outils de support livrés sur le CD-Rom de Windows
Server 2003. Vous y trouverez le fichier nommé inetorgpersonfix.doc.
 8 Quel outil livré avec les Outils de support de Windows Server 2003 pouvez-vous utiliser pour
tester la connectivité et les opérations LDAP d’un contrôleur fonctionnant sous Windows 2000
Server, Windows Server 2003, ou Windows Server 2008 ? Cet outil est désormais disponible de
base avec Windows Server 2008.
 Utilisez la commande LDP.
 9 Citez quelques unes des grandes fonctions comprises dans le protocole LDAP.
 Bind, Connect, Search, Compare, Add, Delete, Modify, Rename, Unbind, Abandon, Extended.
 10 Quel outil graphique vous permet de parcourir les contextes de nommage LDAP d’un contrôleur
de domaine Active Directory ?
 Sur les serveurs Windows Server 2003, l’outil ADSI Edit livré avec les Outils de Support de Windows
Server 2003. Sur les serveurs Windows Server 2008, vous pouvez utiliser le raccourci "Modification
ADSI" situé dans le groupe de programmes "Outils d’Administration".

Travaux pratiques
1. Affichage du RootDSE avec ADSI Edit

Le TP suivant a pour objet de vous faire parcourir les propriétés de l’objet RootDSE. De cette manière,
vous pourrez contrôler que votre contrôleur de domaine est bien fonctionnel dans le mode souhaité et
que le statut de catalogue global est bien correct. Pour réaliser cette opération, procédez comme suit :

Page 192
1.
Ouvrez le menu Démarrer, puis cliquez sur Exécuter. Dans le menu Exécuter, tapez adsiedit.msc.
2.
Dans la console ADSI Edit, faites bouton droit (ou bien allez dans le menu Action) et sélectionnez Connect
to.
3.
Dans la fenêtre, dans la partie Connection Point, choisissez l’option Select a well known Naming
Context, puis choisissez RootDSE.
4.
Entrez dans le contexte RootDSE et positionnez-vous sur le container RootDSE.
5.
Faites bouton droit et ouvrez la page de propriétés.
6.
À partir de la fenêtre Attribute Editor, notez les valeurs des attributs ci-dessus et leur signification :
 configurationNamingContext
 dnsHostName
 domainControllerFunctionality
 domainFunctionality
 forestFunctionality
 isGlobalCatalogReady
 isSynchronized
 supportedLdapVersion
 supportedSASLMechanisms
Vous venez de contrôler le bon fonctionnement des paramètres présentés par les serveurs jouant le rôle
de contrôleur de domaine Active Directory.

2. Utilisation de Ldp pour vérifier le mode fonctionnel d’un domaine ou


d’une forêt

Ce TP va vous permettre d’utiliser la commande Ldp pour vérifier que le domaine Windows Server 2003
fonctionne bien en mode Windows 2000 mixte. Pour réaliser cette procédure, procédez tel que cela est
spécifié ci-dessous :
1.
Ouvrez le menu Démarrer, puis cliquez sur Exécuter. Dans le menu Exécuter, tapez ldp
2.
Dans la console Ldp, allez dans le menu Connexion, puis sélectionnez Se connecter.
3.
Dans la fenêtre Se connecter, vérifiez que le champ Serveur contient localhost et que le Port est bien
fixé à 3268, puis validez par OK.
4.
Allez dans le menu Connexion, puis sélectionnez Lier. Une fenêtre d’authentification apparaît.
5.
Identifiez vous à l’aide de votre UserID / Password. La fenêtre de droite doit vous spécifier que l’opération a
été réalisée avec succès.
6.
Recherchez la valeur des attributs listés ci-dessous :
 domainFunctionality
 forestFunctionality
 domainControllerFunctionality
Vous venez de réaliser une opération de contrôle des paramètres de fonctionnement d’un domaine
Active Directory à l’aide de la commande LDAP, ldp.

Page 193
Eléments de structure active directory

Pré-requis et objectifs
1. Pré-requis

Connaissances générales du service de résolution DNS.

Connaissances générales sur l’intégration des zones dans Active Directory.

Principes de localisation des services Active Directory.

Connaissances générales sur les principes des annuaires et opérations LDAP.

2. Objectifs

À la fin de ce chapitre, vous serez en mesure de :

Comprendre la structure des services de domaine Active Directory.

Comprendre les notions de classes et attributs d’objets.

Savoir pourquoi et comment créer de nouvelles classes et attributs.

Modifier le schéma à l’aide des outils livrés avec Windows Server 2008.

Comprendre les différentes conventions de nommage.

Introduction
Ce chapitre est un chapitre important. En effet, il présente les éléments fondamentaux des services de
domaine Active Directory. Ces éléments nous serviront ensuite de base pour notre progression dans
l’implémentation, l’administration et la maintenance des services Active Directory de Windows Server
2008. Bien entendu, les services de domaine Active Directory sont un élément incontournable de la
stratégie système de Microsoft.
Mais avant d’aller plus loin, peut-être pouvons-nous faire un "premier bilan" de ce qui s’est passé ces
quinze dernières années.
À la fin des années 80, IBM et Microsoft définissent une stratégie commune concernant les prochaines
générations de plates-formes systèmes et applicatives. Selon IBM et Microsoft, il était dit à cette époque
"Le futur sera OS/2 !"
Les premières versions sont bâties autour d’un noyau multitâche préemptif, mais les points les plus
remarquables sont que le système d’exploitation n’est pourvu d’aucun service ni protocole réseau et que
la quasi-totalité du système est écrite en Assembleur et en C. Après de multiples accords avec 3Com qui,
rappelons-le, était à l’origine de 3+Open, Microsoft et IBM ont commencé à développer leurs propres
produits réseau en tant que surcouche d’OS/2 avec Microsoft LAN Manager et IBM LAN Server.
Parallèlement à tout cela, Intel fera partie de la fête et sera la cause de nombreux problèmes de
développement. En effet, au départ, OS/2 est conçu pour exploiter le mode protégé du processeur 286 et
moins d’un an après la sortie de ce processeur, les premiers 386 feront leur apparition.

Page 194
Sur cette base, des applications majeures telles que, par exemple, Microsoft SQL Server ou les "Extended
Services" d’IBM ont émergé. S’il est vrai qu’elles se sont lentement mais sûrement implémentées dans les
administrations et grandes entreprises, il n’en demeure pas moins qu’elles ont fixé les bases de ce qui
allait arriver quelques années plus tard.
À ce moment-là, Novell s’impose à la vitesse de l’éclair et règne en maître incontesté des environnements
réseau PC avec son protocole routable IPX/SPX et ses services de fichiers et d’impressions ultra
performants. Néanmoins, les produits et applications OS/2 demeurent toujours principalement dans le
milieu bancaire. Ce point s’explique par l’absence de Novell Netware en tant que serveur d’applications
client/serveur. La présence d’OS/2 poussera donc Novell à développer un client OS/2 de bonne qualité
pour y intégrer cette plate-forme et en justifiera en partie l’existence !
Parallèlement à tout cela, l’émergence de Windows 3.0 et peu de temps après, l’énorme succès mondial
de Windows 3.1 laissent apparaître la stratégie WOSA de Microsoft - Windows Open Systems
Architecture.
Au cœur de cette stratégie, LAN Manager for NT est présenté comme le futur successeur de MS OS/2 LAN
Manager et finalement Microsoft Windows NT Advanced Server 3.1 sera disponible en septembre 1993. La
séparation entre Microsoft et IBM est alors consommée.
IBM tentera pendant plus de cinq ans de rattraper son retard sur NT en redéveloppant les versions OS/2
V2 et plus tard V3, mais sans y parvenir. Ce sera alors l’occasion pour IBM de pactiser avec son principal
concurrent Novell, et ainsi de promouvoir le fameux Novell Netware en boîtes bleues !
Bien que l’on puisse dire aujourd’hui que la première version de Windows NT n’avait rien à voir avec la
richesse des services dont nous disposons aujourd’hui, il est important de rappeler que Windows Server
2003 et Windows Server 2008 sont bâtis sur le même modèle que la version 3.1 ! C’est d’ailleurs la raison
pour laquelle l’équipe de développement de Windows 2000 avait remercié les architectes de Windows NT
pour avoir construit un modèle qui permette une telle (r)évolution. Les premières démonstrations de la
version NT 3.1 sont pour l’époque époustouflantes. En effet, le rapport prix/services/ performances par
rapport à OS/2 est de l’ordre de 10 ! À titre d’exemple, il était facile de consolider 4 ou 5 serveurs de
bases de données fonctionnant sous OS/2 vers une machine quadri-processeurs Windows NT 3.1
Advanced Server avec 256 Mo de RAM !
Ensuite, au fur et à mesure des évolutions de NT, sa présence dans les entreprises sera de plus en plus
importante. Pendant ce temps, Novell perdra d’énormes parts de marché et se cherchera une stratégie en
rachetant Unix et Wordperfect, en développant UnixWare en successeur de NetWare et, faute de
crédibilité, en revendant le tout quelques années plus tard...
Ce choix, porté vers un noyau Unix, était cependant un bon choix pour centrer NT et Windows Server. Il
suffit, pour s’en convaincre, de constater qu’aujourd’hui l’offre de Novell est basée sur un noyau de type
LINUX Suse.
Depuis 1996, les domaines NT, puis dès 2000, les domaines Active Directory sont grandement présents
dans les entreprises de toutes tailles ! Pensez que des entreprises telles que Siemens ont étudié lors du
programme bêta de NT 5.0 (alias Windows 2000) pendant plus de deux ans la possibilité d’implémenter
l’Active Directory. Aujourd’hui, Siemens dispose d’une architecture de services distribués mondiale basée
sur Active Directory et y intègre plus de 400.000 ordinateurs. De plus, on constate pour la première fois
qu’il est possible de faire baisser le coût total de possession (TCO, Total Cost of Ownership) et en même
temps, d’atteindre une qualité de services largement supérieure à ce que l’on connaissait auparavant.

L’annuaire Active Directory s’inscrit dans la stratégie DSI (Microsoft Dynamic Systems Initiative) laquelle
permet aux responsables informatiques et décideurs de se tenir informés sur la stratégie produits et
partenaires de Microsoft. L’objectif de cette stratégie globale est d’obtenir une diminution de la complexité
des solutions à toutes les phases du cycle de vie du système d’information. Pour en savoir plus, connectez-
vous sur : http://www.microsoft.com/windowsserversystem/dsi/default.mspx.
Bien malin celui qui aurait pu prédire un tel succès lors de la sortie officielle de Windows NT 3.1 ! Mais le
fait est que les grands axes de développement étaient déjà tracés et que les perspectives d’évolution
étaient grandes... Cqfd. Les personnes qui ont assisté courant 1992 aux "Windows NT Inside Tracks" ont
pu découvrir le potentiel de la plate-forme.
Aujourd’hui, l’annuaire Active Directory est au centre des infrastructures distribuées Microsoft. Il s’appuie
sur les services intégrés de Windows pour former un ensemble cohérent, robuste, et surtout évolutif.
Cette introduction nous a permis de constater qu’il ne suffit pas d’être le premier à être arrivé sur un
marché pour le conserver. Novell régnait en maître et a été le premier à offrir des services d’annuaires
intégrés de base. Pourtant, c’est Windows NT 4.0 qui lui aura fait perdre le plus de parts de marché ! En
effet, les services d’annuaire Active Directory ne seront disponibles que bien plus tard. Signe que la NDS -
Netware Directory Services - de Novell est peut-être arrivée trop tôt. À l’heure où ces lignes sont écrites,
les projets d’annuaires et/ou de consolidation d’annuaires sont au cœur de l’actualité et des
Page 195
préoccupations des responsables informatiques. En relation avec ces projets et solutions, nous
retrouverons notamment la gestion de l’information et des documents ainsi que la mise à disposition de
services de sécurité globaux utilisables à l’intérieur comme à l’extérieur du réseau de l’entreprise.
Ce petit rappel historique nous permet d’entrer - sans transition (!) - dans le vif du sujet, pour étudier les
points suivants : les objets, le schéma et le nommage.
Dans les chapitres suivants, nous poursuivrons notre découverte en étudiant les composants de la
structure logique, puis les composants de la structure physique.

Objets
Les objets des services de domaine Active Directory représentent les éléments fondamentaux qui
composent un réseau Windows dans son ensemble. Ainsi, les utilisateurs, les ordinateurs, les serveurs,
les contrôleurs de domaine, les autorités de certification, les bases de données, les stratégies de groupe
ou encore les sites Active Directory sont des objets de l’annuaire Active Directory. Par définition, un objet
est le résultat de l’instance d’une classe d’objet, cette dernière jouant le rôle de modèle.

Objets de l’annuaire et conformité par rapport aux classes : l’annuaire ne peut créer des objets que s’ils sont
conformes aux classes dont il est pourvu. Par conséquent, tout objet de l’annuaire est obligatoirement une
instance d’une classe d’objet existante. C’est ainsi que si vous souhaitez qu’une application contacte
l’annuaire Active Directory pour y chercher quelles sont les caractéristiques d’un véhicule de société alloué à
l’un des employés de l’entreprise, l’annuaire devra forcément disposer d’une classe représentant les
employés et d’une classe représentant les véhicules de la société.

1. Classes et attributs d’objets

Comme cela est le cas pour tous les systèmes d’annuaire, les classes sont définies dans une structure
déclarative qui décrit précisément chacune des classes et chacun des attributs de ces classes. Cet
élément de définition très important s’appelle le schéma. À ce titre, l’annuaire Active Directory dispose
lui aussi d’un schéma.
Une classe est composée d’un ensemble d’attributs obligatoires et optionnels. C’est ainsi qu’une classe
peut être plus ou moins "riche" en fonction du nombre d’attributs qui lui seront ou non associés.
Notez aussi qu’il n’y a pas de relation directe entre les classes et les attributs. En effet, un attribut est
simplement un élément de caractérisation tandis qu’une classe est composée d’un ensemble déclaré
d’attributs. Par exemple, l’attribut "numéro de téléphone" disponible sur un utilisateur pourrait être
utilisé dans une autre classe que la classe user, laquelle est utilisée pour créer des objets utilisateur.
Les classes contiennent aussi les règles qui les régissent. En fait, l’annuaire doit connaître les relations
possibles existant entre les classes et particulièrement quelles classes peuvent être supérieures à un
objet particulier issu d’une autre classe.

Page 196
Édition du schéma à l’aide de la console de gestion MMC ADSI Edit et de la console de gestion MMC
Schéma Active Directory
La console MMC ci-dessus montre les deux outils que vous pouvez utiliser pour éditer et manipuler le
contenu de l’annuaire. Pour illustrer les relations qui existent entre les classes et les attributs par
rapport aux classes, nous allons regarder en détail les relations déclarées sur la classe
organizationalUnit qui permet l’existence même des objets Unités d’organisation.

Affichage des propriétés de la classe organizationalUnit via ADSI Edit

Page 197
L’écran précédent montre que la classe d’objet organizationalUnit possède un attribut particulièrement
important puisqu’il précise les "classes d’objets supérieures possibles" directement parentes de la classe
organizationalUnit.

Valeurs déclarées pour l’attribut systemPossSuperiors


Ainsi, il est précisé au niveau de la classe organizationalUnit que les objets instanciés à partir de cette
classe peuvent avoir pour parent des objets de type country, domainDNS, organization et aussi
organizationalUnit.
C’est ainsi que dans les tâches d’administration quotidiennes de l’annuaire Active Directory, il nous sera
possible de créer des OU (acronymes de UO pour Unités d’Organisation) à l’intérieur du domaine et
aussi d’autres OU.
Un autre attribut permettra de déclarer les "classes d’objets inférieures possibles".
Par exemple, vous pourrez constater que la classe organizationalUnit dispose d’un nombre important
d’objets enfants possibles. Parmi les plus intéressants, nous pouvons par exemple citer les classes
computer, contact, inetorgPerson, intellimirrorGroup, msCOM-Partition, MSPKI-xxx et user.
La console MMC de gestion du schéma Active Directory permet d’avoir une vision plus opérationnelle et
donc plus efficace des classes et des attributs qui composent le schéma. L’écran suivant montre en effet
plus clairement les relations et la nature des syntaxes utilisées sur les attributs.

Page 198
Affichage des attributs obligatoires et facultatifs sur la classe organizationalUnit
Cet écran montre très clairement qu’un objet de type Unité d’Organisation dispose de nombreux
attributs facultatifs mais surtout de l’attribut obligatoire ou qui permettra de nommer l’objet.

Détails des caractéristiques de l’attribut ou


Finalement, l’attribut obligatoire ou possède de nombreuses caractéristiques.

Page 199
Autoriser cet attribut à apparaître dans le mode d’affichage détaillé : cette option permet
l’affichage des attributs de la classe sélectionnée lors de l’exploration de l’annuaire.
L’attribut est actif : la désactivation vous permet - temporairement - de récupérer l’attribut alors que
la suppression est définitive. Active Directory ne vous autorise pas à supprimer des classes ou des
attributs. Lorsqu’un attribut est désactivé, vous ne pouvez ni l’utiliser dans des définitions de nouvelles
classes, ni l’ajouter à des définitions de classes existantes.
Indexer cet attribut dans Active Directory : cette option vous permet de placer l’attribut sélectionné
dans l’annuaire.
Résolution de noms ANR (Ambiguous Name Resolution) : cette option est utile lors de la
recherche d’attributs qui peuvent ne pas être connus du client. En effet, la résolution de noms ANR est
généralement utilisée lorsque le nom et le prénom sont stockés dans l’annuaire dans un format qui n’est
pas intuitif pour le client. Par exemple, l’annuaire peut comporter le nom complet Dupont, Jean alors
qu’un client recherche peut-être Jean Dupont. Dans un tel cas, ANR renvoie une correspondance.
Répliquer cet attribut dans le catalogue global : cette option vous permet de placer l’attribut
sélectionné dans le catalogue global de réplication à l’intention de tous les contrôleurs de domaine.
L’attribut est copié lors de la duplication de l’utilisateur : cette option s’applique uniquement aux
attributs qui sont des instances de la classe d’utilisateur. Lorsque cette option est activée, elle spécifie
que si un objet utilisateur est dupliqué, alors l’attribut est aussi copié dans la nouvelle instance.
Indexer cet attribut pour des recherches en conteneur dans Active Directory : cette option
précise si l’attribut sélectionné sera indexé pour permettre une recherche en conteneur. Cela vous
permettra de définir une recherche sur un attribut se trouvant dans un conteneur spécifique avec un
gain en performance de recherches notable.
Caractéristiques des classes et attributs des objets LDAP
Du fait que les systèmes d’annuaire reposent sur un standard largement adopté par l’industrie
(protocole LDAP V2 et V3 et nommage X.500), vous retrouverez l’ensemble de ces paramètres sur tous
les serveurs compatibles LDAP du marché. L’écran suivant illustre les paramètres généraux de la classe
Active Directory prenant en charge les objets de type Unités d’Organisation.

Affichage des propriétés de la classe organizationalUnit à l’aide de la console MMC de gestion du


schéma Active Directory

Page 200
Cet écran montre les paramètres essentiels qui caractérisent toute classe et aussi tout attribut au sein
d’un système d’annuaire :
Description : dans ce champ, vous pouvez taper la description de l’attribut. Généralement le nom de
l’attribut est identique à la description.
Nom commun : ce champ déclare le nom de l’objet tel qu’assigné dans le schéma Active Directory. Un
nom d’objet est un attribut de la classe de l’objet.
ID d’objet X.500 : les ID d’objet sont uniques sur l’ensemble des réseaux à travers le monde. Tous les
ID d’objet sont assignés par l’ISO afin d’éviter tout conflit entre des objets définis par des entités
différentes lorsque plusieurs services d’annuaire, tels que Active Directory et la NDS de Novell, sont
regroupés dans un annuaire global.

À propos des ID d’objets X.500 (X.500 OID) : chaque objet du schéma - et aussi chaque attribut - doit
disposer d’un identificateur unique. Vous retrouverez ces concepts d’unicité dans des produits tels que les
services d’annuaires de type X500, l’espace de gestion SNMP ou toute application devant disposer
d’identificateurs globalement uniques. L’espace des OID X.500 est similaire à l’espace utilisé pour référencer
les fonctions d’administration de réseaux utilisées par le protocole SNMP. Cet espace est d’ailleurs, comme
cela est le cas des OID X.500, lui aussi géré par l’ISO. L’exemple suivant décompose l’OID Active Directory
de la classe Builtin Domain dont la valeur est 1.2.840.113556.1.5.4 : 1 pour l’ISO / 2 pour ANSI / 840
pour les USA / 113556 pour Microsoft / 1 pour Active Directory / 5 pour localiser les classes Active Directory
et enfin 4 pour la classe Builtin Domain.
Type de classe : la classe sélectionnée peut être de trois types :

 Classe de type structurel : une classe de type structurel peut être instanciée au sein de
l’annuaire.
 Classe de type abstrait (ou résumé) : une classe de type abstrait fournit une définition de
base pour une classe à partir de laquelle il est possible de constituer des classes structurelles.
 Classe de type auxiliaire : une classe de type auxiliaire permet d’étendre la définition d’une
classe qui est son héritière, mais pas de former une classe proprement dite.

Catégorie : il s’agit du nom de classe utilisé par l’agent LDAP pour Active Directory. Ce nom sera le
véritable nom que les clients LDAP utiliseront pour accéder aux objets issus de cette classe.

2. Création d’un attribut LDAP et valeur du Nom LDAP affiché

Le point précédent nous a permis de décrire les caractéristiques des classes et attributs des objets
LDAP. Vous avez certainement remarqué que lors de l’affichage des paramètres d’une classe ou d’un
attribut, la description, le nom commun et l’ID d’objet X.500 sont présentés.
À l’inverse, lorsque vous déciderez de créer une classe ou un attribut, une fenêtre vous proposera de
déclarer les trois attributs précédemment nommés, plus l’attribut correspondant au Nom LDAP affiché.
Dans l’exemple suivant, l’administrateur du schéma doit créer une classe pour prendre en charge une
nouvelle application.

Page 201
Création d’un nouvel attribut et déclaration du Nom LDAP affiché
Microsoft précise que les outils d’administration et par exemple la console de gestion MMC Schéma
Active Directory affichent comme nom de classe ou d’attribut la valeur de l’attribut Nom LDAP affiché.
De fait, les développeurs et les administrateurs système utilisent cet attribut important pour référencer
des objets à l’aide d’un programme. Le nom LDAP affiché est généralement constitué d’un ou deux mots
combinés. Lorsque la signification de l’élément exige que le nom soit constitué de plusieurs mots, les
mots suivant le premier sont généralement identifiés à l’aide de majuscules.
Par exemple, certificateAuthorityObject, company, dnsNotifySecondaries sont des Noms LDAP affichés
existant par défaut dans l’annuaire.

L’attribut est désigné à l’aide de son Nom LDAP affiché

Page 202
Dans cet exemple, l’attribut dispose des caractéristiques suivantes :
Nom LDAP affiché

tvipaddressmode

bien que ce ne soit pas obligatoire, nous aurions pu nommer le nom LDAP affiché tvIpAddressMode.
Description

tv-ip-address-mode

Nom commun

tv-ip-address-mode

ID d’objet X.500

Valeur générée à l’aide d’OIDGen.

Le nom LDAP affiché est un attribut qui doit être - et est forcément - unique pour chaque objet de
l’annuaire. Vous trouverez plus loin des recommandations concernant les bonnes règles d’appellation des
objets intégrés au schéma.
Obtention des ID d’objets X.500
Concernant la valeur à affecter à l’ID d’objet X.500, vous pourrez utiliser l’outil OID Generator,
OIDGen.exe disponible dans le Kit de Ressources techniques de Windows 2000 Server.
Cet outil permet de générer une paire d’identificateurs uniques de base utilisables dans le cadre de
l’extension du schéma de l’annuaire Active Directory. L’utilisation de cet outil est très simple puisqu’il ne
dispose d’aucun paramètre spécifique. Une fois que vous avez exécuté la commande OIDGen, faites un
copier/coller vers votre application ou le code de votre application.
Les OID générés seront utilisables en tant que point de départ de votre espace d’affectation. Il vous
suffira d’assigner de nouveaux identificateurs au sein de votre espace en y ajoutant un nouvel élément à
la fin de chaque OID généré par OIDGen.
Par exemple, si la racine dédiée aux attributs générée par OIDGen est égale à la valeur ci-dessous :
1.2.840.113556.1.4.7000.233.28688.28684.8.492045.1961603.2011489.1208101
alors, votre premier attribut pourrait par exemple prendre l’ID d’objet X.500 suivant :
1.2.840.113556.1.4.7000.233.28688.28684.8.492045.1961603.2011489.1208101.1

Vous pouvez constater que les OID sont des chaînes de caractères particulièrement longues. Vous pouvez
faciliter le copier/coller à réaliser en configurant les propriétés de la fenêtre CMD (Taille de la fenêtre à 200
et Options d’édition : Mode d’édition rapide et mode insertion).
Respect des règles d’appellation des objets du schéma Active Directory
Pour vous aider à normaliser les conventions d’affectation de noms de schéma, Microsoft suggère
fortement que les extensions de schéma adhèrent à des règles d’appellation génériques, à la fois pour le
nom LDAP affiché et aussi pour le nom commun.
Ainsi, lorsque vous étendrez le schéma, vous devrez savoir comment référencer et nommer les objets
du schéma. Les objets de schéma de classe et d’attribut peuvent être référencés à l’aide de noms
d’objet de schéma lesquels comprennent les attributs listés ci-dessous :
Le nom LDAP affiché : ce nom est utilisé pour référencer les objets. Le nom LDAP affiché est
généralement constitué de deux ou plusieurs mots combinés. Lorsque le nom est constitué de plusieurs
mots, les mots suivant le premier sont identifiés à l’aide de majuscules. Par exemple, le nom LDAP
affiché de la classe "Unité d’Organisation" est uniteOrganization. Le nom LDAP affiché est unique pour
chaque objet.
Le Nom commun : le nom commun est une version claire du nom LDAP affiché. Pour la classe d’objet
"Unité d’Organisation", le nom commun est Organizational-Unit. Ces noms sont forcément uniques au
sein d’un conteneur.

Page 203
L’ID d’objet X.500 : in identificateur d’un objet ou OID est délivré par une autorité officielle telle que
l’ISO ou l’ANSI. Chaque OID doit être unique. Dans le cas des classes et des attributs accueillis comme
des éléments de l’annuaire, il n’est pas nécessaire d’en référer à ces autorités officielles. Vous pourrez
dans ce cas utiliser l’outil OIDGen, vu précédemment.

Logiciels certifiés Microsoft Active Directory : les développeurs qui étendent le schéma de l’annuaire Active
Directory et qui souhaitent obtenir pour une application le logo "Certifiée pour Windows" doivent adhérer à
ces règles d’appellation. Pour obtenir tous les détails et les dernières exigences d’éligibilité au programme
application "Certifiée pour Windows", sur le site de Microsoft, cherchez Programme de certification.

3. Protection des classes et attributs SYSTEM

Certaines classes et certains attributs jouent un rôle au sein même du système d’annuaire. S’il était
possible d’en modifier les caractéristiques ou pire, de les désactiver, l’annuaire pourrait potentiellement
être partiellement, voire totalement corrompu.
C’est pour cette raison que certaines classes ou certains attributs sont qualifiés de classes ou d’attributs
system et qu’à ce titre, ils sont non modifiables.
À l’inverse, l’écran ci-dessous montre qu’il est possible sur une classe ou un attribut particulier, d’activer
ou de désactiver la classe ou l’attribut. La possibilité d’accéder ou non à ce contrôle est toujours
dépendante de la criticité de l’élément.

Exemple de classe pour laquelle la désactivation est autorisée


La section suivante explique les particularités qui concernent ces opérations de modification des
attributs ou des classes d’objets au sein de l’annuaire Active Directory.

4. Désactivation d’une classe ou d’un attribut

Les contrôleurs de domaine exécutant Windows Server 2003 ne permettent pas la destruction des
classes ou des attributs. Toutefois, dans le cas où ces éléments ne sont plus nécessaires ou bien si la
définition d’origine comporte une erreur, alors vous pouvez désactiver tout attribut ou toute classe non
système.
Page 204
Lorsqu’une classe ou un attribut est modifié pour prendre l’état désactivé, il est considéré comme
défunt. Une classe ou un attribut défunt n’est plus disponible à l’utilisation. Cependant, vous aurez
toujours la possibilité de procéder à sa réactivation.
Si le niveau fonctionnel de votre forêt a été augmenté jusqu’au niveau Windows Server 2003, vous
pouvez désactiver une classe ou un attribut, puis la ou le redéfinir à loisir. Par exemple, la syntaxe d’un
attribut donné pourrait devoir être changée. Ce sera le cas si la nature des données à stocker sur cet
attribut change, suite à une modification d’une application.
Comme l’annuaire Active Directory ne permet pas de modifier la syntaxe d’un attribut après qu’il a été
déclaré dans le schéma, la procédure consiste à le désactiver puis à créer un nouvel attribut qui utilise le
même identificateur d’objet et le même nom LDAP affiché, mais cette fois-ci avec la syntaxe d’attribut
souhaitée. Notez que pour redéfinir l’attribut avec le même nom, vous devrez au préalable le renommer.

Important : Les classes et les attributs ajoutés au schéma de base peuvent être désactivés sans augmenter
le niveau fonctionnel de la forêt. Cependant, ils ne peuvent être modifiés que dans les forêts dont le niveau
fonctionnel est Windows Server 2003 ou supérieur.

À propos des modes des domaines et des forêts : les modes des domaines et forêts Active Directory sont
traités dans le chapitre 7 - Composants de la structure logique. Cependant, notez que dans les forêts
Windows 2000, la désactivation d’un attribut ou d’une classe non système ne permet pas pour autant de les
modifier.
Attribut systemFlags : les classes et les attributs de schéma de base ne peuvent pas être désactivés
car le bit 4 de l’attribut systemFlags est défini à la valeur 1. Si vous souhaitiez réaliser la désactivation
d’un attribut ou d’une classe de base, définissez le bit 4 de l’attribut systemFlags à la valeur 0.
Conditions nécessaires pour réactiver une classe
Nous venons de voir plus haut qu’une classe défunte pouvait être réactivée. Toutefois, cette opération
ne sera possible que sous certaines conditions :

 Les attributs référencés dans les propriétés de la classe à réactiver, tels que mustContain,
systemMustContain, mayContain et systemMayContain doivent être eux-mêmes actifs.
 Les classes référencées dans les propriétés de la classe à réactiver, telles que subClassOf,
auxiliaryClass, systemAuxiliaryClass, possSuperiors et systemPossibleSuperiors doivent
également être actives.

En fait, ces deux contraintes sont logiques. Les contraintes issues des attributs référencés dans la classe
doivent être par définition respectées. Avec le même principe, les relations de la classe à réactiver avec
les autres classes référencées doivent être contrôlées. Cette opération de contrôle n’est possible que si
ces classes sont elles-mêmes actives.

Microsoft précise qu’il ne sera pas possible de réactiver une classe défunte si les valeurs des attributs
suivants entrent en conflit avec une classe ou un attribut déjà actif : ldapDisplayName, attributeId,
governsId ou schemaIdGuid.
Conditions nécessaires pour réactiver un attribut
Un attribut défunt pourra, lui aussi, être réactivé. Cependant, comme cela a été montré pour les classes,
un attribut défunt ne peut pas être réactivé si les valeurs des attributs suivants entrent en conflit avec
une classe ou un attribut déjà actif : ldap- DisplayName, attributeId, governsId, schemaIdGuid ou
mapiId.

5. Objets, classes, attributs et intégration des applications

Nous venons de voir que les définitions fixées pour les objets dans le schéma Active Directory
déterminent la syntaxe des valeurs que les attributs pourront finalement supporter. La création des
objets nécessite donc que les valeurs des attributs d’un objet d’une classe particulière soient en
conformité avec les exigences publiées dans le schéma de l’annuaire.
Il en sera de même pour les applications qui devront créer ou modifier des objets dans l’Active
Directory. L’application devra solliciter le schéma pour déterminer quels attributs sont obligatoires et
quels attributs sont facultatifs. Ensuite, l’application devra respecter - toujours grâce au schéma - les
contraintes de structure de données et de syntaxes à respecter pour créer l’objet et ses attributs.

Page 205
Important : Le schéma de l’annuaire Active Directory est maintenu au niveau de la forêt. De cette manière,
tout contrôleur de domaine de tout domaine de la forêt aura la possibilité de potentiellement interpréter tout
type de données. Si ce point n’était pas respecté, un contrôleur de domaine ne disposant pas de la bonne
version du schéma pourrait accueillir des données de nature indéterminée, c’est-à-dire illisibles !

Rappelons qu’un service d’annuaire jouant pleinement son rôle, doit offrir ses services et une cohérence des
informations proposées de manière uniforme en tout point du réseau.

6. Outils d’administration en ligne de commande de Windows Server


2003 et Windows Server 2008

De nouvelles commandes du service d’annuaire Active Directory, pratiques et puissantes, ont été
rajoutées au système d’exploitation Windows Server 2003, par rapport à la version précédente Windows
2000 Server.
Ces commandes permettent de gérer les différentes classes d’objets Active Directory et d’effectuer des
demandes d’informations, des créations, des modifications ou même des suppressions. La liste suivante
décrit succinctement chaque commande et ses fonctionnalités :
Dsadd : ajoute des objets à l’annuaire.
Dsget : affiche les propriétés des objets dans l’annuaire.
Dsmod : modifie des attributs spécifiques d’un objet existant dans l’annuaire.
Dsquery : recherche dans l’annuaire des objets correspondant à un critère de recherche spécifié.
Dsmove : déplace un objet de son emplacement actuel vers un nouvel emplacement parent.
Dsrm : supprime un objet, toute la sous-arborescence d’un objet dans l’annuaire ou les deux.
Windows Server 2008 introduit à son tour de nouvelles commandes dans le système d’exploitation.
dsmgmt : cette commande facilite la gestion des partitions AD LDS, des rôles FSMO, ainsi que le
nettoyage des méta données Active Directory. Notez que cette commande existait aussi dans les
environnements AD AM sur les serveurs fonctionnant sous Windows Server 2003.
dsacls : cette commande était initialement livrée avec les Outils de Support de Windows Server 2003.
Elle est équivalente aux opérations offertes via l’onglet Sécurité disponible sur les objets Active
Directory à l’aide des outils tels que Utilisateurs et Ordinateurs Active Directory.

Pour plus d’informations sur la commande Dsmgmt, recherchez Windows Server 2008 Command Reference
sur le site de Microsoft.
Tous les outils en ligne de commande peuvent être employés sur différents types d’objets dans
l’annuaire. Chaque commande accepte des arguments spécifiques à des objets, vous permet d’entrer un
type d’objet cible comme argument ainsi que l’identité de l’objet cible sur lequel la commande sera
exécutée. L’identité de l’objet cible est spécifiée après le type d’objet, sous la forme d’un nom unique,
c’est-à-dire la valeur de l’attribut du nom unique d’un objet.
Par exemple, pour désactiver le compte d’ordinateur pc-market, tapez la commande ci-dessous :
dsmod computer CN=pc-market-0478,OU=Marketing,
DC=corpnet,DC=Company,DC=com -disabled yes
Exécution de commandes sur le réseau
Toutes ces commandes disposent de paramètres qui vous permettent de spécifier le serveur, le
domaine, le nom d’utilisateur et le mot de passe à utiliser lors de l’exécution d’une commande. Par
exemple, la syntaxe de la commande dsadd computer est spécifiée ci-après.

dsadd computer Nom_unique_de_l’objet


[-samid NomSAM]
[-desc Description]
[-loc Emplacement]
[-memberof Groupe ...]
[(-s Serveur | -d Domaine)]
Page 206
[-u NomUtilisateur]
[-p (Mot_de_passe | *)]
[-q]

Si vous n’entrez pas ces paramètres, l’outil utilise le serveur, le domaine, le nom utilisateur et le mot de
passe locaux.
La commande Dsadd
La commande Dsadd vous permet d’ajouter des types d’objets spécifiques à l’annuaire :
dsadd computer : ajoute un ordinateur à l’annuaire.
dsadd contact : ajoute un contact à l’annuaire.
dsadd group : ajoute un groupe à l’annuaire.
dsadd ou : ajoute une unité d’organisation à l’annuaire.
dsadd user : ajoute un utilisateur à l’annuaire.
dsadd quota : ajoute une spécification de quota à une partition d’annuaire.
dsadd computer : ajoute un ordinateur unique à l’annuaire. Utilisez la syntaxe ci-dessous :

Dsadd computer NUOrdinateur [-samid NomSAM] [-desc Description] [-loc


Emplacement] [-memberof NUGroupe ...] [{-s Serveur | -d Domaine}] [-u
NomUtilisateur] [-p {Mot_de_passe | *}] [-q] [{-uc | -uco | -uci}]

NUOrdinateur : obligatoire. Indique le nom unique de l’ordinateur que vous souhaitez ajouter. Si le nom
unique est omis, il est obtenu à partir de l’entrée standard (stdin).
-samid NomSAM : spécifie d’utiliser le nom SAM comme nom de compte SAM unique pour cet ordinateur
(par exemple, TESTPC2$). Si ce paramètre n’est pas spécifié, un nom de compte SAM est alors dérivé
de la valeur de l’attribut nom commun utilisé dans NUOrdinateur.
-desc : spécifie la description de l’ordinateur.

-loc : spécifie l’emplacement de l’ordinateur.

-memberof NUGroupe ... : spécifie les groupes auxquels vous souhaitez que l’ordinateur appartienne.

{-s Serveur | -d Domaine} : connecte l’ordinateur à un serveur ou un domaine spécifié. Par défaut,
l’ordinateur est connecté au contrôleur de domaine dans le domaine d’ouverture de session.
-u NomUtilisateur : spécifie le nom d’utilisateur employé pour ouvrir une session sur un serveur
distant. Par défaut, -u reprend le nom d’utilisateur qui a servi pour ouvrir une session.
-uc : spécifie un format Unicode pour les entrées ou les sorties provenant ou destinées à un canal (|).

-uco : spécifie un format Unicode pour les sorties destinées à un canal (|) ou un fichier.

-uci : spécifie un format Unicode pour les entrées provenant d’un canal (|) ou d’un fichier.

Autres commandes importantes


Dsmove : permet le déplacement d’un objet unique, au sein d’un domaine, de son emplacement
courant vers un nouvel emplacement. Lorsque le déplacement a lieu dans le même domaine, l’objet est
simplement renommé.
Dsrm : supprime un objet d’un type spécifique ou n’importe quel objet général de l’annuaire.
Dsget : permet d’afficher les propriétés sélectionnées d’un objet spécifique au sein de l’annuaire Active
Directory. Vous pouvez utiliser cette commande vers les objets ordinateurs, contacts, groupes, OU,
serveurs, utilisateurs, sous-réseaux, sites, quotas et partitions.

Pour plus de renseignements sur ces commandes, veuillez vous référer à l’aide en ligne de Windows Server
2008 ou consulter le Kit de Ressources techniques de Windows Server 2003. Vous pouvez aussi rechercher
sur le site de Microsoft, « Windows Server 2008 Command Reference ». Vous y trouverez la description de
toutes les nouvelles commandes incluses avec Windows Server 2008.

Page 207
Schéma
Le schéma Active Directory contient toutes les définitions de tous les objets de l’annuaire. Chaque nouvel
objet d’annuaire créé est validé en fonction des contraintes imposées sur les différents attributs
manipulés avant d’être écrit dans l’annuaire.
Nous avons vu précédemment que les classes et attributs étaient stockés dans le schéma. De fait, le
schéma est essentiellement composé de classes et d’attributs d’objets. Le schéma par défaut contient
plus de 350 classes d’objets et plusieurs milliers d’attributs qui répondront à la plupart des besoins des
entreprises tout en respectant le standard X.500 relatif aux services d’annuaire.
Parce qu’il est par définition extensible, vous pourrez modifier les classes et attributs du schéma pour
l’adapter à vos besoins. Cependant, il est recommandé d’étudier et de valider attentivement chacune des
modifications en n’oubliant jamais que l’extension du schéma aura un impact sur le réseau tout entier et
particulièrement sur les catalogues globaux Active Directory.
Nous parlerons plus loin des recommandations de Microsoft concernant l’extension du schéma et des
effets de bord inhérents à ces opérations.

1. Construction de l’annuaire Active Directory et chargement du schéma


par défaut

Le schéma original est au départ chargé automatiquement lors de l’installation du premier contrôleur de
domaine Active Directory du premier domaine de la forêt.
L’assistant d’installation d’Active Directory - DCPromo.exe, utilisera comme source originale le fichier
Schema.ini ainsi qu’une base préformatée, NTDS.DIT. Comme cela est souvent le cas, ces fichiers
sont situés dans le répertoire %Systemroot%\ System32.

Les fichiers Schema.ini et NTDS.DIT situés dans le répertoire %\Systemroot%\System32 ne sont utilisés
que pendant la phase d’installation d’un contrôleur de domaine. Ils servent de modèles à l’assistant
d’installation d’Active Directory. Ensuite, ils ne seront plus utilisés, si ce n’est pour réinstaller l’annuaire
Active Directory, toujours à l’aide de DCPromo.
La présence du fichier schema.ini est intéressante car elle nous permet d’avoir un accès direct à la
nature des objets qui sont créés au moment même de l’installation du contrôleur de domaine. Ainsi, ce
fichier pourra être utilisé comme référence aux "metadata originales" de l’annuaire Active Directory.
Stockage du schéma et mise en cache
Chaque contrôleur de domaine possède deux copies du schéma. Une version est stockée directement
dans l’Active Directory - dans la partition de schéma - tandis que la version opérationnelle est chargée
en mémoire et est réellement utilisée.
Lorsqu’une modification du schéma est validée, l’opération est d’abord inscrite dans l’annuaire Active
Directory. Ensuite, ces modifications seront automatiquement considérées en mémoire après un délai de
5 minutes correspondant à la valeur du paramètre Schema Cache Update. Le délai par défaut de 5
minutes a pour objet de regrouper l’ensemble des modifications afin d’éviter d’inutiles mises à jour
répétitives vers tous les contrôleurs de domaine de la forêt Active Directory.
Vous aurez aussi la possibilité de recharger la version mise à jour du schéma dans le cache à l’aide de
l’option disponible dans la console de gestion MMC du Schéma Active Directory.
Notez aussi que le délai de 5 minutes aura comme principale conséquence de ne pas considérer tout de
suite les modifications apportées au schéma. Une application pourrait donc ne pas "voir" une
information nécessaire à son bon fonctionnement et connaître ainsi un problème lors de son premier
démarrage.
S’il est vrai que dans le cas présent vous utiliserez alors l’option Recharger le schéma disponible dans
la console de gestion Schéma Active Directory, il est recommandé d’utiliser cette option avec
modération. En effet, Microsoft préconise de ne réaliser cette action que lorsque toutes les modifications
ont été réalisées.
De cette façon, le contrôleur ne subira qu’un seul et unique rechargement du schéma en mémoire.

Page 208
Rechargement manuel du schéma à l’aide de la console MMC de gestion du Schéma Active Directory
Il est important de noter que la mise à niveau de schéma générera une réplication urgente sur
l’ensemble des contrôleurs de domaine de la forêt. L’opération de mise à jour aura donc une certaine
incidence en terme de communications réseaux intersites.
Dans la mesure où plusieurs séries de modifications du schéma peuvent avoir lieu, il pourra y avoir en
mémoire plusieurs versions différentes du schéma. En fait, il est précisé qu’une version particulière du
schéma n’est libérée et retirée du cache qu’à la condition qu’aucune application ne soit connectée sur le
dit schéma.
Dans l’absolu, le schéma est un ensemble de données dont la taille est inférieure à 200 ko. Si l’on
considère 10 séries de modifications par jour pendant 10 jours, nous obtiendrons une consommation
mémoire sur les contrôleurs de domaine de l’ordre de 20 Mo, ce qui n’a rien d’alarmant. Cependant,
notez que même si cela n’est pas obligatoire, Microsoft recommande de redémarrer les contrôleurs de
domaine.
Vous devrez aussi considérer les points suivants :
Par définition, le schéma de l’annuaire est stocké dans l’Active Directory au sein de la partition de
schéma. Cette partition, donc le schéma, est disponible sur tous les contrôleurs de domaines de tous les
domaines de la forêt. Une partition de l’annuaire est une unité de réplication contenue dans la base de
données de l’annuaire.
Le fichier de base de données de l’annuaire, nommé \%Systemroot%\Ntds\Ntds.dit, contient la partition
de schéma ainsi que toutes les autres partitions qui concernent le contrôleur.
Le schéma qui suit illustre le découpage de la base de données de l’annuaire Active Directory
(NTDS.DIT) en partitions. Le point d’entrée principal est bien sûr le domaine racine de la forêt, lequel
connaît la structure complète grâce à la partition de configuration. Enfin, l’annuaire peut déterminer
l’emplacement puis accéder à la partition de schéma.

Page 209
Vision de la structure des partitions d’une forêt Active Directory
Par définition aussi, un seul contrôleur de domaine au sein de la forêt aura le contrôle exclusif du
schéma et pourra ainsi en contrôler le contenu et la structure. Le contrôleur de domaine jouant ce rôle
est appelé Contrôleur ou Maître de schéma.

La gestion des rôles de maîtres d’opérations (FSMO) est traitée plus loin.

2. Protection du schéma

Comme tous les objets de l’annuaire Active Directory, les objets du schéma sont protégés contre les
utilisations non autorisées par des listes de contrôle d’accès (ACL). Par défaut, seuls les membres du
groupe Administrateurs du schéma ont un accès en écriture sur le schéma. Par conséquent, pour
être en mesure d’étendre le schéma, vous devez être membre de ce groupe. Par défaut, le seul membre
du groupe Administrateurs du schéma est le compte administrateur du domaine racine de la forêt. Il
est bien sûr recommandé de restreindre l’appartenance à ce groupe. En effet, une modification
incorrecte du schéma peut avoir des conséquences sur l’ensemble de la forêt Active Directory et/ou des
applications qui en dépendent.
L’écran ci-après montre que le groupe des Administrateurs du schéma est un groupe universel. En
fait, il ne s’agit pas de la valeur par défaut. Effectivement, à l’issue de l’installation d’un domaine Active
Directory, le domaine fonctionne en mode mixte. Lorsque le domaine Active Directory fonctionne dans
ce mode, alors il s’agit d’un groupe global de sécurité. Une fois que vous aurez rehaussé le niveau
fonctionnel du domaine au niveau Windows Server 2003 ou supérieur, alors le groupe global de sécurité
sera automatiquement converti en groupe universel de sécurité.

Page 210
En mode natif, le groupe Administrateurs du schéma est un groupe universel
Lorsque le domaine fonctionne en mode natif Windows 2000 ou en mode Windows Server 2003 ou
Windows Server 2008, vous pouvez profiter de nouvelles fonctionnalités que nous détaillerons dans leur
ensemble plus loin. Dans le cas présent, il s’agira du support des groupes de sécurité universels. Ces
groupes sont intéressants dans la mesure où ils peuvent contenir des comptes locaux, des groupes
globaux et des groupes universels provenant de n’importe quel domaine de la forêt.

L’écran précédent montre qu’il n’est pas possible de changer l’étendue du groupe de sécurité
Administrateurs de schéma.
Par contre, lorsque le niveau fonctionnel du domaine est Windows 2000 en mode mixte, les groupes de
sécurité universels ne sont pas disponibles. Par conséquent, il n’est pas possible de tirer parti de ces
avantages.

Attention : L’appartenance à un groupe d’étendue universelle ne doit pas être modifiée fréquemment. En
effet, toute modification apportée à ces appartenances de groupe provoque la réplication de toute
l’appartenance du groupe sur chaque catalogue global de la forêt.

La réplication de l’annuaire Active Directory et les relations et impacts sur les groupes et les contrôleurs de
domaine catalogues globaux sont traités au chapitre Composants de la structure physique.
En résumé...

 Les extensions réalisées dans le schéma sont globales : lorsque vous étendez le schéma,
l’opération concerne la forêt toute entière parce que tous les changements à transmettre
doivent l’être vers tous les contrôleurs de tous les domaines de la forêt.
 Les classes à caractère System ne peuvent pas être modifiées : il est impossible de modifier
les classes System par défaut utilisées par l’Active Directory. Cependant, les applications qui
sont utilisées pour modifier le schéma peuvent ajouter leurs propres classes System que vous
pourrez ensuite modifier.
 Les extensions réalisées dans le schéma peuvent être modifiées ou annulées mais pas
supprimées. Par exemple, lorsqu’un attribut est ajouté au schéma, nous avons vu qu’il était

Page 211
possible de le désactiver, mais pas de le supprimer. Cependant, il est possible de réutiliser le
nom LDAP affiché ou l’OID et ainsi d’être capable d’annuler une déclaration.

Pour plus d’informations sur le schéma, cherchez "Schéma Active Directory" sur le site Web des Kits de
ressources techniques de Microsoft à l’adresse : http://www.microsoft.com/reskit ou
http://msdn.microsoft.com/

Conventions de nommage
Tout service d’annuaire doit supporter une ou plusieurs conventions de nommage pour gérer et localiser
les objets qu’il prend en charge. Ainsi, grâce à ces conventions, chaque objet de l’annuaire disposera de
son propre nom dans un ou plusieurs espaces de nommage.
Comme chaque objet des services de domaine Active Directory est une instance d’une classe définie dans
le schéma, cette classe possédera obligatoirement des attributs dédiés à la prise en charge de chaque
espace de nommage.
Les espaces de nommage supportés par les services d’annuaire Active Directory sont :

 Le support total des normes LDAP pour les noms des objets de l’annuaire.
 L’identification unique de chaque objet en fonction de la classe dont il dépend dans le moteur de
stockage de l’annuaire.
 Le support des identificateurs de sécurité existant sous Windows NT.

Pour plus d’informations sur les spécificités du protocole LDAP, connectez-vous sur http://www.rfc-editor.org
et faites une recherche sur les RFC suivants : RFC 1779 - A String Representation of DN, RFC 2247 - Using
Domains in LDAP/X.500 Distinguished Names, RFC 2251 - LDAP v3.

1. Le nom unique relatif (RDN - Relative Distinguished Name)

Le nom unique relatif LDAP identifie l’objet de façon unique par rapport à son conteneur. Par exemple, le
nom unique relatif LDAP (RDN) d’un utilisateur s’appelant Bob Durand pourrait être CN=Bob Durand.
Bien entendu, les noms uniques relatifs doivent être uniques puisque chaque utilisateur doit disposer de
son propre nom au sein d’un même conteneur, comme cela serait le cas dans une unité d’organisation.

2. Le nom unique (DN - Distinguished Name)

Le nom unique LDAP identifie l’objet de façon unique par rapport au point d’entrée de l’annuaire. Pour y
parvenir, le RFC 1779 nommé A string Representation of DN définit les éléments utilisés pour les DN
par l’Active Directory :
DC

Composant de nom de domaine.

OU

Nom de l’unité d’organisation.

CN

Nom commun.

Par exemple, le nom unique d’un utilisateur s’appelant Bob Durand dans l’unité d’organisation DRH dans
le domaine eu.rootcorp.corporate.net sera CN=Bob Durand, OU=DRH, DC=eu, DC=rootcorp,
DC=corporate, DC=net. Comme pour le RDN, le DN est forcément unique au niveau du domaine.

Page 212
Illustration du DN d’un objet ordinateur
La figure ci-dessus illustre le cas d’un ordinateur situé dans l’OU Postes sécurisés du domaine
eu.rootcorp.corporate.net.

3. Le nom canonique

Nous venons de voir que chaque objet de l’annuaire Active Directory peut être référencé par plusieurs
noms. Pour chaque objet, Active Directory crée un nom unique relatif et un nom canonique, tel que
l’illustre l’écran suivant.

Page 213
Par défaut, les onglets Objet et Sécurité ne sont pas affichés. Pour les afficher, activez le mode
Fonctionnalités avancées en cliquant avec le bouton droit de la souris sur le domaine puis en cliquant sur
Affichage - Fonctionnalités avancées.
En suivant le chemin depuis le point d’entrée de l’annuaire jusqu’au conteneur de l’objet, tous les objets
seront aussi référencés par leur nom unique en fonction de leur nom unique relatif (RDN) et de tous les
objets conteneur à traverser.
De cette manière, le nom canonique se construit de la même façon que le nom unique mais utilise une
notation simplifiée. Ainsi, le nom canonique de l’utilisateur Bob Durand sera
eu.rootcorp.corporate.net/DRH/Bob Durand.
Généralement, les outils de maintenance et de support de l’Active Directory manipulent des noms
respectant la symbolique LDAP, c’est-à-dire l’usage du DN des objets. Cependant, il est évident que le
nom canonique de l’objet, tel qu’il est présenté sur l’écran précédent, montre clairement l’objet et son
emplacement. En conclusion, l’idée ne consiste pas à choisir entre les noms LDAP respectant le RFC
1779 ou les noms canoniques mais simplement à proposer, en plus, une notation plus lisible.

4. Le GUID de l’objet (Globally Unique Identifier)

Un GUID est une valeur hexadécimale sur 128 bits (ou 16 octets) dont l’unicité est garantie au sein de
toute l’entreprise. Cette valeur est générée à partir de l’identificateur unique d’un élément, de la date,
de l’heure en cours, et d’une séquence de chiffres générée aléatoirement.
Par définition, les GUIDs ne changent jamais et sont générés et associés à un objet au moment de la
création de l’objet. Ainsi, lorsqu’une demande de création d’objet est reçue par un contrôleur de
domaine, le DSA (Directory Service Agent) du contrôleur de domaine crée l’objet en regardant tous les
attributs obligatoires. Parmi ceux-ci, il trouvera l’attribut GUID et invoquera les routines nécessaires
pour créer la valeur.

Page 214
Dans la mesure où sous Windows tout n’est qu’objet et où par définition tout objet est et doit être
unique, tout objet disposera de son propre GUID. De plus, celui-ci ne changera pas même si l’objet
devait, dans le futur, être renommé ou déplacé. Exemples d’objets disposant de GUID : un utilisateur,
un groupe, un ordinateur, un contrôleur de domaine, un domaine, une base de données Active
Directory, une partition COM +, une relation d’approbation interdomaines, un lien intersites, une
connexion Active Directory, une carte réseau, un package MSI, une application, une partition de disque,
etc.

5. Le SID de l’objet

Lorsqu’il est nécessaire de réaliser des contrôles d’accès, le système de sécurité de Windows doit
contrôler les droits accordés à des entités de sécurité. Les objets devant être impliqués en tant
qu’entités de sécurité sont des objets Active Directory auxquels sont attribués des ID de sécurité
appelés SID.
Les SID existent depuis la toute première version de Windows NT et existent encore aujourd’hui de la
même façon sur un ordinateur Windows 2000, Windows XP ou dans le cadre d’un domaine Active
Directory. Ces ID de sécurité peuvent être utilisés pour réaliser une ouverture de session locale via la
SAM locale - Security Account Manager (Gestionnaire de comptes de sécurité), et bien entendu pour
ouvrir des sessions vers le domaine Windows NT ou Active Directory. Sur la base de cette
authentification réussie, ces SID peuvent aussi avoir l’autorisation d’accéder à des ressources locales à
la machine ou dispersées au sein du domaine. Les administrateurs auront la charge de gérer les noms
des comptes d’utilisateurs, des comptes de groupes et des comptes d’ordinateurs de manière unique au
sein d’un domaine.
Ce dernier point signifie donc que trois classes d’objets Active Directory peuvent être placées dans des
ACL (listes de contrôles d’accès), à savoir les objets dérivés de la classe User, de la classe Computer et
de la classe Group. Finalement, ces objets sont communément appelés des security principals.
Par définition, tout security principal dispose donc d’un identificateur unique appelé SID Security
Identifier Descriptor. Le SID est finalement composé de deux parties : le SID issu du security
principal du domaine lui-même et un suffixe unique appelé identificateur relatif ou, en anglais,
Relative ID ou RID. Par définition, les RID commencent à partir de la valeur décimale 1000.
Ainsi, le premier utilisateur créé après le domaine recevra le RID 1000, puis le suivant 1001 et ainsi de
suite. Finalement, la combinaison du SID du domaine et du RID forme le SID de l’objet, lequel sera une
valeur unique à l’intérieur du domaine et de la forêt.
Les noms de ces objets de sécurité peuvent contenir tous les caractères Unicode, sauf les caractères
LDAP spéciaux définis dans le RFC 2253, à savoir les espaces à gauche, les espaces à droite et les
caractères suivants : # , + " \ < > ;
De plus, les noms d’entités de sécurité "utilisateurs et ordinateurs" doivent respecter les considérations
suivantes :
Comptes d’utilisateur : les ordinateurs exécutant Windows Server 2008, Windows Server 2003,
Windows Vista, Windows XP Professionnel et Windows 2000 Professionnel peuvent utiliser un nom
principal d’utilisateur tel que BDurand@eu.rootcorp.corporate.net (UPN - User principal name) pour un
compte d’utilisateur. Les ordinateurs exécutant Windows NT 4.0 ou une version antérieure sont limités à
20 caractères et utilisent la syntaxe EU\BDurand. L’écran suivant montre aussi que les noms d’ouverture
de session de Windows 2000 sont uniques au domaine et que les noms d’ouverture de session de
Windows Server 2003 sont uniques à la forêt.

Les "logon names" de Windows Server 2003 nécessitent d’être uniques au sein de l’entreprise,
c’est-à-dire de la forêt Active Directory
Comptes d’ordinateur NetBIOS : 15 caractères ou 15 octets.
Compte d’ordinateur DNS : 63 caractères pour un Nom de domaine complet (FQDN, Fully Qualified
Domain Name). Un compte d’ordinateur ne peut pas être entièrement composé de chiffres, de points (.)
ou d’espaces. De plus, les points à droite sont tronqués.
Page 215
Compte de groupe : 63 caractères ou 63 octets. Un compte de groupe ne peut pas être entièrement
composé de chiffres, de points (.) ou d’espaces. De plus, les points placés à droite seront tronqués.

La création d’un objet ayant comme attribut obligatoire le SID, générera automatiquement un identificateur
universel unique (GUID) utilisé pour reconnaître l’entité de sécurité (SID). Active Directory créera aussi un
nom unique relatif LDAP basé sur le nom de l’entité de sécurité. Un nom unique LDAP et un nom canonique
sont ensuite générés à partir du nom unique relatif et aussi des noms des domaines et du conteneur où
l’objet entité de sécurité est créé.

Si votre organisation comporte plusieurs domaines, vous avez la possibilité d’utiliser le même nom
d’utilisateur ou le même nom d’ordinateur dans des domaines différents.

L’ID de sécurité, l’identificateur universel unique (GUID), le nom unique LDAP et le nom canonique générés
par Active Directory identifieront uniquement chaque utilisateur, ordinateur ou groupe dans la forêt. Si
l’objet entité de sécurité est renommé ou déplacé vers un autre domaine, l’ID de sécurité, le nom unique
relatif LDAP, le nom unique LDAP et le nom canonique Active Directory seront modifiés. En revanche,
l’identificateur universel unique généré par Active Directory restera inchangé.
Utilisation de la commande Getsid.exe (Get Security ID)
Cet outil pourra s’avérer très utile pour vérifier un éventuel "conflit de SID". La commande permet ainsi
de comparer les SID d’un compte sur deux contrôleurs de domaine distincts. Si tel était le cas, il est
probable que l’objet, voire la base de données Active Directory ou SAM sont corrompus.
La commande GetSID s’utilise de la manière suivante : getsid \\Serveur1 CompteX \\Serveur2 CompteX
Les paramètres sont décrits ci-dessous :
\\ServeurN : noms des deux serveurs contenant le compte à vérifier. Vous pouvez utiliser un nom
NetBIOS ou le FQDN du serveur.
CompteX : spécifie le ou les noms des deux comptes d’utilisateur ou de groupe à contrôler. Si les noms
possèdent des espaces, mettez des caractères guillemets.
Exemples :
getsid \\srv1 administrateur \\srv2 administrateur
getsid \\srv1 "Admins du domaine" \\srv2 "Admins du domaine"
Contrôle des SID des comptes d’ordinateurs ou de contrôleurs
La commande GetSID permet aussi le contrôle des SID des ordinateurs. En effet, vous pouvez aussi
spécifier le caractère $ derrière le nom de l’ordinateur. Ainsi, pour vérifier le SID de l’ordinateur
booster2003, utilisez la commande : getsid \\srv1 booster2003$ \\srv2 booster2003$

La commande GetSID est disponible dans les Outils de supports livrés avec le CD-Rom de Windows
Server 2003. Notez cependant que d’autres outils pourront être utiles pour auditer et solutionner les
problèmes de sécurité et de contrôle d’accès :
Acldiag : outil de diagnostic des ACLs.
Clonepr : fonction de clonage des SID.
Dsastat : comparaison des partitions entre contrôleurs de domaine et catalogues globaux.
Sdcheck : liste et contrôle des ACLs des objets Active Directory.
SIDWalker Security Administration Tools : ensemble d’outils qui permettent d’auditer, de mapper
et de convertir les droits sur les fichiers NTFS, les imprimantes et les partages réseau.
Xacls : permet d’afficher et de modifier les ACLS des fichiers et répertoires NTFS.

Pour plus d’informations sur les SIDs, descripteurs de sécurité et les technologies de contrôles d’accès de
Windows Server 2008 et Windows Server 2003, consultez les Windows Server 2008 et Windows Server 2003
Technical Reference, sur le site de Microsoft.

Validation des acquis : questions/réponses


Page 216
1. Questions

Si l’état de vos connaissances sur ce chapitre vous semble suffisant, répondez aux questions ci-après.
1 Dans les systèmes d’annuaires, qu’appelle-t-on une classe d’objet ?
2 Qu’est-ce qu’un objet ?
3 Quel outil permet d’afficher l’ensemble des classes et attributs de l’annuaire LDAP Active Directory ?
4 Quel est le rôle de l’attribut systemPossSuperiors ?
5 Comment pouvez-vous préciser qu’un attribut de l’annuaire Active Directory doit être enregistré et indexé
au sein des catalogues globaux ?
6 Que veut-on dire par respect des syntaxes au sein d’un système d’annuaire ?
7 Quel est le rôle des OID ?
8 Quel outil Microsoft pouvez-vous utiliser pour générer automatiquement un OID valide utilisable au sein de
l’espace LDAP de votre forêt Active Directory ?
9 Est-il possible dans une forêt Windows 2000 de désactiver une classe ou un attribut ?
10 Est-il possible dans une forêt fonctionnant dans le niveau fonctionnel Windows Server 2003 ou Windows
Server 2008 de désactiver une classe ou un attribut ?
11 De quels privilèges devez-vous disposer pour être autorisé à modifier le schéma ?
12 Quel est le rôle du DN ?
13 Qu’appelle-t-on nom canonique Active Directory ?

2. Résultats

Référez-vous aux pages suivantes pour contrôler vos réponses. Pour chacune de vos bonnes réponses,
comptez un point.
Nombre de points /13
Pour ce chapitre, votre score minimum doit être de 10 sur 13.

3. Réponses

1 Dans les systèmes d’annuaires, qu’appelle-t-on une classe d’objet ?

Une classe d’objet est un ensemble d’attributs qui représente un type particulier d’objet stocké dans
l’annuaire. Par exemple, il peut s’agir des utilisateurs, des sites, des banques de boîtes aux lettres
Exchange...

2 Qu’est-ce qu’un objet ?

Par définition, un objet est le résultat de l’instance d’une classe d’objet, cette dernière jouant le rôle de
modèle.

3 Quel outil permet d’afficher l’ensemble des classes et attributs de l’annuaire LDAP Active Directory ?

La console de gestion MMC du schéma et l’outil ADSI Edit livré avec les Outils de support de Windows Server
2003. Sur un serveur Windows Server 2008 vous pouvez directement utiliser l’éditeur Modification ADSI
(ADSI Edit).

4 Quel est le rôle de l’attribut systemPossSuperiors ?

Il déclare au sein du schéma les relations possibles entre une classe enfant et ses éventuels parents.

5 Comment pouvez-vous préciser qu’un attribut de l’annuaire Active Directory doit être enregistré et indexé
au sein des catalogues globaux ?

Page 217
À l’aide de la console de gestion MMC Schéma Active Directory, il faut modifier les propriétés de l’attribut et
valider.

6 Que veut-on dire par respect des syntaxes au sein d’un système d’annuaire ?

Le schéma contient le déclaratif de tous les objets et attributs d’objets. Les attributs d’objets permettent de
préciser la nature des données (ASCII, binaires...) ainsi que les contraintes à respecter en termes de
longueurs minimales et maximales.

7 Quel est le rôle des OID ?

Chaque objet du schéma - et aussi chaque attribut - doit disposer d’un identificateur unique. Il s’agit d’une
valeur qui identifie une classe d’objet ou un attribut. Les identificateurs d’objets (OID, Object Identifier) sont
organisés selon une hiérarchie globale gérée par l’ISO.

8 Quel outil Microsoft pouvez-vous utiliser pour générer automatiquement un OID valide utilisable au sein de
l’espace LDAP de votre forêt Active Directory ?

Utilisez l’outil OIDgen.exe.

9 Est-il possible dans une forêt Windows 2000 de désactiver une classe ou un attribut ?

Oui. Cette opération est possible mais vous ne pouvez pas réutiliser le même OID de classe ou d’attribut.
Cette opération n’est valable que sur certaines classes ou attributs.

10 Est-il possible dans une forêt fonctionnant dans le niveau fonctionnel Windows Server 2003 ou Windows
Server 2008 de désactiver une classe ou un attribut ?

Oui. Cette opération est possible. Cependant comme le niveau fonctionnel de la forêt est Windows Server
2003, vous pouvez aussi réutiliser le même OID de classe ou d’attribut sur une nouvelle classe ou un nouvel
attribut.

11 De quels privilèges devez-vous disposer pour être autorisé à modifier le schéma ?

Vous devez être membre du groupe Administrateurs du schéma dans Active Directory.

12 Quel est le rôle du DN ?

Le Distinguished Name signifie nom unique. Il définit le nom unique d’un objet à l’aide du nom unique relatif
de l’objet, plus les noms des objets conteneur et les domaines qui contiennent l’objet. Par exemple,
CN=Bob,CN=Users,DC=company,DC=com est le nom unique de l’objet utilisateur Bob au sein du domaine
Active Directory company.com., dans le conteneur Users, le conteneur Users appartenant à la classe
Conteneur et non Unité d’organisation.

13 Qu’appelle-t-on nom canonique Active Directory ?

Le nom canonique se présente sous la forme company.com/users/Bob. Il s’agit d’un nom dont la syntaxe est
simplifiée en prenant pour base le DN de l’objet, sans les balises LDAP.

Travaux pratiques
1. Rechargement du schéma

La procédure ci-dessous vous permettra procéder à l’opération de rechargement du schéma Active


Directory.

Pour exécuter cette procédure, vous devez être membre du groupe Admins du domaine (dans le domaine
racine de la forêt), du groupe Administrateurs du schéma ou du groupe Administrateurs de
l’entreprise de Active Directory, ou bien disposer de l’autorisation appropriée.
Page 218
1.
Ouvrez le composant logiciel enfichable Schéma Active Directory.
2.
Dans l’arborescence de la console, cliquez avec le bouton droit sur Schéma Active Directory.
3.
Cliquez sur Recharger le schéma.
4.
Par défaut, le composant Schéma Active Directory n’est pas installé. Pour l’utiliser, tapez la commande :
Regsvr32schmmgmt.DLL puis validez sur OK.

2. Création d’un nouvel attribut

Cette opération a pour objet de présenter la procédure de modification du schéma de l’annuaire dans le
cas de la création d’un nouvel attribut.

Pour effectuer cette procédure, vous devez être membre du groupe Administrateurs du schéma dans
Active Directory ou avoir reçu par délégation les autorisations nécessaires. Le composant logiciel enfichable
Schéma Active Directory doit être connecté au contrôleur de schéma.
1.
Utilisez l’outil Oidgen pour générer un OID valide dans le cadre des classes et attributs utilisés au sein de
l’annuaire Active Directory. Oidgen vous permettra d’obtenir en ligne de commande deux OID de base. Le
premier est réservé aux attributs, tandis que le deuxième le sera pour les classes d’objets de l’annuaire
Active Directory.

L’outil Oidgen est livré avec le Kit de Ressources Technique de Windows 2000 Server.
Ci-dessous, l’usage de la commande Oidgen permet d’obtenir les deux "points de départ" pour ajouter
des classes et des attributs au sein de l’Active Directory.

C:\Documents and Settings\JFAprea.CORP2003o>idgen


Attribute Base OID:
1.2.840.113556.1.4.7000.233.28688.28684.8.320726.640437.386647.1188997
Class BaseFOID: 1.2.840.113556.1.5.7000.111.28688.28684.8.442329.
1601970.1743618.369723

Une fois les deux OIDs obtenus, déclarez l’élément souhaité (classe, attribut ou les deux) en procédant
tel que spécifié ci-dessous :
1.
Ouvrez le composant logiciel enfichable Schéma Active Directory.
2.
Dans l’arborescence de la console, cliquez sur Schéma Active Directory.
3.
Pour ajouter une définition de classe, cliquez avec le bouton droit sur Classes, cliquez sur Créer une
classe puis suivez les instructions.
4.
Pour ajouter une définition d’attribut, cliquez avec le bouton droit sur Attributs, cliquez sur Créer un
attribut puis suivez les instructions.

3. Indexation d’un attribut dans les catalogues globaux Active Directory

Cette opération a pour objet de modifier le schéma de l’annuaire Active Directory pour déclarer que tel
ou tel attribut peut être indexé au sein de l’annuaire Active Directory. Cette technique a pour objectif
d’augmenter les performances du serveur de catalogue global en recherches.

Pour effectuer cette procédure, vous devez être membre du groupe Administrateurs du schéma dans
Active Directory ou avoir reçu par délégation les autorisations nécessaires.
1.

Page 219
Ouvrez la console de gestion Schéma Active Directory.
2.
Dans l’arborescence de la console, cliquez sur Attributs.
3.
Cliquez avec le bouton droit sur l’attribut que vous souhaitez indexer, puis cliquez sur Propriétés.
4.
Cliquez sur Indexer cet attribut dans l’annuaire Active Directory.

L’indexage d’un attribut améliore les performances des requêtes exécutées sur l’attribut.

4. Ajout d’un attribut dans les catalogues globaux Active Directory

Cette opération a pour objet de modifier le schéma de l’annuaire Active Directory pour déclarer que tel
ou tel attribut doit être présent au sein de l’annuaire Active Directory. Cette technique a pour objectif
d’augmenter les performances des recherches sur des attributs particuliers.

Pour effectuer cette procédure, vous devez être membre du groupe Administrateurs du schéma dans
Active Directory ou avoir reçu par délégation les autorisations nécessaires.
Pour ajouter un attribut au catalogue global :
1.
Ouvrez la console de gestion Schéma Active Directory.
2.
Dans l’arborescence de la console, cliquez sur Attributs.
3.
Dans la page de droite, cliquez avec le bouton droit sur l’attribut que vous voulez ajouter au catalogue
global, puis cliquez sur Propriétés.
4.
Activez la case à cocher Répliquer cet attribut dans le catalogue global.

Si le niveau fonctionnel de la forêt n’est pas défini sur Windows Server 2003 ou Windows Server 2008, le fait
d’ajouter un nouvel attribut au catalogue global provoque une synchronisation complète de tous les
contrôleurs de domaine jouant le rôle de catalogue global. En d’autres termes, lorsque vous ajoutez un
nouvel attribut à l’ensemble des attributs du catalogue global, tous les attributs qui faisaient préalablement
partie du catalogue global en plus du nouvel attribut sont immédiatement synchronisés à travers la forêt.

Il est fortement recommandé d’utiliser les groupes globaux ou les groupes universels au lieu des groupes de
domaine locaux lorsqu’il est spécifié des autorisations sur des objets de domaine répliqués vers le catalogue
global.

5. Gestion des comptes utilisateur à l’aide de la console MMC Utilisateurs


et ordinateurs Active Directory

L’objectif de ce TP est de créer un compte utilisateur Active Directory et de renseigner les attributs les
plus significatifs utilisables dans un réseau d’entreprise.
1.
Ouvrez une session avec un compte utilisateur disposant des privilèges vous autorisant la création d’objets
de type utilisateur dans le conteneur où vous souhaiter réaliser l’opération.
2.
Lancez la console de gestion MMC, Utilisateurs et ordinateurs Active Directory.
3.
Cliquez avec le bouton droit sur l’unité d’organisation souhaitée et sélectionnez Nouveau - Utilisateur ou
Nouveau - InetOrgPerson.
4.
Renseignez les informations ci-dessous :
 Prénom : Lana
 Initiale : L

Page 220
 Nom : Lang
 Nom d’ouverture de session : LLang@extranet.corpnet.com
 Nom antérieur à Windows 2000 : Llang
5.
Cliquez sur Suivant et déclarez les paramètres ci-dessous :
 Fixez le mot de passe initial en respectant la stratégie de mot de passe et confirmez le mot de
passe.
 Activez les cases à cocher en fonction de vos besoins et contraintes : L’utilisateur doit changer
de mot de passe : Oui
Le compte est désactivé : Oui
6.
Validez vos sélections en cliquant sur le bouton OK.
Dans un deuxième temps, vous allez spécifier les paramètres ci-dessous :
1.
Double cliquez sur le compte utilisateur précédemment créé.
2.
Dans l’onglet Adresse, déclarez les attributs relatifs à l’adresse de l’utilisateur.
3.
Dans l’onglet Compte, déclarez les attributs relatifs au compte utilisateur tels que ceux spécifiés ci-dessous
:
 Déclarez les horaires des connexions autorisées,
 Déclarez les ordinateurs sur lesquels l’utilisateur est autorisé à ouvrir une session vers le
domaine,
 Enregistrer le mot de passe en cryptant le mot de passe réversible - pour supporter les
authentifications MD5,
 Une carte à puce est nécessaire pour ouvrir une session interactive - pour rendre obligatoire
l’usage d’une carte à puce pour l’authentification vers Active Directory,
 Fixez le délai d’expiration du compte six mois plus tard.
4.
Dans l’onglet Profil, déclarez les attributs relatifs au profil de l’utilisateur tels que ceux spécifiés ci-dessous :
 Déclarez l’emplacement du profil réseau de l’utilisateur, par exemple :
\\company.com\DFSData\Profils\%Username%,
 Déclarez le script d’ouverture de session de l’utilisateur, par exemple, logon.bat. Le script est
situé à l’emplacement du partage NETLOGON dans le Sysvol,
 Déclarez le répertoire de base de l’utilisateur vers un chemin réseau, par exemple, spécifiez la
lettre H: vers \\company.com\DFSData\Users\%Username%,
 Dans l’onglet Téléphones, déclarez les différents numéros de téléphone de l’utilisateur.
5.
Dans l’onglet Organisation, déclarez les différents attributs relatifs à cette catégorie, tels que :
 Le Titre, le Service et la Société de l’utilisateur,
 Son Manager,
 Le numéro de téléphone de l’utilisateur.
6.
Maintenant que vous avez défini l’ensemble des attributs de l’utilisateur, validez votre choix en cliquant sur
OK.

La classe InetorgPerson est dérivée de la classe user mais respecte les dernières RFC relatifs à la classe
InetOrgPerson. Bien que l’usage de cette classe facilite l’interopérabilité avec d’autres systèmes d’annuaires
respectant ces standards, Microsoft ne recommande pas son usage de manière expresse.

6. Gestion des comptes d’ordinateur à l’aide de la console MMC


Utilisateurs et ordinateurs Active Directory

L’objectif de ce TP est de créer un compte d’ordinateur et de renseigner ses attributs les plus significatifs
utilisables dans un réseau d’entreprise.

Page 221
1.
Ouvrez une session avec un compte utilisateur disposant des privilèges vous autorisant à la création d’objets
de type ordinateur dans le conteneur où vous souhaitez réaliser l’opération.
2.
Lancez la console de gestion MMC, Utilisateurs et ordinateurs Active Directory.
3.
Positionnez-vous à l’emplacement souhaité, puis cliquez avec le bouton droit et cliquez sur Nouveau -
Ordinateur. La fenêtre Nouvel objet - Ordinateur apparaît.
4.
Renseignez les champs demandés.
5.
Activez les cases à cocher Attribue ce compte d’ordinateur à un ordinateur antérieur à Windows
2000 ou Attribue ce compte d’ordinateur à un contrôleur de domaine secondaire en fonction des
besoins, puis cliquez sur Suivant.
6.
Sur l’écran Prise en charge, activez la case à cocher Ceci est un ordinateur pris en charge, si vous
prévoyez de faire une réservation utilisée dans le cadre des services d’installation à distance RIS - Remote
Installation Services, puis cliquez sur Suivant.

Cet écran montre une réservation basée sur l’adresse MAC de la carte réseau complétée de 0. En effet, vous
pouvez déclarer soit l’ID unique au format GUID/UUID, soit l’adresse matérielle de la carte réseau. Ces
informations pourront ensuite être utilisées par les services RIS ou une autre application du même type.
7.
Finalement, associez l’ordinateur réservé à un serveur supportant les services RIS, puis cliquez sur Suivant
puis sur Terminer.
Après avoir créé l’objet ordinateur dans l’unité d’organisation souhaitée, il ne reste plus qu’à procéder à
l’intégration de l’ordinateur dans le domaine. Cette opération pourra être réalisée de manière
automatique lors du déploiement d’une image RIS ou manuellement en utilisant les propriétés de l’objet
Poste de travail/Nom de l’ordinateur. Après avoir créé l’objet ordinateur, vous pourrez, dans un
deuxième temps, modifier ou compléter certaines de ses propriétés. L’écran suivant représente
l’ensemble des propriétés disponibles pour un ordinateur de type Windows 2000 ou Windows XP
Professionnel.

Page 222
7. Gestion des comptes de groupe à l’aide de la console Utilisateurs et
ordinateurs Active Directory

L’objectif de ce TP est de gérer les comptes de groupes au sein d’un domaine Active Directory. Dans un
premier temps, vous découvrirez les membres des groupes prédéfinis les plus importants. Ensuite, vous
créerez vos propres groupes et utilisateurs.
Analyse des membres des groupes prédéfinis
1.
Ouvrez une console de gestion MMC, Utilisateurs et ordinateurs Active Directory.
2.
Sélectionnez le conteneur Builtin.
Quels sont les membres par défaut du groupe Administrateur ?
Quels sont les membres par défaut des différents groupes Opérateurs ?
Quels sont les membres par défaut du groupe Invités ?
Quels sont les membres par défaut du groupe Administrateurs de l’entreprise ?
Quels sont les membres par défaut du groupe Admins du domaine ?
Quels sont les membres par défaut du groupe Invités du domaine ?
Concepts concernant les groupes de sécurité dans les environnements Active Directory
Les groupes ont toujours eu pour principal objectif d’organiser et de simplifier les tâches
d’administration ou particulièrement contrôlées. Les domaines Windows 2000 mixtes, Windows 2000
natifs, Windows Server 2003 ou Windows Server 2008 vous permettent de gérer trois grandes étendues
de groupes :

 Les groupes disposant d’une étendue globale sont plutôt utilisés pour regrouper un ensemble
de comptes,
 Les groupes disposant d’une étendue locale sont plutôt utilisés pour attribuer des autorisations
d’accès à des ressources,

Page 223
 Les groupes disposant d’une étendue universelle, disponibles uniquement en mode natif
Windows 2000, en mode Windows Server 2003 ou Windows Server 2008 pour regrouper des
comptes et les groupes globaux à l’échelle de la forêt.

Création d’un groupe


Pour créer un groupe, procédez tel que cela est précisé ci-après :
1.
Positionnez-vous sur le conteneur dans lequel vous souhaitez créer le groupe.
2.
Cliquez avec le bouton droit et choisissez Nouveau - Groupe.
3.
Donnez un nom représentatif du groupe.
4.
Sélectionnez l’étendue du groupe :
 Groupe de domaine local, ou
 Groupe global, ou
 Groupe universel, si le domaine fonctionne en mode Windows 2000 natif ou dans le niveau
fonctionnel Windows Server 2003.
5.
Sélectionnez le type de groupe : Groupe de sécurité ou bien Groupe de distribution.
Ajout d’un membre au sein d’un groupe
1.
Double cliquez sur le groupe à modifier.
2.
Dans l’onglet Membres, cliquez sur le bouton Ajouter.
3.
Sélectionnez les utilisateurs ou ordinateurs qui vous souhaitez ajouter, puis cliquez sur le bouton Ajouter.
4.
Vous pourrez aussi insérer ce groupe dans un autre groupe en utilisant l’onglet Membre de, à la condition
que ce soit le groupe local qui contienne des groupes globaux ou que le domaine fonctionne en mode
Windows 2000 natif dans les niveaux fonctionnels Windows Server 2003 ou Windows Server 2008.

Pour ajouter des membres dans un groupe, vous pouvez aussi sélectionner tous les comptes d’utilisateurs en
réalisant une sélection multiple, cliquer avec le bouton droit et choisir l’option Ajouter des membres à un
groupe.

8. Création d’une stratégie de mot de passe pour un domaine

L’objectif de ce TP est de définir une stratégie de mot de passe sur la base d’un modèle de sécurité
adapté à vos besoins. Une fois créé, le modèle défini sera appliqué aux utilisateurs du domaine.
Ce TP est composé de trois étapes :

 La première permet de définir une nouvelle stratégie de mot de passe en créant une nouveau
modèle de stratégie de sécurité.
 La deuxième permet de définir une stratégie de verrouillage des mots de passe au sein de la
même stratégie de sécurité.
 Finalement, le nouveau modèle sera importé dans une nouvelle stratégie de groupe au niveau
du domaine Active Directory.

Étape 1
1.
Ouvrez le menu Démarrer puis cliquez sur Exécuter.
2.
Tapez MMC, puis chargez le composant enfichable Modèles de sécurité.
3.
Dans la console, faites un clic droit sur le dossier %Systemroot%\Security\Templates, puis choisissez
Nouveau modèle.
Page 224
4.
Dans la fenêtre Nom du modèle, nommez votre nouveau modèle à votre convenance, puis validez par OK.
5.
Développez le modèle et positionnez-vous sur Stratégies de comptes/Stratégie de mot de passe.
6.
Finalement, déclarez les paramètres ci-dessous :
 Longueur minimale du mot de passe : 12 caractères au lieu de 8,
 Conserver l’historique des mots de passe : 30 jours au lieu de 24,
 Durée de vie maximale du mot de passe : 30 jours au lieu de 42,
 Durée de vie minimale du mot de passe : 5 jours au lieu de 2.
La stratégie de mot de passe est désormais définie.
Étape 2
1.
Dans le modèle de sécurité précédemment créé, positionnez-vous sur Stratégie de verrouillage de
comptes et déclarez les paramètres ci-dessous :
 Durée du verrouillage des comptes : 0 jours au lieu de 30. La valeur 0 permet de déclarer que
seul un administrateur du domaine devra déverrouiller le ou les comptes bloqués,
 Seuil de verrouillage du compte : 20 tentatives au lieu de 50,
 Réinitialiser le compteur de verrouillages du compte : 2 minutes au lieu de 30.
2.
Quittez la console de gestion MMC créée précédemment et enregistrez votre modèle.
La stratégie de verrouillage des comptes utilisateur est désormais définie.
Étape 3
1.
À l’aide de la console de gestion MMC Gestion des stratégies de groupe, ajoutez un nouvel objet
stratégie de groupe.
2.
Ouvrez cette nouvelle stratégie de groupe et positionnez-vous sur Configuration ordinateur -
Paramètres Windows - Paramètres de sécurité.
3.
Faites un clic droit sur Paramètres de sécurité et cliquez sur l’option Importer une stratégie.
4.
Sélectionnez la stratégie précédemment définie puis fermez la stratégie de groupe et quittez la console de
gestion des stratégies de groupe.
La stratégie de sécurité est désormais appliquée au niveau du domaine.
Test de la stratégie de sécurité
Finalement, pour tester les paramètres de sécurité que vous venez de spécifier dans votre stratégie de
groupe au niveau du domaine, procédez de la manière suivante :
1.
À l’aide de la console de gestion MMC Sites et services Active Directory, ou des commandes repadmin
ou replmon, forcez une synchronisation des contrôleurs de domaine.
2.
À l’aide de la console de gestion MMC Utilisateurs et ordinateurs Active Directory, créez un nouvel
utilisateur et ne respectez pas les consignes de la stratégie de sécurité. Par exemple, déclarez un mot de
passe d’une longueur inférieure à 12 caractères.
Vous ne devriez pas être capable d’y parvenir.
3.
Une fois le mot de passe défini en respectant cette fois les consignes de la stratégie de mot de passe, ouvrez
une session avec le nouveau compte en entrant plus de 20 mots de passe erronés.
Le compte passera en statut verrouillé.
4.
En tant qu’administrateur du domaine, procédez au déverrouillage du compte verrouillé.
5.

Page 225
Ouvrez une session avec le nouveau compte utilisateur et le bon mot de passe et demandez à changer votre
mot de passe. Vous ne devriez pas être capable d’y parvenir puisque la durée de vie minimale du mot de
passe est fixée à 5 jours.
Vous venez de mettre en œuvre une stratégie de gestion des mots de passe au niveau d’un domaine
Active Directory en préservant la stratégie du domaine par défaut. De plus, les paramètres ont été créés
dans une modèle de sécurité réutilisable à loisir.

Page 226
Composants de la structure logique

Pré-requis et objectifs
1. Pré-requis

Concepts liés aux systèmes d’annuaires LDAP.

Concepts liés aux services de domaine Active Directory.

Éléments de structure Active Directory.

Notions fondamentales sur les objets.

Rôle et modification du schéma.

Notions fondamentales sur les différentes conventions de nommage.

2. Objectifs

À la fin de ce chapitre, vous serez en mesure de :

Comprendre les composants de la structure logique des services de domaine Active Directory.

Comprendre les avantages et contraintes liées aux différents niveaux fonctionnels des domaines.

Comprendre le rôle du contrôleur de domaine Active Directory.

Évaluer les critères de définition d’une hiérarchie d’unités d’organisation.

Comprendre le rôle des arborescences de domaines.

Comprendre le rôle des forêts au sein des infrastructures Active Directory.

Introduction aux composants de la structure logique


L’annuaire Active Directory dépend directement d’éléments techniques qui permettent de disposer d’une
structure globale et bien sûr, des technologies de stockage. La structure logique de l’Active Directory est
composée des domaines et des forêts, lesquels permettent la représentation logique de l’espace de
l’annuaire Active Directory.
Un tel espace logique, on parlera alors de l’infrastructure logique Active Directory, permet aux
administrateurs de faire l’abstraction par rapport à la structure technique, on parlera alors de
l’infrastructure physique Active Directory. Cette séparation permettra une bien meilleure organisation des
éléments qui composent le réseau en fonction de la nature des objets en faisant partie ou pourquoi pas
en fonction de l’organisation de l’entreprise.
Ce chapitre va nous permettre d’explorer l’usage des domaines et des forêts pour que les services
d’annuaire Active Directory puissent jouer le rôle de point central de consolidation. De cette manière,
l’information et les services offerts via l’annuaire Active Directory seront localisables en tout point du
réseau pour les utilisateurs et applications de l’entreprise.
Page 227
Les domaines
Le domaine est un composant fondamental de la structure logique Active Directory. Par définition, il s’agit
d’un ensemble d’ordinateurs qui partagent une base de données d’annuaire commune. Ces ordinateurs
interagiront avec le domaine en fonction de leur rôle respectif, tels que par exemple les contrôleurs de
domaine ou plus simplement les ordinateurs membres dudit domaine.
Le domaine peut être mis en œuvre pour implémenter au sein de l’entreprise une zone d’administration.
De cette manière, il est possible de mettre en place une délégation efficace de l’administration ou de
parvenir à un meilleur contrôle des flux de réplication.
Concernant les infrastructures Active Directory, nous pouvons dire que le critère de choix le plus
fréquemment utilisé, à propos de la création ou non d’un nouveau domaine, concernera la séparation des
flux de réplication entre plusieurs domaines et donc d’un meilleur contrôle des trafics au sein d’une forêt.
Bien qu’une hiérarchie de domaines puisse dans une certaine mesure y parvenir, les unités d’organisation
(OU - Organizational Units) sont particulièrement adaptées pour créer une structure hiérarchique sur la
base de laquelle il sera possible de déléguer tout ou partie des opérations d’administration à des
personnels habilités à prendre en charge telle ou telle tâche spécifique.
En plus de ces considérations de choix, l’objet domaine permet de découper la forêt Active Directory en
autant de partitions qu’il y aura de domaines. C’est ainsi qu’il est dit qu’un domaine est une partition au
sein d’une forêt donnée. Nous pouvons par exemple imaginer une entreprise possédant une forêt, cette
dernière étant elle-même composée de trois domaines, ces derniers prenant en charge des utilisateurs et
ordinateurs situés respectivement au Canada, aux États-Unis et en Europe.
Une telle architecture permet à la forêt d’évoluer facilement au fur et à mesure que ces trois "grands"
domaines deviendront plus volumineux.
Le domaine Active Directory est donc un élément qu’il conviendra de créer à bon escient et, par
conséquent, il faudra toujours être capable d’en justifier la création en se rapportant aux thèmes ou
fonctions spécifiées ci-dessous :

 Un domaine est un container au sein de la forêt.


 Un domaine est une unité de réplication.
 Un domaine est une unité contenant des stratégies de sécurité.
 Un domaine est une zone d’authentification et d’autorisation.
 Un domaine est membre d’une forêt et à ce titre, il possède des relations vers les autres
domaines de la forêt.

Chaque domaine possède sa propre autonomie d’administration et, à ce titre, les membres du groupe
Admins du domaine d’un domaine donné n’ont aucun droit dans le ou les autres domaines de la forêt à
moins, bien sûr, que vous n’ayez fait en sorte qu’il en soit autrement.
La figure ci-après montre que le domaine est membre d’une forêt et qu’il offre ses services
d’authentification et de contrôle des accès aux clients et serveurs membres de celui-ci.

Page 228
Relations entre les membres du domaine Active Directory
Le domaine peut contenir toute machine dont les technologies sont issues de Windows NT, Windows 2000
Server, Windows Server 2003 ou Windows Server 2008.
Par exemple, une tour de lecteurs de CD-Rom accessible via un lien UNC (Universal Naming Convention)
ou encore un serveur LAN Manager for Unix (LMU) ou un serveur Samba sous Linux peuvent faire partie
d’un domaine Active Directory.
Le domaine existe au travers de chacun des contrôleurs de domaine du domaine. Ainsi, chaque contrôleur
de domaine possède sa propre copie et version de la base de données de l’annuaire. Dans le cas où un
contrôleur serait indisponible, les utilisateurs, ordinateurs et services pourront toujours continuer
d’accéder à l’Active Directory en sollicitant un autre contrôleur. Les contrôleurs de domaine participent
donc activement à la disponibilité de l’annuaire et de ses services.
Bien entendu, l’annuaire Active Directory est uniquement installé sur les machines appelées contrôleurs
de domaine fonctionnant sous Windows 2000 Server, Windows Server 2003 ou Windows Server 2008.
Dans la mesure où le domaine sera composé de plus d’un seul contrôleur de domaine, les opérations de
création et de modification des objets et autres attributs d’objets devront être répliquées de manière
uniforme sur l’ensemble des contrôleurs de domaine. Les mécanismes de réplication, indispensables à la
cohérence des informations offertes par l’annuaire, sont aussi fondamentaux pour que l’annuaire lui-
même fonctionne correctement.

1. Conteneur (container) au sein de la forêt

La forêt joue le rôle de container pour accueillir les domaines qui, eux-mêmes jouent le rôle de
container pour de multiples classes d’objets. En d’autres termes, la forêt est l’élément qui fédère ou unit
plusieurs domaines entre eux.
Cela signifie que les objets que sont les domaines s’approuvent mutuellement. Ainsi, tout nouveau
domaine créé dans la forêt générera automatiquement une relation d’approbation bidirectionnelle
transitive entre le nouveau domaine créé et le domaine situé au niveau immédiatement supérieur.
Les relations d’approbation interdomaines permettent aux domaines de prendre en charge les demandes
d’authentification des domaines approuvés. Nous avons vu précédemment que chaque domaine

Page 229
disposait d’une relation d’approbation avec son domaine parent. Comme ces relations interdomaines
sont par nature transitives et bidirectionnelles, il est clair que les objets contenus dans un domaine x de
la forêt peuvent bénéficier d’ACLs (Access Control List) contenant des utilisateurs de tout domaine de la
forêt.

Forêt, domaines, OUs et approbations


Prenons maintenant un exemple concernant le stockage proprement dit des objets de l’annuaire. Les
zones DNS peuvent être considérées comme des objets (objets issus de la classe dnsZone) et qu’à ce
titre, il était possible de les stocker dans l’Active Directory. En fonction des besoins, certaines zones
pourront résider dans un domaine particulier tandis que d’autres le seront au niveau de toute la forêt.
Cet exemple montre à quel point les objets domaine (classe domainDNS) et forêt peuvent contenir des
objets divers et variés tels que des objets unités d’organisation (OU - classe organizationalUnit) ou des
objets utilisateur (classe user ou inetOrgPerson).

Forêt et RootDSE : à propos du point d’entrée... Le support du protocole LDAP version 3.0 permet d’accéder
aux propriétés d’un objet particulier appelé RootDSE. Le RootDSE est défini en tant que racine de l’arbre de
l’annuaire qui est stocké sur un serveur d’annuaire donné. En fait, ce point d’accès n’appartient à aucun
espace de nommage (NC ou domaine Windows) en particulier. Il permet simplement d’obtenir des
informations concernant le serveur d’annuaire proprement dit et ne doit donc pas être confondu avec un
quelconque point d’entrée vers la forêt.

Pour plus d’informations sur l’objet RootDSE, consultez l’aide en ligne du SDK Active Directory disponible à
l’adresse ci-dessous : http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/adschema/adschema/rootdse.asp

2. Niveaux fonctionnels des domaines

Nous allons découvrir qu’un domaine Active Directory peut fonctionner dans différents modes ou
niveaux fonctionnels. La notion de niveau fonctionnel, toute spécifique à un domaine Active Directory,
sera spécifiée à l’aide de l’attribut domainFunctionality.
Cet attribut indique le niveau fonctionnel d’un domaine Active Directory donné :
"0" Domaine Windows 2000 en mode mixte.
"1" Domaine Windows 2000 en mode natif.
"2" Domaine Windows Server 2003.
"3" Domaine Windows Server 2008.

Page 230
Le niveau fonctionnel de domaine permet d’activer certaines fonctionnalités spécifiques au domaine
Active Directory. Tel que vous avez pu le voir avec l’attribut domainFunctionality spécifié plus haut, il
existe quatre niveaux de fonctionnement différents.
Domaine Windows 2000 mixte : ce mode de fonctionnement permet une interopérabilité totale
puisque le domaine pourra contenir indifféremment des contrôleurs de domaine Windows Server 2003,
Windows 2000 Server et/ou Windows NT Server 4.0.
Domaine Windows 2000 natif : ce mode de fonctionnement permet une interopérabilité limitée
puisque le domaine pourra contenir uniquement des contrôleurs de domaine Windows Server 2003 et/ou
Windows 2000 Server.
Domaine Windows Server 2003 version préliminaire (mode spécifique) : ce mode de
fonctionnement permet une interopérabilité limitée puisque le domaine pourra contenir uniquement des
contrôleurs de domaine Windows Server 2003 et/ou Windows NT Server 4.0.
Domaine Windows Server 2003 : ce mode de fonctionnement permet une interopérabilité limitée
puisque le domaine pourra contenir uniquement des contrôleurs de domaine Windows Server 2003 et
versions ultérieures, mais plus aucune version antérieure.

Sous Windows 2000, les niveaux fonctionnels de domaines sont appelés "domaine en mode mixte" ou
"domaine en mode natif".
Domaine Windows Server 2008 : de mode de fonctionnement permet une interopérabilité limitée
puisque le domaine pourra contenir uniquement des contrôleurs de domaine Windows Server 2008 mais
plus aucune version antérieure.
Augmentation des niveaux fonctionnels des domaines
Lorsqu’un serveur Windows Server 2008 est installé en tant que contrôleur de domaine, un ensemble de
fonctionnalités Active Directory sont activées par défaut. Avant de rentrer dans les détails, nous
pouvons déjà préciser que la plus grande partie des nouveautés apportées par les services d’annuaire
Active Directory est disponible indépendamment du niveau fonctionnel du domaine. Cependant, en plus
des fonctionnalités Active Directory de base, vous pourrez le cas échéant profiter de nouvelles
fonctionnalités Active Directory en mettant à niveau les anciens contrôleurs NT vers Windows Server
2003 ou mieux vers Windows Server 2008.
Bien entendu, la démarche à adopter est "impitoyable" !

 Pour atteindre le niveau fonctionnel Windows 2000 mixte, il faudra procéder à la mise à niveau
du domaine NT vers les services de domaine Active Directory.
 Pour atteindre le niveau fonctionnel Windows 2000 natif, il faudra procéder à la mise à niveau
des anciens contrôleurs NT vers Windows 2000 Server, Windows Server 2003, Windows Server
2008 ou les supprimer.
 Pour atteindre le niveau fonctionnel Windows Server 2003, il faudra procéder à la mise à
niveau de tous les contrôleurs vers Windows Server 2003, ou supprimer les contrôleurs de
niveaux inférieurs.

Page 231
Affichage de l’option Augmenter le niveau fonctionnel du domaine
Lorsque tous les contrôleurs de domaine fonctionnent sur la version requise de Windows, alors vous
pourrez décider - en fonction de vos besoins - de rehausser le niveau fonctionnel au niveau
immédiatement supérieur, ou plus, si la technologie le permet.

À propos de l’élévation du niveau fonctionnel : vous remarquerez qu’il ne s’agit pas d’un paramètre qui
concerne un contrôleur de domaine en particulier mais le domaine lui-même dans son intégralité. Il est très
important de noter que cette opération est irréversible et ne pourra donc être annulée en aucune façon, à
moins de procéder à une restauration de l’annuaire Active Directory.

Le mode qui caractérise un domaine n’a d’incidence que pour les contrôleurs dudit domaine. Les serveurs
membres et postes de travail du domaine continuent de fonctionner, mais considèrent les nouvelles
caractéristiques du domaine lorsqu’ils en sont capables. Cela signifie qu’un domaine fonctionnant en niveau
fonctionnel Windows Server 2008, Windows Server 2003 ou Windows 2000 mixte ou natif est aussi vu
comme un simple domaine NT 4.0 par les ordinateurs membres du domaine fonctionnant sous Windows 9x
ou Windows NT.
Dans notre exemple, pour activer les nouvelles fonctionnalités disponibles dans le niveau Windows
Server 2003 à l’échelle du domaine, tous les contrôleurs de domaine du domaine doivent exécuter
Windows Server 2003.
L’écran suivant montre que le domaine Corp2003.Corporate.net est opérationnel au départ dans le
niveau fonctionnel Windows 2000 natif.

Page 232
Sélection du niveau souhaité lorsque les conditions requises sont remplies
Comme tous les contrôleurs du domaine sont des contrôleurs Windows Server 2003, la console de
gestion MMC Utilisateurs et ordinateurs Active Directory autorise les membres du groupe Admins
du domaine ou du groupe Administrateurs de l’entreprise à procéder à l’augmentation du niveau
fonctionnel Windows 2000 natif vers le niveau Windows Server 2003.

Si vous disposez ou prévoyez de disposer de contrôleurs de domaine exécutant Windows NT 4.0 et


antérieure, n’augmentez pas le niveau fonctionnel du domaine vers Windows 2000 natif, Windows Server
2003 ou Windows Server 2008. Une fois que le niveau fonctionnel du domaine rehaussé, il ne peut plus être
modifié pour revenir à un niveau antérieur.

Vous ne pouvez atteindre un niveau fonctionnel donné que si tous les contrôleurs de domaine dudit domaine
fonctionnent avec la version requise de Windows.

Pour plus d’informations sur l’augmentation du niveau fonctionnel d’un domaine, dans l’aide en ligne de
Windows Server 2008, cherchez Pour augmenter le niveau fonctionnel du domaine.

3. Gestion des stratégies au niveau des domaines

En tant que conteneur, un domaine peut contenir de nombreux objets et offrir ses services
fondamentaux (authentification, catalogage et recherche des services globaux) aux utilisateurs,
ordinateurs et applications de l’entreprise.
Comme cela était le cas sous Windows NT, un domaine possède une stratégie de sécurité, sachant que
le domaine en délimite l’étendue de gestion. Ainsi, certains paramètres ne s’appliquent que sur un objet
de type domaine. Par exemple, la stratégie de comptes du domaine existe au niveau du domaine et est
ainsi appliquée uniformément à tous les utilisateurs du domaine.
Bien que n’étant pas le conteneur le plus petit au sein de l’annuaire Active Directory (pour rappel, nous
disposons d’une hiérarchie de conteneurs de type Forêt/Domaines/Unités d’organisation), le domaine est
fréquemment utilisé pour appliquer des stratégies de sécurité globales. Ce point se justifie
principalement pour les organisations qui sont concernées par des emplacements géographiques
différents ou des zones d’administration différentes.
En tant que zone de sécurité particulière, un domaine Active Directory fonctionnant dans le niveau
fonctionnel Windows 2000 mixte ou natif, ou dans le niveau fonctionnel Windows Server 2003, permet
de mettre en œuvre des politiques de gestion des compte distinctes au sein de la même forêt. Même s’il
est possible de spécifier des stratégies de comptes sur des OUs, vous remarquerez que ces stratégies
sont inopérantes, si ce n’est localement sur le ou les ordinateurs concernés et pas dans le domaine ! En
fait, ce point est tout à fait normal.

Page 233
Attention ! Nous verrons plus loin que les domaines fonctionnant dans le niveau fonctionnel Windows Server
2008 supportent désormais de multiples stratégies de comptes au sein du même domaine. Cette nouvelle
fonctionnalité, disponible uniquement dans ce mode, est rendue possible grâce aux objets PSO - Password
Settings Object. En effet, il convient de rappeler qu’un utilisateur ne s’authentifie pas dans une OU mais
dans un domaine. L’entité de domaine Windows est utilisée et utilisable par le protocole Kerberos version 5
au sein d’un royaume Kerberos version 5 mappé sur le domaine Windows tandis que les OUs appartiennent
à l’espace LDAP et aux conventions de nommage X.500.
Dans le cas où vous souhaiteriez disposer de paramètres différents en fonction de certaines régions du
réseau ou de départements devant disposer de règles spécifiques, et dans la mesure où ces paramètres
concernent le domaine Active Directory dans sa totalité, vous pourrez alors dans ce cas, décider de
créer un nouveau domaine.

4. Délégation de l’administration des domaines et contrôle des


paramètres spécifiques au domaine

Les services de sécurité intégrés à l’annuaire Active Directory permettent aux administrateurs de bâtir
un plan de délégation de l’administration. À l’issue de cette réflexion, il sera plus facile de gérer des
environnements comprenant un grand nombre d’objets en disposant de plusieurs entités distinctes.
Le concept de délégation permet aux possesseurs des objets de transférer tout ou partie du contrôle à
d’autres utilisateurs ou groupes d’utilisateurs soigneusement choisis.
Le principe de la délégation est un principe très important puisqu’il permet de distribuer la gestion des
objets à des tiers approuvés au sein d’une entité plus vaste. Pour rappel, sous Windows NT le seul
niveau de délégation était le domaine. Ensuite, l’administrateur du domaine pouvait s’appuyer sur les
groupes par défaut tels que les groupes Administrateurs du domaine ou les différents groupes de
type opérateurs. Aujourd’hui, le concept de délégation de l’annuaire Active Directory permet de
travailler sur la forêt, les domaines, les unités d’organisation, les objets et peut aussi descendre jusqu’à
un attribut particulier d’un objet parmi des millions.
Les points ci-dessous vous permettront de bien comprendre ce qui caractérise de manière toute
particulière un objet de type domaine au sein d’une forêt :
Le domaine et les stratégies de comptes : par définition, les stratégies de comptes et les stratégies
de clé publique et d’inscription automatique sont gérées et appliquées globalement sur l’objet domaine à
l’aide d’une stratégie de groupe (GPO - Group Policy Object).
Le domaine et les stratégies de mot de passe : les stratégies de mot de passe vous permettent de
déterminer comment les mots de passe de domaine sont gérés en termes de longueur, d’historisation et
de durée de vie.
Le domaine et les stratégies de verrouillage des comptes : les stratégies de verrouillage des
comptes vous permettent de déterminer comment les erreurs d’ouverture de sessions dans le domaine
sont prises en charge lors de l’utilisation d’un mauvais mot de passe. L’objet est de détecter
d’éventuelles intrusions et ainsi de bloquer le compte utilisateur utilisé pour une période de temps
déterminée.
Le domaine et les stratégies de tickets Kerberos : les stratégies de gestion des tickets Kerberos
permettent de déterminer la durée de vie des structures de sécurité importantes. Pour un serveur ou
service donné, un ticket Kerberos est délivré au demandeur après que celui-ci ait pu s’authentifier
auprès de l’AS - Authentication Service. Ce composant du système de sécurité fait partie intégrante du
serveur jouant le rôle de Centre de distribution de clés Kerberos. Ce rôle est toujours joué par une
machine de type "contrôleur de domaine Active Directory".

Page 234
Composants Active Directory et concepts de délégation
La figure précédente montre une infrastructure composée de plusieurs domaines. Chacun de ces
domaines dispose de ses propres objets et existe en tant que zone de sécurité distincte. Par conséquent,
chaque domaine dispose de par sa nature d’une stratégie de comptes et de sécurité qu’il faudra adapter
en fonction de la politique de sécurité globale de l’entreprise, si une telle stratégie existe.

Il est fortement recommandé de définir précisément les détails de la stratégie de gestion des comptes de
chacun des domaines de l’entreprise. De cette manière, vous pourrez imposer globalement une politique
uniforme capable de renforcer efficacement le niveau de sécurité global du réseau tout entier. Peut-être
pouvons-nous rappeler qu’un coffre-fort ne peut jouer pleinement son rôle d’espace protégé si les clés de ce
même coffre ne disposent pas elles aussi d’une grande protection !
Ensuite, chaque domaine pourra en fonction de la politique de gestion mettre en œuvre ou non un plan
de délégation. Ce plan aura pour principal objectif de définir qui aura la charge de contrôler ou de
modifier tout ou partie de tels objets. Nous découvrirons plus loin que les mécanismes de sécurité, de
délégation et d’application des objets stratégies de groupe s’appliquent sur les composants principaux
de l’infrastructure Active Directory, à savoir les sites, les domaines et les unités d’organisation.
Création de consoles MMC personnalisées
Pour que la délégation de l’administration soit complètement assurée, vous pourrez créer des consoles
MMC personnalisées que vous distribuerez aux utilisateurs ou groupes d’utilisateurs choisis pour
effectuer les tâches de délégation. La console MMC vous permet de créer des versions limitées d’un
composant logiciel enfichable particulier. Bien sûr, ce sera le cas du composant Utilisateurs et
ordinateurs Active Directory qui est l’outil contenant le plus de fonctionnalités d’administration. De
cette façon, les administrateurs peuvent contrôler les options proposées aux personnes responsables de
telle ou telle tâche.
Usage des stratégies de groupe pour publier ou attribuer les consoles personnalisées
Vous pourrez utiliser les objets stratégies de groupe pour distribuer vos consoles d’administration
personnalisées à certains utilisateurs ou groupes de deux manières.
Par publication : cette méthode permet de publier l’élément en question dans la liste des programmes
disponibles dans l’outil Ajout/Suppression de programmes. Les utilisateurs habilités peuvent ensuite
installer la nouvelle console. L’installation est donc initiée par l’utilisateur lorsqu’il estime avoir besoin de
l’application.
Par attribution : contrairement à la publication, l’attribution d’une application à l’aide d’une stratégie
de groupe automatise l’installation de celle-ci pour tous les comptes spécifiés. Dans ce cas, l’installation
est donc réalisée automatiquement sans que l’utilisateur soit impliqué.

Page 235
Pour plus d’informations sur les concepts de délégation, cherchez Pour déléguer le contrôle et Vue
d’ensemble de la sécurité dans l’aide en ligne de Windows Server 2003. Les objets stratégies de groupe
(GPO) sont étudiés au chapitre Éléments de structure Active Directory.

5. Utilisation du domaine comme unité de réplication élémentaire

Nous savons que l’objet domaine est un élément de la structure logique de l’annuaire Active Directory.
En effet, tout domaine Active Directory existe dans la forêt à l’aide d’un nom DNS et de ce fait, la
structure logique de l’annuaire en sera grandement modifiée.
Cependant, sous certains aspects, nous devons considérer le domaine comme un élément physique
tellement il est impliqué dans les mécanismes de réplication de l’annuaire. En effet, depuis MS OS/2 LAN
Manager, avec les domaines Windows NT et aujourd’hui avec les domaines Active Directory, le domaine
est toujours l’unité de réplication de base.
En fait, le domaine est la plus petite unité de réplication contrôlable au sein de la forêt. Il ne s’agit pas
d’une critique ou d’une quelconque limitation technique mais simplement d’un constat. Par définition, les
objets d’un domaine sont stockés dans le domaine et, de fait, devront être répliqués vers le ou les
contrôleurs de domaine du domaine.
Vous remarquerez que le groupe Contrôleurs de domaine possède le droit de Réplication de toutes
les modifications de l’annuaire. Vous pouvez utiliser la console de gestion MMC Utilisateurs et
ordinateurs Active Directory pour consulter l’onglet Sécurité d’un objet contrôleur de domaine.
Cette information peut paraître élémentaire mais, en fait, elle est d’une importance capitale dans la
compréhension des éléments qui composent l’annuaire Active Directory. Certes, un domaine existe au
travers de ses contrôleurs mais, bien avant cela, la forêt avec son rôle d’autorité de plus haut niveau
existe grâce au premier contrôleur, du premier domaine de la forêt. De fait, les contrôleurs d’un
domaine quelconque de la forêt sont, en quelque sorte, d’abord les contrôleurs de la forêt.

En fait, l’unité de réplication la plus petite n’est pas le domaine lui-même par le biais de la partition du
domaine, mais les partitions de l’annuaire d’applications.

Pour rappel, nous avons vu ces partitions dans le cadre du stockage des zones DNS dans l’Active Directory.
Les membres du groupe Administrateurs de l’entreprise ont ainsi la possibilité de créer une partition
dont les réplicas peuvent être placés sur les contrôleurs de leur choix. Le fait que nous ne considérions pas
les partitions de l’annuaire d’applications tient au fait que ces partitions ne peuvent pas stocker de SIDs,
lesquels sont nécessaires à la création des objets utilisateurs et ordinateurs.

6. Limites du domaine Active Directory et délégation contrainte

Microsoft précise que les domaines ne sont pas "vraiment" des frontières de sécurité à l’échelle de
l’Active Directory. En effet, une instance Active Directory est représentée par la forêt, laquelle est elle-
même représentée par le domaine racine de la forêt, c’est-à-dire le premier domaine de la forêt.
Dans la mesure où l’entité la plus haute est la forêt, Microsoft précise que le domaine ne fournit pas une
isolation totale et ce, même s’il existe dans sa propre partition et s’il détient ses propres SIDs et ses
propres comptes intégrés (Administrateurs, Opérateurs, etc.). En effet, face à une attaque d’un service
malicieux qui réussirait à usurper l’identité de l’administrateur du domaine racine, alors il serait
potentiellement possible d’obtenir un accès complet à tout domaine ou à tout ordinateur de tout
domaine de la forêt.

Définir une politique de sécurité à l’échelle du Système d’Information : une telle problématique, même si elle
existe réellement, devrait s’estomper au fil du temps et ainsi dédramatiser le risque. En effet, le protocole
Kerberos version 5 est une méthode d’authentification réseau très robuste et les systèmes, eux aussi,
peuvent atteindre des niveaux de robustesse élevés contre les agressions. Il faut pour cela définir des règles
d’usage, maintenir les correctifs des systèmes et des applications de manière régulière, disposer d’une
stratégie de sécurité approuvée de tous et régulièrement évaluée.
La transmissibilité - ou transmission possible - de privilèges est un point fondamental de la sécurité des
systèmes. Notez toutefois que la forêt ne prend aucune initiative en termes d’héritage ou de
transmission de privilèges. Ainsi, les privilèges d’administration ne sont pas du tout transmis dans la
hiérarchie de domaines Active Directory ou même entre domaines externes approuvés. Par conséquent,

Page 236
pour qu’un utilisateur d’un domaine obtienne des droits ou privilèges, même mineurs, dans un autre
domaine il faudra qu’une autorité habilitée dans ledit domaine les accorde.
Ce concept existe depuis toujours sous Windows NT avec les relations d’approbation interdomaines. La
relation d’approbation proprement dite n’est qu’un tube qui permet de créer la confiance de manière
unidirectionnelle entre deux contextes de sécurité différents : l’un des domaines est approuvé (the
trusted domain) tandis que l’autre est l’approbateur (the trusting domain). Ensuite, il est du ressort de
l’administrateur du domaine approbateur d’approuver un utilisateur ou groupe global du domaine
approuvé à réaliser une opération sur la base des permissions et/ou privilèges accordés.
Délégation Windows 2000 Server, Windows Server 2003
Néanmoins, les ordinateurs fonctionnant sous Windows 2000 Server et Windows Server 2003 peuvent
tirer parti de fonctionnalités de sécurité améliorées. Ce point met en évidence le fait que la forêt, les
domaines, les serveurs et les applications forment un tout qui nécessite des fonctionnalités très
avancées pour offrir une interopérabilité minimum, une administration centralisée et un cadre de
délégation contrôlée.
La délégation contrainte est une nouvelle option qui ne peut être utilisée que sur les serveurs
fonctionnant au minimum sous Windows Server 2003. Grâce à cette option, l’administrateur peut
spécifier les noms principaux des services (SPN, Service Principal Names) vers qui ce compte peut
déléguer. En procédant de la sorte, un service peut être approuvé pour la délégation, sachant que cette
approbation peut être limitée à un groupe de services sélectionné. Cette opération de délégation
contrôlée est bien entendu explicitement déclarée par un administrateur de domaine.
Pour approuver ou non un ordinateur ou un service spécifique pour la délégation, vous pourrez opter
pour l’un des choix présentés ci-dessous :
Ne pas approuver cet ordinateur pour la délégation : cette option disponible sur Windows 2000
Server, Windows Server 2003 et Windows Server 2008, est le paramètre par défaut. De cette manière,
aucun emprunt d’identité par un processus donné n’est possible.
Approuver cet ordinateur pour la délégation à tous les services (Kerberos uniquement) : la
sécurité de cette option, déjà disponible sur Windows 2000, est fonction du service et des actions de
tous ses administrateurs. Lorsque cette option est sélectionnée sur un ordinateur, tous les services
utilisant le contexte de sécurité du compte "système local" de l’ordinateur seront approuvés pour la
délégation. Par conséquent, l’ordinateur qui est globalement approuvé pourra ensuite accéder à toute
ressource réseau en réalisant un emprunt d’identité représentant par exemple un utilisateur. En fait, les
services d’un ordinateur agissent pour le compte du demandeur.
N’approuver cet ordinateur que pour la délégation aux services spécifiés : cette nouvelle
fonctionnalité n’est disponible que pour les serveurs fonctionnant sous Windows Server 2003 et
Windows Server 2008 et est appelée délégation contrainte. Elle permet d’atteindre une plus grande
granularité de la délégation puisque ce n’est plus la machine qui sera globalement approuvée mais
uniquement les services de votre choix.
Ainsi, grâce à la délégation contrainte, l’administrateur peut spécifier les noms principaux des services
(SPN, Service Principal Names) vers qui ce compte peut déléguer. Il s’agit bien sûr de l’option la plus
sécurisée. La délégation pour les services spécifiés permet à un administrateur de choisir les services
sur le réseau vers qui déléguer en choisissant un service spécifique ou un compte d’ordinateur. En
autorisant uniquement la délégation à des services spécifiques, un administrateur peut contrôler les
ressources réseau pouvant être utilisées par le service ou l’ordinateur. L’écran suivant illustre
l’activation de la délégation sur un ordinateur donné.

Page 237
Activation de la délégation pour tous les services fonctionnant avec l’autorité "système local"

Pour plus d’informations sur la délégation contrainte, consultez l’aide en ligne de Windows Server 2003 ou
Windows Server 2008.
Les domaines Active Directory sont des Unités d’approbation
L’objet domaine est, en tant que conteneur de l’annuaire Active Directory, le plus petit élément utilisable
dans le cadre d’une relation d’approbation. Par définition, tous les domaines appartenant à la même
forêt sont liés par des relations d’approbation Kerberos version 5. Les approbations qui unissent les
domaines entre eux au sein de la forêt sont, par définition, bidirectionnelles et transitives et maintenues
automatiquement par les contrôleurs de domaines.
De cette manière, il est possible à tout domaine de la forêt d’authentifier tout utilisateur ou tout
ordinateur de la forêt.
Sur la base des noms DNS qui régissent les domaines Active Directory et l’espace de nommage de la
forêt, le premier domaine, lequel est situé au plus haut de l’espace, jouera le rôle de racine de la forêt
et servira de point de passage obligé pour prendre en charge les authentifications entre les domaines
situés dans les autres arbres.
La structure de la forêt est détaillée dans la section Les forêts de ce chapitre.

Contrôleurs de domaine et structure logique


Les contrôleurs de domaine d’un domaine Active Directory sont, par définition, tous égaux entre eux. De
cette manière, les objets et les services que le domaine met à disposition sont disponibles par
l’intermédiaire de tous les contrôleurs du domaine.
Ainsi, les contrôleurs de domaine Windows 2000 Server, Windows Server 2003 et Windows Server 2008
utilisent un modèle de réplication où tous les contrôleurs sont disponibles en lecture et en écriture. Ce
modèle, appelé modèle de réplication multimaîtres (Multi Master Replication), permet de ne plus
dépendre d’un seul contrôleur en particulier comme cela était le cas précédemment dans l’environnement
Windows NT avec le contrôleur de domaine principal.
De cette manière, tout objet d’un domaine Active Directory peut être créé sur tout contrôleur de domaine
dudit domaine et toute propriété d’un objet peut aussi être modifiée sur tout contrôleur de domaine
possédant l’objet. L’annuaire Active Directory permet donc une disponibilité totale de l’annuaire en tout
point du réseau. En effet, l’idée est de faire en sorte qu’il soit possible de modifier l’objet au plus près de
Page 238
l’administration ou mieux, au plus près des utilisateurs, ordinateurs ou applications nécessitant une
valeur la plus à jour possible.
Pour rappel, dans un domaine Windows NT, toutes les modifications doivent être et sont réalisées sur le
contrôleur de domaine primaire, ce contrôleur étant le seul contrôleur de domaine à être disponible en
lecture et en écriture.
À ce sujet, nous avons vu que l’un des niveaux fonctionnels disponibles était le niveau Windows 2000
mixte. Ce mode est le mode par défaut de tout domaine Active Directory, qu’il soit composé de
contrôleurs fonctionnant sous Windows 2000 Server, sous Windows Server 2003, sous Windows Server
2008 ou d’un mixte des trois. Il permet une grande compatibilité avec l’existant puisqu’il permet de
maintenir synchronisés d’éventuels contrôleurs Windows NT 4.0.
Les contrôleurs de domaine prennent aussi à leur charge la réplication des données qui concernent la
forêt ou encore les partitions de l’annuaire d’application utilisées par le service DNS. C’est ainsi qu’un
contrôleur de domaine réplique les partitions spécifiées ci-dessous :

 la partition du domaine du contrôleur lui-même ;


 la partition de schéma de la forêt Active Directory ;
 la partition de configuration de la forêt Active Directory ;
 la ou les partitions des autres domaines de la forêt, si le contrôleur joue aussi le rôle de
catalogue global.

Nous savons que les contrôleurs de domaine Active Directory sont tous disponibles en lecture et en écriture.
Notez cependant que cela ne concerne en aucun cas les partitions utilisées par les serveurs de catalogues
globaux. En effet, les données contenues dans ces partitions ne sont utilisables qu’à des fins de recherche et
pas dans le cadre des modifications qu’un administrateur dudit domaine pourrait devoir apporter. Par
conséquent, les partitions réplicas contenues sur les contrôleurs de domaine jouant le rôle de catalogues
globaux ne sont disponibles qu’en lecture seule et ne sont modifiables que dans le domaine d’origine.
La partition de l’annuaire d’applications contenant la zone DNS intégrée à Active Directory du domaine
courant ainsi que la partition de l’annuaire d’applications contenant la zone DNS intégrée à Active
Directory du domaine _msdcs.NomdeDomaineDnsRacinedelaForêt sont deux espaces de stockage
critiques.
Ces derniers points montrent clairement que le contrôleur de domaine d’un domaine doit tenir à jour les
données de son domaine, mais aussi des données qui ne le concernent pas directement mais qui
concernent des applications ou bien la structure même de la forêt.
Ainsi, à la différence des partitions de schéma et de configuration, les partitions de l’annuaire
d’application ne sont pas stockées sur tous les contrôleurs de domaine de la forêt mais uniquement sur
les contrôleurs sélectionnés par un administrateur en tant que réplicas.
Le fait de partitionner techniquement l’annuaire Active Directory en plusieurs partitions accueillies par un
contrôleur de domaine permet de mieux contrôler la réplication vers tel ou tel autre contrôleur ou
partenaire de réplication. De cette manière, l’annuaire Active Directory peut être globalement déployé
dans des environnements dont la bande passante disponible est limitée.

Pour obtenir plus d’informations sur la réplication Active Directory, cherchez Fonctionnement de la
réplication dans l’aide en ligne de Windows Server 2003 ou rendez-vous sur le site Web de Microsoft et
accédez à la page Active Directory Replication Topology Technical Reference à l’aide du lien :
http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/techref/en-us/Default.
asp?url=/Resources/Documentation/windowsserv/2003/all/techref/en-us/ W2K3TR_ad_rep_over.asp
Maîtres d’opérations de domaine Active Directory
La réplication multimaîtres supportée par l’Active Directory est certes indispensable pour qu’il soit
possible de mettre en œuvre des infrastructures d’annuaires capables de prendre en charge des
entreprises comprenant des millions d’objets.
Cependant, certaines opérations de modifications ne peuvent être réalisées de cette manière et de fait,
ces opérations à caractère conflictuel ou dangereux seront dirigées vers un contrôleur particulier appelé le
maître d’opérations.
Tout domaine Active Directory devra disposer des rôles suivants :

 le maître des ID relatifs (RID, Relative ID Master) ;


 le maître d’émulateur du contrôleur principal de domaine (PDC Emulator) ;
Page 239
 le maître d’infrastructure (Infrastructure Master).

Ces rôles doivent être uniques à l’intérieur de chaque domaine. En d’autres termes, il ne peut exister
qu’un maître RID, un maître d’émulateur PDC et un maître d’infrastructure dans chaque domaine de la
forêt.
La figure suivante est obtenue en accédant aux propriétés du domaine Active Directory à l’aide de la
console de gestion MMC Utilisateurs et ordinateurs Active Directory.

Les trois maîtres d’opérations d’un domaine Active Directory


Les maîtres d’opérations jouent un rôle important dans le cadre des opérations de mise à jour en rapport
avec certaines tâches d’administration et de changement de la configuration de l’annuaire Active
Directory.
Le fait d’assigner certaines opérations spécifiques à certains contrôleurs de domaines parmi n, protège
l’Active Directory contre certains types de conflits et permet ainsi de garantir la disponibilité
opérationnelle de l’annuaire.
Les opérations prises en charge par les maîtres d’opérations de domaines (en anglais, FSMO - Flexible
Single Master Operations) sont résumées ci-dessous :

 Le maître des ID relatifs (RID, Relative ID Master) assure la gestion du remplissage du pool de
RIDs pour chaque contrôleur de domaine du domaine.
 Le maître d’émulateur du contrôleur principal de domaine (PDC Emulator) assure le rôle de PDC
pour assurer la compatibilité des contrôleurs de domaine Windows NT, la gestion des mauvais
mots de passe et les mécanismes de synchronisation horaire nécessaires aux horodateurs
insérés dans les paquets d’authentification Kerberos version 5.
 Le maître d’infrastructure (Infrastructure Master) assure la mise à jour des références relatives
à des objets situés dans d’autres domaines.

Nous verrons qu’il existe deux maîtres d’opérations supplémentaires au niveau de la forêt. Les opérations
prises en charge par les maîtres d’opérations de forêt concernent la protection des opérations qui
modifient le schéma ainsi que les opérations de modification du DIT (Directory Information Tree). Ce
dernier maître d’opérations aura pour principal objectif de vérifier le caractère unique des opérations
d’ajout et de suppression des objets de type domaine au sein de la forêt.

Les maîtres d’opérations assurent aussi l’interopérabilité nécessaire entre les contrôleurs de domaine
fonctionnant sous Windows Server 2008, Windows Server 2003, Windows 2000 Server et Windows NT
Server 4.0 ainsi que le contrôle des références des groupes et utilisateurs entre de multiples domaines.

Page 240
Notez aussi que les services de domaine Active Directory vous permettent de transférer ou de reprendre le
contrôle de tous les maîtres d’opérations.

Les unités d’organisation (OU)


Les unités d’organisation (OU - Organizational Unit) sont les objets conteneurs les plus communément
utilisés au sein d’un domaine Active Directory. En effet, autant la structure des domaines et des forêts
(DIT - Directory Information Tree) est rigide et complexe, autant les OUs sont faciles à créer, modifier,
déplacer et supprimer.
Ce conteneur peut contenir de multiples types d’objets tels que des utilisateurs, des contacts, des
ordinateurs, des imprimantes, des dossiers partagés et bien sûr aussi d’autres unités d’organisation.
Le fait que le conteneur de classe OU puisse nous aider à organiser l’espace de stockage des objets d’un
domaine particulier de la forêt est intéressant à plus d’un titre. En effet, les points ci-dessous
caractérisent le bon usage des unités d’organisation :

 D’un point de vue du contenu, l’unité d’organisation peut accueillir les objets les plus
couramment utilisés (objets utilisateurs, groupes, ordinateurs, dossiers partagés, imprimantes).
 D’un point de vue des fonctionnalités de gestion des changements de configuration, l’unité
d’organisation est le plus petit conteneur pouvant faire l’objet de l’application de stratégies de
groupe.
 D’un point de vue de la mise en place des privilèges d’administration, l’unité d’organisation peut
faire l’objet de multiples délégations.
 D’un point de vue de la modélisation d’un espace organisé, les unités d’organisation peuvent
être aisément combinées pour refléter votre modèle d’administration ou d’organisation, et ce,
quels que soient la taille et le nombre d’objets contenus.

Vous pouvez utiliser les OUs de manière individuelle ou dans le cadre d’une hiérarchie d’OUs imbriquées.
Dans ce dernier cas, vous pourrez décider de profiter ou non des mécanismes d’héritage. En fait, le
comportement d’une OU ressemble à s’y méprendre à celui d’un répertoire NTFS. La différence la plus
notable concerne la nature des objets supportés. Bien sûr, un répertoire NTFS ne peut contenir que des
fichiers ou d’autres répertoires avec les autorisations que nous connaissons. Concernant l’analogie que
nous pouvons faire entre l’OU et un simple répertoire, le fait est que la nature des objets contenus dans
une OU est bien plus riche que ce que nous connaissons sur des fichiers.
L’écran suivant illustre la possibilité qu’a l’administrateur de jouer sur les autorisations de l’unité
d’organisation Consultants. Vous remarquerez que cette fenêtre ressemble beaucoup à une fenêtre de
autorisations NTFS.

Page 241
Autorisations sur une unité d’organisation
La fenêtre de sélection des autorisations permet de déclarer les autorisations les plus communes et
génériques. Cependant, compte tenu de la nature très variée des objets pouvant s’y trouver,
l’administrateur utilisera le plus souvent le bouton Paramètres avancés.

Vous pouvez consulter la fenêtre de sélection du type d’objets sur lesquels appliquer les autorisations
dans une OU.

Page 242
Cette fenêtre peut laisser penser qu’il est possible de gérer au sein d’une unité d’organisation des objets
instanciés à partir de toutes les classes déclarées dans le schéma de l’annuaire Active Directory. En fait, il
n’en n’est rien, car cette fenêtre de sélection est une fenêtre générique.

Affectation des autorisations sur les propriétés en fonction de la classe de l’objet


L’écran ci-dessus montre que les autorisations sur les types d’objets dépendront de la nature des objets.
Modélisation d’une hiérarchie d’OUs
Concernant les environnements qui seraient composés de plusieurs domaines Active Directory, il
conviendra de déterminer si le modèle de hiérarchie d’OUs défini est identique ou au contraire, s’il fait
l’objet de spécificités pour chacun des domaines. Dans l’absolu, si certains utilisateurs sont concernés par
la nature de la structure hiérarchique des OUs dans plusieurs domaines, il serait judicieux de faire en
sorte que les deux ou trois premiers niveaux d’OUs soient communs pour tous les domaines concernés.
De cette manière, les utilisateurs retrouveront une hiérarchie d’OUs standardisée dans les différents
domaines.
Quoi qu’il en soit, n’oubliez pas qu’une hiérarchie d’OUs dans un domaine donné n’a aucune relation avec
une hiérarchie d’OUs définie dans un autre domaine.
Le seul point commun pouvant exister entre des OUs situées dans des domaines différents ou au sein du
même domaine peut concerner leur RDN respectif (Relative Distinguished Name). En effet, celui-ci pourra
être identique.
De cette façon, il est possible d’avoir plusieurs OUs portant le même nom. Dans notre exemple, d’autres
OUs portant le RDN "OU=Consultants" peuvent exister dans le domaine ou dans d’autres domaines de la
forêt. Ce type d’opération est possible car tous les objets sont globalement uniques grâce à l’usage des
GUIDs (Globally Universal Identifier Descriptor).
La figure suivante illustre une première approche d’une structure d’OUs. Dans l’absolu, la définition de la
structure est en rapport direct avec les opérations d’administration des éléments contenus dans les OUs
ainsi que la possibilité de faire usage des services de délégation ou non, en fonction de la stratégie de
l’entreprise.

Page 243
Délégation et possesseurs des unités d’organisation
Au départ, l’administrateur a le pouvoir de déléguer sur certaines OUs ou hiérarchies d’OUs, tout ou
partie des opérations d’administration à de simples utilisateurs du domaine ou de tout domaine approuvé.
En suivant les bonnes pratiques, on peut définir trois types d’administrateurs :
Les possesseurs de services : il s’agit des comptes d’administration habituels lesquels possèdent par
définition tous les droits, y compris celui de s’approprier les objets ne leur appartenant pas.
Les possesseurs de comptes : il s’agit de comptes faisant l’objet d’une ou de plusieurs délégations.
Ces comptes peuvent gérer tout ou partie des comptes d’un département ou d’une unité particulière de
l’entreprise. En fonction des délégations à réaliser, il pourra être nécessaire d’avoir plusieurs possesseurs
de comptes dont les autorisations seront adaptées en fonction des besoins.
Les possesseurs de ressources : il s’agit de comptes faisant l’objet d’une ou de plusieurs délégations.
Ces comptes peuvent gérer tout ou partie des ressources d’un département ou d’une unité particulière de
l’entreprise. En fonction des délégations à réaliser, il pourra être nécessaire d’avoir plusieurs possesseurs
de ressources dont les autorisations seront adaptées en fonction des ressources à contrôler.

Dans cet exemple, les comptes de ressources font l’objet de délégation de gestion sur certaines ressources
de la part des possesseurs de services et/ou de la part des possesseurs de comptes. La stratégie de
délégation devra déterminer puis formaliser le plan le plus adapté aux pratiques et à la politique de
l’entreprise.
Si les technologies et méthodes proposées sont utilisées alors, les équipes informatiques se recentreront
sur leur véritable métier, c’est-à-dire les services d’infrastructure et la gestion de l’Information au sens
stratégique du terme. Dans le cadre du Plan de délégation, chaque département de l’entreprise
s’occupera de gérer ses propres objets au sein de sa propre zone d’autorité.

Page 244
Pour en savoir plus sur la mise en œuvre d’une architecture d’unités d’organisation, consultez le Windows
Server 2003 Technical Reference disponible sur le site Web de Microsoft à l’adresse
http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/techref/en-us/default.asp

Vous pourrez aussi consulter le Microsoft Windows Server 2003 Deployment Kit - Designing and
Deploying Directory and Security Services et vous reporter au chapitre intitulé Designing the Active
Directory Logical Structure.
Unités d’organisation et unicité des comptes d’utilisateurs
Lorsque vous créez un compte d’utilisateur, Active Directory génère un SID (Security Identifier
Descriptor) et un GUID. Ce dernier est utilisé pour identifier l’entité de sécurité. Active Directory crée
aussi un nom LDAP (RDN - Relative Distinguished Name) unique relatif basé sur le nom de l’entité de
sécurité. Ce nom unique LDAP, et aussi un nom canonique Active Directory, sont générés en fonction du
nom unique relatif LDAP des noms des contextes du domaine et des conteneurs où l’objet entité de
sécurité est créé.
Si l’entreprise est composée de plusieurs domaines, vous pouvez utiliser le même nom d’utilisateur (ou
nom d’ordinateur) dans des domaines différents. L’ID de sécurité, l’identificateur universel unique (GUID),
le nom unique LDAP et le nom canonique générés par Active Directory identifieront de manière unique
chaque utilisateur, ordinateur ou groupe au sein de la forêt.
Si l’objet entité de sécurité est renommé ou déplacé vers un autre domaine, l’ID de sécurité, le nom
unique relatif LDAP, le nom unique LDAP et le nom canonique seront automatiquement modifiés. Par
contre, puisqu’il s’agit du même objet, l’identificateur universel unique généré par Active Directory restera
inchangé.
Dans le cas où vous essayerez de créer un deuxième compte d’utilisateur portant le même nom
d’affichage dans la même OU, alors vous obtiendrez un message d’erreur indiquant que le nom existe
déjà.
Pour pouvoir disposer de deux objets utilisateur portant le même "nom détaillé" dans le même domaine,
vous devrez faire en sorte qu’ils soient stockés dans des unités d’organisation différentes.

Une unité d’organisation ne peut contenir que des objets en provenance de son propre domaine et ce, quel
que soit le type des objets. Il n’est donc pas possible d’insérer dans une OU du domaine A des objets en
provenance du domaine B.

Les arbres
Un arbre de domaine(s) est un ensemble de domaines regroupés pour former une structure hiérarchique.
Par définition, lorsque vous ajoutez un domaine au sein d’une forêt, deux cas de figures peuvent se
présenter :

 Le domaine est inséré en tant que nouveau domaine enfant dans une arborescence de domaine
existante.
 Le domaine crée une nouvelle arborescence dans une forêt existante.

À propos du premier domaine de la forêt : le choix permettant de créer un nouveau domaine dans une
nouvelle forêt correspond à la création initiale de la forêt. Ce domaine particilier est appelé domaine racine
de la forêt et joue aussi le rôle de domaine racine de la première arborescence. L’importance du rôle de
domaine racine de la forêt est traitée plus loin.
À partir du moment où vous rajoutez un nouveau domaine à un arbre existant, il devient un domaine
enfant du domaine racine de l’arbre. Le domaine racine de l’arbre est, dans cet exemple, le domaine
parent.
Cependant, un domaine enfant peut, lui aussi, avoir un ou plusieurs domaines enfants. Cette structure
composée de multiples domaines formera une hiérarchie de domaine dont la base du nom sera le
domaine racine de l’arbre. Ainsi, le nom d’un domaine enfant dans un arbre est tout simplement son nom
DNS. Ce nom est une combinaison du nom de chacun des domaines jusqu’au domaine racine de l’arbre
tel que, par exemple, le domaine Active Directory responsable de la zone EMEA (Europe, Middle East and
Africa) dont le nom DNS serait, par exemple, emea.corpnet.corporate.net.

Page 245
Par définition, un arbre Active Directory est un espace de noms DNS parfaitement contigu, donc tout nouvel
espace de noms DNS devra faire l’objet de la création d’une nouvelle arborescence au sein de la forêt Active
Directory.
Bien que le domaine soit l’unité d’administration, de sécurité et de réplication de base, il est probable
qu’en fonction du modèle d’administration ou d’organisation de l’entreprise, il sera nécessaire de créer un
ou plusieurs domaines additionnels. Par exemple, vous pourriez avoir besoin d’ajouter des domaines au
sein d’une forêt existante dans les cas présentés ci- dessous :

 Permettre la mise en place d’un modèle d’administration décentralisée.


 Utiliser des stratégies et des paramètres de sécurité différents pour chacun des domaines.
 Augmenter la performance des réplications et ainsi obtenir un meilleur contrôle de celles-ci.
 Supprimer certaines limites techniques telles que le nombre d’objets pris en charge ou le
nombre de contrôleurs de domaine par domaine.

La création d’une arborescence peut se justifier lorsqu’une entreprise possède plusieurs bureaux dans des
pays différents. Si le réseau de l’entreprise n’est composé que d’un seul domaine, alors il sera nécessaire
de disposer au minimum d’un contrôleur de domaine par site pour pouvoir assurer les services globaux.
Il s’agira principalement des services prenant en charge l’authentification des utilisateurs et peut-être
aussi la gestion et la configuration des ordinateurs à l’aide de la technologie IntelliMirror et des stratégies
de groupe.

La technologie IntelliMirror permet de combiner les avantages de l’informatique centralisée avec les
performances et la souplesse de l’informatique distribuée. Cette technologie garantit la disponibilité des
données utilisateur, la disponibilité des logiciels et des paramètres personnels ainsi que leur persistance
lorsque les utilisateurs ouvrent une session dans un domaine Active Directory et ce, à partir de n’importe
quelle machine du domaine ou d’un domaine approuvé.
Supposons une entreprise composée d’un seul domaine Active Directory prenant en charge dix sites
géographiques répartis dans cinq pays. Quelques mois plus tard, l’entreprise est en pleine expansion et
est désormais composée de quarante sites dans huit pays.
Cette évolution notable de la topologie physique de l’entreprise pourra nécessiter une évolution du
modèle original composé d’un seul domaine vers une architecture multidomaine. La figure ci-après illustre
cette évolution.

Page 246
Évolution du DIT (Directory Information Tree)
Une telle évolution devra être techniquement et financièrement justifiée. Il se peut qu’un certain niveau
d’autonomie soit souhaité ou bien que les flux de réplication demandent un certain niveau d’isolation. En
effet, le fait de casser le réseau en plusieurs morceaux pourrait permettre à l’équipe informatique de
disposer d’un domaine Active Directory par pays à la place d’un seul et unique domaine.
Même si la solution parfaite, en termes de simplicité de mise en œuvre, de maintenance et d’évolution
serait de disposer d’une forêt composée d’un domaine comprenant à son tour un seul contrôleur, il ne
faut pas dramatiser les infrastructures composées de multiples domaines. Le fait de posséder plusieurs
domaines ne signifie en aucune façon que l’administration en soit plus lourde ou complexe.
En effet, les domaines d’une forêt partagent l’essentiel, c’est-à-dire le schéma, la configuration, les
catalogues globaux ainsi que les espaces de noms DNS offerts par les différentes arborescences de la
forêt Active Directory. Finalement, les points les plus importants qui caractérisent une arborescence de
domaines sont spécifiés ci-dessous :

 Une arborescence est un nouvel espace de nommage distinct de tous les autres. Par exemple,
vous pourriez créer un nouvel espace de noms DNS (partners.net ou partners.corporate.com,
etc.) et un nouveau domaine Active Directory pour accueillir des partenaires approuvés au sein
de votre forêt Active Directory corpnet.corporate.com. Une telle configuration nécessite une
nouvelle arborescence puisque l’espace de nom initial corpnet.corporate.com est rompu.
 Les noms créés en dessous d’un domaine racine d’arborescence sont toujours contigus ou
forment un espace continu.
 Les noms DNS utilisés peuvent refléter une entité particulière, l’organisation de l’entreprise de
manière géographique, de manière organisationnelle ou un mixte des deux.

La mise en œuvre d’une nouvelle arborescence de domaines permet à l’entreprise de disposer de


plusieurs espaces de noms. Ce point est particulièrement important lorsqu’une entreprise fait l’objet d’une
acquisition et que son nom doit impérativement être préservé. Soyez malgré tout attentif au fait que la
création d’une nouvelle arborescence vide ne permet pas l’intégration naturelle d’une forêt A avec une
Hforêt B. Pour pouvoir récupérer réellement les objets de la forêt B dans la forêt A, vous devrez procéder
à une opération d’export/import ou mieux, de clônage d’objets. La cible de l’opération sera un domaine

Page 247
existant ou un nouveau domaine fonctionnant en mode natif Windows 2000 ou Windows Server 2003 au
sein de la forêt et, comme domaine source, le domaine contenant les objets à récupérer.
Cette opération de récupération consistera à clôner les objets à l’aide de l’outil ADMT 2.0. Dans ce cas,
les nouveaux objets de sécurité créés dans le domaine cible utiliseront l’attribut sIDHistory disponible
uniquement en mode natif.

Le principe de l’attribut sIDHistory est rapidement présenté plus loin dans cette section.
Outil de migration Active Directory ADMT Version 3.0
L’outil de migration Active Directory (ADMT, Active Directory Migration Tool) peut vous aider à migrer les
comptes d’utilisateurs, les groupes ainsi que les comptes d’ordinateurs des domaines Windows NT 4.0
vers des domaines Active Directory (domaines dont les contrôleurs de domaine exécutent Windows 2000
Server, Windows Server 2003 ou Windows Server 2008). L’outil ADMT Version 2.0 était précédemment
livré sur le CD-Rom de Windows Server 2003 dans le répertoire \I386\ADMT.

ADMT version 3.0 apporte les améliorations suivantes : l’éxécution simultanées de plusieurs opérations
ADMT, le support de Microsoft SQL Server pour le stockage de données de migration, la possibilité de
modifier directement les noms de comptes, les noms relatifs (RDN), les noms des comptes SAM et noms
principaux universels (UPN). Ces options sont possibles via la nouvelle page nommée Option de sélection
des objets ajoutée aux Assistants Migration des comptes d’utilisateurs, d’ordinateurs et comptes de groupes.
ADMT version 3.0 améliore également le serveur d’exportation de mots de passe (Password Exportation
Service) s’exécute désormais en tant que service. De cette manière, il est possible de le lancer via les
informations d’authentification d’un utilisateur authentifié sur un domaine de migration cible. Enfin,
l’ensemble des fichiers journaux est désormais stockés dans la base de donnée SQL d’ADMT pour une
consultation ultérieure. Pour télécharger ADMT Version 3.0, recherchez Active Directory Migration Tool
v3.0 sur le site de Microsoft.

Pour plus d’informations, consultez Outils de support Active Directory et Conception et déploiement
des services d’annuaire et des services de sécurité sur le site Web des Kits de ressources techniques
de Microsoft Windows à l’adresse suivante : http://www.microsoft.com/reskit.
La version ADMT 1.0 livrée sur le CD de Windows 2000 Server, ne permettait pas de migrer les mots de
passe. Les versions 2.0 et 3.0 permettent désormais la migration des mots de passe. Pour y parvenir,
vous devrez installer et utiliser un serveur d’exportation de mot de passe. Cette opération est facilement
réalisable en installant le composant d’exportation sur un BDC (Backup Domain Controller) NT 4.0 ou sur
un contrôleur de domaine Windows 2000 Server ou Windows Server 2003. Si votre serveur d’export de
mot de passe exécute Windows NT Server 4.0, vous devrez veiller à disposer du cryptage 128 bits.
De plus, pour maximiser le niveau de sécurité des opérations de récupération des mots de passe,
Microsoft recommande que le serveur d’export de mot de passe du domaine source soit un contrôleur
secondaire de domaine "dédié" à cette tâche et placé dans un lieu particulièrement sécurisé.
L’outil ADMT "clone" les objets de sécurité entre les domaines source et destination situés dans des forêts
différentes. Notez qu’il peut néanmoins aussi être utilisé dans le cadre de la réorganisation d’une forêt
pour déplacer les objets entre les domaines Active Directory de la forêt.
À propos du sIDHistory - données d’historique du SID
Un objet de sécurité "cloné" est un compte situé dans un domaine Active Directory fonctionnant en mode
natif Windows 2000, en mode Windows Server 2003 ou en mode Windows Server 2008 pour lequel les
propriétés d’origine NT 4.0 ont été copiées à partir du compte source. Bien qu’il s’agisse d’un nouvel objet
dans le domaine Active Directory et que de ce fait, il dispose obligatoirement d’un nouveau SID, l’ancien
SID du compte source sera copié vers l’attribut Active Directory sIDHistory du nouvel objet. Le fait de
rapatrier l’ancien SID permet à l’objet clôné de pouvoir continuer à accéder à l’ensemble des ressources
réseau pour lesquelles le compte source disposait d’autorisations.
Techniquement, les accès aux ressources réseau sont préservés via le sIDHistory car, en mode natif,
l’ouverture de session crée un jeton d’accès - Access Token - qui contiendra le SID principal de
l’utilisateur mais aussi le sIDHistory de l’utilisateur et les sIDHistory des groupes auxquels appartenait
l’utilisateur dans l’ancien domaine source.
Ces quelques lignes nous permettent de comprendre qu’un nouvel arbre dans une forêt existante permet
la disponibilité d’un nouvel espace de noms DNS distinct et d’un nouveau domaine Active Directory
vierge. Il n’est donc pas possible de "brancher" un arbre d’une forêt X en tant que nouvel arbre d’une
forêt différente.

Page 248
Emplacement de la nouvelle arborescence
Ce point nous permet maintenant d’envisager la mise en œuvre d’une nouvelle arborescence de domaines
dans la forêt ou peut-être dans une forêt différente. En effet, il est très important de se poser cette
question pour faire le meilleur choix en termes d’évolutions futures à court ou moyen terme.
Avant de créer une nouvelle arborescence pour mettre en œuvre un nouvel espace de nommage au sein
de la forêt, il serait judicieux d’évaluer l’éventualité de créer une nouvelle arborescence dans une nouvelle
forêt. Cette option pourrait permettre à l’entreprise de profiter d’une autonomie totale de l’entité
d’administration, d’un schéma et d’une configuration différente ainsi que d’une séparation totale entre les
infrastructures techniques. De cette manière, une séparation ou cession de l’activité d’une filiale de
l’entreprise devient envisageable.
La figure suivante illustre ces différentes approches.

Arborescences dans la même forêt et dans des forêts distinctes


Une entreprise met en œuvre une infrastructure composée de trois arborescences. Les deux premières
arborescences sont implémentées dans la première forêt en permettant à l’entreprise d’utiliser deux
espaces de noms différents dans le même espace de sécurité et la même infrastructure technique Active
Directory. La troisième arborescence est, cette fois-ci, implémentée dans une forêt différente. Cette
approche est une très bonne solution lorsque vous devez considérer une zone de sécurité distincte ou
l’éventualité d’une cession de cette entité de l’entreprise. La section consacrée au rôle de la forêt
présente les concepts des forêts et la notion d’approbation de forêts.
Les opérations de construction des arborescences sont réalisées par l’Assistant d’installation d’Active
Directory, DCPromo. Cet assistant prendra à sa charge la création d’une relation d’approbation Kerberos
version 5 bidirectionnelle transitive entre le domaine racine du nouvel arbre et le domaine racine de la
forêt. De la même manière, les autres arborescences de domaines de la forêt seront "connectées" à l’aide
du même type d’approbation au domaine racine de la forêt.
L’écran suivant illustre le fait que les domaines Corp2003.corporate.net et Partners.corporate.net
possèdent des approbations bidirectionnelles transitives dont le type est Racine d’arborescence.

Page 249
Le domaine Corp2003.Corporate.net et Partners.Corporate.net s’approuvent mutuellement
Disponibilité du domaine racine de la forêt
Comme cela a été précisé plus haut, ces opérations complexes sont réalisées automatiquement par
DCPromo. Néanmoins, Microsoft suggère que tout soit mis en œuvre pour garantir la disponibilité du
domaine racine de la forêt vis-à-vis des domaines racines d’arborescences.
En effet, deux aspects fondamentaux sont à considérer :
1.
Les approbations sont transitives : la transitivité des relations d’approbation Kerberos version 5 nécessite de
contacter le domaine racine de la forêt. Par conséquent, il faudra s’assurer qu’il est possible de contacter au
moins un contrôleur de domaine de ce domaine.
2.
Les paquets d’authentification Kerberos sont horodatés : nous savons combien le protocole Kerberos version
5 est robuste. Les fonctionnalités d’anti-replay intégrées au protocole Kerberos nécessitent l’horodatage des
paquets d’authentification. De fait, le système de synchronisation horaire doit être fonctionnel au niveau de
la forêt. La référence globale est définie au niveau du domaine racine de la forêt, puis transmise vers les
autres domaines de la forêt en traversant les différentes arborescences.

Le système de synchronisation horaire est implémenté sur les contrôleurs de domaines jouant le rôle de
maître d’opérations PDC Emulator. Ces ordinateurs sont donc particulièrement importants concernant le
bon fonctionnement du protocole d’authentification Kerberos version 5, et ce, en dehors des autres fonctions
qu’ils pourraient aussi détenir au sein de la forêt.
Le contrôleur visé dispose des rôles de maître d’opérations FSMO PDC Emulator, catalogue global,
contrôleur de domaine Active Directory au sens LDAP du terme, centre de distribution de clés Kerberos et
serveur de temps Windows via le service Horloge Windows ou W32 Time.
À propos des noms de domaines enfants
Une fois le ou les domaines racines d’arborescence créés, en fonction du nom de l’entreprise ou d’une
division particulière, il conviendra de définir la politique de nommage des domaines enfants au sein d’une
arborescence de domaine donnée.
Les modifications à appliquer au niveau de l’infrastructure de domaines d’une forêt Active Directory sont
synonymes de complexité, de risques potentiels d’indisponibilité et dans de nombreux cas, d’impossibilité.
Depuis les premiers modèles d’architecture définis par Microsoft avec certains grands clients, Microsoft a
toujours mis en garde contre ces limitations qui demeurent toujours d’actualité, même cinq ans après.
Les domaines enfants d’un domaine racine d’arborescence peuvent facilement représenter des entités
connues des utilisateurs donc globalement approuvées. Ce pourrait être le cas des types d’entités ci-
dessous :

Page 250
 régions géographiques, pays, sites départementaux ;
 entités administratives, départements de l’entreprise ;
 entités spécifiques à une activité particulière.

La bonne pratique qui vous permettra de profiter pleinement de votre architecture de domaines Active
Directory, concernant le nommage des noms de domaines enfants d’un domaine racine d’arborescence,
consiste à s’appuyer sur les sites géographiques.

La définition d’un espace de nom pour l’annuaire Active Directory doit considérer la probabilité d’une
réorganisation imprévue avec un impact sur la ou les hiérarchies de domaines le plus limité possible.
Création d’une arborescence et contrôles réalisés par DCPromo
Lorsqu’un nouveau domaine est implémenté pour créer une arborescence de domaine, l’assistant
d’installation de l’annuaire Active Directory effectue une série d’opérations de contrôle :

 Vérification du nom DNS déclaré. Le nom déclaré doit créer une rupture de l’espace DNS
existant dans la forêt et le nom NetBIOS du domaine doit être unique.
 Recherche d’un contrôleur de domaine opérationnel pour le domaine racine de la forêt.
 Réplication des partitions de schéma et de configuration.
 Création de la nouvelle partition nécessaire au nouveau domaine et des nouveaux objets par
défaut de celle-ci.
 Génération du SID du nouveau domaine et de la stratégie de sécurité.
 Création d’un objet TDO (Trusted Domain Object) dans le domaine racine pour le nouveau
domaine de la nouvelle arborescence.
 Création d’un objet TDO (Trusted Domain Object) dans le domaine de la nouvelle arborescence
pour le domaine racine de la forêt.
 Création d’une relation d’approbation bidirectionnelle entre les deux domaines.
 Création de la stratégie de groupe du domaine.
 Définition de la sécurité sur le contrôleur de domaine, des fichiers Active Directory et des clés du
registre.

Bien que l’interface graphique et la littérature technique nous expliquent que les approbations créées par
dcpromo sont des relations bidirectionnelles, notez qu’en réalité, il s’agit techniquement de deux relations
unidirectionnelles.
Pour plus de détails concernant les opérations réalisées par DCPromo, consultez les journaux d’installation
de l’annuaire Active Directory dans \%Systemroot%\debug. Les fichiers DCPromo.log et
DCpromoUI.log consignent toutes les opérations du processus d’installation de l’annuaire Active
Directory sur l’ordinateur tandis que les fichiers NtFrsApi.log et NtFrs_000x.log consignent les
opérations de mise en place du volume système partagé Sysvol.

Les serveurs Windows Server 2003 et Windows Server 2008 utilisent de dossier %Systemroot%\debug pour
y stocker les fichiers de trace d’installation et de désinstallation. Concernant Windows Server 2008, vous y
trouverez de nouveaux journaux en rapport avec les opérations relatives aux nouveaux rôles et services de
rôles pris en charge par le Gestionnaire de serveur.

Les forêts
Une forêt est une instance complète de l’annuaire Active Directory. De prime abord, il semble que l’Active
Directory n’existe qu’à partir du moment où un nouveau domaine est créé. Cependant, la création de ce
premier domaine ne pourra se faire qu’en ayant au préalable spécifié que le domaine adhérait à une
nouvelle forêt.
Plus simplement, pour que la forêt existe, il lui faut une arborescence contenant un domaine Active
Directory donc, au minimum un domaine.
Chaque forêt existe grâce à l’ensemble de tous les contrôleurs de tous les domaines de la forêt. Ce point
signifie aussi que, finalement, un contrôleur d’un domaine donné est "en tout premier lieu" un contrôleur
de la forêt avant d’être aussi un contrôleur d’un domaine particulier.
Bien entendu, la forêt n’est opérationnelle qu’au travers du premier domaine installé. Ensuite, en fonction
des besoins ou des contraintes de chaque organisation, il sera possible d’y ajouter d’autres domaines. Ces
Page 251
domaines pourront faire partie de l’espace de noms initial ou d’un nouvel espace de noms par
l’intermédiaire d’une nouvelle arborescence, on peut dire aussi d’un nouvel arbre.
Par définition, tous les domaines d’une forêt donnée partagent :

 un schéma commun ;
 une configuration commune ;
 une étendue de recherche globale via les contrôleurs de domaine jouant le rôle de catalogue
global ;
 des relations d’approbation bidirectionnelles transitives représentant la structure logique de la
forêt.

Le schéma suivant illustre une instance Active Directory.

Structure d’une forêt Active Directory


Comme vous pouvez le constater sur cette figure, la forêt possède un domaine particulier situé au plus
haut de l’espace : le domaine racine de la forêt.
Le domaine racine de la forêt est le premier domaine installé. En fait, la mise en œuvre de la forêt
nécessite la mise en œuvre d’une arborescence, qui elle-même nécessite la mise en œuvre d’un domaine,
qui lui-même nécessite l’installation d’un ordinateur avec le statut de contrôleur de domaine et de
catalogue global Active Directory.
Nous avons vu précédemment quelles étaient les opérations de construction d’une nouvelle arborescence
réalisée par DCPromo. L’un des points importants est la création des objets TDO - Trusted Domain Object
- et des approbations de domaines.
Maintenant, si l’on regarde ce qui concerne la forêt, le point le plus important est bien sûr le domaine
racine de la forêt. Ce domaine joue le rôle de point de contrôle et de passage obligé pour de nombreuses
opérations à caractère global. Parmi ces opérations, nous pouvons citer tout ce qui concerne la gestion
des droits et de la configuration au niveau de la forêt et aussi la transitivité des authentifications entre les
domaines de la forêt à l’aide du protocole Kerberos version 5.

1. Critères, rôle et bon usage des forêts

Cette section a pour but de vous aider à faire les bons choix en fonction des différents contextes ou
scénarios que vous pourrez rencontrer. La question est "Quand est-il vraiment nécessaire de créer une
nouvelle forêt ?".
Ainsi, même s’il est vrai qu’une forêt est une instance complète de l’annuaire Active Directory, et si
Microsoft a depuis maintenant plusieurs années clamé le fait qu’une forêt représentait une entreprise
Page 252
"entière" ou une organisation au sens Exchange du terme, Microsoft a toujours laissé entendre que, plus
tard, il serait possible d’imaginer une plus grande interopérabilité dans les environnements composés de
plus d’une forêt.
Très logiquement, et même si la recommandation est de construire des infrastructures simples à
maintenir, le fait de créer plusieurs forêts peut permettre à une entreprise de disposer de plusieurs
zones d’autorités franches.
Ensuite, il sera possible de les connecter en créant des approbations externes ou des approbations de
forêts. Une telle évolution de stratégie permet de construire des solutions où chaque forêt de
l’entreprise peut être connectée avec les autres forêts de l’entreprise ou même des forêts appartenant à
des partenaires externes.
Cette approche permet de percevoir toutes les possibilités qui peuvent être associées aux forêts Active
Directory, lesquelles sont listées ci-dessous :

 La forêt Active Directory est un ensemble de domaines Active Directory. Pour information,
notez que les objets de type "domaine" sont techniquement des conteneurs basés sur les
classes domain, domainDNS et samDomain.
 La forêt Active Directory est un ensemble d’unités de réplications. Ces unités de réplications
sont directement issues des partitions prises en charge par chacun des domaines de la forêt.
 La forêt Active Directory est une frontière de sécurité et peut aussi être un conteneur de choix
pour envisager une délégation d’autorité à l’échelle de la forêt.

2. Configuration de la forêt et domaine racine

Dans l’environnement Windows 2000 Active Directory, il n’est pas possible d’effectuer des opérations de
changement importantes telles que la suppression, la modification ou le renommage du domaine racine
de la forêt. Dès la Beta 3 de Windows 2000, ces limitations étaient connues et Microsoft prévoyait déjà
que lors de la disponibilité de la prochaine version majeure de l’Active Directory, ces opérations
deviendraient certainement possibles.
Par rapport à Windows 2000 Server, Windows Server 2003 est disponible en tant que version "mineure
5.2" et par conséquent, seules certaines fonctionnalités sont disponibles. En effet, les services
d’annuaires Active Directory de Windows Server 2003 supportent que le domaine racine de la forêt soit
renommé ou restructuré, mais il ne pourra toujours pas faire l’objet d’une suppression.

À propos du renommage des domaines Active Directory : l’outil de renommage de domaines - Windows
Server 2003 Active Directory Domain Rename Tool, fournit une méthodologie pour changer le nom DNS et le
nom NetBIOS d’un domaine Active Directory. Attention au fait que de nombreuses contraintes existent ! Par
exemple, cet outil ne doit pas être utilisé dans les forêts disposant d’une organisation Exchange Server dont
les serveurs n’utilisent pas au minimum Exchange Server 2003 SP1. Pour plus d’informations concernant ces
opérations délicates, vous pouvez consulter le Webcast Microsoft intitulé "Microsoft Windows Server 2003:
Implementing an Active Directory Domain Rename Operation" en consultant l’article 819145.

Les domaines fonctionnant dans le niveau fonctionnel Windows Server 2008 sont soumis aux mêmes
contraintes ! Par exemple, l’installation des services AD CS - Active Directory Certificate Services, interdit les
opérations de renommage sur les serveurs Windows Server 2008.
Partitions de la forêt
Le domaine racine de la forêt est très important car il est utilisé pour nommer et localiser la partition de
configuration ainsi que la partition de schéma de la forêt.
Ainsi, pour le domaine racine corpnet.corporate.com, l’Active Directory montre les "DN" de ces deux
partitions de la façon suivante :
Pour la partition de configuration : cn=configuration,dc=corpnet,dc=corporate,dc=com
Pour la partition de schéma : cn=schema,cn=configuration,dc=corpnet,dc=corporate,dc=com
En fait, ces objets n’existent pas vraiment en tant qu’enfants du domaine racine de la forêt. De même, il
peut sembler que la partition de schéma soit contenue à l’intérieur de la partition de configuration, alors
qu’il n’en est rien !
En fait, l’idée est de faire en sorte que quel que soit le domaine de la forêt, ces partitions très
importantes soient référencées avec les mêmes noms. De cette manière, chaque contrôleur de domaine
de n’importe quel domaine de la forêt "détient" les partitions :
Page 253
 cn=configuration, DN du domaine Racine de la Forêt ;
 cn=schema,cn=configuration, DN du domaine Racine de la Forêt.

Les noms communs (DN - Distinguished Names) des partitions de configuration et de schéma fournissent
uniquement une vision logique de ces conteneurs et non une représentation physique de leur "emplacement"
Active Directory.
Création du domaine racine de la forêt
La mise en œuvre du domaine racine de la forêt permet de créer le DIT (Directory Information Tree)
initial qui servira de "squelette" à l’infrastructure des services d’annuaire Active Directory.
Ainsi, l’Assistant d’installation d’Active Directory - Dcpromo, réalise les opérations suivantes :

 Les conteneurs des partitions de schéma et de configuration sont créés.


 Les rôles de maîtres d’opérations - PDC Emulator, RID, Domain Naming, Schema et
Infrastructure sont affectés. Comme il s’agit du premier domaine installé, le premier contrôleur
du premier domaine de la forêt possède donc tous les maîtres d’opérations.
 Les groupes Administrateurs de l’Entreprise et Administrateurs de schéma sont créés
dans ce domaine. Cette opération est très importante puisque ces deux groupes permettent de
gérer l’infrastructure Active Directory toute entière, laquelle doit alors être considérée comme
une zone de sécurité uniquement liée à cette instance de l’Active Directory.

3. Activation des nouvelles fonctionnalités de forêt de Windows Server


2003 et de Windows Server 2008

Pour activer les nouvelles fonctionnalités disponibles au niveau d’une forêt, tous les contrôleurs de
domaine de la forêt devront fonctionner sous Windows Server 2003 puis vous devrez élever le niveau
fonctionnel de la forêt vers le niveau Windows Server 2003.
Pour pouvoir augmenter le niveau fonctionnel de la forêt vers le niveau Windows Server 2003, tous les
domaines de la forêt devront au préalable fonctionner dans le niveau fonctionnel de domaine Windows
Server 2003 ou Windows Server 2008. Ensuite, une fois que tous les domaines de la forêt
fonctionneront dans l’un de ces modes, vous aurez la possibilité d’atteindre le niveau fonctionnel de
forêt Windows Server 2003.

Il est possible d’augmenter le niveau fonctionnel de la forêt vers le niveau Windows Server 2003 alors que
certains domaines Active Directory fonctionnent en mode Windows 2000 natif ! Dans ce cas, les domaines
fonctionnant en mode natif Windows 2000 seront automatiquement rehaussés vers le niveau Windows
Server 2003 et ce, sans que vous en soyez prévenu ! Cette initiative sera prise "spontanément" s’il n’existe
plus de contrôleurs de domaine Windows 2000 Server dans aucun domaine de la forêt.

Le passage d’un domaine du mode natif Windows 2000 vers le mode Windows Server 2003 ne peut être
réalisé que si tous les contrôleurs de domaine fonctionnent sous Windows Server 2003. Le passage d’un
domaine fonctionnant en mode Windows Server 2003 vers le niveau fonctionnel Windows Server 2008 ne
peut être réalisé que si tous les contrôleurs de domaine fonctionnent sous Windows Server 2008. Comme
cela est le cas avec Windows 2000 pour le passage du mode mixte vers le mode natif Windows 2000, il est
impossible d’arrêter une opération en cours. Par conséquent, l’augmentation des niveaux fonctionnels des
domaines et des forêts est irréversible.
Modes des forêts et fonctionnalités supportées par Windows Server 2008
Les forêts fonctionnant dans le mode Windows Server 2008 supportent toutes les fonctionnalités du
niveau fonctionnel de forêt Windows Server 2003, mais pas de fonctionnalités supplémentaires.
Toutefois, tous les domaines qui sont ultérieurement ajoutés à la forêt fonctionneront par défaut au
niveau fonctionnel de domaine Windows Server 2008.

Pour simplifier l’administration, et si vous prévoyez de n’inclure que des contrôleurs de domaine exécutant
Windows Server 2008 dans toute la forêt, vous pouvez choisir ce niveau fonctionnel de forêt. En procédant
de cette manière, il ne sera jamais nécessaire d’augmenter le niveau fonctionnel des domaines que vous
créez dans la forêt.
Modes des forêts et fonctionnalités supportées par Windows Server 2003
Page 254
Les fonctionnalités réservées aux forêts Windows Server 2003 sont listées ci-dessous :
Améliorations de la réplication du catalogue global
Fonction désactivée en mode Windows 2000, sauf lorsque les catalogues globaux directement
partenaires de réplication fonctionnent sous Windows Server 2003.
Fonction disponible en mode Windows Server 2003.
Objets Schéma défunts
Fonction désactivée en mode Windows 2000.
Fonction disponible en mode Windows Server 2003.
Si le niveau fonctionnel de votre forêt a été augmenté au niveau Windows Server 2003, alors vous
pouvez redéfinir une classe ou un attribut après l’avoir désactivé. Pour rappel, sous Windows 2000, les
classes et les attributs ajoutés au schéma de base peuvent être désactivés sans augmenter le niveau
fonctionnel de la forêt, cependant, il ne sera possible de les modifier que si le niveau fonctionnel de la
forêt est Windows Server 2003 (ou supérieur).
Approbations de forêts
Fonction désactivée en mode Windows 2000.
Fonction disponible en mode Windows Server 2003.
Si le niveau fonctionnel de votre forêt a été augmenté au niveau Windows Server 2003, alors vous
pouvez connecter ou relier deux forêts Windows Server 2003 différentes à l’aide d’une relation
d’approbation transitive unidirectionnelle ou bidirectionnelle. Dans le cas où l’approbation créée est
bidirectionnelle, il est possible que chaque domaine de chacune des deux forêts s’approuvent. Les
approbations de forêt sont intéressantes car elles peuvent vous procurer les avantages suivants :

 Gestion simplifiée en réduisant le nombre d’approbations externes nécessaires.


 Relations bidirectionnelles complètes entre tous les domaines de chaque forêt.
 Support de l’ouverture de session via l’UPN (User Principal Name) entre deux forêts.
 Support des protocoles Kerberos version 5 et NTLM.
 Souplesse d’administration puisque chaque forêt est une zone de pouvoir.

Réplication de valeurs liées


Fonction désactivée en mode Windows 2000.
Fonction disponible en mode Windows Server 2003.
La réplication de valeurs liées (LVR - Listed Values Replication) permet de répliquer séparément les
différentes valeurs d’un attribut composé de multiples valeurs. Par exemple, sur les contrôleurs de
domaine Windows 2000, lorsqu’une modification est apportée à un membre d’un groupe, l’attribut
concerné doit être répliqué. La réplication LVR permet de répliquer de manière indépendante chaque
valeur modifiée et non plus le contenu du groupe tout entier. Comme pour les fonctionnalités déjà
décrites plus haut, vous devrez rehausser le niveau fonctionnel de la forêt à Windows Server 2003.
Changement de nom d’un domaine
Fonction désactivée en mode Windows 2000.
Fonction disponible en mode Windows Server 2003.
Alors qu’il avait toujours été possible de renommer les domaines Windows NT, et que Windows 2000 et
l’annuaire Active Directory apportaient une multitude de nouvelles fonctionnalités, l’affectation des noms
DNS aux domaines Windows 2000 devaient être correctement planifiée pour cause d’impossibilité de
renommer tout ou partie de la structure de domaines. Les serveurs Windows Server 2003 supportent
désormais cette fonctionnalité à la condition que tous les contrôleurs de domaine de la forêt
fonctionnent sous Windows Server 2003, que tous les domaines fonctionnent en mode Windows Server
2003 et que la forêt, elle aussi, fonctionne dans le niveau fonctionnel de forêt Windows Server 2003.
La fonctionnalité de renommage d’un domaine sera particulièrement utile si l’entreprise procède à une
acquisition ou pourquoi pas, à un changement de raison sociale. En fait, le changement des noms de
domaine permet d’effectuer toutes les opérations ci-dessous :

 changer les noms DNS et les noms NetBIOS de tout domaine d’une forêt, y compris le domaine
racine de la forêt ;

Page 255
 restructurer la position de tout domaine d’une forêt, sauf concernant le domaine racine de la
forêt qui demeure obligatoirement au plus haut de celle-ci ;
 restructurer la hiérarchie des domaines pour qu’un domaine situé dans une arborescence X
puisse être déplacé vers une arborescence Y.

L’utilitaire de changement des noms de domaine - Rendom.exe, permet les opérations de renommage d’un
domaine lorsque le domaine fonctionne en mode Windows Server 2003. Vous trouverez cet outil sur le CD-
Rom de Windows Server 2003 dans le répertoire Valueadd \Msft\Mgmt\Domren.

Attention au fait que le changement de nom d’un domaine a des effets importants sur tous les contrôleurs
dudit domaine. Avant d’utiliser cet outil, il est indispensable que vous consultiez la documentation relative au
Microsoft Domain Rename Tool sur le site Web de Microsoft à l’adresse ci-dessous :
http://www.microsoft.com/windowsserver2003/downloads/domainrename.mspx
Algorithmes de réplication Active Directory améliorés
Fonction désactivée en mode Windows 2000.
Fonction disponible en mode Windows Server 2003.
Les contrôleurs de domaines fonctionnant sous Windows Server 2003 améliorent de manière
significative les nombreuses fonctionnalités de Windows 2000. Ainsi, Windows Server 2003 améliore
l’utilisation de la mémoire et dispose d’un nouvel algorithme de gestion des sites Active Directory.
Ces améliorations permettent notamment aux grandes entreprises de supporter des infrastructures
composées d’un nombre de domaines et de sites plus importants. Nous découvrirons plus loin que
chaque site Active Directory dispose d’un contrôleur de domaine jouant le rôle de générateur de la
topologie intersites (ISTG - Inter Sites Topology Generator). Le fait de procéder à la mise à niveau d’un
contrôleur de ce type vers Windows Server 2003 améliorera les réplications et ce, même si les sites et
les domaines contiennent encore des contrôleurs de domaine Windows 2000.

La recommandation de Microsoft est de positionner sur chaque site un contrôleur de domaine fonctionnant
sous Windows Server 2003 et jouant le rôle de catalogue global et ISTG. Bien entendu, pour les clients qui
disposent d’un seul et unique contrôleur de domaine par site, cela signifie qu’il faudrait mettre à niveau tous
les contrôleurs.

Comme la majorité des nouvelles fonctionnalités apportées par Windows Server 2003 vise à améliorer et
optimiser le fonctionnement, il pourra être convenu de réaliser ces mises à niveau uniquement sur les sites
devant bénéficier de ces améliorations.
Attention au fait que certaines fonctionnalités ne pourront être activées que si la forêt est déclarée pour
fonctionner dans le niveau fonctionnel Windows Server 2003. Ce sera le cas du nouvel algorithme de
gestion des connexions intersites. Dans le cas d’une forêt Windows 2000, l’ISTG est limité à une
topologie de quelques centaines de sites au maximum, trois cent sites Active Directory. Les contrôleurs
Windows Server 2003 fonctionnant dans une forêt Windows Server 2003 peuvent désormais générer
une topologie de réplication pouvant atteindre trois mille sites.
En plus de cette nouvelle capacité, l’ISTG de chaque site devient capable de réaliser une sélection
aléatoire du ou des serveurs tête de pont du site pour répartir plus équitablement la charge de
réplication intersites à l’aide de l’outil Active Directory Load Balancing - adlb.exe, livré dans le Kit de
ressources techniques de Microsoft Windows Server 2003. Cette possibilité est bien entendu
particulièrement intéressante lorsqu’un site dessert de multiples autres sites en étoile.

À propos de l’ISTG, du KCC, des BHS et de ADLB (Active Directory Load Balancing) : le KCC - Knowledge
Consistency Checker, est un composant disponible sous Windows 2000 Server et Windows Server 2003. Son
rôle consiste à maintenir la topologie de réplication intra et intersites. En créant des objets de type
connexion, il peut ainsi ajuster la topologie physique en fonction de la disponibilité des contrôleurs de
domaines, des coûts de réplication et des heures d’ouverture des liens de sites. Le KCC réalise un contrôle
de la topologie de réplication toutes les 15 minutes et applique automatiquement les changements
nécessaires. Par définition, chaque site Active Directory possède (au moins) un contrôleur de domaine
jouant le rôle de ISTG, de KCC et aussi de serveur tête de pont (ou BHS pour Bridge Head Server). Sous
Windows 2000, le KCC ne peut disposer que d’un seul et unique BHS par site et par partition. Avec Windows
Server 2003, le KCC peut distribuer les réplications entre plusieurs serveurs BHS en créant ou en modifiant
les objets de connexion existants. Vous pourrez ensuite utiliser l’outil ADLB (Active Directory Load Balancing
Page 256
Tool) pour rééquilibrer la charge entre les différents BHS. Notez que dans le cas où l’un des serveurs BHS
deviendrait indisponible, le KCC aura la possibilité de modifier les objets de connexion modifiés par ADLB,
sauf dans le cas où les objets connexion disposent de calendriers pour que la charge de réplication sortante
de chaque serveur soit étalée régulièrement dans le temps.

Pour plus d’informations sur la réplication Active Directory et ses améliorations avec Windows Server 2003,
reportez-vous au site des Kits de ressources techniques Microsoft à l’adresse
http://www.microsoft.com/reskits ou consultez le site consacré à la réplication Active Directory à l’adresse
http://go.microsoft.com/fwlink/?LinkId=1646
Classes auxiliaires dynamiques
Fonction désactivée en mode Windows 2000.
Fonction disponible en mode Windows Server 2003.
Le support des classes auxiliaires dynamiques signifie qu’il est désormais possible de lier ces classes sur
des objets particuliers et non plus à des classes entières d’objets. Notez qu’il est aussi possible de les
supprimer de l’instance après coup.
Modification de la classe d’objets inetOrgPerson
Fonction désactivée en mode Windows 2000.
Fonction disponible en mode Windows Server 2003.
L’annuaire Active Directory supporte la classe d’objets inetOrgPerson et ses attributs, tel que spécifié
dans le RFC 2798. Microsoft a implémenté cette classe absente du schéma Windows 2000 pour offrir
une meilleure interopérabilité de l’annuaire Active Directory avec d’autres services d’annuaire LDAP et
X.500 non Microsoft, notamment concernant la migration des objets de ces annuaires vers Active
Directory. En fait, la classe inetOrgPerson est dérivée de la classe user et peut aussi être utilisée
comme entité de sécurité. Lorsque le domaine fonctionne en niveau fonctionnel Windows Server 2003, il
devient alors possible d’utiliser l’attribut userPassword avec la classe inetOrgPerson et aussi avec la
classe d’objets user. Notez que jusqu’à présent, le mot de passe d’un objet de la classe user était géré
à l’aide de l’attribut unicodePwd.

Les classes user et inetOrgPerson disposent toutes les deux des attributs userPassword et
unicodePwd. L’attribut userPassword est directement hérité de la classe Person tandis que l’attribut
unicodePwd est directement hérité de la classe user.
Ensemble de domaines mutuellement approuvés
Dans l’environnement Windows 2000, Microsoft "idéalise" l’entreprise à une seule forêt Active Directory,
expliquant que les environnements multiforêts présentent des restrictions et une moindre "plus-value"
par rapport à un environnement composé d’une seule et unique forêt.
C’est ainsi que dans les organisations composées de plusieurs zones de pouvoir, il pourra être judicieux
de créer une forêt par zone d’administration.
Les nouvelles possibilités de Windows Server 2003 permettent aujourd’hui de proposer des solutions
plus subtiles. En effet, il est aujourd’hui possible, en dehors des traditionnelles approbations externes,
de créer des approbations de forêts qui permettront aux entreprises nécessitant plusieurs forêts de
construire une solution plus ouverte.
Possibilité de déploiement d’un contrôleur de domaine en lecture seule exécutant Windows
Server 2008
Un contrôleur de domaine en lecture seule est un nouveau type de contrôleur de domaine Windows
Server 2008. Il accueille des partitions Active Directory en lecture seule. Les RODC, pour Read Only
Domain Controllers, permettent de déployer un contrôleur de domaine lorsque la sécurité physique ne
peut être garantie et qu’il est necessaire de garantir un haut niveau de sécurité. Avant de pouvoir
installer un contrôleur de domaine en lecture seule, le niveau fonctionnel de la forêt doit être défini sur
Windows Server 2003 ou sur Windows Server 2008. Lorsqu’il s’agit d’une forêt Windows Server 2003, le
schéma de la forêt doit être mis à niveau.

4. Unités de réplication et rôle des forêts

Une forêt est l’unité de réplication la plus large pouvant exister au sein d’une instance de l’annuaire
Active Directory. Les données à synchroniser sur les différents contrôleurs de domaines de la forêt
seront répliquées et synchronisées sur la base des partitions de l’annuaire Active Directory.
Page 257
Nous avons vu au chapitre traitant de l’intégration des zones DNS dans l’Active Directory qu’il existait
plusieurs partitions. Ces partitions ont pour objet d’organiser l’annuaire en différentes régions et ainsi de
mieux contrôler et maîtriser comment les réplications ont lieues au sein de la forêt.
L’annuaire Active Directory est composé de quatre grands types de données. De fait, il existe quatre
grands types de partitions qui seront utilisés pour y héberger ces données spécifiques :

 Les données qui concernent le domaine lui-même sont stockées dans la partition du domaine.
 Les données qui concernent la forêt toute entière sont stockées dans la partition de
configuration et la partition de schéma. Dans le cas des contrôleurs de domaine fonctionnant
sous Windows Server 2003, la forêt pourra aussi héberger un nouveau type de partitions
dédiées aux applications : les partitions de l’annuaire d’applications.

Bien entendu, les objets d’un domaine Active Directory seront stockés et répliqués dans la partition du
domaine vers tous les contrôleurs de domaine du domaine, tandis que des données relatives à des
objets de la configuration ou du schéma seront répliquées dans les partitions de configuration ou de
schéma vers tous les contrôleurs de domaine de la forêt.
Les différentes partitions et l’impact lié à la réplication au niveau de la forêt sont décrits ci-dessous :
Partition du schéma : chaque instance Active Directory est une unique forêt Active Directory, laquelle
contient une seule et unique version du schéma de l’annuaire de telle sorte qu’il ne peut exister qu’une
seule et unique définition à l’échelle de la forêt. Le schéma contient les définitions de chaque classe
d’objet sachant que celui-ci pourra être étendu en fonction des besoins de l’entreprise. Au même titre
que tous les objets des systèmes NT sont protégés par des ACLs, il en est de même pour les classes
d’objets déclarées dans le schéma.
Partition de configuration : chaque instance Active Directory contient une seule et unique
configuration de l’annuaire à l’échelle de la forêt. La configuration décrit la topologie et autres
paramètres de la forêt tels que la liste des domaines, des arborescences, des forêts ainsi que
l’emplacement des contrôleurs de domaines et catalogues globaux par rapport aux sites Active
Directory. Comme cela est le cas pour la partition de schéma, la partition de configuration est répliquée
sur tous les contrôleurs de domaines de la forêt.
Partitions de l’annuaire d’applications : les données spécifiques à des applications peuvent être
stockées dans des partitions de l’annuaire d’applications de l’Active Directory. À l’inverse des
applications d’entreprise telles que Microsoft Exchange Server ou Microsoft Systems Management Server
qui modifient le schéma puis s’intègrent dans les partitions de configuration et/ou de domaine, certaines
applications pourront stocker dans ces nouvelles partitions des données à caractère "moins global". De
cette manière, il est possible de créer des partitions spécifiques qui ne seront répliquées que vers les
contrôleurs de votre choix, quel que soit leur emplacement au sein de la forêt. L’un des principaux
avantages de ce nouveau type de partition est de pouvoir offrir aux applications une espace de stockage
hautement tolérant et globalement disponible à l’échelle de l’entreprise.
Fonctionnellement parlant, le moteur de réplication de l’annuaire Active Directory est multimaître. Ce
point signifie que tout objet peut être créé et aussi modifié sur tout contrôleur de domaine de la forêt. Il
s’agit bien sûr d’un concept général mais fondamental puisqu’il permet à l’annuaire Active Directory
d’être globalement extensible, disponible et administrable en tout point du réseau, sans dépendre d’un
unique maître tel que cela a toujours été le cas sous LAN Manager et Windows NT.
La granularité de réplication s’applique sur les objets, les attributs d’objets et aussi les valeurs
"multiples" propres à certains attributs. Ce dernier point concerne la réplication sur liste de valeurs,
encore appelée réplication LVR - Listed Values Replication.
À titre d’exemple, sur les contrôleurs de domaine fonctionnant sous Windows 2000, lorsqu’une
modification est apportée à un groupe - telle que l’ajout ou la suppression d’un membre - l’ensemble du
groupe doit être répliqué. Lorsque le domaine est élevé au niveau Windows Server 2003, alors la
réplication LVR est activée et, dans ce cas, seul le membre modifié est répliqué. De cette manière, il
n’est plus nécessaire de répliquer cet attribut particulièrement lourd sur les différents contrôleurs de
domaine du domaine.
Soyez cependant attentif au fait que les opérations à caractère unique contrôlées par les maîtres
d’opérations au niveau de la forêt font qu’il n’est pas possible de réaliser certaines opérations sur
n’importe quel contrôleur de domaine de la forêt, mais uniquement sur les contrôleurs de domaine
possédant le rôle FSMO particulier.
Attention : la réplication Active Directory respecte les exceptions liées aux cinq rôles FSMO que sont les
trois FSMO de chaque domaine auquel il conviendra d’ajouter les deux FSMO dédiés aux opérations de
forêt.

Page 258
Par conséquent, vous devez considérer que pour que la réplication soit pleinement opérationnelle à
l’échelle de la forêt, il est finalement nécessaire que les contrôleurs de domaine, les cinq maîtres
d’opérations simples (FSMO, Flexible Single Master Operations), la topologie intersites ainsi que les
machines jouant le rôle de catalogues globaux soient correctement configurés et, si possible,
opérationnels. Dans le cas où l’un de ces multiples éléments ferait l’objet d’une défaillance, alors les
services offerts par l’élément concerné ne seront plus disponibles et les cas suivants pourront se
produire :

 Si un contrôleur de domaine est absent sur un site, alors un autre contrôleur du site sera
sollicité.
 Si le seul contrôleur d’un site est absent, alors un autre contrôleur d’un autre site du même
domaine sera nommé pour "secourir" le site. Il sera ensuite sélectionné par les clients du site.
 Si les maîtres d’opérations de forêt sont indisponibles, alors les fonctions de schéma et de
création et de suppression de domaines au sein de la forêt seront indisponibles, sans pour
autant gêner le fonctionnement des domaines de la forêt.
 Si le catalogue global d’un site n’est pas disponible, alors un autre catalogue situé sur un autre
site sera choisi et sélectionné. Si aucun catalogue n’est disponible, alors les ouvertures de
session des utilisateurs pourront toujours avoir lieu, sauf pour les utilisateurs n’ayant jamais
ouvert de session de domaine à partir du contrôleur de domaine choisi, à moins que vous ayez
désactivé l’usage des GC pour les authentifications lorsque le domaine fonctionne en mode
Windows 2000 natif, en mode Windows Server 2003 ou en mode Windows Server 2008.

Attention : les membres du groupe Administrateurs du domaine ont toujours la possibilité de


s’authentifier vers le domaine lorsque les contrôleurs GC sont indisponibles. Cette possibilité permet aux
administrateurs du domaine de se connecter au domaine, même en mode dégradé, pour pouvoir
investiguer le problème.

5. Maîtres d’opérations FSMO de forêts

Nous avons vu précédemment que chaque domaine Active Directory disposait de trois maîtres
d’opérations au travers des PDC Emulator, RID Master et l’Infrastructure Master pour gérer les
opérations à caractère unique.
La même problématique se pose au niveau de la forêt qui possède donc deux rôles de maîtres
d’opérations simples. Au même titre que les rôles FSMO de domaine sont uniques au niveau de chaque
domaine, les rôles FSMO de forêt le sont à l’intérieur de la forêt. En d’autres termes, il ne peut exister
qu’un seul et unique contrôleur de schéma et un seul et unique maître d’attribution de noms de domaine
sur l’ensemble de la forêt.
Le maître d’opérations Contrôleur de schéma : le contrôleur de domaine jouant le rôle de
contrôleur de schéma contrôle toutes les opérations de mise à jour et de modification du schéma de
l’annuaire Active Directory. Par conséquent, pour mettre à jour le schéma d’une forêt, il faut
obligatoirement être capable de contacter la machine contrôleur de schéma. Comme expliqué plus haut,
il ne peut exister qu’un seul contrôleur de schéma pour une forêt donnée.
Le maître d’opérations Maître d’attribution de noms de domaine : le contrôleur de domaine
jouant le rôle de maître d’attribution de noms de domaine contrôle toutes les opérations d’ajout ou de
suppression de domaines dans la forêt. Comme cela est bien sûr le cas avec le contrôleur de schéma, il
ne peut exister qu’un seul maître d’attribution de noms de domaine pour une forêt donnée.

6. La forêt et l’infrastructure physique Active Directory

Nous venons de voir que la forêt Active Directory joue un rôle fondamental en tant qu’élément de la
structure technique de l’instance Active Directory. Pour mettre en œuvre le côté physique de
l’infrastructure technique de la forêt Active Directory, il nous reste à découvrir deux éléments
fondamentaux :
Les objets sites Active Directory : par définition, les sites représentent la structure physique du
réseau physique. À l’échelle de la forêt, les objets sites permettent de représenter la topologie réelle du
réseau en terme de zones de connectivité. Ainsi, les contrôleurs de domaines, serveurs et ordinateurs
clients membres du même site Active Directory seront animés par des communications plus rapides et
fréquentes que si les partenaires sont situés sur des sites différents. Les sites sont donc très importants
pour optimiser l’usage de la bande passante entre des contrôleurs situés sur des sites
géographiquement distants et connectés par des liens disposant d’une faible bande passante.

Page 259
Les contrôleurs de domaine catalogues globaux : par définition, les contrôleurs de domaine jouant
le rôle de catalogues globaux (ou GC pour Global Catalog) possèdent une copie de tous les objets de
tous les domaines de la forêt. Cependant, lorsqu’un contrôleur de domaine d’un domaine donné joue le
rôle de catalogue global de la forêt, il "connaît" naturellement tous les objets de son propre domaine
mais ne possédera qu’une copie partielle des objets issus des autres domaines de la forêt. Ce point
signifie que tous les objets sont connus, sans exception aucune, mais pas tous les attributs des dits
objets.

Les partitions présentes sur les GC issues des autres domaines de la forêt sont appelées des ensembles
d’attributs partiels ou PAS (Partial Attributes Set).
Ni les utilisateurs, ni les applications n’ont besoin de connaître les "détails" de la structure des domaines
et des arborescences de la forêt. Il leur suffit d’invoquer un des catalogues globaux de la forêt pour
trouver et localiser l’objet recherché sur la base des attributs les plus intéressants présents dans les
catalogues globaux.
Par défaut, le premier contrôleur de domaine du premier domaine de la forêt est le premier catalogue
global. Par exemple, la fenêtre suivante dirige une requête LDAP vers les catalogues globaux pour
rechercher dans Tout Active Directory une imprimante supportant l’impression en couleurs et le
format de papier A4.

La définition des zones DNS de l’Active Directory permet de localiser les différents services offerts au
sein de la forêt comme par exemple un contrôleur de domaine GC pour un site donné, via
l’enregistrement de ressource de service DNS _gc._tcp.NomdeSite._sites.NomdeForêt. Bien sûr,
"NomdeForêt" correspond au nom du domaine racine de la forêt et le protocole de transport déclaré sur
l’enregistrement de service DNS déclare l’usage du service _gc en TCP sur le port 3268, port utilisé par
les contrôleurs de domaine cumulant le fonction de catalogue global. Les catalogues globaux répondent
donc pour leur domaine sur le port TCP 389 et globalement pour la forêt sur le port TCP 3268.
Vous pourrez et devrez certainement déclarer d’autres catalogues globaux pour offrir les services de
recherche globaux à l’ensemble des utilisateurs et applications qui se trouveront sur les différents sites
géographiques de l’entreprise. De cette manière, il leur sera possible de :

 Rechercher "localement" des objets sur l’ensemble de l’annuaire Active Directory.


 Résoudre les suffixes de noms principaux lorsqu’un contrôleur de domaine doit authentifier un
utilisateur sur la base de son UPN - User Principal Name, tel que
BDurand@eu.corpnet.corporate.net.
 Résoudre les membres des groupes universels. Pour rappel, les groupes de distribution et de
sécurité de type universels sont stockés uniquement sur les contrôleurs de domaine jouant le
rôle de catalogues globaux.
 Résoudre les références vers des objets situés dans d’autres domaines de la forêt.

7. Frontières de sécurité et rôle des forêts

Page 260
Nous savons que dans un environnement composé de plusieurs domaines Windows NT, la plus haute
autorité de gestion, d’administration et de contrôle est le domaine. En effet, l’administrateur d’un
domaine donné peut, par essence même, décider de prendre possession de tout objet contrôlé dans le
cadre dudit domaine.
Concernant l’annuaire Active Directory, la question que nous devons nous poser est "Existe-t-il dans la
forêt une autorité suprême qui puisse s’approprier les objets situés dans d’autres domaines de la forêt
?". La réponse est "Oui !" en la personne d’un utilisateur qui sera membre du groupe des
Administrateurs de l’entreprise.

Attention : les membres du groupe des Administrateurs de l’entreprise peuvent contrôler tous les objets
de tous les domaines de la forêt. La protection des membres de ce groupe est très importante et dépend
essentiellement de l’administration du domaine racine de la forêt. Notez aussi que le groupe
Administrateurs de l’entreprise ainsi que le groupe des Administrateurs du schéma n’existent que
dans le domaine racine de la forêt.
Le conteneur situé au plus haut niveau de l’espace contrôlé étant la forêt, il paraît clair que des
administrateurs d’une forêt X ne pourront pas prendre le contrôle d’un objet qui sera situé dans un
domaine d’une autre forêt sauf, bien entendu, dans le cas où un administrateur de la forêt possédant
l’objet le souhaiterait.
Le schéma ci-après illustre la séparation des pouvoirs à l’échelle de la forêt. Chaque forêt dispose de son
propre groupe Administrateurs de l’entreprise et chaque forêt est par définition une frontière de
sécurité. Qu’il y ait ou non une approbation de domaine ou de forêt entre les domaines racines des deux
forêts, les membres du groupe Administrateurs de l’entreprise d’une forêt ne pourront pas prendre
possession des objets situés dans l’autre forêt.

Isolation de la sécurité des contrôles d’accès au niveau de l’entité de forêt


Délégation au niveau des forêts
Du fait que la forêt est une véritable unité isolée et autonome, il est possible pour les architectes Active
Directory de proposer la forêt comme un élément capable de jouer le rôle de frontière de sécurité et de
zone d’administration et de pouvoir. Nous venons de voir que les membres du groupe des
Administrateurs de l’entreprise ne peuvent pas prendre le contrôle des objets situés dans n’importe quel
domaine d’une autre forêt. À l’inverse, les Administrateurs de l’entreprise ont tous les pouvoirs sur tous
les domaines membres de la forêt et ce, même dans le cas où vous auriez retiré certains pouvoirs.

Attention : de par leur statut, les Administrateurs de l’entreprise auront toujours, par définition,
l’opportunité de se redonner directement tous droits manquants.
S’il est vraiment nécessaire de créer une nouvelle zone de sécurité pour disposer d’une réelle isolation,
la seule solution consistera à créer une nouvelle forêt et à déclarer manuellement les approbations
nécessaires en fonction des besoins et contraintes souhaitées.
Dans le cas où deux zones de pouvoirs distincts doivent être mises en place, créez deux forêts. Dans le
cas où chaque domaine nécessite une isolation totale, alors créez une forêt pour chacun des domaines

Page 261
nécessitant une isolation de la sécurité. Bien sûr, cette démarche ne va pas sans rappeler ce qui était
fait par le passé dans les environnements Windows NT, mais à situation exceptionnelle, solutions
exceptionnelles. Nous allons cependant voir plus loin que les approbations de forêts sont bien plus riches
et performantes que les anciennes relations d’approbation NT.
La mise en œuvre de l’isolation pourra se justifier dans les cas suivants :

 Vous devez sécuriser les accès à des données de manière exclusive à des utilisateurs d’une
forêt donnée.
 Vous devez disposer d’une isolation du schéma de l’annuaire.
 Vous devez scinder la partition de configuration en plusieurs entités pour isoler les évolutions
de configuration. De cette manière, les impacts liés aux changements de configuration de
l’Active Directory sont mieux maîtrisés.

8. Approbations au sein des forêts Active Directory

Par définition, les échanges relatifs aux authentifications et à la sécurité des contrôles d’accès au sein
d’une forêt sont pris en charge par les approbations internes de forêt. Ces approbations, créées par
dcpromo durant la phase de promotion, sont des approbations transitives bidirectionnelles capables de
prendre en charge les relations de type "Parent- enfant" et aussi "Racine d’arborescence" en mode
bidirectionnel et en supportant la transitivité :

 Le mode bidirectionnel permet au domaine X d’approuver le domaine Y et réciproquement.


 La transitivité implique que lorsque les domaines X et Y s’approuvent et que les domaines Y et
Z s’approuvent, alors les domaines X et Z s’approuvent aussi.

Une approbation (ou relation d’approbation) est une relation logique établie entre des domaines. Elle permet
une authentification directe au cours de laquelle un domaine autorisé à approuver honore les
authentifications d’ouverture de session d’un domaine approuvé. Les comptes d’utilisateurs et les groupes
globaux définis dans un domaine approuvé peuvent recevoir des droits et autorisations d’accès sur un
domaine approbateur, même si ces comptes n’existent pas dans le domaine autorisé à approuver.

a. Bénéfices apportés par la transitivité des approbations

La transitivité des approbations au sein des forêts Active Directory permet un accès inter-domaines
simplifié. Ce principe permet à l’ensemble des utilisateurs de la forêt une ouverture de session unique.
Le principe de l’ouverture de session unique est apparu en 1993 avec Windows NT 3.1. Cette
fonctionnalité fondamentale, qui permet à des contextes de sécurité différents d’avoir confiance les uns
envers les autres, simplifie la gestion des comptes utilisateurs et des groupes en ne nécessitant de les
créer qu’une seule fois. Ce concept est l’un des concepts fondamentaux qui permettent une
centralisation de la gestion des identités.
Le mode bidirectionnel rend service à l’infrastructure technique et est une facilité pour les
administrateurs.
Ces deux grands principes permettent à tous les domaines de la forêt de s’approuver mutuellement.
Dans ce cas, les authentifications validées dans un domaine donné deviennent potentiellement
acceptables dans tous les autres domaines de la forêt, toujours grâce à la transitivité et au côté
bidirectionnel des approbations internes. Dans la mesure où tout nouveau domaine de la forêt fait
l’objet d’une approbation, le nombre d’approbations nécessaires pour "brancher" n domaines d’une
forêt est égal à n-1.

Une forêt Active Directory est comparable à un environnement de domaines NT bâti sur un modèle de type
Modèle d’approbation total. En comparaison, vous pouvez noter que sous Windows NT, un modèle
composé de dix domaines nécessite de créer et maintenir n x n-1 domaines, c’est-à-dire quatre-ving dix
relations d’approbation unidirectionnelles non transitives. Dans un environnement Active Directory, le même
modèle ne nécessite que neuf relations d’approbation bidirectionnelles transitives, créées automatiquement,
c’est-à-dire dix fois moins !
Les approbations disponibles à l’intérieur d’une forêt Active Directory ont le même objet que dans
l’environnement Windows NT. Elles créent une relation entre deux domaines permettant ainsi aux
utilisateurs d’un domaine d’accéder à des ressources situées dans l’autre domaine et aux

Page 262
administrateurs d’un domaine de contrôler les ressources d’un autre domaine et vice versa, si
nécessaire.

Une approbation ne donne aucun droit ni aucune autorisation ! Elle permet uniquement à deux contextes de
sécurité distincts de participer "d’égal à égal" dans une négociation de la sécurité. C’est seulement dans un
deuxième temps que l’administrateur d’un domaine donné autorisera un utilisateur ou un groupe d’un autre
domaine à manipuler de telle ou telle manière une ressource particulière.

b. Structure de la forêt et approbations

Du point de vue de la structure de la forêt, chaque fois qu’un nouveau domaine est ajouté, une
nouvelle approbation interne bidirectionnelle transitive est créée automatiquement par dcpromo entre
le domaine parent et le domaine enfant.
Il en sera de même lors de la création d’une nouvelle arborescence grâce à la mise en place d’une
nouvelle approbation de type Racine d’arborescence.
L’écran suivant montre les propriétés du domaine corp2003.corporate.net. Ce domaine dispose d’une
approbation de type Racine d’arborescence et fait clairement apparaître sa nature transitive.

Approbation interne de type Racine d’arborescence transitive et bidirectionnelle

c. Approbations et objets TDO dans les forêts Active Directory

Il est intéressant de constater que la forêt étant la plus "haute" entité de sécurité autonome, il nous
est toujours possible de nous appuyer sur les relations d’approbation pour "créer et implémenter la
confiance" entre des espaces de sécurité distincts.
Les approbations vous permettront de réaliser tous les "branchements fonctionnels et technologiques"
que vous pourrez être amené à réaliser. Le concept même de la forêt repose sur les approbations.
Outre leur usage au sein de la forêt Windows 2000, Windows Server 2003 ou Windows Server 2008,
les approbations permettront le branchement des domaines Windows NT, Windows 2000 Server,
Windows Server 2003 et Windows Server 2008, des forêts Active Directory et aussi des domaines
Kerberos V5 non-Windows, c’est-à-dire fonctionnant principalement sous Unix.
Technologies, Protocoles d’approbation et objets TDO :

 Les contrôleurs de domaine fonctionnant sous Windows Server 2008, Windows Server 2003
et Windows 2000 Server utilisent les protocoles Kerberos v5 et NTLM pour authentifier les
utilisateurs et les applications. Par défaut, les ordinateurs Windows 2000, Windows XP
Professionnel et Windows Vista membres d’un domaine Windows 2000, Windows Server 2003

Page 263
ou Windows Server 2008 utilisent le protocole Kerberos v5. Dans le cas où un ordinateur ne
serait pas capable de négocier le protocole d’authentification Kerberos v5, alors le protocole
Windows NT NTLM sera utilisé.
 Le protocole Kerberos v5 est un protocole moderne dans la mesure où l’authentification
initiale permet aux clients de demander un ticket de demande de tickets. Les tickets ainsi
obtenus seront ensuite valides pour un service donné hébergé par un serveur particulier.
L’authentification Kerberos v5 est prise en charge par le contrôleur de domaine Active
Directory par le module AS (Authentication Service) tandis que la délivrance des tickets de
service est assurée par le module TGS (Ticket Granting Services). En fait, le contrôleur de
domaine joue le rôle d’autorité approuvée entre le client et le serveur. Finalement, le client
présente le ticket de service approuvé au serveur dans le domaine d’approbation pour
authentification.
 À l’inverse, le protocole Windows NT NTLM nécessite que le serveur contenant les ressources
contacte un contrôleur du domaine du client afin de vérifier les informations d’identification
du compte par rapport à celles contenues dans le jeton d’accès du client.
 Objets du domaine approuvé : Les relations d’approbation de chaque domaine sont
représentées au sein de l’Active Directory par des objets de type domaine approuvé (TDO,
Trusted Domain Objects). Chaque fois qu’une relation d’approbation est établie, un objet TDO
unique est créé et stocké dans le conteneur système de son domaine.

Les objets TDO sont des objets particulièrement importants dans la mesure où leurs attributs décrivent
toutes les caractéristiques de l’approbation qui peut exister entre deux domaines. Comme cela a été
expliqué précédemment, les objets TDO d’un domaine résident dans le container System dudit
domaine.

Objet de la classe trustedDomain pour le domaine partners.corporate.netde la forêt


corp2003.corporate.net
En fonction des circonstances pendant lesquelles les approbations seront créées, les objets TDO issus
de la classe trustedDomain seront créés par DCpromo, par la console de gestion MMC Domaines et
approbations Active Directory ou encore manuellement via la commande Netdom, disponible avec
les Outils de support de Windows Server 2003.
Les attributs de chaque objet TDO contiennent les informations qui précisent le type de l’approbation,
sa nature, la transitivité de l’approbation ainsi que les noms des domaines réciproques. Dans le cas
des approbations de forêts, les objets TDO stockent aussi des attributs supplémentaires pour identifier
tous les espaces de noms approuvés par la forêt de leur partenaire.
Vous trouverez ci-dessous les détails qui concernent les attributs les plus importants d’une approbation
au travers d’un objet TDO :
flatName : désigne le nom NetBIOS du domaine qui est associé à cette approbation.
trustDirection : désigne le sens de la relation d’approbation.

0 L’approbation est désactivée.

1 L’approbation est "entrante". Cela signifie que le domaine est autorisé à approuver.

Page 264
2 L’approbation est "sortante". Cela signifie que le domaine est approuvé.

3 L’approbation est à la fois entrante et sortante. Cela signifie que le domaine est approuvé et aussi
autorisé à approuver.

trustPartner : cet attribut représente le nom au format DNS associé au domaine lorsqu’il s’agit d’un
domaine Active Directory ou le nom NetBIOS du domaine, s’il s’agit d’une approbation de bas niveau,
c’est-à-dire Windows NT ou compatible NT.
trustType : cet attribut déclare le type de relation d’approbation établi avec le domaine.

1 Approbation de bas niveau NT ou compatible.

2 Approbation Windows 2000.

3 MIT.

4 DCE.

Les types d’approbation MIT (Massachusetts Institute of Technology) et DCE (Distributed Computing
Environment) permettent la prise en charge des différentes implémentations Kerberos disponibles dans les
environnements Unix. Les implémentations MIT et DCE du protocole Kerberos sont largement distribuées sur
les systèmes Unix tels que AIX, Solaris, HPUX et bien d’autres.

L’attribut securityIdentifier d’un objet TDO déclare le SID de l’objet


À l’aide d’ADSI Edit, l’écran précédent illustre les attributs d’un objet TDO représentant une
approbation d’arborescence. Ces attributs comprennent les noms des différentes arborescences, les
suffixes de noms d’utilisateurs principaux (UPN, User Principal Name), les suffixes de nom principal de
services (SPN, Service Principal Name) et les espaces de noms d’ID de sécurité (SID, Security ID).

d. Types d’approbation supportés

Page 265
Nous venons de rappeler que les approbations permettent la communication entre les domaines. Ainsi,
les approbations jouent le rôle de canaux d’authentification nécessaires aux utilisateurs d’un domaine
X pour accéder aux ressources d’un domaine Y. Lorsqu’un nouveau domaine est ajouté à une forêt
existante, deux approbations sont créées par l’Assistant Installation de l’Active Directory. Les
différents types d’approbation pouvant être créés à l’aide de l’Assistant Nouvelle approbation ou de
l’outil de ligne de commande Netdom sont présentés ci-dessous :
Approbations internes créées par DCPromo
Lorsqu’un nouveau domaine est ajouté au domaine racine de la forêt ou en tant que nouvelle
arborescence via l’Assistant Installation de l’Active Directory, des approbations transitives
bidirectionnelles sont automatiquement créées.
Ces approbations peuvent être de deux types différents :
Approbations de type Parent-Enfant : lorsqu’un nouveau domaine enfant est ajouté à une
arborescence de domaine existante, une nouvelle relation d’approbation parent-enfant transitive
bidirectionnelle est établie. Les requêtes d’authentification effectuées à partir des domaines approuvés
remontent vers le haut de la hiérarchie de domaines, en passant par leur parent, jusqu’au domaine
autorisé à approuver.
Approbations de type Racine d’arborescence : lorsqu’une arborescence de domaine est créée
dans une forêt existante, une nouvelle approbation de racine d’arborescence transitive bidirectionnelle
est établie par défaut.

Les approbations créées par dcpromo sont indestructibles. Ces approbations ne peuvent donc pas être
détruites lors d’une erreur d’administration.
Les autres types d’approbations de l’Active Directory
L’Active Directory supporte quatre autres types d’approbations. Vous pourrez créer ces approbations à
l’aide de l’Assistant Nouvelle approbation ou via la commande Netdom. Ces approbations sont les
approbations externes, les approbations de domaine Kerberos, les approbations de forêts et les
approbations raccourcies.

Déclaration d’une approbation via la console Domaines et approbations Active Directory


Les approbations externes sont par définition non transitives et peuvent être unidirectionnelles ou
bidirectionnelles. Une approbation externe est utilisée pour accéder à des ressources situées dans un
domaine Windows NT 4.0 ou un domaine se trouvant dans une autre forêt (non liée par une
approbation de forêt).

Page 266
Les approbations de domaine Kerberos v5 sont par définition transitives ou non transitives et
peuvent être unidirectionnelles ou bidirectionnelles. Une approbation de domaine Kerberos v5 permet
à un domaine Windows Active Directory et un domaine Kerberos non-Windows d’interopérer.
Les approbations de raccourcis sont transitives et peuvent être unidirectionnelles ou
bidirectionnelles. Les approbations de ce type permettent de raccourcir le chemin d’authentifications
Kerberos à l’intérieur d’une forêt. Ce sera particulièrement intéressant pour améliorer les ouvertures
de session entre deux domaines lorsque les deux domaines sont situés dans des arborescences
différentes.
Les approbations de forêts sont par définition transitives et peuvent être unidirectionnelles ou
bidirectionnelles. Une approbation de forêts permet de "marier" deux forêts. De cette manière, il est
possible de partager des ressources entre les deux forêts c’est-à-dire entre tous les domaines de
chaque forêt.

e. Forêts Windows Server (2003 ou 2008) et approbations de forêts

Les approbations de forêts sont une nouvelle fonctionnalité des services d’annuaire de Windows Server
2003 toujours utilisables à l’identique dans les forêts Windows Server 2008. Le principe fondamental
est basé sur l’utilisation de la transitivité des approbations Kerberos v5.
En effet, les domaines Windows NT et les domaines Active Directory fonctionnant sous Windows 2000
ne permettent pas aux utilisateurs d’une forêt d’accéder aux ressources qui seraient situées dans une
autre forêt. Ce point s’explique par le fait que, dans une forêt fonctionnant en mode Windows 2000, la
transitivité des approbations Kerberos n’est disponible que dans le cas des approbations internes à la
forêt.
Ainsi, parce que les approbations externes sont par définition unidirectionnelles et non transitives, il ne
sera pas possible que le chemin de l’approbation puisse s’étendre aux autres domaines de la forêt
cible.
Aujourd’hui, lorsque l’environnement est composé de deux forêts fonctionnant dans le niveau
fonctionnel Windows Server 2003 et/ou Windows Server 2008 et qu’une approbation de forêts existe
entre les deux domaines racines des forêts respectives, alors les authentifications peuvent être routées
entre tous les domaines des deux forêts. L’approbation de forêts permet alors un accès des utilisateurs
de la forêt approuvée à toutes les ressources du réseau de la forêt approuvante, bien évidemment à la
condition que les utilisateurs approuvés disposent des autorisations adéquates.
Les entreprises qui disposent de plus d’une forêt pourront alors profiter des avantages ci-dessous :
Un nouvel élément de structure : la forêt peut devenir un conteneur utilisable dans le cadre de la
politique de délégation de l’entreprise. De cette manière, il pourra être envisagé de scinder
l’administration en plusieurs entités.
Une administration plus simple : la transitivité des approbations de forêts permet de limiter le
nombre d’approbations externes nécessaires au partage des ressources entre les domaines des deux
forêts.
Les utilisateurs des deux forêts peuvent utiliser les authentifications basées sur les UPN, telles que
BDurand@eu.corpnet.corporate.com.
Le protocole Kerberos mais aussi NTLM peuvent être utilisés au sein de chaque forêt mais aussi entre
les deux forêts.
Approbations de forêts et niveau fonctionnel des forêts

Les approbations de forêts nécessitent obligatoirement que les deux forêts partenaires fonctionnent
dans le niveau fonctionnel Windows Server 2003 et/ou Windows Server 2008. Tous les domaines
doivent donc utiliser le niveau fonctionnel de domaine Windows Server 2003 ou ultérieur, lequel
nécessite que tous les contrôleurs de domaine fonctionnent sous Windows Server 2003 ou ultérieur.
Bien que le protocole Kerberos soit le seul protocole capable de supporter la transitivité au sein de la
forêt mais aussi entre deux forêts, les serveurs Windows NT Server 4.0 membres de domaines
Windows Server 2003 ou Windows Server 2008 pourront prendre en charge les contrôles d’accès issus
d’une autre forêt. Cette possibilité est réalisée par les contrôleurs de domaine Windows Server (2003
ou 2008) qui jouent le rôle de passerelles d’authentification entre les protocoles Kerberos et
NTLM.Notez que cette fonctionnalité était déjà présente sur les contrôleurs de domaine Windows 2000.
Ainsi, un utilisateur authentifié à l’aide du protocole Kerberos peut, sans aucun problème, être contrôlé
en NTLM pour accéder à une ressource contrôlée par un serveur Windows NT Server 4.0

Page 267
Possibilités, limites et cadre d’utilisation des approbations de forêts

f. Routage des suffixes de noms et approbations de forêts

Le routage des suffixes de noms permet de gérer la façon dont les requêtes d’authentification sont
transmises et dispatchées entre des forêts Windows Server 2003 disposant d’approbations de forêt.
Dans la mesure où le premier besoin consiste à profiter de la transitivité des approbations de forêts,
par défaut, tous les suffixes de noms uniques sont routés. De cette manière, l’administration des deux
forêts partenaires peut être grandement simplifiée et tous les utilisateurs d’une forêt donnée peuvent -
peut-être - accéder à des ressources situées dans n’importe quel domaine de l’autre forêt.
Cette configuration initiale pourra cependant être personnalisée pour permettre de "mieux" contrôler
les demandes d’authentification approuvées par l’une des forêts. En effet, deux forêts peuvent être
associées grâce à une approbation de forêt tout en excluant certains domaines.
Par définition, une forêt est un espace de noms uniques matérialisé par des suffixes de noms uniques.
Un suffixe de nom unique est un nom au sein d’une forêt, tel qu’un UPN (User Principal Name) un SPN
(Service Principal Name), ou le nom DNS du domaine racine de la forêt ou d’une arborescence de
domaine. Les noms ci-dessous sont des exemples de suffixes de noms uniques :

 Rootcorp.corporate.com ;
 Emea.rootcorp.corporate.com ;
 Partners.net ;
 BDurand@extranet.rootcorp.corporate.com ;
 Svc1$@rootcorp.corporate.com.

D’un point de vue du fonctionnement de l’approbation de forêts, tous les enfants de tous les suffixes
connus de la forêt sont naturellement routés vers l’autre forêt. C’est pour cela que l’interface
graphique de la console de gestion MMC Domaines et approbations Active Directory montre tous
les suffixes de noms connus avec le caractère astérisque (*).
Par exemple, si la forêt utilise comme suffixe de noms *.rootcorp.corporate.com, alors toutes les
requêtes d’authentification portant sur les domaines enfants de rootcorp.corporate.com telles que
*.emea.rootcorp. corporate.com, seront routées via l’approbation de forêt.

Attention : très logiquement, tout suffixe de nom enfant hérite de la configuration de routage du suffixe de
nom unique auquel il appartient. Cependant, le routage des nouveaux suffixes apparus après la création de
l’approbation de forêts sera par défaut désactivé. Cette façon de procéder est la plus sécurisée qui soit. En
effet, il ne serait pas normal qu’un nouveau domaine au sein d’une forêt soit automatiquement approuvé
sans qu’aucune validation n’ait eu lieu. Vous pourrez donc, dans un deuxième temps, visualiser les nouveaux
suffixes de noms issus des nouveaux domaines intégrés après la mise en place de l’approbation de forêts et
seulement ensuite décider d’activer ou non le routage des authentifications.

Page 268
Pour visualiser ou modifier le routage des noms de suffixes, vous pourrez utiliser la boîte de dialogue
Propriétés de l’approbation de forêt. La sélection des suffixes de noms spécifiques vous permettra
d’activer ou désactiver le routage des authentifications vers la forêt partenaire.
Détection des suffixes dupliqués, gestion des conflits et désactivation automatique
Il n’est pas impossible que des noms de domaines identiques puissent exister dans deux forêts
différentes. Ce pourrait, par exemple, être le cas de domaines utilisant des noms génériques tels que
partners.net ou encore extranet.privnet.net. Il faut donc que l’approbation de forêt puisse gérer cette
exception.
Dans le cas où cette problématique serait rencontrée, le routage du suffixe de nom le plus récent sera
automatiquement désactivé.

Microsoft recommande de ne pas ajouter de caractère @ au suffixe UPN déclaré, ni de nom d’utilisateur. En
effet, le traitement des requêtes d’authentification routées vers une forêt approuvée considère les caractères
situés à gauche du caractère @ comme le nom de l’utilisateur et les caractères situés à droite du caractère
@ comme le nom DNS du domaine. L’Autorité de sécurité locale LSASS, désactive le routage à tout suffixe
UPN ne respectant pas le format DNS, ce qui sera le cas si un caractère @ est présent dans le nom.
Notez que seuls les noms respectant le nommage DNS doivent être déclarés. Par conséquent, tout
nom incompatible entraînera sa désactivation automatique.
Les opérations de conflits proprement dites sont appelées des collisions. Les collisions peuvent se
produire lorsque le même nom DNS, le même nom NetBIOS ou lorsque le SID d’un domaine est en
conflit avec une autre SID de suffixe de nom.
Bien sûr, ces points paraissent évidents ! Cependant, il convient de faire particulièrement attention aux
problèmes de noms de domaines DNS. En effet, comme tout conflit entraînera la désactivation du nom
au niveau de l’approbation de forêt, il convient d’anticiper au mieux les effets des erreurs de
nommage.
Exemple de conflit : nous savons que les domaines corpnet.corporate.com et corporate.com sont des
domaines DNS différents. Au sein de la même forêt, ces deux domaines DNS forment une
arborescence de domaines au sein de la forêt dont le domaine racine est corporate.com. Si l’on
considère que les deux domaines appartiennent à deux forêts distinctes, il n’y a aucun problème tant
qu’il n’y a pas d’approbation ou pas d’approbation de forêts. Cette remarque signifie qu’il est tout à fait
possible de créer une approbation externe entre les deux domaines. Par contre, il y aura conflit si la
forêt nommée corporate.com et la forêt nommée corpnet.corporate.com sont réunies à l’aide d’une
approbation de forêts. En effet, comme ces deux domaines appartiennent au même espace DNS, le
routage entre ces deux suffixes de noms sera désactivé. Notez toutefois que le routage continuera de
fonctionner pour tous les autres suffixes de noms uniques non conflictuels.
L’écran ci-après illustre les suffixes de noms UPN déclarés sur la forêt corp2003.corporate.net.

Page 269
La détection de conflits des approbations de forêts concerne aussi les suffixes UPN
Lorsqu’un conflit - de quelque nature qu’il soit - est détecté, les contrôles d’accès à ce domaine seront
refusés depuis l’extérieur de la forêt. Toutefois, le fonctionnement normal au sein de la forêt sera
préservé, ce qui est tout à fait normal, puisque le conflit n’a de signification qu’entre les deux forêts et
aucunement entre les domaines de la forêt d’appartenance.
L’onglet Routage des suffixes de noms disponible dans la console de gestion MMC Domaines et
approbations Active Directory au niveau des propriétés des approbations de forêt vous permettra
d’enregistrer un fichier journal des conflits des suffixes de noms. Ce fichier pourra être créé pendant
ou après la création de l’approbation de forêt.

Pour plus d’informations sur les approbations et le fonctionnement des forêts et domaines Active Directory,
consultez le site : http://www.microsoft.com/resources/documentation/WindowsServ/
2003/all/techref/enus/default.asp ou la documentation Active Directory Technical Reference disponible
sur le site des Kits de ressources techniques à l’adresse http://www.microsoft.com/reskits.

g. Utilisation de la commande Netdom pour créer et gérer les approbations

Généralement, les approbations internes, externes et de forêts sont directement déclarées à l’aide de
l’interface graphique. Cependant, vous pourez utiliser la commande Netdom.exe disponible avec les
outils de support de Windows Server 2003 pour créer, vérifier, réinitialiser et supprimer des objets
approbations.
Opérations prises en charge par Netdom concernant les approbations :

 Mise en place des approbations unidirectionnelles ou bidirectionnelles entre les domaines


Windows NT 4.0, Windows 2000 et Windows Server 2003.
 Mise en place des approbations unidirectionnelles ou bidirectionnelles entre des domaines
Windows 2000 Server, Windows Server 2003 ou Windows Server 2008, situés dans des
organisations différentes.
 Mise en place des approbations racourcies entre des domaines Windows 2000 Server,
Windows Server 2003 ou Windows Server 2008 situés dans la même organisation.
 Mise en place d’une approbation vers un royaume Kerberos non-Windows.

Page 270
 Énumération des approbations directes et indirectes.
 Visualisation des paramètres et changements des paramètres des approbations.

Vous pourrez, par exemple, utiliser la commande Netdom :

 Pour vérifier une approbation unidirectionnelle entre le domaine DomA et le domaine DomB :
netdom trust /d:DomA DomB /verify
 Pour vérifier une approbation bidirectionnelle : netdom trust /d:DomA DomB /verify
/twoway

L’opération de vérification a pour objet de contrôler le bon fonctionnement de l’approbation ainsi que
les mots de passe déclarés entre les deux domaines lors de la mise en place de l’approbation.

 Pour vérifier que le protocole Kerberos v5 est pleinement opérationnel entre un ordinateur et
son domaine d’appartenance dom1.corporate.com : netdom trust /d:dom1.
corporate.com /verify /KERBEROS. L’usage des paramètres /verify et /kerberos nécessite
l’obtention d’un ticket de session pour contacter le service d’administration Kerberos du
contrôleur de domaine (service KDC) dans le domaine cible. À partir du moment où
l’opération réussit, vous pouvez considérer que toutes les opérations Kerberos peuvent
fonctionner correctement entre l’ordinateur client et le domaine de destination.

Cette opération de vérification des fonctions Kerberos ne peut être réalisée que localement sur l’ordinateur à
tester. Vous pourrez dans ce cas utiliser les fonctions de Bureau à distance.
La commande Netdom permet de gérer les approbations mais permet aussi de gérer les opérations ci-
dessous :

 Insérer un ordinateur Windows XP Professionnel dans un domaine quel que soit son type avec
la possibilité de spécifier l’unité d’organisation et de générer le mot de passe du compte
d’ordinateur aléatoirement.
 Gérer les opérations d’administration des comptes d’ordinateurs telles que l’ajout, la
suppression, l’interrogation, le déplacement des comptes d’ordinateurs d’un domaine à un
autre en préservant le SID de l’ordinateur.
 Vérifier les SC (Secure Channel) entre les postes de travail, les serveurs, les BDC NT 4.0.
 Renommer et déplacer les BDC NT4.0 dans d’autres domaines.

Toutes ces fonctions sont bien sûr très utiles dans le cadre de la maintenance des comptes
d’ordinateurs, qu’il s’agisse de simples ordinateurs de bureaux ou de serveurs membres du domaine.

Réussir le processus de mise à niveau d’Active Directory vers


les services de domaine Active Directory de Windows Server
2008
Windows Server 2008 est une version majeure à plus d’un titre et, de fait, on pourrait penser que
l’installation de nouveaux contrôleurs de domaine Active Directory, voir la mise à niveau de serveurs
Windows Server 2003 vers Windows Server 2008 soient des tâches complexes nécessitant une grande
préparation.
Il n’en n’est rien et vous allez voir qu’avec un minimum de préparation, le déploiement de nouveaux
contrôleurs de domaine Active Directory sera simple et avec un minimum de risques.
L’objectif principal de la mise à niveau vers Windows Server 2008 doit permettre de procéder à une
transition douce de l’environnement actuellement en production vers une cible composée d’au moins deux
contrôleurs de domaine (ou plus) en fonction de l’architecture Active Directory, fonctionnant sous
Windows Server 2008.

Le processus de migration vers les services de domaine Active Directory de Windows Server 2008 doit avoir
comme objectif final - à terme - la possibilité de rehausser le niveau fonctionnel du ou des domaines vers le
niveau fonctionnel Windows Server 2008, sans oublier bien sûr d’en faire de même concernant le niveau
fonctionnel de la forêt.

Page 271
1. Vérifications et gestion des risques

Avant de commencer les différentes opérations propres à l’intégration de contrôleurs de domaine


fonctionnant sous Windows Server 2008 au sein d’un réseau Windows Server 2003, il est recommandé
de procéder aux opérations ci-dessous :

 Faites un inventaire précis de tous les contrôleurs de domaine importants notamment, le


positionnement des cinq rôles FSMO, des catalogues globaux ainsi que les niveaux de SP
(Services Packs) installés sur chacun d’eux.
 Faites une sauvegarde de type System State d’un ou plusieurs contrôleurs de domaine
opérationnels.
 Déterminez le meilleur scénario de retour arrière, en prévision d’une éventuelle catastrophe.

2. Préparation de l’infrastructure Active Directory pour Windows Server


2008

Comme cela a été le cas par le passé lors des migrations de domaine Windows NT 4.0 vers les services
d’annuaire Active Directory de Windows 2000 Server et ensuite vers les services d’annuaire Active
Directory de Windows Server 2003, l’infrastructure Active Directory doit être préparée pour accueillir les
nouveaux serveurs Windows Server 2008 hébergeant les nouveaux services AD DS. Les
recommandations et opérations ci-dessous devront donc être réal