Configuration d'une infrastructure Active Directory avec Windows Server 2008

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.

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

© ENI Editions - All rigths reserved

- 1-

À 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 

© ENI Editions - All rigths reserved

- 1-

À 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. 

© ENI Editions - All rigths reserved

- 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é. 

© ENI Editions - All rigths reserved

- 1-

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. 

© ENI Editions - All rigths reserved

- 1-

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 

●

Server Core Installation Option 

© ENI Editions - All rigths reserved

- 1-

- 2-

●

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 

© ENI Editions - All rigths reserved

●

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  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. 

© ENI Editions - All rigths reserved

- 3-

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.  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 

- 4-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 5-

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  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 

© ENI Editions - All rigths reserved

- 1-

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 

- 2-

© ENI Editions - All rigths reserved

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 

Système de stockage réparti. 

Stockage des données d’annuaire unifié nécessitant  peu de tâches administratives. 

Extensibilité de l’annuaire. 

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

Administration centralisée et délégation. 

Contrôle des privilèges d’administration et des  paramètres de sécurité de manière hiérarchique à  l’échelle de l’entreprise. 

Disponibilité des informations de l’annuaire, tolérance  de panne, hautes performances. 

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 la  topologie de réplication et au mode de réplication  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 à l’aide de la technologie IntelliMirror. 

Cohérence des paramètres appliqués et opérations  réalisées grâce aux stratégies de groupe.  

Services de sécurité à l’échelle des entreprises de  toutes tailles via le support de Kerberos v5, SSL  (Secure Socket Layer) 3.0, TLS (Transport Layer  Security) et les services de clés publiques (PKI ­ Public  Key Infrastructure et certificats X509 V3). 

Les services d’authentification et de contrôle des  accès assurent une prise en charge au sein du réseau  privé et aussi sur Internet. 

© ENI Editions - All rigths reserved

- 1-

- 2-

Gestion de la sécurité et délégation de gestion de  l’administration. 

La granularité descend jusqu’à l’attribut et l’étendue  de management s’exerce sur les objets de types Site,  Domaine et OU. 

Support des standards de l’Internet : un domaine  Windows est un domaine DNS (Domain Name System),  un domaine d’authentification est un royaume  Kerberos, les certificats sont utilisables de manière  naturelle pour l’authentification (ouverture de session  par carte à puce (Smart logon) et la sécurisation des  informations (signatures numériques et chiffrement  des données locales et transitant sur le réseau). 

L’entreprise est assurée d’une pérennité de ses choix  de par la participation active de Microsoft aux  standards de l’industrie. TCP/IP v4 et v6, DNS, DDNS  (Dynamic DNS), IPSec, DHCP (Dynamic Host  Configuration Protocol), Kerb5, Radius (Remote  Authentication Dial­in User Service), EAP (Extensible  Authentication Protocol), PEAP (Protected EAP), LDAP  (Lightweight Directory Access Protocol), LT2P (Layer 2  Tunneling Protocol), PPTP (Point to Point Tunneling  Protocol), SSL3, TLS, Infrastructure à clés publique  (PKI), certificats X509 V3 et authentification par cartes  à puce. 

© ENI Editions - All rigths reserved

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) 

●

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 

© ENI Editions - All rigths reserved

- 1-

●

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. 

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 ? 

- 2-

© ENI Editions - All rigths reserved

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".  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. 

© ENI Editions - All rigths reserved

- 3-

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 

Lecteur 

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 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 :  ●

Utilisez un ordinateur type Intel Core 2 Duo ou AMD équivalent ou supérieur équipé de 2 Go de RAM et d’un 

© ENI Editions - All rigths reserved

- 1-

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. 

- 2-

© ENI Editions - All rigths reserved

É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  Remarquez que les principales versions de Windows Server 2008 sont disponibles sur un seul DVD. 

© ENI Editions - All rigths reserved

- 3-

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 

- 4-

© ENI Editions - All rigths reserved

É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). 

© ENI Editions - All rigths reserved

- 5-

É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. 

É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. 

- 6-

© ENI Editions - All rigths reserved

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 domaine. 

Suffixe DNS principal 

<nom de connexion réseau 1>: 

Adresse IP : 

<nom de connexion réseau 2>: 

Adresse IP : 

<nom de connexion réseau 3>: 

Adresse IP : 

État d’activation de produit Windows : 

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

ID de produit (si active) : 

ID de produit    © ENI Editions - All rigths reserved

- 7-

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. 

État de Windows Update 

Affiche si le serveur est configuré pour télécharger et  installer des mises à jour logicielles Windows  automatiquement. 

Dernière recherche de mises à jour 

Affiche le jour et l’heure de la dernière vérification par  le serveur de la présence de mises à jour logicielles. 

Dernières mises à jour installées 

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

Configuration de sécurité renforcée d’Internet  Explorer 

Indique si la configuration de sécurité avancée  d’Internet 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  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. 

- 8-

Accédez au Centre de réseau et partage. 

© ENI Editions - All rigths reserved

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) : 

4. 

●

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 

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)  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 

© ENI Editions - All rigths reserved

- 9-

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. 

- 10 -

© ENI Editions - All rigths reserved

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.  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).  © ENI Editions - All rigths reserved

- 1-

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 : 

- 2-

●

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é. 

© ENI Editions - All rigths reserved

●

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. 

●

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. 

© ENI Editions - All rigths reserved

- 3-

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). 

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. 

- 4-

© ENI Editions - All rigths reserved

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 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 : 

© ENI Editions - All rigths reserved

- 5-

●

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  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 :  ●

- 6-

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. 

© ENI Editions - All rigths reserved

●

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. 

© ENI Editions - All rigths reserved

- 7-

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  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. 

© ENI Editions - All rigths reserved

- 1-

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.  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/. 

- 2-

© ENI Editions - All rigths reserved

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". 

© ENI Editions - All rigths reserved

- 3-

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 

Start of Authority (SOA) 

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 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.  

Host (A) 

Identifie l’adresse IP d’un nom d’hôte spécifique. Cet  enregistrement d’adresse IP de l’hôte mappe un nom  de domaine DNS complet vers une adresse IP version  4 de 32 bits. 

Pointer (PTR) 

Identifie les noms d’hôte par rapport à une adresse IP  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.  

Mail Exchanger (MX) 

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

Service Locator (SRV) 

Identifie un service offert au niveau du domaine Active  Directory. L’annuaire Active Directory fait un usage  avancé de 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". 

© ENI Editions - All rigths reserved

- 1-

- 2-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 1-

●

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. 

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 : 

- 2-

●

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.  © ENI Editions - All rigths reserved

●

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. 

●

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. 

© ENI Editions - All rigths reserved

- 3-

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.  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. 

- 4-

© ENI Editions - All rigths reserved

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.  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  © ENI Editions - All rigths reserved

- 5-

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.  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 :  ●

- 6-

privnet.corporate.com, pour implémenter un sous­domaine de l’espace existant officiellement déclaré. 

© ENI Editions - All rigths reserved

●

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.  

eu.partners.com 

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

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

  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 

© ENI Editions - All rigths reserved

- 7-

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 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  - 8-

© ENI Editions - All rigths reserved

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. 

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  © ENI Editions - All rigths reserved

- 9-

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. 

●

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. 

- 10 -

© ENI Editions - All rigths reserved

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.  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. 

© ENI Editions - All rigths reserved

- 11 -

  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. 

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  - 12 -

© ENI Editions - All rigths reserved

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). 

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 

© ENI Editions - All rigths reserved

- 13 -

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). 

●

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. 

- 14 -

© ENI Editions - All rigths reserved

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  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. 

© ENI Editions - All rigths reserved

- 15 -

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

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. 

- 16 -

© ENI Editions - All rigths reserved

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.  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. 

© ENI Editions - All rigths reserved

- 17 -

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.  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 

- 18 -

© ENI Editions - All rigths reserved

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. 

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. 

© ENI Editions - All rigths reserved

- 19 -

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. 

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 : 

- 20 -

© ENI Editions - All rigths reserved

●

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. 

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 

© ENI Editions - All rigths reserved

- 21 -

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é. 

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 

- 22 -

© ENI Editions - All rigths reserved

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 : 

  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. 

© ENI Editions - All rigths reserved

- 23 -

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.  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 

Espace de résolution 

Tout nom situé au même  niveau ou à un niveau  supérieur aux zones  locales. 

Tout nom situé au même  niveau, à un niveau  inférieur ou supérieur  aux zones locales. 

Limité aux sous­ domaines des zones  locales. 

Requêtes DNSutilisées 

Le serveur essaie les  requêtes itératives puis  récursives. 

Le serveur résout la requête ou passe une référence  au client pour réaliser une requête itérative (en  fonction de la demande). 

Sécurité et Firewall 

Supporte les firewalls. 

Peut être affecté par les firewalls qui empêchent les  clients de contacter certains serveurs DNS. 

Niveau deconfiguration 

À déclarer sur chaque  serveur DNS. 

Réplication automatique  lorsque l’intégration  Active Directory est  utilisée. 

Toujours répliquée vers  les NS de la zone  parent. 

Reconfigurationnécessaire 

Doit être reconfiguré  lorsque des serveurs de  noms sont ajoutés aux  domaines cibles. 

Mise à jour automatique  lorsque les NS sont  ajoutés à la zone cible. 

Doit être reconfigurée  lorsque les NS sont  ajoutés à la zone cible. 

Support de la tolérance  de pannes 

Peut être tolérant aux 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. 

- 24 -

© ENI Editions - All rigths reserved

Gestion des noms multihôtes  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 

© ENI Editions - All rigths reserved

- 1-

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. 

© ENI Editions - All rigths reserved

- 1-

  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. 

  Encore une fois, la fonction n’est par défaut pas activée. Pour information, la zone utilisée dans nos exemples est la 

- 2-

© ENI Editions - All rigths reserved

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. 

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. 

© ENI Editions - All rigths reserved

- 3-

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. 

  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. 

© ENI Editions - All rigths reserved

- 1-

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. 

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. 

- 2-

© ENI Editions - All rigths reserved

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

© ENI Editions - All rigths reserved

- 3-

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  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. 

© ENI Editions - All rigths reserved

- 1-

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é. 

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

© ENI Editions - All rigths reserved

- 1-

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.  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

© ENI Editions - All rigths reserved

- 1-

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  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.  - 2-

© ENI Editions - All rigths reserved

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. 

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  © ENI Editions - All rigths reserved

- 3-

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 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é. 

- 4-

© ENI Editions - All rigths reserved

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 :  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. 

© ENI Editions - All rigths reserved

- 5-

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é.  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  /s   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..  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 

- 6-

© ENI Editions - All rigths reserved

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.  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é. 

© ENI Editions - All rigths reserved

- 7-

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. 

- 8-

© ENI Editions - All rigths reserved

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  Performances 

Type de données  collectées 

Évaluation 

Stratégie de  surveillance 

Mises à jour dynamiques  refusées 

Nombre total de mises à  jour dynamiques  refusées par le serveur  DNS. 

Un nombre important de  refus concernant un  serveur DNS sécurisé  peut signifier que des  ordinateurs non  autorisés tentent de  réaliser des mises à jour  dynamiques. 

Toute augmentation doit  déclencher une analyse  détaillée de cette  activité douteuse.  

Requêtes récursives par  secondes 

Nombre moyen de  requêtes récursives  reçues par le serveur  DNS en une seconde. 

Ce compteur permet de  surveiller l’activité du  serveur DNS en terme  de charge de résolution  de noms.  

Toute variation  importante doit faire  l’objet d’une action de  contrôle de l’activité. 

Nombre total de  demandes de transferts  de zone complets  envoyées par le serveur  DNS secondaire. 

Le serveur secondaire  hébergeant une zone  secondaire demande  des transferts de zone.  Lorsque ce chiffre est  élevé un nombre de  changements importants  est réalisé dans la zone  primaire. 

Si ce compteur évolue  de manière importante  par rapport à la base, il  pourra être nécessaire  de revoir le nombre de  modifications autorisées  ainsi que la méthode  utilisée. 

Demandes AXFR  envoyées 

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

© ENI Editions - All rigths reserved

- 1-

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 : 

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

- 2-

© ENI Editions - All rigths reserved

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. 

●

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). 

© ENI Editions - All rigths reserved

- 3-

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 : 

- 4-

●

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. 

© ENI Editions - All rigths reserved

●

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  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 : 

© ENI Editions - All rigths reserved

- 5-

●

Connectez­vous  sur  le  site  Microsoft  Events  and  Errors  http://www.microsoft.com/technet/support/eventserrors.mspx 

Message 

Center 

●

Installez le Kit de Ressources Techniques de Windows 2000 ou Windows Server 2003. 

●

Connectez­vous sur le site http://www.EventID.net. 

à 

l’adresse 

: 

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. 

- 6-

© ENI Editions - All rigths reserved

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  Sélectionné. 

© ENI Editions - All rigths reserved

- 1-

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. 

- 2-

© ENI Editions - All rigths reserved

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  à  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  © ENI Editions - All rigths reserved

- 1-

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. 

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. 

- 2-

© ENI Editions - All rigths reserved

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 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 :  © ENI Editions - All rigths reserved

- 3-

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 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. 

- 4-

© ENI Editions - All rigths reserved

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. 

Déclaration de la liste des serveurs WINS à l’aide des paramètres TCP/IP et de l’onglet WINS 

© ENI Editions - All rigths reserved

- 5-

●

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 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. 

- 6-

© ENI Editions - All rigths reserved

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.  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. 

© ENI Editions - All rigths reserved

- 7-

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. 

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. 

- 8-

© ENI Editions - All rigths reserved

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. 

Propriétés de l’utilisateur Bob Durand au sein du domaine Active Directory 

© ENI Editions - All rigths reserved

- 9-

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.  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. 

- 10 -

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 11 -

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. 

- 12 -

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 13 -

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. 

- 14 -

© ENI Editions - All rigths reserved

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. 

●

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.  © ENI Editions - All rigths reserved

- 15 -

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  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é.

- 16 -

© ENI Editions - All rigths reserved

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.  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 

© ENI Editions - All rigths reserved

- 17 -

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  pour  faciliter  la  jonction  de  domaines et la création de contrôleurs de domaine" dans la Base de connaissances Microsoft. 

- 18 -

© ENI Editions - All rigths reserved

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 

© ENI Editions - All rigths reserved

- 1-

formats. Le serveur DNS peut utiliser des redirecteurs dont les adresses sont dans les deux formats.  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 complètement DNS tout en  continuant de supporter des noms plats de type simple label au sein de la nouvelle zone DNS GlobalNames. 

- 2-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 3-

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é.  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. 

- 4-

© ENI Editions - All rigths reserved

© ENI Editions - All rigths reserved

- 5-

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 ?  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. 

© ENI Editions - All rigths reserved

- 1-

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  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. 

- 2-

© ENI Editions - All rigths reserved

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.  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  ServerName /config /Enableglobalnamessupport 1.  

fonctionnalité 

à 

l’aide 

de 

la 

commande 

Dnscmd 

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.  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. 

© ENI Editions - All rigths reserved

- 3-

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. 

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. 

© ENI Editions - All rigths reserved

- 1-

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 : 

- 2-

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é. 

© ENI Editions - All rigths reserved

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. 

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 

© ENI Editions - All rigths reserved

- 3-

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 dnscmd /RecordAdd /help. 

/?  ou  la  commande 

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. 

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. 

- 4-

© ENI Editions - All rigths reserved

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 :  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.  © ENI Editions - All rigths reserved

- 5-

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 :  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 : 

- 6-

●

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. 

© ENI Editions - All rigths reserved

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. 

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 

© ENI Editions - All rigths reserved

- 7-

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 :  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 : 

- 8-

© ENI Editions - All rigths reserved

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 :  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]

© ENI Editions - All rigths reserved

- 9-

[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. 

- 10 -

© ENI Editions - All rigths reserved

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.  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, 

© ENI Editions - All rigths reserved

- 1-

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. 

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 

canonicalName 

Représente le nom canonique Active Directory de  l’objet 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. 

dNSHostName 

Représente le nom DNS sous la forme d’un FQDN  xp1.Corp2003.Corporate.net. 

name 

Représente le nom XP1. 

sAMAccountName 

Représente le nom SAM (Security Account Manager) de  l’ordinateur XP1$. 

servicePrincipalName 

Représente les noms des identités (SPN, Security  Principal Names) HOST/XP1  HOST/xp1.Corp2003.Corporate.net. 

Comme  expliqué  précédemment,  ce  tableau  montre  qu’un  ordinateur  au  sein  du  domaine  Windows  existe  dans  - 2-

© ENI Editions - All rigths reserved

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 

objectCategory 

CN=Computer,CN=Schema,CN=Configuration,DC=Corp2003,  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.  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. 

© ENI Editions - All rigths reserved

- 3-

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. 

- 4-

© ENI Editions - All rigths reserved

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.  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. 

© ENI Editions - All rigths reserved

- 5-

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  CN=Configuration,DC=Corp2003,DC=Corporate,DC=Net 

dont 

le 

nom 

complet 

est 

: 

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  CN=Schema,CN=Configuration,DC=Corp2003,DC=Corporate,DC=Net 

le 

nom 

complet 

est 

: 

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  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. 

- 6-

© ENI Editions - All rigths reserved

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.  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. 

© ENI Editions - All rigths reserved

- 7-

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. 

À  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. 

- 8-

© ENI Editions - All rigths reserved

●

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  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 

Tous les serveurs DNS dans la forêt Active Directory : 

Réplique les données de la zone vers tous les  serveurs DNS exécutés sur des contrôleurs de 

© ENI Editions - All rigths reserved

- 9-

une partition de l’annuaire d’application sera créée au  niveau de la forêt. 

domaine dans la forêt Active Directory. Il s’agit  généralement de l’étendue de réplication la plus  importante. 

Tous les serveurs DNS dans le domaine Active  Directory : une partition de l’annuaire d’application  sera créée au niveau du domaine. 

Réplique les données de la zone vers tous les  serveurs DNS exécutés sur des contrôleurs de  domaine du domaine Active Directory. Cette option  constitue le paramètre par défaut de la 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 n’est pas nécessaire de créer une  partition de l’annuaire d’application. La zone sera  créée au sein de la partition existante dans le  domaine. 

Réplique les données de la zone vers tous les  contrôleurs de domaine du domaine Active Directory.  Ce choix est nécessaire pour supporter le chargement  d’une zone Active Directory par des serveurs DNS  Windows 2000. 

Tous les contrôleurs de domaine dans une partition  de répertoire d’application spécifiée : une partition de  l’annuaire d’application devra être spécifiquement  créée et répliquée vers les serveurs spécifiquement  désignés. 

Réplique les données de la zone en fonction de  l’étendue de réplication de la partition de répertoire  d’application spécifiée. Pour qu’une zone soit stockée  dans la partition de répertoire d’application spécifiée,  il faut que le serveur DNS qui héberge 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  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. 

- 10 -

© ENI Editions - All rigths reserved

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  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. 

© ENI Editions - All rigths reserved

- 11 -

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. 

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. 

- 12 -

© ENI Editions - All rigths reserved

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. 

●

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, 

© ENI Editions - All rigths reserved

- 13 -

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 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  - 14 -

© ENI Editions - All rigths reserved

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. 

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 

© ENI Editions - All rigths reserved

- 15 -

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.  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. 

- 16 -

© ENI Editions - All rigths reserved

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 

Administrateurs 

Autoriser : Lire, Écrire, Créer tous les objets enfants,  Autorisations spéciales 

Utilisateurs authentifiés 

Autoriser : Créer tous les objets enfants 

Propriétaire créateur 

Autorisations spéciales 

DNSAdmins 

Autoriser : Écriture complète, Lire, Écrire, Créer tous  les objets enfants, Supprimer les objets enfants,  Autorisations spéciales 

Admins du domaine 

Autoriser : Écriture complète, Lire, Écrire, Créer tous  les objets enfants, Supprimer les objets enfants,  Autorisations spéciales 

Administrateurs de l’entreprise 

Autoriser : Écriture complète, Lire, Écrire, Créer tous  les objets enfants, Supprimer les objets enfants,  Autorisations spéciales 

ENTERPRISE DOMAIN CONTROLLERS 

Autoriser : Écriture complète, Lire, Écrire, Créer tous  les objets 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 

© ENI Editions - All rigths reserved

- 17 -

SYSTEM 

Autoriser : Écriture complète, Lire, Écrire, Créer tous  les objets 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  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 : 

- 18 -

© ENI Editions - All rigths reserved

●

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). 

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. 

© ENI Editions - All rigths reserved

- 19 -

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.  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. 

- 20 -

© ENI Editions - All rigths reserved

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. 

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. 

© ENI Editions - All rigths reserved

- 21 -

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  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. 

- 22 -

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 23 -

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  

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  

1996 

A Mechanism for Prompt Notification of Zone Changes  (DNS NOTIFY)  

2136 

Dynamic Updates in the Domain Name System (DNS  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 

© ENI Editions - All rigths reserved

- 1-

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  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. 

- 2-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 3-

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 ?  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 

© ENI Editions - All rigths reserved

- 1-

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 ?  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. 

- 2-

© ENI Editions - All rigths reserved

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  dnscmd /CreateDirectoryPartition /? 

de 

cette 

commande, 

à 

l’invite 

de 

commandes, 

tapez 

2. Stockage d’une zone vers tous les serveurs DNS de la forêt  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 

© ENI Editions - All rigths reserved

- 1-

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. 

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.  - 2-

© ENI Editions - All rigths reserved

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  NomServeur /EnlistDirectoryPartition FQDN 

tapez 

la 

commande 

ci­dessous 

: 

dnscmd 

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.  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  © ENI Editions - All rigths reserved

- 3-

À  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. 

- 4-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 1-

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  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 

© ENI Editions - All rigths reserved

- 1-

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.  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.

- 2-

© ENI Editions - All rigths reserved

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é 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. 

© ENI Editions - All rigths reserved

- 3-

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  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.  © ENI Editions - All rigths reserved

- 1-

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. 

- 2-

© ENI Editions - All rigths reserved

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  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. 

© ENI Editions - All rigths reserved

- 1-

_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 : 

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  Service 

_kerberos 

Identifie le service à localiser au  sein de l’espace de nom DNS. 

_ldap  _tcp  Protocole  _udp 

Déclaration du protocole de  transport à utiliser. 

Nom 

Corporate.net 

Représente le nom du domaine  DNS contenant l’enregistrement. 

TTL 

10 minutes 

Représente la durée de vie de  l’enregistrement en secondes  (600 secondes.)  Déclare le type d’enregistrement 

- 2-

© ENI Editions - All rigths reserved

Classe 

IN 

Enregistrement de ressource 

SRV 

Déclare le type d’enregistrement  en tant qu’enregistrement de  ressource de type localisation de  services "SRV". 

0 

Identifie la priorité de  l’enregistrement. Lorsque  plusieurs enregistrements  existent pour le même service, le  client sélectionne l’enregistrement  possédant la valeur de priorité la  plus faible. 

100 

Permet la gestion des fonctions  de répartition de charge. S’il  existe pour le même service  plusieurs enregistrements de SRV  de même priorité, les clients  sélectionnent le ou les  enregistrements de poids forts. 

Priorité 

Poids 

3268 pour _gc   Port  

88 pour _kerberos  389 pour _ldap  Booster2003. 

Cible  Corporate.net 

en tant qu’enregistrement  standard de type DNS Internet. 

Identifie le numéro de port sur  lequel le service demandé est  disponible. 

Représente le nom complet de la  machine fournissant le service  identifié 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. 

© ENI Editions - All rigths reserved

- 3-

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.  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.  

- 4-

© ENI Editions - All rigths reserved

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 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  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 

© ENI Editions - All rigths reserved

- 5-

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 

  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 

- 6-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 7-

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. 

●

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. 

© ENI Editions - All rigths reserved

- 1-

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.  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 

© ENI Editions - All rigths reserved

- 1-

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: [] 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.  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 : 

- 2-

●

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. 

© ENI Editions - All rigths reserved

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  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. 

© ENI Editions - All rigths reserved

- 1-

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 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. 

- 2-

© ENI Editions - All rigths reserved

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 ? 

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 ? 

© ENI Editions - All rigths reserved

- 1-

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.  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. 

- 2-

© ENI Editions - All rigths reserved

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. 

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.    © ENI Editions - All rigths reserved

- 1-

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 

- 2-

© ENI Editions - All rigths reserved

À 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. 

© ENI Editions - All rigths reserved

- 1-

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. 

© ENI Editions - All rigths reserved

- 1-

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 :  ●

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 

© ENI Editions - All rigths reserved

- 1-

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 

2251 

Lightweight Directory Access  Protocol (v3) 

Proposed 

Les alias et les DN de type multivaleurs ne sont à ce jour pas supportés.  

2252 

Lightweight Directory Access  Protocol (v3): Attribute Syntax  Definitions  

Proposed 

Certaines syntaxes Unix ne sont pas à ce jour supportées.  

2253 

Lightweight Directory Access  Protocol (v3): UTF­8 String  Representation of Distinguished  Names  

Proposed 

2254 

The String Representation of LDAP  Search Filters  

Proposed 

2255 

The LDAP URL Format 

Proposed 

2256 

A Summary of the X.500(96) User  Schema for use with LDAPv3  

Proposed 

2829 

Authentication Methods for LDAP  

Proposed 

2830 

Lightweight Directory Access  Protocol (v3): Extension for  Transport Layer Security 

Proposed 

RFC 

RFC LDAP additionnels 

2696 

LDAP Control Extension for Simple  Paged Results Manipulation  

Proposed 

2247 

Using Domains in LDAP/X.500  Distinguished Names  

Proposed 

© ENI Editions - All rigths reserved

- 1-

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 

RFC LDAP additionnels supportés  par Windows Server 2003 et  Windows Server 2008 

État des RFC 

2589 

LDAP Protocol (v3): Extensions for  Dynamic Directory Services  

Proposed 

2798 

Definition of the inetOrgPerson  LDAP Object Class 

Proposed 

2831 

Using Digest Authentication as an  SASL Mechanism  

Proposed 

2891 

LDAP Control Extension for Server  Side Sorting of Search Results  

Proposed 

2589 

LDAP Protocol (v3): Extensions for  Dynamic Directory Services  

Proposed 

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.  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. 

© ENI Editions - All rigths reserved

- 1-

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  http//support.microsoft.com/kb/314649 

à 

l’article 

Technet 

314649 

disponible 

via 

le 

lien 

ci­après 

: 

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"  Le  paramètre  /c  remplace  toutes  les  occurrences  de  "DC=X"  dans  le  fichier  LDF  inetorgperson.ldf  par  "DC=Corpnet,DC=Corporate,DC=net" 

© ENI Editions - All rigths reserved

- 1-

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  msExchLabeledURI. 

●

CN=ms­Exch­House­Identifier,CN= Schema,CN= Configuration,DC= X  le  lDAPDisplayName  sera  renommé  en  msExchHouseIdentifier. 

le 

lDAPDisplayName 

sera 

renommé 

en 

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.  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  - 2-

© ENI Editions - All rigths reserved

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. 

  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  © ENI Editions - All rigths reserved

- 3-

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  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. 

- 4-

© ENI Editions - All rigths reserved

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.  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. 

© ENI Editions - All rigths reserved

- 5-

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 à. 

  Choisissez l’option Sélectionnez un contexte d’attribution de noms connu. 

© ENI Editions - All rigths reserved

- 1-

Visualisation des propriétés des attributs de l’objet RootDSE 

- 2-

© ENI Editions - All rigths reserved

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.  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. 

© ENI Editions - All rigths reserved

- 1-

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  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  url=/downloads/list/directorysrv.asp 

●

Site Microsoft dédié à Active Directory : http://www.microsoft.com/ad 

●

Site  Microsoft  dédié  à  ADAM  ­  Active  http://www.microsoft.com/windowsserver2003/adam/default.mspx 

ADSI 

testing 

suite 

overview 

http://msdn.microsoft.com/library/default.asp?

© ENI Editions - All rigths reserved

Directory 

Application 

Mode 

- 1-

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.  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 ? 

© ENI Editions - All rigths reserved

- 1-

À  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". 

- 2-

© ENI Editions - All rigths reserved

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 :  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 

© ENI Editions - All rigths reserved

- 1-

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. 

- 2-

© ENI Editions - All rigths reserved

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.  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. 

© ENI Editions - All rigths reserved

- 1-

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  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. 

- 2-

© ENI Editions - All rigths reserved

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. 

É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. 

© ENI Editions - All rigths reserved

- 1-

Affichage des propriétés de la classe organizationalUnit via ADSI Edit  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. 

- 2-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 3-

Détails des caractéristiques de l’attribut ou  Finalement, l’attribut obligatoire ou possède de nombreuses caractéristiques.  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 

- 4-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 5-

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. 

- 6-

© ENI Editions - All rigths reserved

L’attribut est désigné à l’aide de son Nom LDAP affiché  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  1.2.840.113556.1.4.7000.233.28688.28684.8.492045.1961603.2011489.1208101.1 

d’objet 

X.500 

suivant 

: 

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.  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.  © ENI Editions - All rigths reserved

- 7-

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.  Lorsqu’une classe ou un attribut est modifié pour prendre l’état désactivé, il est considéré comme défunt. Une classe 

- 8-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 9-

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)] [-u NomUtilisateur] [-p (Mot_de_passe | *)]

- 10 -

© ENI Editions - All rigths reserved

[-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. 

© ENI Editions - All rigths reserved

- 11 -

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. 

© ENI Editions - All rigths reserved

- 1-

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. 

Vision de la structure des partitions d’une forêt Active Directory 

- 2-

© ENI Editions - All rigths reserved

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é. 

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.  © ENI Editions - All rigths reserved

- 3-

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  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/ 

- 4-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 1-

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. 

- 2-

© ENI Editions - All rigths reserved

  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.  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. 

© ENI Editions - All rigths reserved

- 3-

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  [email protected]  (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.  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. 

- 4-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 5-

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 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 ?  À 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. 

© ENI Editions - All rigths reserved

- 1-

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. 

- 2-

© ENI Editions - All rigths reserved

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. 

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. 

© ENI Editions - All rigths reserved

- 1-

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. 

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. 

- 2-

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  © ENI Editions - All rigths reserved

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 : 

5. 

6. 

●

Prénom : Lana 

●

Initiale : L 

●

Nom : Lang 

●

Nom d’ouverture de session : [email protected] 

●

Nom antérieur à Windows 2000 : Llang 

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 

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 : 

4. 

5. 

●

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. 

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. 

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. 

© ENI Editions - All rigths reserved

- 3-

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.  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. 

- 4-

Finalement, associez l’ordinateur réservé à un serveur supportant les services RIS, puis  cliquez sur Suivant puis sur Terminer. 

© ENI Editions - All rigths reserved

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. 

 

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  à 

© ENI Editions - All rigths reserved

- 5-

des ressources,  ●

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 : 

5. 

●

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. 

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. 

- 6-

Ouvrez le menu Démarrer puis cliquez sur Exécuter. 

© ENI Editions - All rigths reserved

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. 

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. 

2. 

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. 

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é. 

© ENI Editions - All rigths reserved

- 7-

4. 

En tant qu’administrateur du domaine, procédez au déverrouillage du compte verrouillé. 

5. 

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. 

- 8-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 1-

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. 

© ENI Editions - All rigths reserved

- 1-

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  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. 

- 2-

© ENI Editions - All rigths reserved

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.  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. 

© ENI Editions - All rigths reserved

- 3-

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. 

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 

- 4-

© ENI Editions - All rigths reserved

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. 

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 

© ENI Editions - All rigths reserved

- 5-

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.  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". 

- 6-

© ENI Editions - All rigths reserved

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é.  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. 

© ENI Editions - All rigths reserved

- 7-

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,  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

- 8-

© ENI Editions - All rigths reserved

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é. 

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. 

© ENI Editions - All rigths reserved

- 9-

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. 

- 10 -

© ENI Editions - All rigths reserved

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 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 © ENI Editions - All rigths reserved

- 1-

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) ; 

●

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 : 

- 2-

●

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. 

© ENI Editions - All rigths reserved

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. 

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. 

© ENI Editions - All rigths reserved

- 3-

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. 

Autorisations sur une unité d’organisation 

© ENI Editions - All rigths reserved

- 1-

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.  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. 

- 2-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 3-

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é.  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 

- 4-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 5-

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.  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. 

© ENI Editions - All rigths reserved

- 1-

É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  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. 

- 2-

© ENI Editions - All rigths reserved

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.  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 

© ENI Editions - All rigths reserved

- 3-

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. 

Le domaine Corp2003.Corporate.net et Partners.Corporate.net s’approuvent mutuellement 

Disponibilité du domaine racine de la forêt

- 4-

© ENI Editions - All rigths reserved

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 :  ●

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. 

© ENI Editions - All rigths reserved

- 5-

●

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. 

- 6-

© ENI Editions - All rigths reserved

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 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. 

© ENI Editions - All rigths reserved

- 1-

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 "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. 

- 2-

© ENI Editions - All rigths reserved

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 :  ●

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. 

© ENI Editions - All rigths reserved

- 3-

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 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 

- 4-

© ENI Editions - All rigths reserved

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 ; 

●

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 

© ENI Editions - All rigths reserved

- 5-

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 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 

- 6-

© ENI Editions - All rigths reserved

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.  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  © ENI Editions - All rigths reserved

- 7-

chaque domaine auquel il conviendra d’ajouter les deux FSMO dédiés aux opérations de forêt.  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.  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 

- 8-

© ENI Editions - All rigths reserved

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 [email protected]. 

●

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  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 

© ENI Editions - All rigths reserved

- 9-

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 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 : 

- 10 -

●

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. 

© ENI Editions - All rigths reserved

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 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. 

© ENI Editions - All rigths reserved

- 11 -

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 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, 

- 12 -

© ENI Editions - All rigths reserved

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.  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. 

© ENI Editions - All rigths reserved

- 13 -

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  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 

- 14 -

© ENI Editions - All rigths reserved

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).  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 

© ENI Editions - All rigths reserved

- 15 -

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  [email protected].  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 

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 : 

- 16 -

●

Rootcorp.corporate.com ; 

●

Emea.rootcorp.corporate.com ;  © ENI Editions - All rigths reserved

●

Partners.net ; 

●

[email protected] ; 

●

[email protected]. 

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.  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. 

© ENI Editions - All rigths reserved

- 17 -

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 : 

- 18 -

●

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. 

© ENI Editions - All rigths reserved

●

É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. 

© ENI Editions - All rigths reserved

- 19 -

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. 

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éalisées :  ●

Assurez­vous  que  vous  disposez  d’un  compte  d’administration  de  domaine  faisant  partie  des  groupes  Administrateurs  du  domaine,  Administrateurs  de  l’entreprise,  Administrateur  du  schéma.  Toutes  les  opérations  devant  avoir  lieu  sur  un  serveur  devant  faire  l’objet  d’une  promotion  nécessiteront  aussi  de  disposer des privilèges Administrateur sur la machine locale. 

●

Réalisez l’opération  de  mise  à  jour  du  schéma  Active  Directory  via  la  commande adprep /foresprep.  Pour  y  parvenir, copiez le contenu du dossier \Sources\adprep du CD­Rom d’installation de Windows Server 2008  dans un dossier \adprep sur le serveur. À partir de ce dossier, sur le contrôleur de domaine possédant le rôle  de  maître  d’opération  de  Schéma,  lancez  la  commande  adprep /forestprep.  Pour  réussir  la  mise  à  jour  en  exécutant  cette  commande,  l’administrateur  devra  faire  partie  des  groupes  Administrateur  du  schéma,  Administrateurs de l’entreprise et Administrateurs du domaine. 

●

Réalisez  l’opération  de  préparation  du  domaine  Active  Directory  via  la  commande  adprep /domainprep /gpprep. Pour y parvenir, copiez le contenu du dossier  \Sources\adprep du CD­Rom  d’installation de Windows Server 2008 dans un dossier \adprep sur le serveur. À partir de ce dossier, sur le  contrôleur  de  domaine  possédant  le  rôle  de  maître  d’infrastructure,  lancez  la  commande  adprep /domainprep /gpprep. Pour exécuter cette commande, l’administrateur devra faire partie du groupe  Administrateur du domaine dans lequel l’opération est réalisée. 

© ENI Editions - All rigths reserved

- 1-

●

Attention  !  Après  avoir  réalisé  cette  opération,  évitez  d’installer  dans  la  foulée  le  premier  contrôleur  de  domaine.  Il  est  recommandé  d’attendre  que  les  nouvelles  informations  se  soient  répliquées  au  sein  du  domaine.  Bien  entendu,  vous  pouvez  forcer  les  réplications  à  l’aide  des  outils  habituels  Replmon  ou  via  la  commande Repadmin. 

●

Attention  aux  problèmes  de  cohérence  lors  de  la  mise  à  jour  du  schéma  avec  Microsoft  Exchange  2000  Server ! Dans l’absolu, il ne doit pas y avoir de problème majeur pour réaliser les étapes préparatoires que  sont  la  mise  à  jour  du  schéma  ainsi  que  la  mise  à  jour  des  objets  du  domaine,  en  vue  de  l’intégration des  contrôleurs fonctionnant sous Windows Server 2008. Le problème le plus courant, concerne un problème déjà  connu des ingénieurs systèmes qui auront procédé au même type de scénario, lorsqu’il y a quelques années,  la problématique consistait à introduire les premiers contrôleurs de domaine Windows Server 2003, dans des  forêts Windows 2000 Server contenant Exchange 2000 Server. En effet, la phase de préparation de la forêt ­  réalisée via Adprep, peut échouer lorsque le schéma a été préalablement mis à niveau pour Exchange 2000.  Le  problème  concerne  les  attributs  de  la  classe  inetOrgPerson  ­  attributs  Secretary,  labeledURI,  et  houseIdentifier, lesquels sont conflictuels avec ceux d’Exchange plus anciens et ne respectant donc pas les  RFC de cette nouvelle classe, inetOrgPerson. Pour résoudre ce problème, peut­être déjà résolu si le schéma  a été mis à niveau pour Windows Server 2003, vous pourrez manuellement corriger le schéma en utilisant le  fichier  Inetorgpersonfix.ldf  contenu  dans  le  fichier  Support.cab  du  dossier  Support\Tools  du  CD­Rom  de  Windows  Server  2003.  Ensuite,  à  partir  de  la  console  du  maître  d’opérations  du  schéma,  vous  pourrez  importer le fichier LDF contenant de corrections à l’aide de la commande LDIFDE. Pour plus de renseignements  sur  cette  procédure,  vous  pourrez  consulter  l’article  Technet  à  l’aide  du  lien  suivant :http://support.microsoft.com/kb/314649 

Attention  aux  problèmes  de  cohérence  lors  de  la  mise  à  jour  du  schéma  lorsque  le  schéma  de  la  forêt  supporte  les  Services  for  Unix  2.0  !  Un  conflit  de  réplication  sur  l’attribut  CN= uid ­  respectant  le  RFC  2307,  peut se produire lorsque le schéma a été préparé pour supporter les services SFU 2.0. Pour résoudre ce problème,  une fois de plus bloquant, vous pourrez soit procéder à la mise à jour de SFU 2.0 vers les Windows Services for  UNIX  3.0  ou  bien  installer  le  patch  Q293783.  Pour  plus  de  renseignements  sur  cette  procédure,  vous  pourrez  consulter l’article Technet à l’aide du lien suivant : http://go.microsoft.com/fwlink/?LinkId=106317 

3. Mise en œuvre d’un nouveau contrôleur Windows Server 2008 AD DS  L’environnement de production fonctionnant sous Windows 2000 Server et/ou Windows Server 2003 peut être mis à  niveau sous Windows Server 2008 en utilisant l’un ou l’autre des scénarios ci­dessous :  ●

L’insertion d’un  nouveau  serveur  fonctionnant  sous  Windows  Server  2008  dans  le  domaine  Active  Directory  de production. Procédez à la promotion du nouveau serveur au rôle de nouveau contrôleur de domaine dans  un  domaine  existant.  Retirez  les  anciens  contrôleurs  fonctionnant  sous  Windows  2000  Server  ou  Windows  Server  2003  ou  bien,  procédez  à  leur  mise  à  niveau  vers  Windows  Server  2008.  L’opération  de  promotion  pourra être réalisée à l’aide de l’interface graphique ou via un fichier de réponse créé au préalable. L’interface  de  Windows  Server  2008  propose  deux  assistants.  Le  premier  est  directement  accessible  via  le  nouveau  Gestionnaire de serveur ­ Rôles ­ Ajouter des rôles. Le deuxième est le traditionnel assistant d’installation  des services de domaine Active Directory, disponible depuis Windows 2000 Server, et toujours présent avec  Windows Server 2008, Dcpromo.exe ! 

●

La mise à niveau de tous les contrôleurs existants vers Windows Server 2008, en commençant par celui qui à  le plus de chance d’être le meilleur candidat pour initier le processus de migration. 

4. Réaffectation des rôles FSMO  Une  fois  le  processus  de  mise  à  niveau  du  premier  contrôleur  terminé,  il  sera  nécessaire  de  mettre  à  niveau  les  éléments d’infrastructure Active Directory ci­dessous :  ●

- 2-

Réaffectation du rôle de maître d’opérations de noms de domaine au niveau du domaine racine de la forêt :  cette  opération  n’est  pas  obligatoire,  mais  elle  est  nécessaire  pour  garantir  la  création  des  partitions  de  l’annuaire  d’applications  utilisées  pour  les  zones  DNS  Active  Directory.  Si  vous  ne  souhaitez  pas  mettre  à  niveau  le  contrôleur  de  domaine  qui  possède  le  rôle,  il  suffit  de  transférer  le  rôle  vers  un  contrôleur  de  domaine déjà mis à niveau vers Windows Server 2008. Cette opération peut s’avérer nécessaire car lors du  premier redémarrage, le service serveur DNS tente de localiser les partitions nécessaires à la mise à jour des  zones. De plus, s’il ne les trouve pas, il prendra l’initiative de les créer. Pour garantir la bonne création de ces  partitions, si nécessaire, il est obligatoire que le maître de noms de domaine soit hébergé sur un contrôleur  de domaine fonctionnant sous Windows Server 2008. 

© ENI Editions - All rigths reserved

●

Réaffectation  du  rôle  de  maître  d’opérations  Émulateur  de  contrôleur  de  domaine  principal  au  niveau  du  domaine  racine  de  la  forêt  :  cette  opération  garantie  que  la  création  des  nouveaux  comptes  additionnels  nécessaires aux domaines Windows Server 2008 seront bien créés au niveau du domaine racine de la forêt. 

●

Réaffectation  du  rôle  de  maître  d’opérations  Emulateur  de  contrôleur  de  domaine  principal  dans  les  autres  domaines  de  la  forêt  :  cette  opération  garantie  que  les  nouveaux  groupes  apportés  par  Windows  Server  2008 ainsi que leur contenu respectif seront bien créés dans tous les domaines de la forêt. 

●

Attention  !  Il  n’est  pas  possible  de  procéder  à  une  mise  à  niveau  de  Windows  2000  Server  vers  Windows  Server  2008.  Si  cette  opération  doit  être  réalisée,  vous  devez  d’abord  procéder  à  une  mise  à  niveau  intermédiaire en procédant à la mise à niveau de Windows 2000 Server vers Windows Server 2003. 

●

À partir du moment où le schéma Active Directory à été mis à niveau via la commande adprep /foresprep et  où  le  domaine  cible  a  été  préparé  via  la  commande  adprep  /domainprep,  l’insertion  du  premier  nouveau  contrôleur  de  domaine  dans  la  forêt  Active  Directory  existante  peut  avoir  lieue.  Bien  qu’il  soit  possible  d’installer ce nouveau premier contrôleur de domaine Windows Server 2008 dans n’importe quel domaine de  la  forêt,  il  est  recommandé  de  positionner  ce  premier  contrôleur  de  domaine  Windows  Server  2008  dans  le  domaine racine de la forêt. Bien entendu, cette problématique ne se pose pas dans les environnements de  forêt mono­domaine. 

5. Opérations de finalisation Post Migration  a. Modification des stratégies de sécurité des contrôleurs de domaine  Dans le souci d’accroître le niveau de sécurité des plates­formes d’entreprises les plus critiques, les contrôleurs de  domaine  Windows  Server  2008  exigent  que,  par  défaut,  les  authentifications  clients  utilisent  la  signature  des  paquets SMB (Server Message Block), ainsi que la signature du canal d’authentification sécurisé (Secure Channel).  Dans  le  cas  où,  le  réseau  de  l’entreprise  contient  des  systèmes  fonctionnant  sous  Windows  NT  4.0  SP2  (pas  de  support de la signature des paquets SMB) ou même SP3 (pas de support de la signature du canal d’authentification  sécurisé), vous devrez procéder à la modification de la stratégie de sécurité des contrôleurs de domaine. 

Paramètres de sécurité à modifier en cas d’extrême nécessité. 

La  bonne  pratique  serait  de  procéder  à  une  mise  à  niveau  de  ces  anciens  systèmes  en  procédant,  au  minimum, à l’application du SP6a de Windows NT 4.0. 

Dans  le  cas  où  il  serait  nécessaire  de  modifier  la  stratégie  des  contrôleurs  de  domaine,  procédez  avant  toute modification à la sauvegarde de la stratégie en utilisant la fonction de sauvegarde disponible dans la  console de gestion des stratégies de groupe, GPMC. 

© ENI Editions - All rigths reserved

- 3-

Les fenêtres de configuration de Windows Server 2008 exposent les effets des paramètres et le lien vers l’article  Technique Microsoft. 

Pour  plus  d’informations  sur  la  signature  des  paquets  SMB  et  la  signature  du  canal  d’authentification  sécurisé, vous pouvez rechercher sur le site de Microsoft Technet « Background Information for Upgrading  Active Directory Domains to Windows Server 2008 AD DS Domains ». 

b. Mise à jour des autorisations des objets GPO pour les domaines migrés à partir de Windows 2000  Lorsqu’un domaine Windows 2000 a fait l’objet d’une migration vers Windows Server 2008, le groupe ENTERPRISE  DOMAIN CONTROLLERS ne dispose pas des autorisations de lecture sur les objets stratégies de groupe disponibles  dans  tous  les  domaines  de  la  forêt.  Cette  remarque  est  vraie  pour  tous  les  objets  GPO  ayant  été  créés  avant  la  mise à niveau vers Windows Server 2008.  Si tel est le cas, la fonction de «modélisation» incluse dans la console de gestion des stratégies de groupe (GPMC),  sera inopérante. En effet, lorsque cette option est invoquée, un composant du contrôleur de domaine est sollicité  pour lire et ouvrir les objets GPO impliqués dans la simulation où qu’ils puissent se trouver dans la forêt. 

- 4-

© ENI Editions - All rigths reserved

Vérification des permissions de lecture sur un objet GPO  Pour corriger ce problème en réalisant la mise à jour des autorisations de tous les objets stratégie de groupe, vous  pouvez  utiliser  le  script  GrantPermissionOnAllGPOs.wsf.  Ce  script  fait  partie  des  exemples  de  scripts  précédemment  inclus  avec  la  console  de  gestion  des  stratégies  de  groupe  disponible  en  téléchargement  pour  Windows XP SP2 et Windows Server 2003. En effet, sous Windows Server 2008, ces scripts, jugés trop dangereux,  ont été retirés du système d’exploitation, et sont désormais disponibles via un téléchargement à partir du site de  Microsoft.  Un package contenant l’ensemble des scripts d’automation des opérations de maintenance des objets GPO  est  disponible  sur  le  site  de  Microsoft.  Cherchez  Group  Policy  Management  Console  Sample  Scripts  ou  utilisez le lien suivant : http://go.microsoft.com/fwlink/?LinkId=106342. Une fois installés, les scripts seront placés  dans le dossier %programfiles%\Microsoft Group Policy\GPMC Sample Scripts, comme cela était le cas sous  Windows  Server  2003.  Notez  que  la  modification  des  autorisations  des  objets  stratégies  de  groupe  ­  lesquels  sont stockés dans la partition de domaine et dans le dossier SYSVOL, nécessite l’appartenance au groupe Admins  du domaine. 

© ENI Editions - All rigths reserved

- 5-

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 Quels sont les éléments de structure logique utilisés dans une forêt Active Directory ?  2 Qu’est­ce qu’une arborescence (un arbre) de domaine(s) ?  3 Comment les relations entre les objets gérés au sein de la forêt Active Directory sont­elles créées ?  4 Que contient le schéma ?  5 Un attribut peut­il être associé à de multiples classes ?  6 Citez, dans l’ordre, tous les protocoles impliqués dans une communication entre un client Active Directory et le  domaine Active Directory.  7 Quels sont les trois facteurs qui peuvent justifier la présence d’un nouveau domaine au sein d’une forêt  existante ?  8 Quels sont les ordinateurs qui disposent d’un réplica d’un domaine donné ?  9 Quels sont les ordinateurs qui disposent d’un réplica de tous les domaines de la forêt ?  10 Quelle opération est réalisée à l’issue de l’installation du premier contrôleur de domaine de la forêt ?  11 Quel est le rôle de l’objet Unité d’organisation au sein des domaines d’une forêt ?  12 Quelle relation existe­t­il entre les domaines d’une même arborescence ?  13 Existe­t­il une relation entre la structure logique et la structure physique de l’Active Directory ?  14 Quels sont les niveaux fonctionnels de domaines disponibles dans les environnements Windows Server 2003 et  Windows Server 2008 ?  15 Quels sont les niveaux fonctionnels de forêt disponibles dans les environnements comprenant des contrôleurs  de domaine Windows Server 2003 et Windows Server 2008 ?  16 Quelle condition est nécessaire pour atteindre le niveau fonctionnel de domaine Windows 2000 natif ?  17 Quelle condition est nécessaire pour atteindre le niveau fonctionnel de domaine Windows Server 2003 ?  18 Quelle condition est­elle nécessaire pour atteindre le niveau fonctionnel de forêt Windows Server 2008 ?  19 Quel outil utilisez­vous pour rehausser le niveau fonctionnel des domaines ?  20 Quel outil utilisez­vous pour rehausser le niveau fonctionnel des forêts ?  21 Est­il possible d’annuler le passage d’un niveau fonctionnel à l’autre ?  22 Quel genre d’opération l’outil ADMT Version 3 permet­il ?  23 Quels types d’approbations existe­t­il dans l’environnement Active Directory ?  24 Quel est le nombre d’approbations au sein d’une forêt Active Directory composée de N domaines ?  25 Que permet le routage des suffixes de noms entre les forêts ?  26 Quels sont les services systèmes offrant les services nécessaires au bon fonctionnement des services de  domaine Active Directory de Windows Server 2008 ? 

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 /26  Pour ce chapitre, votre score minimum doit être de 20 sur 26. 

3. Réponses 

© ENI Editions - All rigths reserved

- 1-

1 Quels sont les éléments de structure logique utilisés dans une forêt Active Directory ?  Les arbres (ou arborescences), les domaines et les unités d’organisation.  2 Qu’est­ce qu’une arborescence (un arbre) de domaine(s) ?  Une  arborescence  (un  arbre)  est  un  ensemble  de  domaines  composé  d’au moins un domaine mettant en  œuvre un  nouvel espace de nommage.  3 Comment les relations entre les objets gérés au sein de la forêt Active Directory sont­elles créées ?  À l’aide du schéma.  4 Que contient le schéma ?  Les classes et les attributs disponibles à l’échelle de la forêt.  5 Un attribut peut­il être associé à de multiples classes ?  Oui, sans aucune limite.  6 Citez, dans l’ordre, tous les protocoles impliqués dans une communication entre un client Active Directory et le  domaine Active Directory.  TCP/IP, DNS, SNTP, Kerberos, LDAP, Services IntelliMirror (GPO, Préférences, Scripts).  7 Quels sont les trois facteurs qui peuvent justifier la présence d’un nouveau domaine au sein d’une forêt  existante ?  Le domaine est une unité d’administration, une unité de réplication et une limite de sécurité.  8 Quels sont les ordinateurs qui disposent d’un réplica d’un domaine donné ?  Les contrôleurs de domaine fonctionnant sous Windows 2000 Server, Windows Server 2003 et Windows Server 2008  du dit domaine Active Directory.  9 Quels sont les ordinateurs qui disposent d’un réplica de tous les domaines de la forêt ?  Les contrôleurs de domaine fonctionnant sous Windows 2000 Server, Windows Server 2003 ou Windows Server 2008  jouant le rôle de catalogue global.  10 Quelle opération est réalisée à l’issue de l’installation du premier contrôleur de domaine de la forêt ?  La forêt existe à travers le domaine racine de la forêt.  11 Quel est le rôle de l’objet Unité d’organisation au sein des domaines d’une forêt ?  Les  OUs  permettent  la  mise  en  place  d’un  modèle  organisé  dans  le  but  d’utiliser  les  services  de  délégation  de  l’administration  et  d’utiliser  les  technologies  de  gestion  IntelliMirror  telles  que  les  objets  stratégie  de  groupe,  les  nouvelles préférences et les scripts associés via des objets stratégie de groupe.  12 Quelle relation existe­t­il entre les domaines d’une même arborescence ?  Aucune,  si  ce  n’est  qu’ils  partagent  le  même  espace  de  nommage  DNS  et  qu’ils  sont  unis  de  haut  en  bas  à  l’aide  d’approbations Kerberos V5 bidirectionnelles transitives.  13 Existe­t­il une relation entre la structure logique et la structure physique de l’Active Directory ?  Non.  Il  n’existe  aucune  relation.  Par  définition,  la  structure  physique  Active  Directory  n’a  aucune  relation  avec  la  structure logique.  14 Quels sont les niveaux fonctionnels de domaines disponibles dans les environnements Windows Server 2003 et  Windows Server 2008 ?  Les contrôleurs de domaine fonctionnant sous Windows Server 2003 permettent au domaine Active Directory d’opérer  dans les modes suivants : le mode Windows 2000 mixte, le mode Windows 2000 natif, le mode Windows Server 2003  version préliminaire et le mode Windows Server 2003.Les contrôleurs de domaine fonctionnant sous Windows Server  2008  permettent  au  domaine  Active  Directory  d’opérer  dans  les  modes  suivants  :  le  mode  Windows  2000  natif,  le  mode Windows Server 2003 et le mode Windows Server 2008. Les modes Windows 2000 mixte et Windows Server  2003 version préliminaire ne sont plus supportés. Pour rappel, les contrôleurs de domaine fonctionnant sous Windows  Server 2003 sont intégrables dans des domaines Windows 2000 mixte, c’est­à­dire contenant encore des contrôleurs  NT 4.0, ou susceptibles d’en contenir. Lorsqu’au sein d’un domaine les contrôleurs fonctionnent sous Windows Server  2003 et NT 4.0, alors le domaine fonctionne dans le mode Windows Server 2003 version préliminaire. Pour rappel, les  contrôleurs de domaine fonctionnant sous Windows Server 2008 ne peuvent être directement mis à niveau de NT 4.0  ou  Windows  2000  vers  Windows  Server  2008,  ce  processus  nécessitant  que  le  serveur  fonctionne  sous  Windows  Server 2003 SP1, au minimum. Enfin, vous devez considérer que les contrôleurs de domaine Windows Server 2008 ne  peuvent  coexister  avec  des  contrôleurs  de  domaine  Windows  NT.  Ce  point  signifie,  évidemment,  qu’avec  des  contrôleurs de domaine Windows Server 2008, il n’y a plus de mode Windows Server 2003 version préliminaire. Notez  cependant  qu’il  est  possible  d’avoir  des  domaines  utilisant  le  niveau  fonctionnel  de  domaine  Windows  Server  2003  utilisant  des  contrôleurs  de  domaine  Windows  Server  2008  dans  une  forêt  utilisant  le  niveau  fonctionnel  de  forêt  Windows Server 2003 version préliminaire. Ce point est possible car dans ce cas, les contrôleurs de domaine Windows  Server 2008 sont justement dans un domaine utilisant le niveau fonctionnel Windows Server 2003. La conséquence  de  tout  ceci  fait  que  pour  installer  votre  1er  contrôleur  de  domaine  Windows  Server  2008  vous  devez  supprimer  ou  mettre à niveau les anciens contrôleurs NT vers Windows 2000 Server ou Windows Server 2003.  15 Quels sont les niveaux fonctionnels de forêt disponibles dans les environnements comprenant des contrôleurs  de domaine Windows Server 2003 et Windows Server 2008 ? 

- 2-

© ENI Editions - All rigths reserved

Forêt Windows 2000, forêt Windows Server 2003 et forêt Windows Server 2008.  16 Quelle condition est nécessaire pour atteindre le niveau fonctionnel de domaine Windows 2000 natif ?  Il  est  nécessaire  que  tous  les  contrôleurs  du  domaine  fonctionnent  sous  Windows  2000,  Windows  Server  2003  ou  Windows Server 2008.Notez que le mode Windows 2000 natif est le mode par défaut assigné par DCPROMO à l’issue  de l’installation de Windows Server 2008 en tant que contrôleur de domaine d’un nouveau domaine. Il autorise donc  l’installation de contrôleurs de domaine Windows 2000 Server et aussi Windows Server 2003.  17 Quelle condition est nécessaire pour atteindre le niveau fonctionnel de domaine Windows Server 2003 ?  Il  est  nécessaire  que  tous  les  contrôleurs  du  domaine  fonctionnent  sous  Windows  Server  2003  ou  Windows  Server  2008.  18 Quelle condition est­elle nécessaire pour atteindre le niveau fonctionnel de forêt Windows Server 2008 ?  Il  est  nécessaire  que  tous  les  contrôleurs  de  domaine  de  tous  les  domaines  de  la  forêt  fonctionnent  sous  Windows  Server 2003 ou Windows Server 2008.  19 Quel outil utilisez­vous pour rehausser le niveau fonctionnel des domaines ?  La  console  de  gestion  MMC  Utilisateurs  et  ordinateurs  Active  Directory  ou  la  console  de  gestion  MMC  Domaines  et  approbations  Active  Directory.  Sur  les  serveurs  Windows  Server  2008,  vous  pouvez  aussi  utiliser  le  gestionnaire  de  serveur/Rôles/Services  de  domaine  Active  Directory/Utilisateurs  et  ordinateurs  Active  Directory  puis  accéder  à  la  fonction Augmenter le niveau fonctionnel du domaine….  20 Quel outil utilisez­vous pour rehausser le niveau fonctionnel des forêts ?  La console de gestion MMC Domaines et approbations Active Directory.  21 Est­il possible d’annuler le passage d’un niveau fonctionnel à l’autre ?  Non. Comme sous Windows 2000 Server et Windows Server 2003, il n’est pas possible d’annuler cette opération.  22 Quel genre d’opération l’outil ADMT Version 3 permet­il ?  Il  permet  la  migration  des  comptes  utilisateurs,  des  groupes,  des  comptes  de  services  des  approbations,  des  profils  utilisateurs  et  des  mots  de  passe  d’un  domaine  Windows  NT  vers  des  domaines  utilisant  les  niveaux  fonctionnels  Windows  2000  natif,  Windows  Server  2003  ou  Windows  Server  2008,  grâce  à  la  gestion  de  l’attribut  sIDHistory.  Il  permet aussi les réorganisations inter ou intra forêts entre domaines Active Directory.  À  ce  jour,  seule  la  version  3.0  de  l’outil  ADMT  est  disponible.  Cette  version  supporte  parfaitement  les  opérations  de  migration  des  plates­formes  Windows  NT,  Windows  2000  Server  et  Windows  Server  2003.  ADMT  Version  3.0  ne  supporte pas la migration ni la translation des paramètres de sécurité des machines Windows Vista ou Windows Server  2008. Il n’est pas possible d’installer ADMT Version 3.0 sur un serveur Windows Server 2008.  La  migration  des  objets  vers  un  domaine  cible  opérant  dans  le  niveau  fonctionnel  Windows  Server  2008  est  parfaitement  supportée.  Par  contre  ce  n’est  pas  le  cas  lorsqu’il  s’agit  d’un  domaine  source.  La  migration  ou  consolidation des objets à partir d’un domaine source opérant dans le niveau fonctionnel Windows Server 2008 sera  prise en charge dans la version ADMT v3.1 laquelle devrait être disponible au cours du mois d’août 2008. Pour utiliser  ADMT Version 3.0 vers un environnement cible composé de contrôleurs de domaine fonctionnant sous Windows Server  2008 vous devez déployer au minimum un contrôleur de domaine Windows Server 2003, les autres contrôleurs étant  donc  opérationnels  sous  Windows  Server  2008.  Ce  point  est  quelque  peu  contraignant  puisque  cela  signifie  que  le  domaine  cible  ne  peut  être  opérationnel  en  mode  Windows  Server  2008  (niveau  3).  Une  fois  les  opérations  de  migrations  terminées,  vous  pourrez  retirer  le  contrôleur  temporaire  fonctionnant  sous  Windows  Server  2003  et  rehausser le niveau du domaine.  23 Quels types d’approbations existe­t­il dans l’environnement Active Directory ?  Les approbations internes crées lors de la création des domaines par dcpromo, les approbations de type Parent­Enfant,  les approbations de type Racine d’arborescence, les approbations externes, les approbations de domaines Kerberos V5  non Windows, les approbations raccourcies au sein d’une forêt et les approbations de forêts entre forêts fonctionnant  dans le niveau fonctionnel Windows Server 2003.  24 Quel est le nombre d’approbations au sein d’une forêt Active Directory composée de N domaines ?  N ­ 1, grâce au fait que les relations d’approbations internes utilisent le protocole Kerberos V5, sont transitives et bi­ directionnelles.  25 Que permet le routage des suffixes de noms entre les 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 deux forêts Windows Server 2003 reliées par une approbation de forêt.  26 Quels sont les services systèmes offrant les services nécessaires au bon fonctionnement des services de  domaine Active Directory de Windows Server 2008 ?  Par défaut, les services de domaine Active Directory de Windows Server 2008 nécessitent 9 services dont 8 sont en  démarrage  automatique  et  un  en  démarrage  manuel.  Il  s’agit  des  services  suivants  :  Centre  de  distribution  de  clés  Kerberos  ­  kdc,  Espace  de  noms  DFS  ­  dfs,  Horloge  Windows  ­  w32time,  Messagerie  intersite  ­  ismserv,  Netlogon  ­  netlogon, Réplication DFS ­ dfsr, Service de réplication de fichiers ­ ntfrs, Services de domaine Active Directory ­ ntds,  Station  de  travail  ­  lanmanworstation.Ces  services  sont  regroupés  au  niveau  du  Gestionnaire  de  serveur/Rôles/Services de domaine Active Directory/Services système. 

© ENI Editions - All rigths reserved

- 3-

Travaux pratiques  1. Création du domaine racine de la forêt Active Directory  Cette  procédure  a  pour  objet  de  mettre  en œ uvre  une  nouvelle  forêt  Active  Directory.  Comme  nous  l’avons  appris  précédemment, la forêt existe au travers du domaine racine de la forêt, lequel est mis en œ uvre via l’installation du  premier contrôleur de ce domaine. Ce TP vous permettra donc d’installer le premier contrôleur de domaine, du premier  domaine de la forêt.  1. 

Sur votre serveur autonome ­ ou membre d’un domaine déjà existant, cliquez sur  Démarrer ­ Exécuter. 

2. 

À l’aide du Gestionnaire de serveur/Gestion des rôles, sélectionnez le rôle Services de  domaine Active Directory. Vous pouvez aussi, comme sous Windows Server 2003, taper  la commande Dcpromo. Dans ce cas, l’installation des fichiers binaires nécessaires au  bon fonctionnement de Dcpromo sera d’abord réalisé. 

3. 

Sur l’écran de l’Assistant Installation de Active Directory, cliquez sur Suivant puis  sélectionnez l’option Contrôleur de domaine pour un nouveau domaine. 

4. 

Sur l’écran suivant, sélectionnez l’option Créer une nouvelle arborescence de domaine,  puis cliquez sur Suivant. 

5. 

Sélectionnez l’option Créer une nouvelle forêt d’arborescences de domaines, puis  cliquez sur Suivant. 

6. 

Entrez le nom du domaine DNS qui sera utilisé comme nom de domaine de la racine Active  Directory. Il pourra par exemple s’agir de privnet.company.com ou companynet.fr. Validez  votre choix en cliquant sur le bouton Suivant. 

7. 

L’écran suivant vous propose de valider le nom de domaine compatible NetBIOS associé  au domaine Active Directory. Par rapport à notre exemple, le nom proposé sera PRIVNET  ou COMPANYNET. Attention au fait que si le nom NetBIOS est déjà en production sur le  réseau, le caractère # sera associé au nom proposé, par exemple PRIVNET#. Validez  votre choix en cliquant sur le bouton Suivant. 

8. 

Validez les emplacements proposés pour accueillir la base de données Active Directory  ainsi que ses journaux de transactions en cliquant sur le bouton Suivant. 

9. 

Validez l’emplacement proposé pour accueillir le volume système partagé SYSVOL, lequel  doit être positionné sur une partition NTFS 5.0, puis cliquez sur Suivant.  En fonction de votre configuration DNS, la fenêtre Diagnostics des inscriptions DNS  s’affichera. 

10. 

Sélectionnez l’option Installer et configurer le serveur DNS sur cet ordinateur et  définir cet ordinateur pour utiliser ce serveur DNS comme serveur DNS de  préférence. Validez votre choix en cliquant sur Suivant. 

11. 

Sélectionnez l’option Autorisations compatibles uniquement avec les systèmes  d’exploitation serveurs Windows 2000 ou Windows Server 2003. Cliquez sur Suivant.

12. 

Déclarez le mot de passe du compte Administrateur local qui pourra être utilisé lors du  démarrage du contrôleur de domaine en mode DSRM (Directory Service Repair Mode). 

13. 

Validez votre configuration et déclenchez le processus de promotion vers le statut de  contrôleur de domaine. 

14. 

Il ne reste plus qu’à redémarrer l’ordinateur. 

15. 

Attendez quelques minutes que le premier redémarrage soit complètement réalisé, puis  ouvrez une session en tant qu’administrateur du domaine. 

Vous venez de réaliser l’installation d’un contrôleur de domaine dans le cadre de la mise en œ uvre de la forêt Active  Directory. 

2. Ajout d’un deuxième contrôleur de domaine dans le domaine racine 

© ENI Editions - All rigths reserved

- 1-

Cette procédure a pour objet de mettre en œ uvre un contrôleur de domaine supplémentaire dans un domaine. Dans  le cadre du rôle critique de tout domaine et plus particulièrement du domaine racine de la forêt, il est indispensable  de procéder à cette opération.  Ce TP vous permettra donc d’installer le deuxième contrôleur de domaine du domaine.  1. 

Sur votre serveur autonome ou membre d’un domaine déjà existant, cliquez sur  Démarrer ­ Exécuter. 

2. 

À l’aide du Gestionnaire de serveur/Gestion des rôles, sélectionnez le rôle Services de  domaine Active Directory. Vous pouvez aussi, comme sous Windows Server 2003, taper  la commande Dcpromo. Dans ce cas, l’installation des fichiers binaires nécessaires au  bon fonctionnement de Dcpromo sera d’abord réalisé. 

3. 

Sélectionnez le choix Contrôleur de domaine supplémentaire pour un domaine existant,  puis cliquez sur le bouton Suivant. 

4. 

Entrez les identifications nécessaires pour obtenir l’autorisation d’insérer dans le  domaine souhaité un nouveau contrôleur de domaine, puis cliquez sur Suivant. 

5. 

Indiquez le nom du domaine pour lequel vous souhaitez ajouter un nouveau contrôleur  de domaine, puis cliquez sur Suivant. 

6. 

Validez l’emplacement proposé pour accueillir le volume système partagé SYSVOL, lequel  doit être positionné sur une partition NTFS 5.0, puis cliquez sur Suivant. 

7. 

Déclarez le mot de passe du compte Administrateur local qui pourra être utilisé lors du  démarrage du contrôleur de domaine en mode DSRM (Directory Service Repair Mode). 

8. 

Validez votre configuration, déclenchez le processus de promotion vers le statut de  contrôleur de domaine puis redémarrez l’ordinateur. 

9. 

Attendez quelques minutes que le premier redémarrage soit complètement réalisé puis  ouvrez une session en tant qu’administrateur du domaine. 

3. Création d’un nouveau domaine enfant  L’objectif  de  cette  opération  est  de  créer  un  nouveau  domaine  enfant  au  sein  d’un  arbre  existant  dans  une  forêt  donnée. 

- 2-

1. 

Sur votre serveur autonome ­ ou membre d’un domaine déjà existant, cliquez sur  Démarrer ­ Exécuter. 

2. 

À l’aide de Gestionnaire de serveur/Gestion des rôles, sélectionnez le rôle Services de  domaine Active Directory. Vous pouvez aussi, comme sous Windows Server 2003, taper  la commande Dcpromo. Dans ce cas, l’installation des fichiers binaires nécessaires au  bon fonctionnement de Dcpromo sera d’abord réalisé. 

3. 

Sélectionnez le choix Créer un nouveau domaine enfant dans une arborescence de  domaine existante, puis cliquez sur le bouton Suivant. 

4. 

Entrez les identifications nécessaires pour obtenir l’autorisation d’insérer le domaine  souhaité dans la forêt, puis cliquez sur Suivant. 

5. 

À l’aide du bouton Parcourir, indiquez le nom du domaine parent pour lequel vous  souhaitez ajouter le nouveau domaine enfant, puis cliquez sur Suivant. 

6. 

L’écran suivant vous propose de valider le nom de domaine compatible NetBIOS associé  au domaine Active Directory. Validez votre choix en cliquant sur le bouton Suivant. 

7. 

Validez les emplacements proposés pour accueillir la base de données Active Directory  ainsi que ses journaux de transactions en cliquant sur le bouton Suivant. 

8. 

Validez l’emplacement proposé pour accueillir le volume système partagé SYSVOL, lequel  doit être positionné sur une partition NTFS 5.0, puis cliquez sur Suivant. 

9. 

Sélectionnez le mode Autorisations compatibles uniquement avec les systèmes  d’exploitation serveurs Windows 2000 ou Windows Server 2003. Cliquez sur Suivant.

© ENI Editions - All rigths reserved

10. 

Déclarez le mot de passe du compte Administrateur local qui pourra être utilisé lors du  démarrage du contrôleur de domaine en mode DSRM (Directory Service Repair Mode). 

11. 

Validez votre configuration, déclenchez le processus de promotion vers le statut de  contrôleur de domaine puis redémarrez l’ordinateur. 

12. 

Attendez quelques minutes que le premier redémarrage soit complètement réalisé puis  ouvrez une session en tant qu’administrateur du nouveau domaine ou du domaine racine  de la forêt. 

Vous  venez  de  réaliser  l’installation  d’un  nouveau  contrôleur  de  domaine  dans  le  cadre  de  la  mise  en  œ uvre  d’un  domaine enfant dans une arborescence d’une forêt Active Directory. 

4. Création d’une nouvelle arborescence  L’objectif  de  cette  opération  est  de  créer  un  nouveau  domaine  en  tant  que  racine  d’arborescence  dans  une  forêt  donnée.  1. 

Sur votre serveur autonome ­ ou membre d’un domaine déjà existant, cliquez sur  Démarrer ­ Exécuter. 

2. 

À l’aide du Gestionnaire de serveur/Gestion des rôles, sélectionnez le rôle Services de  domaine Active Directory. Vous pouvez aussi, comme sous Windows Server 2003, taper  la commande Dcpromo. Dans ce cas, l’installation des fichiers binaires nécessaires au  bon fonctionnement de Dcpromo sera d’abord réalisé. 

3. 

Sélectionnez le choix Arborescence de domaine dans une forêt existante, puis cliquez  sur le bouton Suivant. 

4. 

Entrez les identifications nécessaires pour obtenir l’autorisation d’insérer le domaine  souhaité dans la forêt, puis cliquez sur Suivant. 

5. 

Entrez le Nom DNS complet pour le nouveau domaine racine d’arborescence. 

 

6. 

L’écran suivant vous propose de valider le nom de domaine compatible NetBIOS associé  au domaine Active Directory. Validez votre choix en cliquant sur le bouton Suivant. 

7. 

Validez les emplacements proposés pour accueillir la base de données Active Directory 

© ENI Editions - All rigths reserved

- 3-

ainsi que ses journaux de transactions en cliquant sur le bouton Suivant.  8. 

Validez l’emplacement proposé pour accueillir le volume système partagé SYSVOL, lequel  doit être positionné sur une partition NTFS 5.0, puis cliquez sur Suivant. 

9. 

Sélectionnez le mode Autorisations compatibles uniquement avec les systèmes  d’exploitation serveurs Windows 2000 ou Windows Server 2003. Cliquez sur Suivant.

10. 

Déclarez le mot de passe du compte Administrateur local qui pourra être utilisé lors du  démarrage du contrôleur de domaine en mode DSRM (Directory Service Repair Mode). 

11. 

Validez votre configuration, déclenchez le processus de promotion vers le statut de  contrôleur de domaine puis redémarrez l’ordinateur. 

12. 

Attendez quelques minutes que le premier redémarrage soit complètement réalisé puis  ouvrez une session en tant qu’administrateur du nouveau domaine ou du domaine racine  de la forêt. 

Vous  venez  de  réaliser  l’installation  d’un  nouveau  contrôleur  de  domaine  dans  le  cadre  de  la  mise  en  œ uvre  d’un  domaine racine d’arborescence au sein d’une forêt Active Directory. 

5. Désinstallation normale d’un contrôleur de domaine Active Directory  Cette  opération  vous  permettra  de  retirer  un  contrôleur  de  domaine  d’un  domaine  ­  et  donc  de  la  partition  de  configuration d’une forêt donnée.  Pour  effectuer  cette  procédure,  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.  Avant  d’exécuter cette procédure, vérifiez que ce contrôleur de domaine n’est pas le seul catalogue  global  et  qu’il  ne  tient  pas  de  rôle  de  maître  d’opérations.  Si  ce  contrôleur  de  domaine  est  un  catalogue  global,  assurez­vous qu’il existe un autre catalogue global mis à la disposition des utilisateurs avant de le rétrograder. Si  ce contrôleur de domaine joue actuellement un ou plusieurs rôles de maître d’opérations, transférez les rôles de  maître d’opérations vers un autre contrôleur de domaine avant de le rétrograder. Si ce contrôleur de domaine est  le dernier contrôleur du domaine, le fait de le rétrograder permet de supprimer le domaine concerné de la forêt. S’il  s’agit du dernier domaine de la forêt, le fait de le rétrograder permet de supprimer la forêt. 

Cas  particulier  des  partitions  de  l’annuaire  d’applications  :  pour  pouvoir  rétrograder  votre  contrôleur  de  domaine lorsque celui­ci possède le dernier réplica d’une ou plusieurs partitions de l’annuaire d’applications,  vous  devez  d’abord  supprimer  ces  réplicas.  L’Assistant  Installation  de  Active  Directory  vous  proposera  cette  opération de suppression et vous perdrez donc toutes les données associées à ces partitions. Vous pourrez aussi  les supprimer manuellement à l’aide de la commande de maintenance de l’annuaire Active Directory ntdsutil. 

Certains composants empêchent de retirer le rôle d’un contrôleur de domaine. Dans certains cas, certaines  opérations préalables seront nécessaires. 

  La  suppression  d’un  contrôleur  de  domaine  ne  peut  avoir  lieu  lorsque  celui­ci  joue  le  rôle  d’autorité  de  certification  racine  d’entreprise.  Cette  restriction  est  valable  sous  Windows  2000  Server,  Windows  Server  2003 et Windows Server 2008.  Pour rétrograder le contrôleur de domaine, procédez de la manière suivante :  1. 

- 4-

Sur votre serveur contrôleur de domaine ou membre d’un domaine déjà existant, cliquez  sur Démarrer ­ Exécuter.  © ENI Editions - All rigths reserved

2. 

Tapez dcpromo pour lancer l’Assistant Installation de Active Directory, puis cliquez sur  Suivant. 

3. 

Sur la page Supprimer Active Directory, cliquez sur Suivant puis continuez en suivant  les étapes de l’Assistant. 

6. Désinstallation forcée d’un contrôleur de domaine Active Directory  Cette  opération  vous  permettra  de  réussir  le  retrait  des  composants  Active  Directory  d’un  contrôleur  de  domaine  lorsque l’état du contrôleur ou de la forêt ne permet pas d’y parvenir.  Cette opération est très intéressante dans le cas où le serveur concerné doit absolument être récupéré, sans passer  par une réinstallation complète du système d’exploitation.  1. 

Sur votre serveur contrôleur de domaine ou membre d’un domaine déjà existant, cliquez  sur Démarrer ­ Exécuter. 

2. 

Pour lancer l’Assistant Installation de Active Directory en mode de suppression forcée,  tapez dcpromo /forceremoval, puis cliquez sur Suivant. 

3. 

Cliquez sur Suivant puis continuez en suivant les étapes de l’Assistant. 

L’écran qui suit montre que le contrôleur quitte la forêt sans réaliser les opérations de retrait. Il sera donc du ressort  de l’administrateur de l’entreprise de réaliser les opérations de metadata cleanup à l’aide de la commande Ntdsutil.  L’assistant  Installation  de  Active  Directory  vous  informera  que  vous  procédez  à  la  suppression  d’Active  Directory  sans mettre à jour les métadonnées.  Windows Server 2003 et Windows Server 2008 permettent l’utilisation du switch /ForceRemoval pour forcer  la suppression des services Active Directory. Dans le même ordre d’idée, Windows Server 2008 implémente le  nouveau  switch  /Demotion  pour  prendre  en  charge  la  désinstallation  automatisée  des  contrôleurs  de  domaine  Windows  Server  2008.  Pour  plus  d’informations  sur  les  paramètres  du  switch  /Demotion,  tapez  la  commande  :  Dcpromo /?:Demotion. 

7. Augmentation du niveau fonctionnel d’un domaine  L’objectif de cette opération est d’augmenter le niveau fonctionnel de votre domaine.  Pour rappel, à l’issue de la mise en œ uvre d’un nouveau domaine à partir d’un contrôleur fonctionnant sous Windows  Server  2008,  le  domaine  fonctionne  en  mode  Windows  2000  mixte.  Il  pourra  donc  être  nécessaire  d’atteindre  le  niveau Windows 2000 natif ou les niveaux fonctionnels Windows Server 2003 ou Windows Server 2008.  Pour  exécuter  cette  procédure,  vous  devez  être  membre  du  groupe Admins  du  domaine  dans  le  domaine  pour  lequel  vous  souhaitez  augmenter  la  fonctionnalité  ou  du  groupe Administrateur  de  l’entreprise dans  Active Directory ou bien disposer de l’autorisation appropriée. 

1. 

Ouvrez la console de gestion MMC Domaines et approbations Active Directory. 

2. 

Dans l’arborescence de la console, cliquez avec le bouton droit sur le domaine pour lequel  vous souhaitez augmenter la fonctionnalité, puis cliquez sur Augmenter le niveau  fonctionnel du domaine. 

3. 

Dans la fenêtre Sélectionner un niveau fonctionnel du domaine disponible, effectuez  l’une des actions suivantes :  ●

Pour augmenter le niveau fonctionnel du domaine vers Windows 2000 natif,  cliquez sur Windows 2000 natif, puis cliquez sur Augmenter. 

●

Pour augmenter le niveau fonctionnel du domaine vers Windows Server 2003,  cliquez sur Windows Server 2003, puis cliquez sur Augmenter. 

●

Pour augmenter le niveau fonctionnel du domaine vers Windows Server 2008,  cliquez sur Windows Server 2008, puis cliquez sur Augmenter. 

© ENI Editions - All rigths reserved

- 5-

Pour activer les nouvelles fonctionnalités à l’échelle du domaine, tous les contrôleurs de domaine du domaine  doivent exécuter Windows Server 2008. 

De plus, pour qu’il soit, à terme, possible d’activer les nouvelles fonctionnalités Active Directory à l’échelle de  la forêt, tous les contrôleurs de domaine de la forêt doivent fonctionner sous Windows Server 2008 et tous  les domaines doivent avoir atteint le niveau fonctionnel Windows Server 2008. 

Une fois que le niveau fonctionnel d’un domaine est défini sur Windows 2000 natif, Windows Server 2003 ou  Windows Server 2008, il n’est plus possible de retourner vers l’ancien mode. 

Vous pouvez également augmenter le niveau fonctionnel du domaine en cliquant avec le bouton droit sur un  domaine  affiché  dans  la  console  Utilisateurs  et  ordinateurs  Active  Directory,  puis  en  cliquant  sur  Augmenter le niveau fonctionnel du domaine. 

Vous  venez  de  réaliser  l’augmentation  du  niveau  fonctionnel  d’un  domaine  fonctionnant  en  mode  Windows  2000  mixte, vers le niveau Windows 2000 natif, le niveau Windows Server 2003 ou le niveau fonctionnel Windows Server  2008. 

8. Augmentation du niveau fonctionnel de la forêt  L’objectif  de  ce  TP  est  d’augmenter  le  niveau  fonctionnel  de  votre  forêt  du  niveau  Windows  2000  vers  le  niveau  Windows Server 2003.  À  l’issue  de  l’installation  du  1e r  contrôleur  de  domaine  fonctionnant  sous  Windows  Server  2008  au  sein  du  1 e r  domaine du 1 e r arbre de la forêt, la forêt est opérationnelle dans le niveau fonctionnel Windows 2000.   Vous  pouvez  ensuite  réaliser  la  même  opération  pour  passer  du  niveau  Windows  Server  2003  vers  le  niveau  Windows Server 2008.  1. 

Ouvrez la console de gestion MMC Domaines et approbations Active Directory. 

2. 

Dans l’arborescence de la console, cliquez avec le bouton droit sur Domaines et  approbations Active Directory, puis cliquez sur Augmenter le niveau fonctionnel de la  forêt. 

3. 

Dans Sélectionner un niveau fonctionnel de forêt disponible, cliquez sur Windows  Server 2003, puis cliquez sur Augmenter.  Une fois que le niveau fonctionnel de la forêt est défini sur Windows Server 2003, il ne peut plus être changé  pour atteindre à nouveau Windows 2000. 

Le  niveau  fonctionnel  de  domaine  Windows  2000  natif  est  le  niveau  fonctionnel  minimum  requis  pour  augmenter le niveau fonctionnel de la forêt vers Windows Server 2003. 

Pour augmenter le niveau fonctionnel de la forêt, vous devez d’abord mettre à niveau (ou rétrograder) tous  les  contrôleurs  de  domaine  Windows  2000  existant  dans  votre  forêt.  Cette  opération  vous  permettra  d’atteindre  le  niveau  fonctionnel  de  domaine  Windows  Server  2003  dans  tous  les  domaines  de  la  forêt.  Pour  atteindre  le  niveau  fonctionnel  de  forêt  Windows  Server  2008,  vous  devez  respecter  la  même  logique.  Tous  les  domaines  de  la  forêt  doivent,  dans  un  1 e r  temps,  atteindre  le  niveau  fonctionnel  Windows  Server  2008,  ce  qui  signifie  que  vous  devez  mettre  à  niveau  vers  Windows  Server  2008  tous  les  contrôleurs  de  domaine.  En  cas  de  problème : dans le cas où il ne serait pas possible d’atteindre le niveau fonctionnel souhaité, vous pourrez utiliser  le  bouton  Enregistrer  sous  de  la  fenêtre  Augmenter  le  niveau  fonctionnel  de  la  forêt.  Cette  opération  vous  permettra  d’enregistrer  dans  un  fichier  la  liste  des  contrôleurs  de  domaine  de  la  forêt  qui  devraient  faire  l’objet  d’une opération de mise à niveau de Windows 2000 Server ou Windows Server 2003 vers Windows Server 2008.  Une autre alternative pourra aussi consister à retirer ces "anciens" contrôleurs. 

- 6-

© ENI Editions - All rigths reserved

Vous venez de réaliser l’augmentation du niveau fonctionnel d’une forêt fonctionnant en mode Windows 2000 vers le  niveau fonctionnel Windows Server 2003 et Windows Server 2008. 

9. Recherche d’un objet à l’aide des Requêtes sauvegardées  Cette opération vous permettra de créer des requêtes sauvegardées dans la console de gestion MMC Utilisateurs et  ordinateurs  Active  Directory.  Il  s’agit  d’une  nouvelle  fonctionnalité  du  composant  enfichable  Utilisateurs  et  ordinateurs Active Directory.  1. 

Ouvrez la console Utilisateurs et ordinateurs Active Directory. 

2. 

Dans l’arborescence de la console, cliquez avec le bouton droit sur Requêtes  sauvegardées ou sur l’un des sous­dossiers dans lequel vous voulez sauvegarder une  requête. 

3. 

Cliquez sur Nouveau puis sur Requête. Vous pouvez aussi organiser vos requêtes en  créant de multiples dossiers. 

4. 

Dans la zone Nom et Description, tapez le nom de la requête et éventuellement une  description de celle­ci. 

5. 

Pour définir l’emplacement à partir duquel vous souhaitez lancer votre recherche, cliquez  sur le bouton Parcourir. 

6. 

Pour faire en sorte qu’une recherche porte sur tous les conteneurs et sous­conteneurs  de l’emplacement sélectionné, sélectionnez la case à cocher Inclure les sous­ conteneurs. 

7. 

Pour définir votre requête, cliquez sur Définir la requête. Vous retrouverez une fenêtre  de sélection des différentes classes et des attributs Active Directory. 

Les requêtes sauvegardées sont très pratiques pour retrouver rapidement des objets répondant à certains  critères  spécifiques.  Vous  pouvez  aussi,  en  utilisant  l’option  Recherche  personnalisée  ­  Avancé,  créer  directement une requête en utilisant les syntaxes Ldap. 

Les requêtes sont directement enregistrées dans le fichier de console dsa.msc. Il vous suffit donc d’accéder  à ce fichier pour disposer de vos requêtes sauvegardées. Vous pouvez aussi exporter vers un fichier .xml vos  requêtes et les importer dans d’autres consoles. 

Vous  venez  de  créer  des  requêtes  sauvegardées  dans  un  fichier  de  console  .msc  et  d’exporter  et  importer  des  requêtes sauvegardées à l’aide d’un fichier XML. 

10. Création d’une Unité d’Organisation  L’objectif de cette opération est de créer une nouvelle unité d’organisation dans votre domaine Active Directory.  Un  objet  de  type  Unité  d’organisation  aide  à  la  représentation  de  la  structure  logique  de  l’entreprise.  Un  modèle  d’organisation  construit  sur  la  base  d’une  hiérarchie  d’unités  d’organisation  pourra  aider  au  regroupement  et  à  l’organisation  des  objets  de  type  utilisateurs,  ordinateurs,  imprimantes  et  dossiers  partagés.  Ensuite,  ces  unités  d’organisations pourront être utilisées par les services de délégation et être pourvues de permissions capables de  masquer certains objets.  1. 

Ouvrez la console Utilisateurs et ordinateurs Active Directory. 

2. 

Dans l’arborescence de la console, cliquez avec le bouton droit sur Nouveau puis cliquez  sur Unité d’organisation. 

3. 

Sur la fenêtre Nouvel objet ­ Unité d’organisation, entrez le nom de l’objet : Direction du  Marketing, puis validez en cliquant sur OK. 

4. 

Créez la hiérarchie ci­dessous dans l’unité d’organisation Direction du Marketing.  ●

OU Direction Europe et OU Direction Asie 

© ENI Editions - All rigths reserved

- 7-

●

Dans chacune des OU, créez les OUs PC Marketing, Portables Marketing, Serveurs  Marketing, Utilisateurs Marketing 

●

Dans chacune des OU Utilisateurs, créez les OU Utilisateurs, Directeurs et  Administrateurs. 

Vous  venez  de  créer  une  hiérarchie  d’unités  d’organisation  à  l’aide  de  la  console  de  gestion  MMC  Utilisateurs  et  ordinateurs Active Directory. 

11. Délégation du contrôle de l’administration sur une OU et modification de l’ACL d’un  objet  L’objectif  de  cette  opération  consiste  à  transmettre  le  contrôle  administratif  sur  des  objets  de  l’annuaire  Active  Directory à des utilisateurs et/ou groupes d’utilisateurs. De cette manière, ces utilisateurs ou groupes d’utilisateurs  disposeront des droits qui leur permettront d’effectuer telle ou telle tâche d’administration sur les dits objets.  Objectif du TP : En tant qu’administrateur du domaine, vous allez déléguer à l’utilisateur Bob Durand le contrôle total  sur les objets utilisateurs de l’unité d’organisation Direction Europe / Utilisateurs Marketing.  Vous vous arrangerez pour que sur les containers :  ●

Direction Europe/Utilisateurs Marketing/Directeurs et 

●

Direction Europe/Utilisateurs Marketing/Administrateurs, 

l’utilisateur Bob Durand dispose uniquement des informations de lecture sur les objets utilisateurs et des permissions  de modification sur les informations personnelles des utilisateurs.  Étape 1  Pour réaliser ces opérations et déléguer le contrôle d’une unité d’organisation, procédez de la manière suivante :  1. 

Ouvrez la console Utilisateurs et ordinateurs Active Directory. 

2. 

Dans l’arborescence de la console, cliquez avec le bouton droit sur l’unité d’organisation ­  Direction Europe / Utilisateurs Marketing ­ sur laquelle vous devez réaliser l’opération de  délégation du contrôle. 

3. 

Sélectionnez Délégation de contrôle pour démarrer l’Assistant Délégation de contrôle. 

4. 

Ajoutez l’utilisateur Bob Durand à la liste des personnes concernées par l’opération de  délégation, puis cliquez sur Suivant. 

5. 

Dans la fenêtre Tâches à déléguer, sélectionnez l’option Créer une tâche personnalisée  à déléguer, puis cliquez sur Suivant. 

6. 

Dans la fenêtre Type d’objet Active Directory, sélectionnez l’étendue de la tâche que  vous voulez déléguer en cochant les objets de types Objets Utilisateur et Unité  d’organisation. 

7. 

Sur la fenêtre Autorisations, sélectionnez les autorisations à déléguer en cochant  l’option Contrôle total. 

8. 

Acceptez les opérations à réaliser par l’assistant en cliquant sur le bouton Terminer. 

Cette première étape du TP vous a permis de créer un jeu de permissions qui définit sur les objets  Utilisateurs et  Unités d’organisation du container Direction Europe/Utilisateurs Marketing, le contrôle total à Bob Durand.  Étape 2  La suite du TP consiste à modifier les droits des unités d’organisation enfants nommées Directeurs et Administrateurs  de  telle  sorte  que  Bob  Durand  ne  puisse  que  lire  les  objets  et  modifier  les  propriétés  des  utilisateurs  de  type  Informations personnelles.  Pour  réaliser  ces  opérations  en  jouant  sur  les  permissions  attribuées  sur  les  objets  de  l’annuaire  Active  Directory,  vous devrez procédez de la manière suivante : 

- 8-

1. 

Ouvrez la console Utilisateurs et ordinateurs Active Directory. 

2. 

Dans l’arborescence de la console, cliquez avec le bouton droit sur un container 

© ENI Editions - All rigths reserved

quelconque et activez l’option Fonctionnalités avancées du menu Affichage.  3. 

Positionnez­vous sur le conteneur Directeurs, puis cliquez avec le bouton droit et  choisissez Propriétés. 

4. 

Accédez à l’onglet Sécurité du conteneur Directeurs puis cliquez sur le bouton  Paramètres avancés. 

5. 

Désélectionnez l’option Permettre aux autorisations héritées du parent de se propager  à cet objet et aux objets enfants, puis validez la fenêtre de sécurité en cliquant sur le  bouton Copier. 

6. 

Supprimez tous les doits appliqués à l’utilisateur Bob Durand, puis sélectionnez le bouton  Ajouter pour réaffecter à Bob les droits ci­dessous :  ●

Appliquer à : Objets Utilisateur 

●

Autorisations : Lire toutes les propriétés 

●

Propriétés : Lire toutes les propriétés, Ecrire Informations personnelles. 

7. 

Validez la fenêtre d’entrée en cliquant sur OK.  Cette deuxième étape du TP vous a permis d’altérer les permissions des conteneurs  souhaités pour éviter que les permissions des conteneurs de niveaux supérieurs aient  une influence. 

8. 

Finalement, assurez­vous que l’utilisateur Bob Durand dispose bien de la bonne  délégation en ouvrant une session sous le nom de Bob Durand. Cet utilisateur doit être  capable de créer des objets utilisateur et unité d’organisation dont le répertoire dans le  conteneur Directeurs. 

La modification de l’option d’héritage Permettre aux autorisations héritées du parent de se propager à cet  objet et aux objets enfants, permettant de stopper l’héritage, propose de copier les droits pour pouvoir les  modifier.  L’opération  de  copie  des  permissions  peut  avoir  un  effet  dramatique  en  terme  de  taille  de  base  et  de  volume des réplications à réaliser pour synchroniser les ACLs des objets et aussi de leurs propriétés, vers tous les  contrôleurs de domaine. Un message d’avertissement vous en informe. 

 

12. Déplacement d’une OU  L’objectif de cette opération consiste à déplacer un objet de type Unité d’organisation vers un autre conteneur situé  dans le même domaine.  Pour  effectuer  cette  procédure,  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. 

© ENI Editions - All rigths reserved

- 9-

1. 

Ouvrez la console Utilisateurs et ordinateurs Active Directory. 

2. 

Dans l’arborescence de la console, cliquez avec le bouton droit sur l’unité d’organisation  que vous souhaitez déplacer. 

3. 

Cliquez sur Déplacer, puis sur le dossier de destination du déplacement. 

La  console  de  gestion  MMC  Utilisateurs  et  ordinateurs  Active  Directory  ne  prend  en  charge  que  le  déplacement  des  unités  d’organisation  à  l’intérieur  du  même  domaine.  Pour  pouvoir  déplacer  des  objets  entre domaines, vous pourrez utiliser la commande Movetree, disponible dans les outils de support de Windows  Server 2003. Cet outil peut aussi être utilisé sous Windows Server 2008. 

13. Création des relations d’approbations externes  L’objectif de ce TP vous permettra de créer une relation d’approbation externe entre un domaine de votre forêt et un  domaine d’une autre forêt ou un domaine fonctionnant sous Windows NT 4.0.  Pour créer une approbation externe, procédez de la façon suivante :  1. 

Ouvrez une console de gestion MMC, Domaines et approbations Active Directory. 

2. 

Dans l’arborescence de la console, faites un clic droit sur le domaine Active Directory pour  lequel vous souhaitez déclarer une approbation, puis faites Propriétés. 

3. 

Sous l’onglet Approbations, cliquez sur Nouvelle approbation puis sur Suivant. 

4. 

Sur la page Nom d’approbation, tapez le nom DNS (ou le nom NetBIOS) du domaine puis  cliquez sur Suivant. 

5. 

Sur la page Type d’approbation, cliquez sur Approbation externe puis sur Suivant. 

6. 

En fonction des besoins, spécifiez le sens de l’approbation : 

7. 

●

Pour créer une approbation externe à deux sens, cliquez sur Deux sens. 

●

Pour créer une approbation externe à sens unique, choisissez le sens de  l’approbation, en entrée ou en sortie. 

Continuez en suivant les étapes de l’Assistant.  Pour  effectuer  cette  procédure,  vous  devez  être  membre  du  groupe  Admins  du  domaine  ou  du  groupe  Administrateurs de l’entreprise dans Active Directory. 

Si  vous  disposez  des  informations  d’identification  appropriées  pour  chaque  domaine,  vous  pouvez  créer  simultanément les deux sens d’une approbation externe en cliquant sur À la fois ce domaine et le domaine  spécifié, sur la page Sens de l’approbation. 

Si  vous  voulez  permettre  aux  utilisateurs  du  domaine  spécifié  d’avoir  accès  à  toutes  les  ressources  de  ce  domaine,  cliquez  sur  Autoriser l’authentification  pour  toutes  les  ressources  dans  le  domaine  local  sur  la  page  Propriétés  de  l’approbation  sortante.  Microsoft  recommande  cette  option  lorsque  les  deux  domaines  appartiennent à la même organisation. 

Si vous voulez restreindre l’accès aux ressources de ce domaine aux utilisateurs du domaine spécifié, cliquez  sur Autoriser l’authentification uniquement pour les ressources sélectionnées dans le domaine local sur la  page  Propriétés  de  l’approbation  sortante.  Microsoft  recommande  cette  option  lorsque  les  domaines  appartiennent à des organisations différentes. 

Vous  venez  de  créer  une  approbation  externe  avec  un  domaine  Active  Directory  d’une  autre  forêt  ou  un  domaine  Windows  NT  4.0.  En  fonction  des  besoins,  le  sens  de  l’approbation  sera  unidirectionnel  ­  dans  un  sens  ou  dans 

- 10 -

© ENI Editions - All rigths reserved

l’autre, ou bidirectionnel, c’est­à­dire dans les deux sens. 

14. Création des relations d’approbations raccourcies  L’objectif de ce TP vous permettra de créer une relation d’approbation raccourcie dans le but d’optimiser le circuit des  authentifications Kerberos au sein d’une forêt Windows 2000, Windows Server 2003 ou Windows Server 2008.  Pour créer une approbation raccourcie entre deux domaines de la même forêt, procédez de la façon suivante :  1. 

Ouvrez une console de gestion MMC, Domaines et approbations Active Directory. 

2. 

Dans l’arborescence de la console, faites bouton droit sur le domaine pour lequel vous  souhaitez déclarer une approbation raccourcie, puis cliquez sur Propriétés. 

3. 

Sous l’onglet Approbations, sélectionnez Nouvelle approbation puis sur Suivant. 

4. 

Sur la page Nom d’approbation, tapez le nom DNS (ou le nom NetBIOS) du domaine puis  cliquez sur Suivant. 

5. 

Sur la page Direction de l’approbation, effectuez l’une des opérations suivantes : 

6. 

●

Pour créer une approbation raccourcie à deux sens, cliquez sur Deux sens. 

●

Pour créer une approbation raccourcie à sens unique entrante, cliquez sur Sens  unique : en entrée. 

●

Pour créer une approbation raccourcie à sens unique sortante, cliquez sur Sens  unique : en sortie. 

Continuez en suivant les étapes de l’Assistant. 

Vous venez de créer une approbation de type raccourcie entre deux domaines Active Directory de la même forêt. De  cette manière, le transit des authentifications inter­domaines est raccourci. 

15. Création des relations d’approbations entre forêts  L’objectif  de  ce  TP  vous  permettra  de  créer  une  relation  d’approbation  de  forêts  afin  de  fédérer  deux  entités  de  sécurité distinctes en une plus grande entité. Cette configuration conviendra certainement à des organisations qui ­  pour des raisons techniques ou organisationnelles, ont été obligées d’implémenter deux forêts Active Directory, plutôt  qu’une seule.  Avec les approbations de forêts, les authentifications Kerberos V5 pourront être utilisées entre les deux forêts et la  transitivité  des  authentifications  de  forêts  permettra  un  branchement  facilité  des  forêts  composées  de  multiples  domaines.  Pour créer une approbation de forêts, suivez les indications ci­dessous :  1. 

Ouvrez une console de gestion MMC, Domaines et approbations Active Directory. 

2. 

Dans l’arborescence de la console, faites bouton droit sur le domaine racine de votre  forêt puis cliquez sur Propriétés. 

3. 

Sous l’onglet Approbations, sélectionnez l’option Nouvelle approbation puis cliquez sur  Suivant. 

4. 

Dans la page Nom d’approbation, tapez le nom DNS (ou le nom NetBIOS) du domaine  racine de l’autre forêt, puis cliquez sur Suivant. 

5. 

Dans la page Type d’approbation, cliquez sur Approbation de la forêt puis sur Suivant. 

6. 

Dans la page Direction de l’approbation, effectuez l’une des opérations suivantes :  ●

Pour créer une approbation de forêt bidirectionnelle, cliquez sur Bidirectionnel. 

●

Pour créer une approbation de forêt entrante unidirectionnelle, cliquez sur Sens  unique : en entrée. 

●

Pour créer une approbation de forêt sortante unidirectionnelle, cliquez sur Sens  unique : en sortie. 

© ENI Editions - All rigths reserved

- 11 -

7. 

Continuez en suivant les étapes de l’Assistant. 

Pour  créer  une  approbation  de  forêt,  votre  environnement  doit  être  correctement  configuré.  Tous  les  contrôleurs  doivent  fonctionner  sous  Windows  Server  2003  ou  Windows  Server  2008,  tous  les  domaines  doivent utiliser le niveau fonctionnel Windows Server 2003 ou Windows Server 2008 et les deux forêts impliquées  dans  l’approbation  de  forêt  doivent  fonctionner  dans  le  niveau  fonctionnel  Windows  Server  2003  ou  Windows  Server 2008. 

Dans le cadre du processus de mise à niveau des forêts, Microsoft recommande de commencer ce processus  de  mise  à  niveau  technique  en  commençant  par  le  domaine  racine  de  la  forêt.  Une  fois  les  contrôleurs  de  domaine des domaines racines mis à niveau, vous pouvez choisir d’appliquer un niveau fonctionnel commun à ces  deux domaines. Les domaines racines de chacune des forêts pourront donc utiliser le niveau fonctionnel de forêt  Windows Server 2003 ou Windows Server 2008. 

Pour  pouvoir  effectuer  cette  procédure,  vous  devez  être  membre  du  groupe  Admins  du  domaine  (dans  le  domaine racine de la forêt) ou du groupe Administrateurs de l’entreprise dans Active Directory. 

Si  vous  êtes  membre  du  groupe  Créateurs  de  confiance  de  forêt  entrante,  vous  pouvez  créer,  pour  cette  forêt, des approbations de forêt entrantes unidirectionnelles. 

Sur un contrôleur de domaine exécutant Windows Server 2003, le domaine racine de la forêt est le premier  domaine  listé  dans  l’arborescence  de  la  console  Domaines  et  approbations  Active  Directory.  Cette  configuration n’est pas prévue sur les contrôleurs de domaine exécutant Windows 2000. 

Si  vous  disposez  des  informations  d’identification  d’administration  appropriées  pour  chaque  forêt,  vous  pouvez créer simultanément les deux côtés d’une approbation de forêt en cliquant sur À la fois ce domaine  et le domaine spécifié, dans la page Sens de l’approbation. 

Vous  venez  de  créer  une  approbation  de  forêts  entre  deux  forêts  Active  Directory  fonctionnant  dans  le  niveau  fonctionnel Windows Server 2003 ou Windows Server 2008. En fonction des besoins, vous avez configuré le sens de  l’approbation en entrée, en sortie ou en mode bidirectionnel. Ainsi, les deux forêts sont assemblées et la transitivité  Kerberos est possible entre les deux forêts. 

16. Gestion des suffixes UPN  L’objectif de ce TP vous permettra de déclarer sur la forêt l’usage possible d’un ou plusieurs espaces de nommage  additionnels utilisables pour former l’UPN des utilisateurs et ainsi aider à une ouverture de session plus conviviale et  simple pour les utilisateurs de la forêt.  Par exemple, l’usage des suffixes UPN permet à un utilisateur dont le compte utilisateur est réellement stocké dans le  domaine eu.corpnet.company.com d’ouvrir une session réseau Kerberos en utilisant les UPN [email protected]  ou Bdurand@ corporate.net. Dans le deuxième exemple, le domaine corporate.net n’existe pas en tant que domaine  Active Directory.  Pour ajouter des suffixes de noms d’utilisateurs principaux, procédez de la manière suivante : 

- 12 -

1. 

Ouvrez une console de gestion MMC, Domaines et approbations Active Directory. 

2. 

Dans l’arborescence de la console, cliquez avec le bouton droit sur Domaines et  approbations Active Directory puis cliquez sur Propriétés. 

3. 

Sous l’onglet Suffixes UPN, déclarez un autre suffixe UPN pour la forêt puis cliquez sur  Ajouter. 

© ENI Editions - All rigths reserved

Ajout et Suppression des suffixes UPN sur la forêt Active Directory  Une  fois  les  suffixes  déclarés,  vous  pourrez  les  exploiter  modifiant  si  nécessaire  le  nom  principal  de  l’utilisateur  à  l’aide de la console de gestion MMC, Utilisateurs et ordinateurs Active Directory.  La figure ci­après illustre cette opération. 

© ENI Editions - All rigths reserved

- 13 -

Modification de l’UPN de l’utilisateur Bob Durand 

Pour  pouvoir  effectuer  cette  procédure,  vous  devez  être  membre  du  groupe  Admins  du  domaine  (dans  le  domaine racine de la forêt) ou du groupe Administrateurs de l’entreprise dans Active Directory.    Les suffixes UPN doivent impérativement respecter les syntaxes officielles DNS.

Lorsqu’un utilisateur ouvre une session réseau à un UPN différent de son domaine réel, il est nécessaire de  contacter un catalogue global. 

Un  utilisateur  disposant  d’un  UPN  spécifique  peut  toujours  continuer  d’utiliser  l’UPN  lié  à  son  domaine  d’appartenance Active Directory. 

Vous  venez  d’utiliser  la  console  de  gestion  MMC  Domaines  et  approbations  Active  Directory  pour  gérer  les  suffixes  UPN au niveau de la forêt. 

- 14 -

© ENI Editions - All rigths reserved

Usage des groupes en environnement Active Directory  1. Les différents types de groupes Windows  La quasi­totalité des systèmes d’exploitation implémente la notion de groupe dans le but de simplifier l’administration  des  systèmes  ainsi  que  la  gestion  des  accès  aux  ressources  partagées  par  ces  mêmes  systèmes.  Ainsi,  en  regroupant  les  différentes  catégories  d’utilisateurs  au  sein  des  groupes,  il  devient  plus  simple  d’assigner  des  autorisations et par la suite, d’en assurer le suivi.  En effet, la gestion des autorisations octroyées de manière spécifique à certains utilisateurs doit rester une opération  à caractère ponctuelle et devrait plutôt faire l’objet d’une opération basée sur un groupe.  Depuis  OS/2  LAN  Manager  et  depuis  les  toutes  premières  versions  de  Windows  NT,  la  notion  de  groupe  a  été  largement utilisée dans le cadre de la gestion des privilèges d’administration et des accès aux ressources partagées.  Cependant,  en  dehors  du  cadre  du  domaine,  il  convient  de  rappeler  que  les  groupes  sont  aussi  disponibles  sur  toutes  les  machines  fonctionnant  sous  Windows  NT,  Windows  2000,  Windows  XP,  Windows  Server  2003  et  bien  entendu, Windows Vista et Windows Server 2008.  Aujourd’hui, les services d’annuaire Active Directory offrent de multiples groupes prédéfinis ainsi que différents types  de groupes, lesquels sont destinés à différents types d’usage. L’écran ci­après illustre cet aspect et montre qu’Active  Directory propose deux grandes catégories de groupes : les groupes de sécurité et les groupes de distribution. 

 

a. Les groupes de sécurité  Comme  leur  nom  l’indique,  les  groupes  de  sécurité  sont  prédisposés  à  être  utilisés  dans  le  cadre  des  opérations  nécessitant un contrôle d’accès. Pour que ces opérations ou demandes d’accès puissent être contrôlées, il est clair  que les groupes de sécurité devront disposer d’un SID unique (Security Identifier Descriptor), tout comme cela est le  cas pour les objets des classes user, inetOrgPerson ou computer.  Bien  entendu,  lorsque  des  utilisateurs  sont  membres  d’un  ou  plusieurs  groupes,  ces  utilisateurs  héritent  des  autorisations assignées à chacun des groupes dont ils sont membres.  Vous pouvez vérifier très facilement ce point en procédant de la manière suivante :  ■

Ouvrez une session avec un compte d’utilisateur du domaine. 

■

Ouvrez une invite de commandes et tapez la commande whoami /all. 

■

Analysez  les  informations  qui  vous  sont  retournées.  Vous  découvrirez,  votre  nom  d’ouverture  de  session,  vos  appartenances aux groupes, leurs SID respectifs ainsi que la liste de vos privilèges.  © ENI Editions - All rigths reserved

- 1-

Dans  la  mesure  où  la  fonction  première  du  groupe  consiste  à  regrouper  utilisateurs  et  groupes  imbriqués,  les  groupes de sécurité peuvent également être utilisés pour les applications comme liste de distribution. Cette fonction  des groupes est traitée ci­après. 

b. Les groupes de distribution  Les  applications  peuvent  nécessiter  l’usage  des  services  offerts  par  l’infrastructure  Active  Directory.  Par  exemple,  nous avons déjà étudié les mécanismes de localisation des services de l’annuaire Active Directory, disponibles pour  toute application. Les groupes de distribution peuvent eux aussi agir dans ce sens.  Le bon usage des groupes de distribution est directement lié aux exigences d’une application pouvant les utiliser à  des  fins  autres  que  la  gestion  de  la  sécurité  et  des  contrôles  d’accès  de  Windows.  Finalement,  comme  son  nom  l’indique, les groupes de distribution servent uniquement à rassembler les utilisateurs ou autres groupes, sans qu’il  soit jamais possible de les utiliser à des fins de contrôles d’accès.  Avantages des groupes de distribution ●

Ne disposant pas de SID, les groupes de distribution ne sont pas inclus dans le jeton d’accès de l’utilisateur  ayant  réussi  à  ouvrir  une  session.  Ce  point  peut  être  considéré  comme  un  avantage  en  permettant  de  minimiser la taille des jetons et ainsi, de minimiser certains flux réseau. 

●

D’autre  part,  la  sécurité  en  est  renforcée  puisque  aucun  SID  n’étant  émis  pour  le  groupe,  aucun  accès  contrôlé ne peut avoir lieu. 

Inconvénients des groupes de distribution ●

Comme les groupes de distribution n’ont pas de SID, ils ne peuvent donc pas être utilisés pour réaliser des  contrôles d’accès, si ce n’est de manière empirique, au sein d’une application n’utilisant pas les services de  sécurité Active Directory. 

Nous  verrons  plus  loin  que  le  type  de  groupe  peut  être  changé  de  sécurité  en  distribution  et  vice  versa  lorsque le domaine fonctionne dans le niveau fonctionnel Windows 2000 natif ou Windows Server 2003. 

2. Portée des groupes  Les  groupes  disponibles  dans  les  environnements  de  domaines  Windows  NT,  Windows  2000  Server  et  Windows  Server 2003 peuvent prendre différentes formes. Ces différents types de groupes vous permettront de contrôler la  portée des groupes et la nature de objets que vous pourrez y placer. 

a. Les groupes globaux  Par définition, les groupes globaux sont d’un usage global. Ce point signifie que les groupes globaux peuvent être  directement utilisés sur toute machine du domaine local mais aussi dans tout domaine de la forêt. Au sens large, les  groupes  globaux  sont  utilisables  dans  tous  les  domaines  approuvés,  qu’il  s’agisse  des  domaines  Active  Directory  d’une forêt donnée ou de domaines Windows NT externes ou de domaines Active Directory situés dans une autre  forêt.  Les groupes globaux ne peuvent contenir que des comptes du domaine local, qu’il s’agisse de comptes utilisateur  ou  de  comptes  d’ordinateur.  En  effet,  dans  la  mesure  où  les  groupes  globaux  sont  utilisables  dans  tous  les  domaines approuvés, s’il avait été possible de mettre dans des groupes globaux des comptes d’un autre domaine,  cela aurait introduit une transitivité induite non souhaitable.  Lorsque  le  domaine  Active  Directory  fonctionne  en  mode  Windows  2000  natif  ou  bien  dans  le  niveau  fonctionnel  Windows Server 2003, alors les groupes globaux peuvent aussi contenir des groupes globaux du domaine local. 

b. Les groupes locaux de domaine  Par définition, les groupes locaux ne sont utilisables que dans le domaine local où ils résident.  Lorsque  le  niveau  fonctionnel  du  domaine  est  Windows  2000  en  mode  natif,  Windows  Server  2003  ou  Windows 

- 2-

© ENI Editions - All rigths reserved

Server 2008, les membres des groupes de domaine local peuvent contenir des comptes et des groupes globaux de  n’importe quel domaine, des groupes universels de n’importe quel domaine ainsi que des groupes de domaine local  du même domaine.  Vous  avez  la  possibilité  d’ajouter  des  groupes  locaux  à  d’autres  groupes  locaux  et  de  leur  assigner  des  autorisations dans ce domaine uniquement.  À la différence des groupes locaux des domaines Windows NT, les groupes locaux de domaine Active Directory sont  utilisables  sur  toute  machine  membre  du  domaine.  Dans  l’environnement  Windows  NT,  les  groupes  locaux  créés  dans le domaine NT n’étaient utilisables que sur les contrôleurs de domaine Windows NT, limitant leur utilisation aux  seuls contrôleurs de domaine. 

c. Les groupes universels  Par  définition,  les  groupes  universels  peuvent  contenir  des  membres  de  n’importe  quel  domaine  de  la  forêt.  Ils  peuvent être utilisés, comme cela est le cas des groupes globaux, dans tout domaine de la forêt.  Les  groupes  universels  sont  physiquement  stockés  sur  les  contrôleurs  de  domaine  catalogue  globaux.  Par  conséquent,  une  telle  particularité  ne  peut  être  autorisée  que  lorsque  le  domaine  Active  Directory  fonctionne  en  mode  natif  Windows  2000  ou  dans  le  niveau  fonctionnel  Windows  Server  2003.  Notez  que  cette  remarque  ne  concerne  que  les  groupes  universels  de  sécurité  et  pas  les  groupes  universels  de  distribution.  En  effet,  seuls  les  groupes  de  sécurité  ont  une  “signification  NT”  et  pas  les  groupes  de  distribution.  Par  conséquent,  vous  avez  la  possibilité de créer des groupes universels de distribution dans un domaine Active Directory fonctionnant en mode  mixte  Windows  2000.  Ce  domaine  pourra  contenir  des  contrôleurs  Windows  Server  2008,  Windows  Server  2003,  des contrôleurs Windows 2000 Server et aussi des contrôleurs secondaires fonctionnant sous Windows NT.  Il est souvent écrit que les groupes universels ne sont disponibles qu’en mode natif. En fait, ce point est  vrai  lorsqu’il  s’agit  de  groupes  de  sécurité.  Comme  nous  l’avons  expliqué,  un  domaine  Active  Directory  opérant en mode mixte et contenant des contrôleurs Windows NT peut contenir des groupes universels de type  distribution ! 

3. Règles générales concernant les objets groupes  Comme pour tous les objets de l’annuaire Active Directory, de nombreuses opérations sont possibles. Les points qui  suivent précisent les opérations et recommandations d’usage destinées aux administrateurs Active Directory. 

a. Bon usage des comptes de groupes  Évitez  d’assigner  directement  à  des  comptes  d’utilisateurs  ou  d’ordinateurs  des  autorisations.  L’utilisation  des  groupes  de  sécurité  est  bien  plus  souple  et  simple  à  gérer.  Pour  atteindre  cet  objectif  de  simplification  et  de  rationalisation, vous aurez au préalable étudié le meilleur usage des groupes dans votre entreprise en fonction de  votre propre problématique d’administration et de délégation de l’administration.  Créez une convention de nommage de vos groupes de sécurité et de distribution de telle sorte que leur rôle et/ou  cadre d’utilisation soit facilement identifiable par les gestionnaires de comptes et de sécurité.  Notez que les groupes des environnements Active Directory peuvent contenir plus que de simples utilisateurs. En  effet,  ils  peuvent  contenir  des  comptes  de  type  utilisateur,  groupe,  contact,  inetOrgPerson  et  enfin  de  type  ordinateur.  Dans  les  réseaux  "anciens",  il  n’est  pas  habituel  de  créer  des  groupes  de  machines.  Les  systèmes  fonctionnant  sous Windows 2000, Windows XP Professionnel, Windows Vista et Windows Server 2008 dans un domaine Active  Directory  utilisent  le  protocole  Kerberos  et  des  mécanismes  de  délégation  puissants  ainsi  que  la  possibilité  d’autoriser  les  services  sur  la  base  des  SPN.  Par  conséquent,  vous  pourrez  peut­être  être  amené  à  créer  des  groupes contenant uniquement des comptes d’ordinateurs. Ces groupes pourront nécessiter leur propre convention  de nommage.  Vous pouvez créer des groupes locaux de domaine pour contrôler les accès des ressources ou opérations que vous  souhaitez contrôler.  Sur  les  serveurs  membres  et  autres  stations  du  réseau  membres  des  domaines  Active  Directory,  vous  avez  la  possibilité d’utiliser des groupes locaux de machine ou bien des groupes locaux de domaine. La règle voudrait que  sur  une  machine  locale  devant  contrôler  des  accès  sur  ses  propres  ressources  locales,  la  bonne  pratique  soit  d’utiliser un compte de groupe local, local à la machine. Cependant, cette méthode crée une dépendance des ACLs  par  rapport  au  système  d’exploitation  local.  Ce  point  signifie  que  la  consolidation  ultérieure  des  données  vers  un  autre serveur provoquera la perte de toutes les autorisations. De fait, lorsque plusieurs machines sont susceptibles  de contrôler les mêmes disques ou ressources, il est recommandé de ne surtout pas utiliser de groupes locaux de  machine. 

© ENI Editions - All rigths reserved

- 3-

Ce  cas  typique  peut  concerner  les  machines  fonctionnant  en  cluster  qui  peuvent  potentiellement  contrôler  les  disques ou ressources à tour de rôle.  La formule magique En résumé, depuis de nombreuses années, c’est­à­dire depuis Windows NT 3.1, nous connaissons la règle AGLP ­  Accounts/Global  groups/Local  groups/Permissions.  Cette  formule  a  été  adaptée  à  Active  Directory  sous  la  forme  AGUDLP, c’est­à­dire  Accounts/ Global groups/Universal groups/Domain Local groups/Permissions. Ainsi, il convient de  respecter la méthode suivante :  ●

Placez les comptes utilisateur dans des groupes globaux. 

●

Placez les groupes globaux dans des groupes universels. 

●

Placez les groupes universels dans des groupes locaux de domaine. 

●

Accordez les autorisations aux groupes locaux de domaine. 

b. Bon usage des groupes universels  Les  groupes  universels  ne  devraient  être  utilisés  que  pour  consolider  des  groupes  qui  s’étendent  sur  plusieurs  domaines.  La  méthode  classique  consiste  à  ajouter  les  comptes  à  des  groupes  globaux  puis  à  imbriquer  ces  groupes  globaux  au  sein  de  groupes  universels.  De  cette  manière,  une  modification  des  membres  d’un  groupe  global n’aura aucun effet sur les groupes universels les contenant.  L’appartenance  à  un  groupe  universel  doit  être  modifiée  avec  parcimonie.  En  effet,  toute  modification  apportée  à  un  groupe  universel  provoque  la  réplication  de  toute  l’appartenance  du  groupe  sur  chaque  catalogue  global  de  la  forêt.  Dans  la  mesure  où  un  groupe  universel  peut  contenir  un  nombre  important  de  membres,  une  seule  modification  peut  générer  une  réplication  bien  plus  conséquente.  Pour  cette  raison,  il  est  recommandé d’éviter de placer des comptes utilisateur dans un groupe universel mais plutôt des groupes de type  global. De cette manière, les flux de réplication vers et entre les catalogues globaux seront limités.  Lorsque la forêt Active Directory est opérationnelle dans le niveau fonctionnel Windows Server 2003, la réplication  LVR  (Listed  Value  Replication)  est  automatiquement  activée  et  permet  de  ne  plus  tenir  compte  des  remarques  ci­ dessous. En effet, la réplication des listes de valeurs permet de ne plus répliquer entièrement l’attribut avec toutes  ses valeurs, mais de répliquer indépendamment chaque valeur de l’attribut modifié. 

- 4-

© ENI Editions - All rigths reserved

Définition d’une structure d’unités d’organisation  1. Rôle des objets unités d’organisation  Une unité d’organisation est un objet de l’annuaire Active Directory. Cet objet, de type container (ou conteneur), est  un objet fondamental à tous les systèmes d’annuaires. De fait, il est très régulièrement utilisé en tant que conteneur  de la structure logique.  Vous pourrez y placer un nombre quasi illimité d’objets des classes utilisateurs, inetOrgPerson, groupes, ordinateurs  et aussi d’autres unités d’organisation.  Remarquez que les unités d’organisation ne peuvent, par définition, contenir que des objets de leur propre domaine  et en aucune manière, des objets provenant d’autres domaines Active Directory.  De plus, en tant que container privilégié, l’unité d’organisation pourra être facilement utilisée pour prendre en charge  les opérations listées ci­dessous :  ●

Les unités d’organisation permettent la mise en place d’un modèle organisé. 

●

Les unités d’organisation peuvent contenir des objets qui seront soumis à la politique de délégation appliquée  à  l’unité  d’organisation  mais  aussi  de  manière  spécifique  grâce  aux  différentes  autorisations  applicables  directement sur les objets. 

●

Les unités d’organisation permettent l’usage de la technologie IntelliMirror grâce à l’application des stratégies  de groupe. 

Dans  la  mesure  où  les  services  de  délégation  et  la  liaison  des  objets  stratégie  de  groupe  sont  utilisables  sur  une  étendue de type site puis domaine puis unités d’organisation, il apparaît que les unités d’organisation sont les “plus  petits containers” utilisables.  Les  conteneurs  Builtin,  Computers,  ForeignSecurityPrincipals,  LostAndFound,  NTDS  Quotas,  Program  Data,  Systems  et  Users  ne  sont  pas  des  conteneurs  de  type  unité  d’organisation  mais  des  objets  conteneur  appartenant à d’autres classes spécifiques. Par conséquent, il n’est pas possible de lier une stratégie de groupe sur  ces types d’objets. Comme nous l’avons déjà dit, les objets stratégie de groupe ne s’appliquent que sur les objets  ordinateur et utilisateur situés sur des sites, dans des domaines et dans des unités d’organisation.  Vous pouvez découvrir la nature de classes présentées plus haut en activant le mode Fonctionnalités avancées puis  en consultant l’onglet Objet de chacun de ces containers.  En résumé, vous devez considérer le rôle des unités d’organisation de la manière suivante :  ●

Les  OU  représentent  des  unités  d’administration  séparées  puisque  vous  pourrez  déléguer  les  autorisations  sur l’OU et les objets qu’elle contient. 

●

Les  OU  représentent  des  configurations  utilisateur  et  ordinateur  particulières  puisque  vous  pourrez  y  relier  des objets stratégie de groupe. 

●

En  plus  de  ces  deux  points  fondamentaux,  les  OU  sont  un  bon  moyen  pour  mettre  en  place  un  modèle  d’organisation puisque vous pourrez les utiliser dans l’élaboration de vos requêtes LDAP. 

2. Utilisation des unités d’organisation et relation avec l’organisation de l’entreprise  Le “positionnement” des technologies d’annuaire au sein des entreprises est un sujet sensible. En effet, le rôle central  de  ces  technologies  tend  à  compliquer  leur  “réelle”  implémentation  au  cœ ur  du  système  d’information.  Cependant,  petit à petit, la nécessité de mieux gérer et trouver l’information impose leur utilisation. De plus, certaines applications  et services d’entreprise, telles que la messagerie électronique ou les services de certificats nécessitent un annuaire tel  que l’Active Directory.  C’est ainsi que les services d’annuaire Active Directory et l’usage des unités d’organisation peuvent tenir une place au  sein des entreprises de deux grandes manières :  ●

Pour  commencer,  l’annuaire  peut  jouer  un  rôle  technique.  Cette  approche  signifie  que  les  ordinateurs,  serveurs,  utilisateurs  et  autres  applications  Windows  appartenant  à  l’infrastructure  Active  Directory  peuvent  © ENI Editions - All rigths reserved

- 1-

utiliser les services de celui­ci.  ●

Enfin,  l’annuaire  peut  jouer  un  rôle  plus  proche  de  l’organisation.  Une  telle  approche  tendra  à  le  rendre  totalement  dépendant  des  éventuelles  évolutions  de  la  structure  de  l’entreprise  au  risque  d’en  fragiliser  l’exploitation et d’en limiter son usage. 

Ainsi,  si  vous  essayez  de  mettre  en  place  une  structure  d’unités  d’organisation  qui  représente  la  structure  organisationnelle de l’entreprise, il est fort probable que ce modèle ne permettra pas d’utiliser au mieux la délégation  et le déploiement des stratégies de groupe.  Au  départ,  c’est­à­dire en 1998/1999, les recommandations issues du programme Beta de Windows 2000 tendaient  vers  le  respect  du  modèle  organisationnel.  Les  premières  grandes  études  réalisées  par  MCS  (Microsoft  Consulting  Services) ont commencé à faire apparaître que cette méthode avait pour principal inconvénient de ralentir le processus  de définition de l’organisation de l’annuaire et donc le déploiement de l’Active Directory.  En  effet,  un  modèle  basé  sur  l’organisation  de  l’entreprise  nécessite  de  nombreuses  réunions  et  d’interminables  discussions. De plus, l’organisation générale de l’entreprise ne fait pas forcément apparaître les disparités existantes  au niveau de celle­ci et, par conséquent, des zones d’ombre pourront subsister.  Depuis, l’approche de Microsoft a évolué et il n’est plus question de tenir compte du modèle de fonctionnement interne  de l’entreprise, si ce n’est pour déterminer le nombre de forêts et domaines au sein de chaque unité d’organisation.  Gardez  à  l’esprit que les unités d’organisation  de  l’Active Directory doivent simplifier les opérations réalisées par les  administrateurs  et  qu’elles  ne  devraient  pas  être  utilisées  pour  simplifier  l’accès  utilisateur  ou  “mieux”  organiser  l’entreprise.  Un  point  important  qui  corrobore  cette  approche  est  directement  visible  dans  l’interface  graphique  de  Windows  XP  Professionnel  et  Windows  Server  2003.  En  effet,  seul  Windows  2000  est  capable  de  parcourir  directement l’annuaire en passant par Explorateur Windows ­ Favoris réseau ­ Tout le réseau ­ Active Directory.  Les systèmes fonctionnant sous Windows XP Professionnel et Windows Server 2003 n’ont plus cette possibilité. Par  conséquent, il n’est plus possible sur ces systèmes de “voir” une quelconque unité d’organisation ! 

Pour  plus  d’informations  sur  la  délégation  de  l’administration,  consultez  Active  Directory  Planning  and  Deployment, sur le site Web de Microsoft (http://www.microsoft.com/). 

3. Délégation de l’autorité d’administration et usage des unités d’organisation  La  délégation  de  l’administration  vous  permettra  d’attribuer  un  certain  nombre  de  tâches  administratives  à  des  utilisateurs  et  groupes  sélectionnés  de  manière  appropriée.  De  cette  manière,  certaines  opérations  basiques  ou  simples pourront être réalisées par des utilisateurs ou groupes ne disposant évidemment pas de privilèges de type  administrateur.  En  procédant  de  la  sorte,  les  véritables  administrateurs  peuvent  réellement  se  consacrer  à  l’administration  des  services d’entreprise inclus dans l’Active Directory ou dans la périphérie de l’infrastructure.  Un autre aspect important concerne la “bonne gestion” des ressources. En effet, qui connaît le mieux les autorisations  à accorder sur les ressources que celui qui les a directement créées ? L’utilisateur lui­même, bien entendu !  Les  services  de  délégation  permettent  donc  au  final  de  libérer  les  administrateurs  de  certaines  tâches  et  aux  personnes directement responsables de certaines ressources d’en mieux gérer les accès. Finalement, la délégation de  l’administration  peut  être  vue  comme  une  sorte  de  “décentralisation”  du  pouvoir  et  peut  donc  profiter  à  tout  le  monde !  Parmi les grandes opérations qui concernent la délégation de l’autorité d’administration sur des objets de l’annuaire  Active Directory, vous devrez : 

- 2-

●

Déléguer  le  contrôle  administratif  à  l’intérieur  d’un  domaine  de  votre  forêt  en  créant  une  hiérarchie  d’unités  d’organisation  à  l’intérieur  dudit  domaine  et  en  déléguant  le  contrôle  administratif  sur  certaines  unités  d’organisation à des utilisateurs ou groupes d’utilisateurs aptes à réaliser les dites tâches. 

●

Tenir compte de la structure de votre organisation pour bien décider quelles unités d’organisation doivent être  ou bien peuvent être mises en délégation. 

●

Personnaliser des consoles de gestion MMC pour créer une version personnalisée et limitée d’un composant  logiciel  enfichable  tel  que  Utilisateurs  et  ordinateurs  Active  Directory  ou  Gestion  de  l’ordinateur.  La  personnalisation des consoles MMC passe par l’assistant Nouvelle vue de la liste des tâches... lequel permet  de  contrôler  les  options  proposées  aux  personnes  pour  lesquelles  une  délégation  de  l’administration  a  été  réalisée.  © ENI Editions - All rigths reserved

Documenter les délégations réalisées et vous assurer que les utilisateurs auxquels va être attribué le contrôle  sur des objets disposent du minimum de connaissances pour réaliser les dites opérations. 

●

a. Structure basée sur la nature des objets gérés  Une structure basée sur les différentes natures des objets est particulièrement bien adaptée lorsqu’il est nécessaire  de  déléguer  des  tâches  administratives  en  fonction  des  types  d’objets.  Par  exemple,  vous  pourrez  procéder  de  la  manière suivante :  ●

Créez un ou plusieurs groupes de sécurité pour accueillir les utilisateurs ou les groupes qui feront l’objet de  la délégation. 

●

Créez une hiérarchie d’unités d’organisation adaptée à votre hiérarchie d’administration. 

●

Dans chaque unité d’organisation, insérez les différents types d’objets à mettre en délégation. 

●

Déléguez les différentes tâches d’administration sur les différentes unités d’organisation aux groupes devant  disposer des ces autorisations. 

b. Structure basée sur les tâches d’administration  Une  structure  basée  sur  les  tâches  déléguées  à  accomplir  est  définie  en  fonction  des  différentes  tâches  d’administration. Dans un tel modèle, vous pourrez procéder de la manière suivante :  ●

Créez un ou plusieurs groupes de sécurité pour accueillir les utilisateurs ou les groupes qui feront l’objet de  la délégation. 

●

Créez une hiérarchie d’unités d’organisation adaptée à votre hiérarchie d’administration. Dans ce modèle, la  hiérarchie  d’unités  d’organisation  ne  serait  influencée  que  par  les  tâches  d’administration.  Cependant,  ce  point  n’est  pas  obligatoire  et  la  structure  peut  considérer  d’autres  critères  (organisation  des  objets,  emplacements  géographiques,  organisation  de  l’entreprise,  types  d’objets,  types  de  tâches  d’administration). 

●

Dans chaque unité d’organisation, insérez les différents types d’objets à mettre en délégation. 

●

Déléguez les tâches d’administration sur les différentes unités d’organisation aux groupes devant disposer  de  délégations  en  fonction  de  la  nature  des  objets  et  des  tâches  associées  à  ces  types  d’objets.  Pour  réaliser une délégation de ce type, vous pourrez procéder de la manière suivante : 

■

Dans  l’Assistant  Délégation  de  contrôle,  à  l’étape  Tâches  à  déléguer,  sélectionnez  le  choix  Créer  une  tâche  personnalisée à déléguer. 

■

Sur l’écran Type d’objet Active Directory, sélectionnez le choix Seulement des objets suivants dans le dossier,  puis sélectionnez le ou les classes souhaitées. 

■

Finalement, sur l’écran Autorisations, sélectionnez les autorisations souhaitées. 

c. Facteurs à intégrer dans la définition d’une hiérarchie d’unités d’organisation  Avant de définir précisément la structure d’une hiérarchie d’unités d’organisation, il est intéressant de faire le point  sur  les  conteneurs  par  défaut.  Ensuite,  nous  identifierons  les  facteurs  de  structure  les  plus  judicieux  qui  nous  permettrons d’étudier une structure d’unités d’organisation basée sur différents modèles.  À propos des conteneurs par défaut Tout domaine Active Directory contient un ensemble générique d’objets unités d’organisation et d’autres conteneurs.  Ainsi, dans chaque domaine Active Directory, vous trouverez les éléments suivants :  Builtin : ce conteneur contient les objets qui définissent les groupes d’administration prédéfinis par défaut. Vous y  retrouverez,  par  exemple,  les  groupes  Administrateurs,  Opérateurs  de  compte,  Opérateurs  d’impressions  ou 

© ENI Editions - All rigths reserved

- 3-

encore le groupe Accès compatible pré­Windows 2000.  Computers : ce conteneur contient les objets ordinateurs Windows NT, Windows 2000, Windows XP, Windows Vista,  Windows  Server  2003  et  2008,  y  compris  des  comptes  d’ordinateurs créés à l’origine  par  les  anciennes  API  NT  ne  connaissant pas Active Directory. Ce conteneur est aussi utilisé lorsque les domaines Windows NT sont mis à niveau  vers Windows 2000, Windows Server 2003 ou Windows Server 2008. À l’issue de la migration d’un domaine NT vers  Active Directory, tous les ordinateurs membres du domaine sont rangés dans ce conteneur. Ce conteneur ne peut  pas être renommé.  Domain  Controllers  :  cette  unité  d’organisation  contient  des  objets  ordinateur  destinés  à  des  contrôleurs  de  domaine  fonctionnant  sous  Windows  2000  Server,  Windows  Server  2003  ou  Windows  Server  2008.  Les  comptes  d’ordinateurs des anciens contrôleurs de domaine secondaires NT apparaîtront aussi à cet emplacement.  Users : ce conteneur contient des comptes d’utilisateurs et des groupes créés à l’origine par des anciennes API NT  ne  connaissant  pas  Active  Directory.  Ce  conteneur  est  aussi  utilisé  lorsque  les  domaines  Windows  NT  sont  mis  à  niveau  vers  Windows  2000  Server,  Windows  Server  2003  ou  Windows  Server  2008.  À  l’issue  de  la  migration  d’un  domaine  NT  vers  Active  Directory,  tous  les  utilisateurs  membres  du  domaine  sont  rangés  dans  ce  conteneur.  Ce  conteneur ne peut pas être renommé.  LostAndFound  :  cet  objet  conteneur  de  la  classe  LostAndFound  contient  des  objets  dont  les  conteneurs  ont  été  supprimés  au  moment  où  l’objet a été créé. Lorsqu’un  objet  a  été  créé  à  un  emplacement  donné  ou  déplacé  vers  celui­ci  et  qu’il  vient  à  manquer  après  la  réplication,  cet  objet  perdu  est  ajouté  au  conteneur  LostAndFound.  Le  conteneur LostAndFound­  Config situé dans la partition d’annuaire  de  configuration  remplit  le  même  rôle  pour  les  objets de la forêt.  System : le dossier System est un conteneur qui contient des informations critiques pour le domaine Active Directory  tout  entier.  Par  exemple,  ce  conteneur  contient  les  informations  qui  concernent  la  stratégie  locale  de  sécurité,  les  paramètres de  File Link Tracking, les objets TDO représentant les approbations inter­domaines ainsi que les points  de  connexions  TCP  et  Windows  Sockets.  Vous  y  trouverez  les  sous­conteneurs  suivants  :  AdminSDHolder,  Default  Domain  Policy,  Dfs  Configuration,  File  Replication  Service,  FileLinks,  IP  Security,  Meetings,  MicrosoftDNS,  Policies,  RpcServices, WinsockServices.  La  suite  de  ce  chapitre  va  nous  permettre  de  construire  notre  réflexion  pour  définir  une  structure  d’unités  d’organisation adaptée.  Critères d’emplacements, d’opérations et de types d’objets Nous  avons  vu  plus  haut  que  la  bonne  approche  concernant  la  définition  d’une  bonne  hiérarchie  d’unités  d’organisation  dépendait  fortement  de  la  relation  qui  devait  exister  entre  le  modèle  à  définir  et  l’organisation  de  l’entreprise,  étant  précisé  que,  justement,  il  était  fortement  recommandé  de  se  dégager  de  ce  type  de  contrainte  pour pouvoir profiter pleinement des services de sécurité, de délégation et de gestion IntelliMirror.  Une  hiérarchie  d’unités d’organisation  bien  construite  doit  donc  permettre  aux  administrateurs  de  bâtir  un  plan  de  mise en délégation de l’autorité le plus simplement possible. Pour y parvenir, vous devez, au départ, avoir déjà une  bonne  perception  des  opérations  que  vous  souhaitez  déléguer  et,  aussi,  à  qui  et  sur  quels  objets  et/ou  types  d’objets.  En règle générale, vous devez garantir un bon niveau de stabilité des premiers niveaux de votre hiérarchie d’unités  d’organisation.  Pour  y  parvenir,  définissez  ces  niveaux  sur  la  base  de  critères  fiables,  statiques  et  si  possible  indépendants  des  paramètres  de  l’entreprise.  En  respectant  au  mieux  ces  quelques  contraintes,  vous  vous  protégerez des effets négatifs engendrés par une réorganisation interne de l’entreprise.  Vous  pouvez  considérer  les  critères  ci­dessous  comme  des  critères  stables  utilisables  pour  construire  les  premiers  niveaux de votre hiérarchie d’unités d’organisation :  ●

Considérez les sites géographiques, bâtiments, étages ou zones particulières de votre réseau en respectant  les plans de nommage déjà définis et donc bien connus de tous. Le fait de construire la hiérarchie d’unités  d’organisation  en  fonction  des  différents  emplacements  revient  à  utiliser  un  modèle  basé  sur  les  tâches  d’administration en fonction des emplacements. 

●

Considérez  la  nature  des  opérations  à  déléguer,  telles  que,  par  exemple,  la  création,  suppression  ou  la  modification des comptes utilisateur, le contrôle des membres des groupes, ou les comptes d’ordinateurs. Il  pourra  s’agir  aussi  de  tâches  telles  que  la  création  d’objets  stratégie  de  groupe,  des  filtres  WMI,  ou  uniquement des liens de stratégies de groupe. Ce type de modèle est très séduisant dans la mesure où il  est indépendant de l’organisation de l’entreprise où les tâches génériques seront toujours les mêmes. 

●

Considérez la nature des objets. Ce type d’approche est semblable au modèle précédent basé sur les types  d’opérations mises en délégation. 

Ces  trois  grandes  familles  de  critères  vous  permettront  de  définir  les  premiers  niveaux  d’une  hiérarchie  d’unités  d’organisation. En plus de ces critères de structure, vous pourrez respecter les conseils ci­dessous :  ●

- 4-

Si  votre  entreprise  est  composée  de  plusieurs  domaines  Active  Directory,  faites  en  sorte  que  les  premiers  niveaux définis soient le plus possible réutilisables. De cette manière, vous garantissez une bonne cohérence  © ENI Editions - All rigths reserved

administrative des objets.  ●

En dessous des premiers niveaux qui doivent être le plus génériques possible, les unités d’organisation des  niveaux  inférieurs  doivent  représenter  des  niveaux  précis  en  rapport  avec  les  opérations  déléguées.  Ces  unités  d’organisation  pourront  aussi  être  utilisées  pour  masquer  des  objets  ou  pour  y  appliquer  des  stratégies de groupe. 

●

Pour profiter efficacement des services de délégation, ne compliquez pas outre mesure votre structure. Vous  pourrez mieux profiter et contrôler les mécanismes d’héritage dans une hiérarchie simple et ne comportant  pas plus d’une dizaine de niveaux. 

Pour  mettre  en  pratique  ces  principes,  nous  pouvons  imaginer  la  structure  d’unités  d’organisation  de  la  société  corporate.net, tel que spécifié ci­dessous :  @Corporate : cette unité d’organisation contient une hiérarchie adaptée aux besoins de la maison mère.  @Extranet  Network  :  cette  unité  d’organisation  contient  une  hiérarchie  adaptée  aux  besoins  du  réseau  Extranet.  Dans le cas d’une externalisation de ces services, la gestion de l’Extranet  de  l’entreprise peut être déléguée à un  fournisseur de service “approuvé” et bénéficiant d’une délégation de l’administration.  @Groups : cette unité d’organisation contient tous les groupes classiques. Le fait de ranger tous les groupes dans  ce  conteneur  permet  de  les  localiser  très  facilement  et  ainsi  d’avoir  une  visibilité  totale  sur  ces  objets  sensibles  puisque utilisés dans l’affectation des autorisations. De plus, comme il n’est pas possible d’appliquer des stratégies  de groupe sur des groupes, cette méthode n’a aucun effet négatif.  Managers & External Services : cette unité d’organisation contient uniquement les comptes de services utilisés par  les applications ainsi que les comptes temporaires disposant de délégations. Cette approche permet de localiser très  facilement  les  comptes  utilisés  par  les  applications  ainsi  que  les  comptes  externes  disposant  temporairement  d’autorisations obtenues au travers d’une délégation de l’administration.  Subsidiary  :  cette  unité  d’organisation  contient  les  points  de  départ  des  hiérarchies  qui  seront  dédiées  aux  différentes filiales de l’entreprise. Cette approche est expliquée plus loin.  A propos de “The Boston Company” : cette unité d’organisation contient une hiérarchie adaptée aux besoins de la  filiale  de  Boston.  Cette  partie  du  domaine  Active  Directory  utilise  un  modèle  basé  sur  la  nature  des  tâches  d’administration déléguées. De fait, un modèle qui regroupe les objets par nature est particulièrement bien adapté.  A propos de “The London Company” : cette unité d’organisation contient une hiérarchie adaptée aux besoins de la  filiale de Londres. Cette partie du domaine Active Directory utilise un modèle basé sur l’organisation de l’entreprise  puis  sur  les  types  d’objets.  Un  modèle  de  ce  type  permet  de  faire  référence  aux  différents  départements  de  l’entreprise tout en utilisant les services de délégation en fonction des différents types d’objets.  A propos de “The Monaco Company” : cette unité d’organisation contient une hiérarchie adaptée aux besoins de la  filiale de Monaco. Cette partie du domaine Active Directory utilise un modèle basé sur les emplacements puis sur les  types d’objets. Un modèle de ce type permet de faire clairement apparaître les différents sites géographiques ainsi  que les catégories d’objets sur lesquels vous utilisez la délégation et peut­être aussi les stratégies de groupe.  L’écran suivant montre une structure d’unités d’organisation respectant ces différents principes fondamentaux. 

© ENI Editions - All rigths reserved

- 5-

Hiérarchie d’unités d’organisation basée sur différents critères et modèles  A propos de “Dispatch In Progress” : cette unité d’organisation joue le rôle de zone temporaire lorsque les objets  doivent  être  urgemment  créés  mais  que  leur  unité  d’organisation  d’accueil  n’est  pas  encore  définie.  Vous  pourrez  dans  un  deuxième  temps  déplacer  l’ordinateur,  l’utilisateur  ou  le  groupe  souhaité  dans  l’unité  d’organisation  appropriée. 

4. Usage des unités d’organisation pour les stratégies de groupe  Nous  étudierons  plus  loin  en  détail  le  fonctionnement  des  stratégies  de  groupe.  Cependant,  la  relation  qui  existe  entre les containers de type unité d’organisation et les objets stratégie de groupe est telle qu’il n’est pas possible de  ne pas évoquer les bonnes pratiques à respecter concernant la définition d’une hiérarchie d’unités d’organisation et le  bon usage des stratégies de groupe au sein de cette hiérarchie.  Les  objets  stratégie  de  groupe  sont  les  objets  de  l’annuaire  Active  Directory  qui  permettent  la  mise  en  œ uvre  et  l’utilisation de la technologie IntelliMirror. Grâce à ces objets, vous pourrez prendre en charge via Active Directory les  services suivants : tous les paramètres de registre, les paramètres de sécurité, les scripts d’ouverture et de fermeture  de session, l’installation et la gestion des applications, la redirection des dossiers, la gestion des quotas de disques, la  gestion  des  paramètres  sans  fils,  les  stratégies  de  restriction  logicielle,  les  paramètres  de  clés  publiques,  les  paramètres  de  stratégies  IPSec,  les  paramètres  d’Internet  Explorer,  les  paramètres  des  services  RIS  (Remote  Installation Services) et, pour finir, les paramètres de QoS (Quality of Services).  Nous savons que, par concept, les stratégies de groupe s’appliquent selon le schéma L,S,D,OUs. Ce schéma signifie  que dans un premier temps les paramètres locaux à l’ordinateur sont appliqués, suivis des paramètres des stratégies  de groupe du site, suivis des paramètres des stratégies de groupe du domaine, suivis finalement des paramètres des  stratégies de groupe de la hiérarchie d’unités d’organisation.  Ce principe de fonctionnement surpuissant montre à quel point la structure d’unités d’organisation est importante. Les  stratégies  de  groupe  s’appliquent  de  haut  en  bas  et  descendent  la  hiérarchie  grâce  aux  possibilités  d’héritage  des  services d’annuaires Active Directory.  Pour  plus  de  détails  sur  le  fonctionnement  et  la  délégation  des  stratégies  de  groupe  ou  opérations  les  concernant,  reportez­vous au chapitre 7 traitant des stratégies de groupe. 

5. Règles générales et bonnes pratiques  Faites en sorte de profiter des fonctionnalités d’héritage de l’annuaire Active Directory et bloquez l’héritage au niveau  d’un container seulement lorsque cela s’avère nécessaire. 

- 6-

© ENI Editions - All rigths reserved

Utilisez  un  modèle  basé  sur  l’organisation  lorsque  vous  souhaitez  que  les  premiers  niveaux  représentent  les  différentes entités, directions ou centres de profits de l’entreprise. Lorsque l’entreprise est très structurée, ce modèle  permet de bâtir très simplement un plan de délégation de l’administration qui reflétera très précisément l’organisation  de l’entreprise. Cependant, ce modèle peut présenter l’inconvénient suivant :  ●

Cette technique est dépendante de l’organisation et sera bouleversée lorsque l’entreprise sera soumise à une  réorganisation interne. 

●

A contrario, le fait que cette structure soit déjà connue, puisque basée sur l’organisation de l’entreprise, elle  sera généralement approuvée par tous. Ce point peut être considéré comme un avantage certain. 

Utilisez un modèle basé sur les différentes activités de l’entreprise lorsqu’une activité se suffit à elle­même et possède  donc  une  grande  autonomie.  Si  l’entreprise  semble  être  composée  de  plusieurs  entités  très  autonomes,  voire  indépendantes, un modèle de ce type sera généralement résistant aux réorganisations.  Faites  en  sorte  que  les  premiers  niveaux  de  structure  de  la  hiérarchie  ne  soient  pas  soumis  à  des  changements  fréquents.  L’idée  serait  que  dans  une  forêt  composée  de  plusieurs  domaines,  les  deux  ou  trois  premiers  niveaux  respectent les mêmes règles de structure, quels que soient les domaines.  Utilisez les objets unités d’organisation avec parcimonie ! Il est judicieux de créer une unité d’organisation lorsque l’un  des trois cas ci­dessous se présente :  ●

Il est nécessaire de mettre en place une délégation de l’autorité d’administration. 

●

Vous souhaitez masquer la visibilité de certains objets. 

●

Vous souhaitez maîtriser l’application des stratégies de groupe à l’aide de la formule L,S,D,OUs. 

Pour plus d’informations sur la délégation de l’administration, faites référence au document Active Directory  Planning  and  Deployment,  disponible  en  téléchargement  sur  le  site  Web  de  Microsoft  (http://www.microsoft.com/). 

© ENI Editions - All rigths reserved

- 7-

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 Quels sont les deux grands types de groupes disponibles dans un domaine Active Directory ?  2 Quelles sont les étendues possibles lorsque vous créez un groupe dans un domaine Active Directory ?  3 Quel outil Windows utilisez­vous pour gérer les groupes sur une machine locale membre d’un domaine ?  4 Quels sont les deux types de noms que vous pouvez créer et qu’un utilisateur peut utiliser pour ouvrir une  session dans un réseau Active Directory ?  5 Quelle commande Active Directory vous permet de créer un objet de type groupe dans une unité d’organisation  donnée ?  6 Quel est le nombre maximum de membres d’un groupe ?  7 Que peut contenir un groupe local en mode natif Windows 2000, Windows Server 2003 ou Windows Server  2008 ?  8 Est­il possible de créer des groupes universels de sécurité en mode Windows 2000 mixte ou Windows Server  2003 version préliminaire ?  9 Est­il possible de créer des groupes universels en mode Windows 2000 mixte ?  10 Est­il possible de changer l’étendue d’un groupe global en groupe local ?  11 Dans quels cas les unités d’organisations (OU) sont­elles utilisées ?  12 De quelle manière est­il possible de déléguer tout ou partie du contrôle d’administration à un groupe  d’utilisateurs sur une unité d’organisation spécifique ?  13 Quels types de modèles d’unités d’organisation pouvez­vous concevoir pour bâtir un modèle organisé adapté à  la gestion des stratégies de groupe et aussi à la gestion de la délégation des tâches administratives ?  14 Est­il judicieux d’intégrer l’organisation de l’entreprise dans le modèle d’unités d’organisation défini dans le  cadre de la politique de délégation et d’usage des stratégies de groupe ?  15 Quelle est l’une des fonctionnalités qui intéressera particulièrement les administrateurs dans la mise en place  d’une hiérarchie d’OUs ?  16 Quelle nouvelle fonctionnalité intéressante apportées par Windows Server 2008 permet aux administrateurs de  protéger les objets des services de domaine Active Directory des suppressions accidentelles ?  17 Comment installez­vous les différents outils d’administration associés aux rôles et services de Windows Server  2008 et/ou Windows Server 2003 sur un serveur fonctionnant sous Windows Server 2008 ?  18 Comment installez­vous les différents outils d’administration associés aux rôles et services de Windows Server  2008 et/ou Windows Server 2003 sur un poste d’administration fonctionnant sous Windows Vista ? 

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 /18  Pour ce chapitre, votre score minimum doit être de 14 sur 18. 

3. Réponses  1 Quels sont les deux grands types de groupes disponibles dans un domaine Active Directory ?  Les  groupes  de  sécurité  et  les  groupes  de  distribution.  Notez  que  les  environnements  disposant  d’Exchange  Server  2003 peuvent utiliser un type de groupe supplémentaire appelé Groupe de distribution fondé sur une requête. Ce type  de groupe n’est pas présent dans les environnements Active Directory fonctionnant sous Windows 2000 Server. Pour  utiliser  ce  type  de  groupes  fondés  sur  des  requêtes,  l’organisation  Exchange  doit  fonctionner  en  mode  natif  et  être  composée  de  serveurs  Exchange  Server  SP3  ou  supérieur,  de  serveurs  Exchange  Server  2003  ou  même  Exchange  Server 2007. Le domaine Active Directory doit fonctionner au minimum dans le niveau fonctionnel Windows 2000 natif, 

© ENI Editions - All rigths reserved

- 1-

mais les catalogues globaux doivent utiliser au minimum Windows Server 2003.  2 Quelles sont les étendues possibles lorsque vous créez un groupe dans un domaine Active Directory ?  Il existe trois étendues : Locale de domaine, globale et universelle.  3 Quel outil Windows utilisez­vous pour gérer les groupes sur une machine locale membre d’un domaine ?  La console de gestion MMC Gestion de l’ordinateur.  4 Quels sont les deux types de noms que vous pouvez créer et qu’un utilisateur peut utiliser pour ouvrir une  session dans un réseau Active Directory ?  Le nom principal de l’utilisateur et le nom d’ouverture de session.  5 Quelle commande Active Directory vous permet de créer un objet de type groupe dans une unité d’organisation  donnée ?  La  commande  dsadd  group  suivie  du  DN  de  l’objet  à  créer.  Tous  les  paramètres  de  cette  commande  peuvent  être  affichés à l’aide de la commande dsadd group /?.  6 Quel est le nombre maximum de membres d’un groupe ?  5000 au maximum. En général, il est dit que le nombre maximum d’éléments contenus dans un groupe des services  d’annuaire Active Directory est de 5000 membres. Cependant, il convient de préciser que cette limitation concerne les  domaines  Windows  2000.  Ce  point  s’explique  par  le  fait  que  les  contrôleurs  de  domaine  Windows  2000  Server  ne  peuvent  pas  prendre  en  charge  plus  de  5000  changements  en  une  seule  transaction.  Les  contrôleurs  de  domaine  fonctionnant sous Windows Server 2003 supportent, via la réplication LVR ­ Listed Value Replication, la modification de  chaque valeur d’attribut sur des objets utilisant des attributs multi valeurs, tels que les groupes. Notez aussi que la  réplication  LVR  nécessite  que  le  domaine  soit  opérationnel  dans  les  niveaux  fonctionnels  Windows  Server  2003,  Windows Server 2003 version préliminaire ou, bien sûr, Windows Server 2008.  7 Que peut contenir un groupe local en mode natif Windows 2000, Windows Server 2003 ou Windows Server  2008 ?  Des  utilisateurs  du  même  domaine  et  des  groupes  globaux  de  tout  domaine  de  la  forêt,  des  groupes  universel  de  la  forêt,  des  groupes  locaux  de  domaine  du  même  domaine  ainsi  que  des  groupes  globaux  de  domaines  externes  approuvés.  8 Est­il possible de créer des groupes universels de sécurité en mode Windows 2000 mixte ou Windows Server  2003 version préliminaire ?  Non.  9 Est­il possible de créer des groupes universels en mode Windows 2000 mixte?  Oui, s’il s’agit de groupes de distribution. Tant que le domaine n’est pas rehaussé dans le niveau fonctionnel Windows  2000 natif ou supérieur, alors il n’est pas possible de créer des groupes de sécurité universels.  10 Est­il possible de changer l’étendue d’un groupe global en groupe local ?  Oui, à condition de changer au préalable son étendue de globale à universelle.  11 Dans quels cas les unités d’organisations (OU) sont­elles utilisées ?  Elles permettent la mise en place d’un modèle organisé pour contenir des objets qui seront soumis à une politique de  délégation.  Les  unités  d’organisation  permettent  aussi  l’usage  de  la  technologie  IntelliMirror  grâce  à  l’application  des  stratégies de groupe.  12 De quelle manière est­il possible de déléguer tout ou partie du contrôle d’administration à un groupe  d’utilisateurs sur une unité d’organisation spécifique ?  Dans la console de gestion MMC Utilisateurs et ordinateurs Active Directory, positionnez­vous sur l’unité d’organisation  et ouvrez le menu Délégation de contrôle.  13 Quels types de modèles d’unités d’organisation pouvez­vous concevoir pour bâtir un modèle organisé adapté à  la gestion des stratégies de groupe et aussi à la gestion de la délégation des tâches administratives ?  Structure basée sur la nature des objets, structure basée sur la nature des tâches à réaliser, structure basée sur les  emplacements géographiques.  14 Est­il judicieux d’intégrer l’organisation de l’entreprise dans le modèle d’unités d’organisation défini dans le  cadre de la politique de délégation et d’usage des stratégies de groupe ?  Non,  car  pour  garantir  un  bon  niveau  de  stabilité  des  premiers  niveaux  d’OUs  il  est  préférable  d’utiliser  des  critères  fiables, statiques et si possible indépendants des paramètres de l’entreprise.  15 Quelle est l’une des fonctionnalités qui intéressera particulièrement les administrateurs dans la mise en place  d’une hiérarchie d’OUs ?  Les  fonctionnalités  d’héritage.  En  effet,  elles  sont  disponibles  pour  la  délégation  de  l’administration  mais  aussi  pour  l’application des stratégies de groupe.  16 Quelle nouvelle fonctionnalité intéressante apportées par Windows Server 2008 permet aux administrateurs de  protéger les objets des services de domaine Active Directory des suppressions accidentelles ?  Les  nouveaux  outils  d’administration  Active  Directory,  tels  que  le  composant  logiciel  enfichable  Utilisateurs  et  ordinateurs Active Directory, ou encore Sites et services Active Directory permettent d’activer l’option Protéger l’objet  des suppressions accidentelles. Vous accédez à cette nouvelle option à partir de l’onglet Objet.  - 2-

© ENI Editions - All rigths reserved

17 Comment installez­vous les différents outils d’administration associés aux rôles et services de Windows Server  2008 et/ou Windows Server 2003 sur un serveur fonctionnant sous Windows Server 2008 ?  Les nouveaux outils d’administration de Windows Server 2008 respectent les interfaces d’administration déjà utilisées  avec Windows Server 2003 et Windows 2000 Server (utilisation des RPC, de l’interface WMI et de l’interface NetBIOS).  Les nouveaux outils sont de nouveaux composants enfichables nécessitant la console de gestion Microsoft MMC 3.0,  déjà  disponible  avec  Windows  Server  2003  R2.  Pour  rappel,  Windows  Server  2003  dispose  de  la  MMC  version  2.0.  L’installation de la console de gestion MMC 3.0 ­ disponible en téléchargement depuis le site de Microsoft ­ nécessite le  SP1 de Windows Server 2003. Enfin, la console de gestion MMC 3.0 est incluse dans Windows Vista et Windows Server  2008. L’installation des différents outils d’administration de Windows Server 2008 est réalisée à l’aide du Gestionnaire  de serveurs/Assistant Ajout de fonctionnalités/Outils d’administration de serveur distant.  18 Comment installez­vous les différents outils d’administration associés aux rôles et services de Windows Server  2008 et/ou Windows Server 2003 sur un poste d’administration fonctionnant sous Windows Vista ?  L’installation des différents outils d’administration de Windows Server 2008 sur un poste Windows Vista nécessite au  préalable  d’installer  le  SP1  de  Windows  Vista.Une  fois  le  SP1  installé,  vous  pourrez  installer  RSAT  ­  Remote  Server  Administratrion  Tools ­  lequel  est  disponible  en  téléchargement  à  partir  du  site  de  Microsoft.  Une  fois  RSAT  installé,  vous devrez sélectionner les outils d’administration souhaités à l’aide du Panneau de configuration/Programmes/Activer  ou  désactiver  des  fonctionnalités  Windows.  L’option  Remote  Server  Administration  Tools  peut  alors  être  sélectionnée. 

© ENI Editions - All rigths reserved

- 3-

Introduction  La  structure  physique  des  services  d’annuaire  Active  Directory  dépend  d’un  ensemble  de  composants  qui  vous  permettront d’optimiser deux grands types de trafic réseau. D’une part, les trafics liés à la réplication des différentes  partitions  de  l’annuaire  et  d’autre  part,  les  trafics  inhérents  aux  phases  d’authentification  des  ordinateurs  et  des  utilisateurs membres des services de domaine Active Directory.  Comme vous pouvez le constater, l’infrastructure de sites joue un rôle important puisqu’elle est au centre des services  d’infrastructure  qui  caractérisent  les  services  d’annuaires  modernes.  Pour  rappel,  nous  avons  vu  au  chapitre  qui  présente les fondements des services d’annuaire Active Directory à quel point les services Active Directory forment le  cœ ur des infrastructures de systèmes distribués de Microsoft.  Ce  chapitre  met  l’accent  sur  l’infrastructure  de  sites  en  particulier  et  son  rôle  important,  mais  n’oubliez  pas  que  la  structure de sites Active Directory n’est qu’un élément parmi tant d’autres stockée dans la partition de configuration de  l’annuaire.  Dans  l’idée,  une  fois  l’architecture  logique  terminée  sur  le  base  des  forêts,  des  domaines  et  aussi  des  unités  d’organisation, il est probable qu’il sera nécessaire de définir puis d’implémenter une architecture de sites. La topologie  de  sites  retenue  devra  permettre  de  maximiser  la  disponibilité  de  l’annuaire  et  de  ses  services  pour  l’ensemble  des  clients du réseau tout en minimisant les coûts issus de la réplication et du support de l’infrastructure technique Active  Directory.  À propos de la planification de l’infrastructure de sites Active Directory La  conception  d’une  infrastructure  Active  Directory  nécessite  l’implication  de  nombreuses  technologies  et  donc  des  grands  principes  qui  leur  sont  associés.  Par  le  passé,  les  systèmes  d’exploitation  ne  considéraient  en  aucune  façon  l’incidence de la topologie du réseau sur le fonctionnement d’un service ou d’une application. Cette lacune est la cause  de tous les maux et de l’apparition de solutions techniques de type "usine à gaz" pour pallier ces faiblesses. Seul IBM  et ses grands systèmes, avec l’architecture SNA, SAA, APPC et APPN considérait des éléments d’architecture en relation  avec le physique, donc la topologie du réseau.  Avec l’Active Directory, Microsoft offre aux entreprises la possibilité de "dessiner" le réseau physique et d’y intégrer des  services  globaux  que  toutes  les  applications  pourront  utiliser,  lorsque  nécessaire.  De  fait,  l’infrastructure  du  réseau  physique n’est plus un problème majeur et passe en second plan. D’un mot, l’approche à utiliser pour mettre en œ uvre  une infrastructure Active Directory peut respecter la planification ci­dessous :  ●

Définition de la structure de forêt(s) ; 

●

Définition de la structure de domaine(s) ; 

●

Définition de la structure du système de résolution DNS ; 

●

Définition de la structure de sites en fonction des contraintes physiques, si nécessaire ; 

●

Définition de la structure des unités d’organisation. 

Une  fois  cette  phase  de  construction  planifiée  et  réalisée,  les  services  additionnels  tels  que  la  technologie  Microsoft  IntelliMirror  et  les  stratégies  de  groupe,  les  services  de  messagerie  Microsoft  Exchange,  les  services  de  gestion  de  certificats  ou  l’usage  du  DFS  à  l’échelle  de  l’entreprise  pourront  être  rajoutés  sur  la  base  de  l’infrastructure  définie  précédemment.  Il est clair que l’architecture définie initialement ne sera pas affectée par les éléments qui viendront s’appuyer sur celle­ ci.  La  mise  en  œ uvre  ainsi  que  le  suivi  de  la  topologie  physique  de  l’Active  Directory  nécessiteront  que  les  Administrateurs de l’entreprise soient en contact avec l’équipe réseau. Ainsi, au fur et à mesure des modifications qui  pourront  avoir  lieu  sur  le  réseau  physique  de  l’entreprise,  la  topologie  physique  de  l’Active  Directory  pourra  ­  et  certainement ­ devra, refléter ces évolutions. 

© ENI Editions - All rigths reserved

- 1-

Contrôleurs de domaine et structure physique  Nous avons déjà beaucoup parlé des contrôleurs de domaine(s). Cependant, il est intéressant de clarifier l’importance  de ce type d’ordinateur par rapport à la problématique de l’infrastructure de sites Active Directory. Les contrôleurs de  domaines jouent un rôle important dans la mesure où toute la plus­value technologique apportée par Microsoft gravite  autour  d’extensions  de  l’Active  Directory  ou  de  l’intégration  de  certaines  applications  avec  l’Active  Directory.  Dans  le  premier cas, nous pouvons citer les services de certificats X.509 V3 (Services AD CS) et les authentifications par cartes  à puce tandis que dans l’autre, nous pouvons citer Microsoft Exchange Server. Nous pouvons aussi citer les services AD  RMS (Rights Management Services), lesquels sont déclarés dans Active Directory via un objet SCP (Service Control Point).  Toute machine Windows Server 2008, Windows Server 2003 ou Windows 2000 Server autonome ou bien membre d’un  domaine  de  n’importe  quelle  nature  (Windows  NT,  Windows  2000,  Windows  Server  2003)  peut  faire  l’objet  d’une  promotion vers le rôle de contrôleur de domaine. L’inverse est aussi vrai lorsqu’il n’est plus nécessaire qu’un contrôleur  soit présent sur tel ou tel emplacement géographique. La promotion d’un ordinateur au rôle de contrôleur de domaine  est souvent justifiée par la nécessité de créer une nouvelle forêt, un nouveau domaine ou bien de rajouter un nouveau  contrôleur dans un domaine existant. L’objet  contrôleur  de  domaine  joue  le  rôle  de  serveur  d’annuaire et de ce fait,  héberge  un  certain  nombre  de  partitions.  Sous  Windows  2000  Server,  un  contrôleur  de  domaine  héberge  trois  partitions ­ aussi appelées NC (pour Naming Context), telles que la partition du domaine, la partition du schéma et la  partition  de  configuration.  Les  contrôleurs  de  domaine  fonctionnant  sous  Windows  Server  2008  ou  Windows  Server  2003  supportent  de  nouvelles  partitions  principalement  dédiées  aux  applications.  Ainsi,  on  appelle  ces  partitions  partitions de l’annuaire d’applications. Nous avons découvert ces nouvelles partitions lors d’une nouvelle installation  de l’annuaire Active Directory. En effet, à l’issue de la promotion, DCPromo créera deux nouvelles partitions dédiées au  système de résolution de noms DNS. Hormis les fonctions traditionnelles d’un serveur compatible LDAP, un contrôleur  de  domaine  Windows  devra  aussi  assurer  parfois  le  support  de  services  globaux  spécifiques  à  l’Active  Directory  tels  que les catalogues globaux et les maîtres d’opérations.  À propos des anciens contrôleurs Windows NT : les contrôleurs Windows NT 3.51 SP5, Windows NT SP6a et  Windows  2000  SP4  peuvent  faire  partie  d’un  domaine  Active  Directory  fonctionnant  en  mode  Windows  2000  mixte  ou  mode  Windows  Server  2003  interim.  Ils  continuent  ainsi  de  jouer  leur  rôle  de  contrôleur  de  domaine  secondaire  ­  sans  s’apercevoir  que  le  contrôleur  de  domaine  principal  fonctionne  sous  Windows  Server  2008,  Windows Server 2003 ou Windows 2000 Server. Bien entendu, ces anciens serveurs ne disposent d’aucun service,  module  composant  ou  fonctionnalité  de  type  Active  Directory.  Dans  la  mesure  où  la  technologie  de  fond  de  ces  anciens  contrôleurs  est  basée  sur  l’interface  NetBIOS  et  les  services  de  résolution  Wins,  les  contrôleurs  Windows  Server 2008, Windows Server 2003 et Windows 2000 Server continuent de supporter ces anciennes technologies. 

1. Catalogue global et ensemble partiel d’attributs  Par définition, un contrôleur de domaine stocke les objets qui le concernent c’est­à­dire tous les objets du domaine  Windows pris en charge. À partir du moment où le contrôleur de domaine joue ­ en plus de ses tâches habituelles ­ le  rôle  de  GC  (pour  Global  Catalog)  il  hébergera  aussi  des  réplicas  des  partitions  de  domaines  de  tous  les  autres  domaines de la forêt ­ sans exception aucune.  Le catalogue global contient la partition propre à son propre domaine ­ disponible en lecture et en écriture, et donc  tous les objets et attributs d’objets du domaine.  Par  contre,  les  autres  partitions  issues  des  autres  domaines  de  la  forêt  qui  seront  répliquées  vers  un  GC  ne  contiendront qu’un ensemble partiel des attributs.  Une partition de domaine répliquée vers un contrôleur de domaine d’un autre domaine n’est disponible qu’en  lecture seule et ne contient que les attributs les plus intéressants. 

Une  telle  partition,  contenant  un  ensemble  partiel  d’attributs,  est  appelée  PAS  ­  Partial  Attributes  Set.  Un  ensemble d’attributs par défaut présents dans les GC a été défini par Microsoft et est facilement modifiable  en modifiant le schéma de l’annuaire. 

L’idée  qui  consiste  à  ne  répliquer  dans  un  GC  que  les  "meilleurs  attributs"  ne  signifie  pas  pour  autant  que  les  recherches  qui  lui  seront  adressées  seront  inconsistantes  puisque  l’ensemble  des  attributs  déclarés  comme  disponibles dans un GC sont effectivement les plus pertinents. 

© ENI Editions - All rigths reserved

- 1-

Exemple d’attribut (X509­Cert) répliqué dans le catalogue global  Obtenu  à  l’aide de la console de gestion MMC du Schéma Active Directory, l’écran précédent montre comment vous  pouvez sélectionner tel ou tel attribut de l’annuaire et décider de l’y insérer dans les GC de l’entreprise.  L’avantage  le  plus  intéressant  concerne  surtout  les  réseaux  composés  de  plusieurs  domaines  et  d’un  volume  d’informations  d’annuaire  très  important,  pouvant  atteindre  des  dizaines,  voire  des  centaines  de  millions  d’objets.  Ainsi,  les  catalogues  globaux  permettent­il  aux  clients  de  trouver  les  objets  "sans  faire  le  tour"  des  contrôleurs  de  domaines,  mais  tout  simplement  en  recherchant  les  objets  sur  le  serveur  d’annuaire  LDAP  de  type  "Catalogue  Global". 

2. Rôle des catalogues globaux  Les serveurs qui possèdent le rôle de GC jouent un rôle central dans l’infrastructure Active Directory. Ces rôles sont  présentés ci­dessous :  ●

Les catalogues globaux prennent en charge les recherches LDAP à l’échelle de la forêt. 

●

Les  catalogues  globaux  participent  à  l’authentification  des  utilisateurs  en  vérifiant  l’appartenance  de  l’utilisateur  aux  groupes  de  sécurité  universels,  dès  lors  que  le  domaine  est  opérationnel  dans  le  niveau  fonctionnel Windows 2000 natif, Windows Server 2003 ou Windows Server 2008. 

●

Les  catalogues  globaux  prennent  en  charge  la  résolution  des  UPN.  Ainsi,  lorsqu’un  utilisateur  ouvre  une  session  à  l’aide  d’un  ordinateur  fonctionnant  sous  Windows  2000,  Windows  XP  Professionnel  ou  Windows  Vista  en  entrant  son  information  de  logon  sous  la  forme  d’un  UPN  ­  tel  que  [email protected],  un  catalogue global sera sollicité pour déterminer quel est le domaine qui prend en charge les authentifications  pour le suffixe demandé, company.com. 

Il n’est nécessaire de réaliser une recherche sur les suffixes UPN que dans le cas où la forêt est composée de  plus  d’un  domaine  Active  Directory.  L’opération  de  recherche  vers  les  GC  est  indispensable  car  les  suffixes  UPN additionnels éventuellement déclarés à l’aide de la console de gestion MMC Domaines et approbations Active  Directory  ne  sont  connus  que  des  catalogues  globaux.  Donc,  lorsque  la  forêt  est  composée  d’un seul et unique  domaine  Active  Directory,  tous  les  contrôleurs  de  domaines  peuvent  prendre  en  charge  les  demandes  d’authentification  ­  y  compris  lorsque  les  utilisateurs  utilisent  une  forme  UPN  telle  que  [email protected],  - 2-

© ENI Editions - All rigths reserved

sans qu’il soit nécessaire de contacter un catalogue global. Notez cependant que seuls les contrôleurs configurés  pour jouer le rôle de catalogue global peuvent répondre aux requêtes initiées sur le port TCP 3268. 

●

Les catalogues globaux sont à la disposition des serveurs Exchange 2000 Server, Exchange Server 2003 ou  Exchange  Server  2007.  Ainsi,  Exchange  Server  extrait  les  informations  concernant  les  adresses  email  des  utilisateurs des catalogues globaux tandis que les utilisateurs Microsoft Outlook les utilisent pour accéder à la  liste d’adresses globale. 

3. Fonctions principales des catalogues globaux  La fonction première des catalogues globaux est de prendre en charge des recherches LDAP sur la base de requêtes  LDAP standard à ceci près que le port utilisé sera le port 3268 au lieu du traditionnel port 389. Le fait d’envoyer des  requêtes LDAP sur le port 3268 dirige les requêtes sur les partitions des domaines en réplication partielle ainsi que  sur la partition du domaine d’appartenance du contrôleur de domaine gobal catalogue.  D’un point de vue des méthodes d’accès disponibles, les catalogues globaux supportent quatre grands protocoles et  interfaces :  Le protocole LDAP : le protocole LDAP (v2 et v3) est le protocole "principal" utilisé pour toutes les communications  avec l’annuaire Active Directory. Il utilise le protocole de transport TCP 389 mais peut aussi utiliser le protocole UDP,  notamment pour la localisation des contrôleurs et l’accès au rootDSE. Les clients LDAP peuvent envoyer des requêtes  vers les catalogues globaux via TCP sur le port 3268.  Les RPC : le protocole RPC  ­ Remote Procedure Call ­ est utilisé dans le cadre de la réplication de l’annuaire et donc  des catalogues globaux.  Le protocole SMTP : le protocole SMTP est préférable lorsqu’il n’existe pas de connexion stable entre les partenaires  mais  malheureusement  n’est  utilisable  que  "partiellement"  puisqu’il  ne  peut  être  utilisé  que  pour  la  réplication  des  partitions  de  schéma,  de  configuration  et  de  catalogues  globaux.  Le  protocole  SMTP  ne  peut  donc  pas  être  utilisé  pour répliquer les données des partitions de domaines.  Au­delà  des  protocoles  de  transport  qui  permettent  les  communications  vers  les  catalogues  globaux,  les  interfaces  suivantes pourront être invoquées par les utilisateurs, les applications et l’Active Directory :  ●

L’interface  LDAP  est  implémentée  sous  la  forme  d’une  DLL  (Wldap32.dll),  laquelle  permet  d’accéder  au  DSA  (Ntdsa.dll), qui lui­même permet d’accéder aux données contenues dans le moteur de stockage géré par ESE  (Esent.dll), 

●

L’interface REPL qui prend en charge les services de réplication de l’annuaire Active Directory. 

●

L’interface NSPI (Name Service Provider Interface) qui prend en charge le support de l’interface de messagerie  MAPI, utilisée par les clients Outlook. 

●

L’interface  SAM  qui  joue  le  rôle  de  passerelle  pour  que  les  clients  ancienne  technologie  (Windows  NT,  Windows 9x) puissent ­ via l’interface SAM ­ accéder au DSA (Directory Service Agent). 

L’interface  NSPI  n’est fournie que pour le support des anciens clients de messagerie. Microsoft précise que  cette interface de développement n’est plus supportée. 

4. Catalogues globaux et activation de l’appartenance aux groupes universels  Les  contrôleurs  de  domaine  Windows  Server  2003  supportent  la  mise  en  cache  de  l’appartenance  aux  groupes  universels afin de limiter les trafics réseau induits par les authentifications lorsque les domaines sont opérationnels  en mode natif Windows 2000, Windows Server 2003 ou Windows Server 2008.  Vous  pouvez  activer  la  fonction  de  cache  site  par  site  en  modifiant  les  propriétés  de  l’objet  NTDS  Site  Settings  à  l’aide de la console de gestion MMC Sites et services Active Directory.  Dans  le  cas  où  vous  souhaiteriez  faire  cette  modification  sur  de  nombreux  sites,  vous  pourrez  décider  de  créer  un  script et de modifier les propriétés de l’objet NTDS Site Settings. Prenez garde au fait que pour l’attribut options qui  contrôle les options de cet objet est par défaut à 0, ce qui signifie que la fonction de mise en cache est désactivée.  Pour l’activer, vous devrez déclarer la valeur de l’attribut options à 32. Ce type d’attribut utilise un ensemble de bits  qui est finalement converti en décimal. En fait, cette option est contrôlée par le sixième bit, c’est­à­dire 100000, donc  32.  L’écran  suivant  obtenu  à  l’aide  de  la  console  de  gestion  MMC  Sites  et  services  Active  Directory  montre 

© ENI Editions - All rigths reserved

- 3-

l’activation de la mise en cache. 

Activation de la mise en cache des groupes universels sur le site de Sophia Antipolis vers un catalogue du site de  Cannes  Vous pouvez consulter, à l’aide d’ADSI Edit, la valeur de l’attribut options de l’objet NTDS Site Settings. La valeur 32  signifie que la mise en cache de l’appartenance aux groupes universels est activée. 

- 4-

© ENI Editions - All rigths reserved

Sites et services Active Directory  La topologie de sites Active Directory est une représentation du réseau physique de l’entreprise. Comme nous l’avons  déjà dit, l’objectif principal de l’infrastructure de sites est d’optimiser les réplications entre les contrôleurs de domaine  Active Directory fonctionnant sous Windows 2000 Server, Windows Server 2003 et Windows Server 2008 ainsi que de  permettre  une  "bonne  sélection"  des  services  en  fonction  de  leur  emplacement  sur  cette  même  topologie.  De  cette  manière,  le  poids  de  l’infrastructure  technique  Active  Directory  sera  maîtrisé,  au  point  que,  le  plus  souvent,  il  sera  quasiment "oublié".  La phase de conception ne pourra réellement être initialisée qu’une fois que vous aurez une bonne appréhension et  compréhension des différents éléments qui composent l’infrastructure de sites. Une fois ces points acquis, le processus  de  conception  sera  itératif  sur  la  base  de  la  création  des  objets  sites,  de  la  topologie  de  réplication  intersites  et  de  l’emplacement des serveurs d’infrastructure sur lesdits sites. 

1. Qu’est­ce qu’un site Active Directory ?  Par définition, un site est un objet de l’annuaire Active Directory qui représente le réseau physique. À l’échelle de la  forêt, la topologie physique sera au service de l’infrastructure Active Directory, c’est­à­dire pour la réplication, pour la  sélection  des  contrôleurs  par  les  clients  de  l’annuaire  Active  Directory,  pour  les  applications  d’entreprise  (Microsoft  Exchange, Microsoft Message Queuing, etc.) et aussi pour les services globaux tels que les services de certificats, les  ouvertures de session par cartes à puce et les services réseau comme le service DHCP.  Un  site  Active  Directory  est  un  ensemble  de  un  ou  plusieurs  réseaux  ou  sous­  réseaux  IP  connectés  par  des  liens  rapides et stables. Généralement, vous pouvez considérer qu’un réseau local de type LAN à 10 Mbps (ou bien sûr à  100 Mbps ou même en Gigabits) est un réseau rapide, mais libre à vous de décider que plusieurs sites géographiques  connectés via des liaisons à 2 Mbps forment un seul et unique site au sens Active Directory du terme.  En  général,  les  sites  sont  séparés  les  uns  des  autres  par  des  connexions  WAN  plus  lentes  et  certainement  moins  fiables puisque pouvant transiter par des réseaux à caractère public.  Ces liaisons entre les différents sites Active Directory sont virtuellement représentées par les objets Liens de sites,  formant  ainsi  un  premier  niveau  de  la  topologie  physique  de  l’annuaire  Active  Directory.  Les  services  de  l’annuaire  Active  Directory  vont  ensuite  considérer  la  topologie  des  sites  pour  déterminer  quand,  comment  et  quel  chemin  il  faudra  emprunter  pour  pouvoir  réaliser  une  opération  de  réplication  ou  bien  la  sélection  de  tel  ou  tel  service  enregistré dans l’annuaire en fonction de l’endroit d’où la demande aura été initiée. 

2. Pourquoi créer un site ?  Les  services  d’infrastructure  sont  fondamentaux.  D’ailleurs,  ils  sont  de  plus  en  plus  utilisés  par  le  système  d’exploitation mais aussi par les applications. L’infrastructure de site vous permettra d’optimiser la bande passante  disponible dans les cas listés ci­dessous :  ●

Il existe un lien particulièrement lent entre deux sites : dans ce cas, vous pourrez limiter la bande passante  consommée par les flux de réplication Active Directory et la récupérer pour un autre usage. 

●

Certains  liens  coûtent  plus  cher  que  d’autres  :  vous  pourrez  affecter  un  coût  et  gérer  un  planning  hebdomadaire pour définir la meilleure utilisation d’une liaison intersites particulière. 

●

La  bande  passante  disponible  est  faible  :  cette  fois­ci,  vous  souhaitez  contraindre  la  bande  passante  disponible  aux  réplications  Active  Directory  car  la  bande  passante  disponible  est  insuffisante  et  les  communications inter sites ne sont pas toujours disponibles. 

© ENI Editions - All rigths reserved

- 1-

Une forêt Active Directory dispose d’une seule et unique configuration donc d’une seule infrastructure de site  La  figure  précédente  illustre  une  infrastructure  de  sites  Active  Directory  réaliste.  La  forêt  corpnet.corporate.com  est  composée de multiples domaines dans une ou plusieurs arborescences, de multiples sites interconnectés à l’aide de  liens de sites, et d’un ou plusieurs contrôleurs de domaines par site. 

3. Sites et services  La  topologie  de  sites  Active  Directory  fait  tout  de  suite  penser  au  côté  physique  du  réseau.  Cependant,  le  réseau  n’est que le support sur lequel les services de l’infrastructure transitent.  Finalement, les services distribués de l’annuaire Active Directory nous montrent que l’Active Directory voit un réseau,  c’est­à­dire des sites mais aussi des services. L’écran ci­après illustre cette approche pragmatique. 

La console de gestion MMC Sites et services Active Directory  Comme vous pouvez le constater, le nœ ud Services montre les services tels que Microsoft Exchange, MsmqServices  pour les services de Message Queuing, Public Key Services pour les services de certificats et RRAS pour les services  de gestion des accès distants. 

- 2-

© ENI Editions - All rigths reserved

Par  défaut  le  nœ ud  des  services  n’est  pas  affiché.  Pour  l’afficher,  activez  l’option  Afficher  le  nœud  des  services.  Le protocole Kerberos, les services de certificats X.509 v3 ainsi que l’ouverture de session par cartes à puce ont un  caractère global au niveau de l’entreprise toute entière. Par conséquent, ces éléments sont inscrits dans la partition  de configuration de l’annuaire Active Directory, qui contient aussi les sites mais aussi le nœ ud des services globaux.  Services, applications et gestion de la bande passante intersites La topologie de sites Active Directory vous permettra d’optimiser l’usage de la bande passante disponible entre vos  sites géographiques en fonction des activités réseau présentées ci­dessous :  ●

Les  ouvertures  de  sessions  réalisées  par  les  ordinateurs  et  les  utilisateurs  membres  d’un  domaine  Active  Directory. Nous avons vu au chapitre traitant des méthodes de localisation des services Active Directory que  les  ordinateurs  clients  de  l’annuaire  utilisaient  le  service  Net  Logon  Ouverture  de  session  réseau  ­  en  tant  que  Principal  Locator  Service  via  le  service  DNS  pour  rechercher  la  machine  la  plus  proche  jouant  le  rôle  demandé sur la base des sites Active Directory. La topologie des sites doit donc permettre de minimiser les  flux  liés  aux  authentifications  et  à  la  phase  post­authentification  qui  prend  en  charge  l’application  des  stratégies de groupes et autres scripts d’ordinateurs ou d’utilisateurs. 

●

Les flux de réplication de l’annuaire la topologie de sites servira les opérations propres aux réplications en  vous permettant de contrôler quand et comment les réplications doivent se produire. 

●

Les applications Active Directory une application Active Directory peut utiliser les services de l’annuaire en  fonction  de  ses  besoins  à  quelque  niveau  que  ce  soit.  Il  pourrait  s’agir  des  mécanismes  d’authentification  Kerberos,  du  stockage  de  données  répliquées  dans  le  volume  système  SYSVOL  ou  directement  dans  une  partition  de  l’annuaire  d’applications  Active  Directory.  Les  contrôleurs  de  domaine  Windows  Server  2003  et  aussi Windows 2000 Server utilisent la topologie de sites pour construire la topologie de réplication utilisée  par  le  système  de  réplication  de  fichiers  FRS  NT  File  Replication  Service.  Ce  point  est  très  important  car  il  permet la réplication du SYSVOL et des réplicas DFS qui pourraient être mis en réplication automatique. 

© ENI Editions - All rigths reserved

- 3-

Réplication Active Directory  Le moteur de réplication de l’annuaire Active Directory (appelé DRS ­ Directory Replication System) adapte sa méthode  de réplication en fonction de la topologie de sites pour procéder aux mises à jour des données de l’annuaire entre un  contrôleur  de  domaine  et  un  autre  contrôleur  de  domaine  lorsqu’ils  sont  situés  sur  le  même  site  ou  sur  des  sites  différents.  Le moteur de réplication DRS n’existe pas en tant que service que vous pourriez contrôler. Il est directement  intégré  au  cœ ur  du  rôle  de  contrôleur  de  domaine  via  le  DSA  (Directory  Service  Agent)  au  sein  de  la  DLL  Ntdsa.dll.  Ensuite,  les  accès  à  la  base  de  données  NTDS.DIT  sont  pris  en  charge  via  le  moteur  ESE  (Extensible  Storage Engine) représenté par le DLL Esent.dll.  Il convient de garder à l’esprit que l’annuaire Active Directory doit s’assurer que toutes les informations offertes sont  bien  disponibles  sur  tous  les  contrôleurs  de  domaine  concernés  pour  tous  les  ordinateurs  et  utilisateurs  clients  du  réseau Active Directory.  Pour  atteindre  cet  objectif,  la  réplication  Active  Directory  met  en  œ uvre  deux  grands  types  de  réplication.  Les  points  clés qui caractérisent ces différentes méthodes sont présentés ci­dessous :  La réplication de type intrasite :  ●

est recommandée sur des liaisons réseau rapides et fiables, 

●

utilise le protocole RPC sur TCP/IP, 

●

utilise le principe des notifications de modifications, 

●

est rapide. 

La réplication de type intersites :  ●

est recommandée lorsque la bande passante disponible est faible ou lorsque les liaisons sont peu fiables, 

●

utilise presque toujours le protocole IP, mais peut aussi dans certains cas s’appuyer sur le protocole SMTP, 

●

utilise un cycle et une planification hebdomadaire. 

●

utilise la compression de flux. 

1. Concept de la réplication intrasite  La  réplication  qui  se  produit  entre  des  contrôleurs  de  domaine  situés  dans  le  même  site  est  appelée  réplication  intrasite  et  est  particulièrement  adaptée  pour  des  communications  fiables  et  rapides.  En  anglais,  on  parle  de  connexions  entre  des  contrôleurs  de  domaine  dits  well  connected,  c’est­à­dire  bien  connectés.  Par  définition,  les  réplications intrasites considèrent que la connectivité entre deux partenaires de réplication est excellente. De fait, il  est possible que des flux importants se produisent entre des contrôleurs de domaine situés sur un même site Active  Directory.  Le principal avantage de la réplication intrasite est certainement sa bonne réactivité. On dit aussi que la réplication  intrasite offre une faible latence.  D’un  point  de  vue  de  son  fonctionnement  interne,  la  réplication  intrasite  est  basée  sur  un  concept  de  type  notification. Ainsi, les contrôleurs d’un site donné attendent qu’une modification d’un contexte de nommage (c’est­à­ dire une partition) ait lieu pour notifier leurs voisins directs sur le site. Les partenaires voisins notifiés vont ensuite  "tirer" les modifications à partir du contrôleur de domaine ayant été à l’origine de la modification. Vous trouverez ci­ dessous les spécificités propres aux deux types de contrôleurs de domaine que vous pourrez utiliser :  Cas des contrôleurs Windows 2000 Server : les contrôleurs de domaine fonctionnant sous Windows 2000 Server  utilisent, par défaut, une pause après modification de 300 secondes, c’est­à­dire 5 minutes.  Cas  des  contrôleurs  Windows  Server  2003  et  Windows  Server  2008  :  les  contrôleurs  de  domaine  fonctionnant  sous Windows Server 2003 utilisent une valeur beaucoup plus faible. Ils notifient désormais leurs partenaires après  une pause d’à peine 15 secondes, ce qui les rend plus réactifs que leurs prédécesseurs. 

© ENI Editions - All rigths reserved

- 1-

Modification du paramètre Pause After Modify : pour modifier le comportement des contrôleurs de domaine  Windows  2000  Server,  vous  pourrez  changer  la  valeur  par  défaut  de  la  clé  spécifiée  ci­après  :  HKLM/System/CurrentControlSet/Services/ NTDS/Parameters — Clé : Replicator Notify Pause After Modify — Valeur  de type REG_DWORD : défaut (300 sec.) 

Forçage des réplications intrasites à l’aide de la console de gestion MMC Vous pourrez forcer un contrôleur spécifique à aller chercher les modifications disponibles sur l’un de ses partenaires  en  sélectionnant  l’objet  connexion  correspondant,  au  contrôleur  servant  de  référence.  La  procédure  ci­dessous  détaille cette opération simple mais faisant partie des tâches d’administration courantes :  ■

Lancez la console de gestion MMC Sites et services Active Directory. 

■

Positionnez­vous  sur  le  site  souhaité,  parcourez  le  conteneur  nommé  Servers,  sélectionnez  le  serveur  à  synchroniser puis cliquez sur le conteneur NTDS Settings. 

■

Sélectionnez l’objet connexion correspondant à la source de réplication, cliquez avec le bouton droit puis choisissez  l’option Répliquer maintenant. 

Forçage des réplications à l’aide de la commande Repadmin L’interface graphique de la console de gestion MMC est d’un usage facile. Cependant, elle ne permet pas un contrôle  de toutes les options disponibles. Vous pourrez donc, dans certains cas, préférer la commande Repadmin.exe. Cette  commande est livrée avec les outils de support de Windows Server 2003.  La commande Repadmin est intégrée de base dans Windows Server 2008. Les paramètres disponibles avec  la version livrée dans les Outils de Support de Windows Server 2003, fonctionnent toujours sous Windows  Server  2008.  Notez  toutefois  que  la  version  Repadmin  intégrée  à  Windows  Server  2008  supporte  de  nouveaux  paramètres.  Par  exemple,  le  paramètre  /prp  permet  à  un  administrateur  d’afficher  ou  de  modifier  la  stratégie  de  réplication des mots de passe pour les contrôleurs de domaine en lecture seule (RODC).  Déclenchement des réplications à l’aide de la commande Repadmin  La  commande  Repadmin  nécessite  que  vous  spécifiiez  le  nom  du  contrôleur  de  domaine  à  synchroniser.  Pour  y  parvenir, procédez de la manière suivante :  ■

Déterminez  les  partenaires  de  réplication  directe  du  serveur  source  en  tapant  la  commande  suivante  :  repadmin /showreps nom_du_serveur_cible  Si  le  serveur  cible  est  contactable,  il  affiche  des  données  donnant  un  compte  rendu  des  partitions  connues  de  chaque partenaire ainsi que l’état des dernières synchronisations. 

■

Recherchez la partition d’annuaire à synchroniser et le serveur source avec lequel le serveur cible sera synchronisé.  Notez l’objectGuid du serveur source. 

■

Vous pouvez maintenant déclencher la réplication en tapant la commande :  repadmin /sync partition_annuaire nom_du_serveur_cible objectGuid_du_serveur_source 

Par  exemple,  pour  lancer  la  réplication  sur  le  serveur  S1  pour  répliquer  les  modifications  à  partir  de  S2  :  repadmin /sync dc=emea,dc=corpnet,dc=corporate,dc=com S1 d2e3fbad­e07a­11d2­b573­0000f87a253b  Vous pouvez aussi, en fonction des cas, utiliser les options suivantes :  /force  Ignore les timing de réplication planifiés.  /async  Démarre la réplication sans attendre qu’une réplication en cours soit terminée.  /full 

- 2-

© ENI Editions - All rigths reserved

Force une réplication complète de tous les objets du DSA de destination. 

Il  ne  s’agit que des paramètres les plus couramment utilisés. Aussi, pour plus de détails, référez­vous  à  la  documentation  disponible  sur  le  site  de  Microsoft  à  l’adresse  :  http://www.microsoft.com/Resources/Documentation/windowsserv/2003/ all/techref/en­us/repadmin_syntax.asp 

Vous  pourrez  aussi  consulter  l’article  229896  Using  Repadmin.exe  to  Troubleshoot  Active  Directory  Replication de la base de connaissances de Microsoft, en sélectionnant le lien http://support.microsoft.com/? kbid=229896. 

Commande Repadmin et anciens paramètres Windows 2000 Server  La  commande  Repadmin  /oldhelp  vous  permet  d’afficher  les  paramètres  qui  étaient  disponibles  dans  la  version  Windows 2000 de Repadmin. De nouveaux paramètres plus performants remplacent les anciens, lesquels demeurent  toujours utilisables pour maintenir une compatibilité ascendante.  Les commandes déclarées comme "anciennes" sont listées ci­dessous :  Repadmin sync : cette commande déclenche une réplication pour la partition spécifiée entre le contrôleur de domaine  source et le contrôleur de domaine de destination. Vous pouvez obtenir la valeur du paramètre source UUID à l’aide  de la commande qui permet d’afficher les partenaires de réplication, Repadmin /showreps. La syntaxe complète est  spécifiée  ci­dessous  :  repadmin  /sync  NamingContext  DestDC  SourceDCUUID  [/force]  [/async]  [/full]  [/addref]  [/allsources]  NamingContext  Correspond au DN de la partition d’annuaire.  DestDC  Correspond  au  DSA  ­  Directory  Server  Agent,  c’est­à­dire  le  nom  d’hôte  du  contrôleur  de  domaine  avec  lequel  vous  souhaitez répliquer.  SourceDCUUID  Correspond au GUID du serveur source. Il s’agit d’une valeur unique hexadécimale qui identifie l’objet. Comme cela  est spécifié plus haut, le paramètre /showreps vous permettra d’obtenir cette valeur.  /force  Permet d’outrepasser les plannifications horaires définies.  /async  Spécifie  que  les  réplications  fonctionnent  en  mode  asynchrône.  Ce  point  signifie  que  la  commande  Repadmin  peut  démarrer un événement de synchronisation, mais n’attend pas une réponse immédiate du contrôleur de destination  sollicité.  Il  est  recommandé  d’utiliser  ce  paramètre  lorsque  les  deux  contrôleurs  de  domaine  sont  séparés  par  des  liens lents.  /full  Force une synchronisation totale de tous les objets à partir du contrôleur de domaine de destination.  Les autres commandes de type Windows 2000 Server fonctionnant toujours avec la version Repadmin livrée avec les  outils de support de Windows Server 2003 sont listées ci­dessous :  Repadmin  /propcheck  /?  :  cette  commande  compare  les  propriétés  de  contrôleurs  de  domaine  spécifique  pour  déterminer s’ils sont ou non correctement synchronisés.  Repadmin /getchanges /? : cette commande affiche directement à l’écran les changements d’une partition ou d’un  objet spécifié.  Repadmin /showreps /? : cette commande affiche directement à l’écran les partenaires de réplication de toutes les  partitions du contrôleur de domaine spécifié. Cette commande aide les administrateurs à avoir une visibilité sur les  partenaires de réplication impliqués dans la réplication d’une partition donnée. 

© ENI Editions - All rigths reserved

- 3-

Versions des outils de support : il convient de signaler que vous devez faire attention à la version des outils  de support que vous utilisez. En effet, en fonction des versions Windows 2000 ou Windows Server 2003 de  ces  outils,  certaines  options  peuvent  être  disponibles  ou  non.  Microsoft  recommande  l’utilisation  des  dernières  versions des outils de support. Ce principe est certainement un bon principe puisqu’il vous permettra de disposer  des outils les plus "puissants". Cette remarque est très importante lorsque vous devez solutionner un problème  dans l’urgence. De plus, rappelons aussi que les outils de support livrés avec Windows 2000 Server ou Windows  Server  2003  font  l’objet  de  mises  à  jour  lors  du  passage  des  Services  Packs  de  Windows.  En  bref,  les  meilleurs  outils de support sont donc ceux livrés avec la dernière version de système d’exploitation avec le dernier SP. 

Notez aussi que certains outils ou commandes sont mis à niveau et téléchargeables gratuitement sur le site  Web  de  Microsoft  à  l’adresse  ci­dessous  :  http://www.microsoft.com/windowsserver2003/downloads/tools/default.mspx.  Les  outils  du  Kit  de  Ressources  Techniques de Windows Server 2003 font aussi l’objet de mises à niveau spécifiques. Vous pourrez retrouver ces  Windows Server 2003 Resource Kit Tool Updates en vous rendant à l’adresse : http://go.microsoft.com/fwlink/? linkid=20207 

2.  Réplication  intrasite  avec  des  contrôleurs  Windows  2000  Server,  Windows  Server  2003 et Windows Server 2008  Les  contrôleurs  de  domaine  fonctionnant  sous  Windows  2000  Server  qui  sont  mis  à  niveau  vers  Windows  Server  2003  conservent  la  valeur  par  défaut  de  réplication  intrasite  égale  à  300/30.  Cette  notation  signifie  que  tout  changement  effectué  sur  un  contrôleur  de  domaine  Active  Directory  sera  répliqué  vers  les  autres  contrôleurs  de  domaine du site 5 minutes (300 secondes) plus tard, à laquelle il conviendra d’ajouter une valeur aléatoire comprise  entre 0 et 30 secondes avant de notifier le prochain contrôleur de domaine.  Une fois que les contrôleurs de domaine Windows 2000 auront été migrés vers Windows Server 2003, vous pourrez  rehausser le niveau fonctionnel de la forêt vers le niveau Windows Server 2003 et profiter des nouveaux timings de  réplication intrasite.  Cette remarque est toujours vraie avec Windows Server 2008. En effet, pour profiter de cette nouvelle fonctionnalité,  il suffit d’attendre le niveau fonctionnel de forêt Windows Server 2003 (ou Windows Server 2008).  Les timings utilisés sur les contrôleurs de domaine Windows Server 2003 et Windows Server 2008 utilisent le ratio  15/3. Cette nouvelle valeur signifie que tout changement effectué sur un contrôleur de domaine Active Directory sera  répliqué vers les autres contrôleurs de domaine du site 15 secondes plus tard, à laquelle il conviendra d’ajouter une  valeur aléatoire de 3 secondes avant de notifier le prochain contrôleur de domaine.  Notez  que  toute  nouvelle  installation  d’un  contrôleur  de  domaine  Windows  Server  2003  ou  Windows  Server  2008  utilise toujours le ratio 15/3, mais que ces valeurs par défaut dépendent de la version du système d’exploitation, des  éventuelles mises à niveau et aussi du niveau fonctionnel la forêt.  Microsoft recommande d’éviter de changer les timings de réplication par défaut (300/30) des contrôleurs de  domaine Windows 2000. À la place, il est conseillé de mettre à niveau le ou les contrôleurs de domaine et de  rehausser le niveau fonctionnel de la forêt vers le niveau Windows Server 2003, ou mieux Windows Server 2008. 

3. Concept de la réplication intersites  La réplication qui se produit entre des contrôleurs de domaine situés sur des sites différents est appelée réplication  intersites. Elle est particulièrement adaptée pour des communications moins fiables et/ou qualifiables de lentes.  L’avantage principal de la réplication intersites est qu’elle permet à l’administrateur de contrôler les plages horaires  affectées  ou  non  affectées  aux  réplications  Active  Directory.  En  plus  de  cette  possibilité,  les  réplications  intersites  sont compressées ­ avec un ratio de 10 à 15%, ce qui permettra bien sûr de moins consommer de bande passante  sur le ou les liens intersites.  À  propos  de  la  bande  passante  des  connexions  intersites  :  en  général,  une  liaison  rapide  est  une  liaison  permettant  de  disposer  d’un  débit  minimum  compris  entre  512  Kbps  et  2  Mbps.  Par  conséquent,  tout  site  connecté par un lien inférieur à cette valeur devrait être considéré et déclaré comme site Active Directory et profiter  de la gestion des communications intersites. Cependant, la classification en termes de liens "lents ou rapides" est  subjective  et  dépendra  aussi  de  la  bande  passante  et  des  volumes  de  données  à  transférer  entre  les  sites.  Techniquement, il est tout à fait possible de considérer qu’un lien est lent lorsque la bande passante disponible est  inférieure à 128 Kbps.  Le  seul  aspect  négatif  introduit  par  les  mécanismes  de  réplication  intersites  est  certainement  l’augmentation  de  la 

- 4-

© ENI Editions - All rigths reserved

latence de réplication entre les contrôleurs de domaine situés sur des sites géographiquement différents.  Nous pouvons conclure qu’il s’agit du prix à payer pour disposer d’informations d’annuaire à jour sur l’ensemble de la  topologie du réseau tout en minimisant l’impact sur celui­ci.  À propos de la latence des réplications Le problème de latence de la réplication des objets, attributs d’objets et valeurs des attributs d’objets n’en est pas  toujours  un.  Effectivement,  la  réplication  Active  Directory  est  basée  sur  un  modèle  multimaître  ­  en  anglais  "Multi  master replication".  Ce concept permet de modifier directement les objets à l’emplacement qui le nécessite, ce qui a pour effet de faire  baisser le caractère urgent d’une réplication.  Par  exemple,  pour  modifier  le  numéro  de  téléphone  d’un  utilisateur,  ou  bien  ses  appartenances  aux  groupes  ou  même son mot de passe, vous pouvez modifier directement ces valeurs sur le contrôleur du site sur lequel l’utilisateur  est actuellement connecté. Il n’est donc plus nécessaire de répliquer "rapidement" une information qui n’est d’ailleurs  peut­être pas réellement utile sur un autre site.  Cette remarque n’enlève rien au fait que certaines opérations particulières nécessitent de répliquer certaines  informations  de  façon  urgente.  Ce  sera,  par  exemple,  le  cas  du  blocage  d’un  compte  utilisateur  lors  de  l’utilisation d’un mauvais mot de passe. Le cas particulier des réplications urgentes est traité plus loin. 

4. Création des objets connexion en intrasite et anneaux de réplication  La réplication des mises à jour des objets stockés dans les partitions de l’annuaire sont transmises de contrôleur en  contrôleur et donc de site en site. Nous pouvons considérer qu’il existera deux grands types de chaînage possibles :  ●

Les contrôleurs d’un même domaine sont ventilés sur de multiples sites. 

●

Les contrôleurs de multiples domaines sont ventilés sur le même site et sur de multiples sites. 

Les  objets  de  connexion  sont  des  objets  indispensables  au  bon  fonctionnement  des  réplications.  Grâce  à  eux,  les  liens de communication qui permettent à deux partenaires de réplication d’échanger des données qu’ils auraient en  commun existent et alors, tout devient possible.  Ces objets de connexion sont créés par le Vérificateur  de  la  topologie  de  réplication appelé en anglais KCC pour  Knowledge Consistency Checker. Le KCC est une véritable application distribuée qui fonctionne de manière régulière —  par défaut toutes les 15 minutes — sur tous les contrôleurs de domaine Windows 2000 Server, Windows Server 2003  et Windows Server 2008. En fait, chaque contrôleur de domaine disposant de la partition de configuration de la forêt  utilisera le KCC et les informations de la partition de configuration pour déterminer et créer les meilleures connexions.  Bien sûr, le KCC s’appuiera sur l’infrastructure de sites Active Directory pour créer :  ●

des connexions adaptées à un fonctionnement intrasite, 

●

et des connexions adaptées à un fonctionnement intersites. 

En fonction de la situation géographique des contrôleurs de domaines et des partitions qu’ils hébergent (partitions  de schéma, de configuration, de domaine et partition de l’annuaire d’applications Active Directory).  Important  :  à  partir  du  moment  où  il  existe  au  sein  de  la  forêt  plus  d’un  contrôleur  de  domaine,  il  est  indispensable qu’il existe au minimum une connexion (ou deux ou plus) pour chacun d’entre eux. Lorsqu’un  contrôleur  ne  dispose  plus  de  ces  connexions,  alors  il  ne  lui  est  plus  possible  de  communiquer  avec  ses  partenaires. 

Un tel phénomène ne devrait pas se produire puisque le KCC de chaque contrôleur vérifie la cohérence de la  topologie  de  réplication  toutes  les  15  minutes.  Par  contre,  dans  le  cas  où  le  KCC  serait  désactivé  sur  un  contrôleur  particulier,  seul  un  administrateur  de  l’entreprise  pourra  rétablir  la  situation  en  créant  les  connexions  nécessaires  au  bon  fonctionnement  du  contrôleur.  Tant  que  cette  opération  manuelle  n’aura  pas  été  réalisée,  le  contrôleur sera en dehors de la topologie de sites et sera, de ce fait, "isolé" de l’infrastructure. 

Les  objets  de  connexion  nécessaires  aux  contrôleurs  de  domaine  situés  sur  un  même  site  sont  créés  de  manière 

© ENI Editions - All rigths reserved

- 5-

entièrement automatique. Le KCC de chaque contrôleur de domaine s’arrangera pour que un ou plusieurs anneaux  de réplication soient toujours disponibles. Par défaut, le KCC se déclenche automatiquement toutes les 15 minutes.  Pour  pouvoir  personnaliser  le  cycle  de  déclenchement  du  KCC,  vous  pourrez  modifier  sur  le  ou  les  contrôleurs  souhaités, la clé ci­dessous :  Emplacement : HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters  Paramètre : Repl topology update period (secs)  Valeur de type REG_DWORD : la valeur doit être comprise entre 0x14­et 0xFFFFFFFF. La valeur par défaut est 0x384  soit 900 secondes, c’est­à­dire 15 minutes.  Description : ce paramètre permet de spécifier quand le KCC réévalue la topologie de réplication. Le KCC évaluera la  topologie  de  réplication  à  l’intervalle  spécifié  lorsque  l’annuaire  Active  Directory  fonctionne.  Notez  que  par  défaut  cette entrée n’existe pas dans le registre.  Utilisation des anneaux en intrasite La figure ci­après illustre la structure d’un anneau de réplication intra site. Par définition, un anneau de réplication est  composé  au  plus  de  7  contrôleurs  de  domaines,  sachant  que  les  réplications  entre  contrôleurs  supportent  une  transitivité des réplications limitée à 3 sauts.  Le scénario suivant illustre les opérations qui peuvent se produire sur un site comportant de multiples contrôleurs :  1. Au fur et à mesure du déploiement, les contrôleurs Active Directory ont été insérés sur le site et le KCC a créé la  topologie de réplication adéquate à l’aide des objets connexion du site.  2.  Une  modification  est  réalisée  sur  le  contrôleur  s1.  Ce  contrôleur  devient  l’origine  de  la  modification.  De  fait,  il  incrémente la valeur de l’USN de la base Active Directory (USN ­ Unique Sequence Number) ainsi que l’USN de l’objet et  aussi des attributs modifiés. Celui­ci attend son délai de 15 secondes.  3.  s1  identifie  les  partenaires  de  réplication  concernés,  puis  réalise  les  recherches  DNS  nécessaires  pour  s’y  connecter.  4.  s1  sélectionne  ses  partenaires  et  réalise  une  authentification  mutuelle  à  l’aide  du  protocole  Kerberos  via  des  appels RPC sur IP. À l’issue de cette authentification, s1 envoie une notification de changement vers ses partenaires. 

Réplication Intrasite et objets de connexion  5. Les contrôleurs s2 et s7 notifiés contactent le serveur ayant fait l’objet des modifications en retournant à s1 une  demande  des  changements.  Cette  opération  est  réalisée  en  demandant  la  table  des  changements  des  métadonnées.  6. s1 renvoie les données demandées aux partenaires authentifiés.  7.  Finalement,  les  contrôleurs  s2  et  s7  utilisent  le  sous­système  de  réplication  Active  Directory  pour  appliquer  les  changements dans la base de données NTDS.DIT.  Dans cet exemple, vous pouvez constater que le contrôleur s3 est indisponible. Du coup, le KCC des machines s2 et  s4  détectera  cette  absence  ­  au  plus  tard  avec  un  délai  de  15  minutes  et  une  nouvelle  connexion  sera  automatiquement créée.  - 6-

© ENI Editions - All rigths reserved

Une  autre  problématique  prise  en  charge  par  le  moteur  de  réplication  de  l’Active  Directory  permet  de  "freiner"  les  réplications  inutiles.  Dans  notre  exemple,  s4  informe  son  partenaire  s5  qu’il  possède  des  modifications.  Les  deux  contrôleurs  vont  échanger  des  tables  de  modifications  (Watermark  Vector  and  Up­To­Dateness  Vector)  qui  permettront au serveur sollicité d’accepter ou refuser les propositions notifiées. Dans notre cas, s5 refuse car il a déjà  reçu les informations via le serveur s6.  L’écran ci­après montre les caractéristiques d’un objet connexion. Vous remarquerez que le nom de l’objet est généré  automatiquement. En fait, il ne s’agit pas du véritable CN de l’objet mais d’une sorte de commentaire qui a pour objet  de nous faire remarquer que la connexion a été créée par le KCC et pas manuellement par un administrateur de la  topologie de site. Le véritable CN est tout simplement une valeur de type GUID telle que 013ba9c6­7fc7­437a­a9da­ 402d88e6171e 

Caractéristiques d’un objet connexion créé par le KCC  Vous  pourrez  aussi  ajouter  des  connexions  manuellement  pour  raccourcir  certains  chemins  de  réplication.  Dans  ce  cas, le KCC ne prendra pas l’initiative de supprimer ces connexions spécifiques.  À  l’inverse,  si  vous  supprimez  des  objets  connexion  créés  par  le  module  KCC,  celui­ci  s’empressera  lors  de  son  prochain cycle de fonctionnement, de les recréer.  À propos du renommage des objets connexion La  console  de  gestion  MMC  Sites  et  services  Active  Directory  vous  permet  de  créer  vos  propres  connexions  ou  même de modifier les connexions créées par le KCC. Cependant, si vous souhaitez renommer les connexions créées  par  le  KCC,  un  message  vous  informera  que  la  connexion  perdra  son  statut  de  "connexion  générée  automatiquement".  Le fait de poursuivre fera que le KCC ne prendra plus à sa charge la gestion de cette connexion. Cela signifie aussi  que vous contrôlez désormais totalement les différentes propriétés de cet objet. 

5. Réplication intersites à l’aide des liens de sites et ponts de liaisons  Nous  venons  d’étudier  la  réplication  intrasite  et  nous  avons  pu  voir  à  quel  point  le  KCC  est  un  composant  fondamental de la création de la topologie de réplication. Alors que dans le cas de la topologie de réplication intrasite  toutes  les  opérations  sont  prises  en  charge  par  le  KCC  de  manière  automatique,  cette  fois­ci,  les  connexions  nécessaires  à  la  réplication  seront  créées  sur  la  base  des  informations  intersites  que  vous  aurez  au  préalable  déclarées à l’aide de la console de gestion MMC Sites et services Active Directory. 

© ENI Editions - All rigths reserved

- 7-

L’annuaire stocke les informations nécessaires à la construction de la topologie de réplication sous la forme d’objets  de type liaison de sites et autres ponts de liaisons intersites.  Un seul et unique contrôleur de domaine par site a la charge de construire la topologie. Le contrôleur ­ le premier à  être  arrivé  sur  le  site  ­  jouant  ce  rôle  est  appelé  ISTG ­  pour  Inter  Site  Topology  Generator,  c’est­à­dire  en  français  générateur de topologie intersite. Un algorithme d’arborescence à moindre coût permet de construire une topologie  de  réplication  efficace  en  éliminant  les  objets  connexion  inutiles  et  du  même  coup,  les  chemins  de  réplication  redondants  entre  les  sites.  Comme  nous  l’avons  vu  concernant  la  topologie  intrasite,  la  topologie  de  réplication  intersites  est  mise  à  jour  régulièrement  pour  répondre  aux  éventuelles  évolutions  de  la  structure  du  réseau.  Vous  pouvez contrôler la réplication intersite par le biais des informations que vous fournissez en créant des objets lien de  sites. 

a. Les liens de sites  Les liens de sites vous permettent de relier un ou plusieurs sites de telle sorte que les communications deviendront  possibles  entre  les  contrôleurs  répartis  sur  de  multiples  sites.  En  fonction  de  ces  déclarations,  l’ISTG  prendra  ensuite à sa charge la création et la configuration des objets connexion.  Les  liens  intersites  ­  parfois  appelés  liaisons  intersites,  vous  permettent  de  maîtriser  quand  et  comment  les  réplications  intersites  se  produisent.  Active  Directory  économise  la  bande  passante  entre  sites  en  réduisant  au  minimum la fréquence de réplication. Par défaut, la réplication intersites a lieu toutes les 180 minutes (3 heures) sur  chaque liaison de sites, sachant que la valeur minimale ne peut être inférieure à 15 minutes.  Bien sûr, vous pouvez modifier cette fréquence en fonction de vos propres exigences. Une fréquence de réplication  plus  importante  consomme  davantage  de  bande  passante.  En  plus  de  la  valeur  de  ce  cycle,  vous  pouvez  aussi  planifier  la  disponibilité  des  liaisons  de  sites  pour  la  réplication.  Par  défaut,  une  liaison  de  sites  est  disponible  24  heures  sur  24,  7  jours  sur  7.  Vous  pouvez  limiter  cette  disponibilité  à  certains  jours  de  la  semaine  ou  à  certains  créneaux  horaires.  Par  exemple,  vous  pouvez  planifier  la  réplication  intersites  pour  qu’elle  s’effectue  uniquement  après les heures de travail ou les week­end.  Le dernier paramètre intéressant concernant le lien de site est la valeur de Coût qui lui est associée. Ainsi, tout lien  traversé  pour  atteindre  un  site  donné  augmente  le  coût  global  de  la  route  entre  le  site  source  et  le  site  de  destination. L’usage des coûts permettra donc à l’administrateur de l’infrastructure Active Directory de respecter un  certain nombre de consignes directement émises par l’équipe ayant en charge l’administration du réseau physique.  La configuration présentée ci­après est composée de trois sites (San Francisco, Paris et Vancouver). Ces sites ont  été déclarés à l’aide de la console de gestion MMC Sites et services. Les sous­réseaux IP ont été créés et associés à  leur site respectif.  Dans cette première configuration, chaque site est associé au lien de site par défaut nommé DEFAULTIPSITELINK.  Les  caractéristiques  de  ce  lien  font  que  les  réplications  intersites  sont  planifiées  pour  être  réalisées  toutes  les  3  heures sur un planning hebdomadaire autorisant les réplications totalement. 

- 8-

© ENI Editions - All rigths reserved

Lien de sites et objets connexion  Sur chaque site, le contrôleur jouant le rôle de générateur de topologie intersites prend à sa charge la création de  ses propres objets de connexion, lesquels lui permettront de communiquer avec le ou les autres sites.  La création d’un site est une opération simple puisqu’il suffit de nommer le site et d’associer le site à un lien de site.  Cette association est obligatoire au risque de recevoir une message d’alerte vous spécifiant que tout site doit être  relié au minimum à un lien de site. 

b. Choix du transport Intersites : IP (avec RPC) ou SMTP  Les  objets  connexion  sont  principalement  caractérisés  par  leur  protocole  de  transport.  Les  différents  transports  supportés  permettent  de  réaliser  techniquement  le  transfert  des  données  à  répliquer  entre  les  contrôleurs.  Windows  2000  Server,  Windows  Server  2003  et  Windows  Server  2008  supportent  trois  grands  types  de  transports :  ●

Un  transport  rapide  synchrone  de  type  RPC/IP  pour  les  communications  intra  site  :  Les  communications  intrasites  utilisent  toujours  ce  transport.  Dans  l’interface  graphique,  ce  choix  correspond  à  la  valeur  RPC.  Notez que si vous changez la valeur du protocole sur un objet connexion, le KCC reconfigurera l’objet pour  réutiliser le protocole RPC. 

●

Un transport faible vitesse point à point synchrone de type RPC/IP pour les communications intersites. 

●

Un  transport  asynchrone  utilisant  le  protocole  SMTP  pour  les  communications  inter  sites.  L’écran  suivant  montre les deux protocoles que vous pourrez utiliser en tant que protocoles de type intersites. D’une part le  protocole IP, qui lui aussi utilise des RPC ­ mais en mode faible vitesse, et aussi le protocole SMTP. 

© ENI Editions - All rigths reserved

- 9-

Protocoles de transport de type Intersites  Ainsi, les réplications intersites pourront ­ en fonction des situations être ­ réalisées soit via le transport RPC/IP, soit  via le transport SMTP/IP.  Faites cependant attention au fait que la réplication intersites à l’aide du protocole de transport SMTP n’est possible  qu’entre des contrôleurs de domaine de domaines différents. Cette remarque signifie donc que seules les partitions  de schéma, de configuration et des réplicas des catalogues globaux pourront effectivement être répliquées.  Attention : Le transport SMTP n’est pas utilisable pour les contrôleurs d’un même domaine situés sur des  sites différents. Cela signifie donc que pour répliquer des contrôleurs de domaine d’un même domaine dans  un environnement intersites, vous devrez toujours utiliser le transport IP qui nécessite des communications point  à point et l’usage des RPC/IP.  L’écran  suivant  illustre  le  cas  d’un  objet  connexion  créé  automatiquement  par  le  KCC/ISTG  dans  le  cadre  des  communications intersites et l’usage du transport IP qui pour rappel, utilise des RPC sur IP en mode faible vitesse. 

Objet connexion intersites et type de protocole de transport utilisé  Par  définition,  un  objet  connexion  représente  toujours  une  source  de  données.  Tel  que  spécifié  sur  l’écran  ci­ dessus, cette connexion permet de Répliquer depuis les contextes de noms (NC ­ Naming Contexts) suivants :  ●

- 10 -

Les  contextes  qui  concernent  la  configuration  de  l’entreprise,  c’est­à­dire  les  partitions  de  schéma  et  de 

© ENI Editions - All rigths reserved

configuration.  ●

Dans notre exemple, la partition de domaine du domaine noam. corpnet. corporate.com. 

c. Service système Messagerie intersites  Le service Messagerie intersites est un service inclus de base au sein du système Windows 2000, Windows Server  2003  et  Windows  Server  2008.  Vous  ne  pouvez  pas  choisir  de  l’installer  ou  de  le  désinstaller.  En  tant  que  composant interne, ce module ismserv.exe (Windows NT Intersite Messaging Service) est activé lorsqu’un serveur  joue le rôle de contrôleur de domaine. Il permet de supporter de multiples transports au sein de l’architecture de  sites Active Directory.  Dans une forêt fonctionnant en mode Windows 2000, il est important de noter que le service Messagerie intersites  peut  être  sollicité  par  le  KCC  pour  découvrir  quels  sont  les  chemins  disponibles  ou  pas.  Le  service Ouverture  de  session réseau  peut  lui  aussi  invoquer  le  service Messagerie  inter  sites, notamment concernant les fonctions de  couverture automatique de sites.  Quand la forêt fonctionne en mode Windows Server 2003 ou Windows Server 2008, le KCC devient autonome et de  fait, n’utilise plus le service Messagerie intersites.  Microsoft précise que quel que soit le mode de fonctionnement de la forêt, le service Messagerie inter sites  est toujours indispensable pour les fonctions suivantes : le fonctionnement du service DFS (Distributed File  System)  en  intersites,  les  fonctions  de  couverture  automatique  de  sites,  le  support  de  la  mise  en  cache  de  l’appartenance aux groupes universels et la réplication basée sur le protocole de transport SMTP. 

d. Mise en œuvre du transport SMTP  Pour  que  le  KCC/ISTG  soit  capable  de  créer  les  objets  connexion  nécessaires  à  la  topologie  de  réplication  sur  la  base de connexions basées sur le protocole SMTP, vous devrez respecter les consignes de mise en œ uvre listées ci­ dessous :  ●

IIS 6.0 doit être installé sur les serveurs contrôleurs de domaines partenaires sur chacun des sites, 

●

Une autorité de certification de type Enterprise CA doit être disponible au sein de la forêt Active Directory.  Cette  autorité  de  certification  pourra  émettre  des  certificats  de  type  Domain  Controller  lesquels  seront  utilisés  pour  signer  les  messages  SMTP  qui  seront  échangés  entre  les  contrôleurs  situés  sur  des  sites  différents. 

●

Les  sites  peuvent  communiquer  grâce  à  des  liens  de  sites  appartenant  au  nœ ud  Sites  et  services  Active  Directory/Sites/Inter­Site Transports/SMTP. 

●

Le lien de site utilisant le protocole de transport SMTP dispose d’un chemin "plus court" que n’importe quel  autre chemin qui pourrait être emprunté pour accéder au site de destination. 

●

La  remise  des  messages  est  possible.  Si  les  deux  partenaires  de  réplication  disposent  d’une  connectivité  directe, aucune configuration supplémentaire n’est nécessaire. Sinon, vous devrez configurer les éventuels  relais pour que la remise des messages puisse avoir lieu. 

Différences entre le protocole SMTP et le protocole RPC/IP Généralement, le protocole IP (RPC/IP) est utilisé. Néanmoins, le fait de connaître les avantages et inconvénients de  chacun d’eux vous permettra de faire le bon choix.  Les protocoles RPC/IP et SMTP supportent les fonctions suivantes :  ●

Les données sont compressées, 

●

Les  deux  transports  s’appuient  sur  TCP  et  de  fait,  une  retransmission  complète  des  données  transférées  sera nécessaire en cas d’erreur. 

Microsoft  recommande  l’utilisation  du  protocole  IP  (RPC/IP)  car  il  permet  de  répliquer  des  contrôleurs  de  domaine  d’un même domaine sur des sites différents, ce qui est un cas très fréquent. De plus, les RPC ­ même lorsqu’elles  sont utilisées en mode lent, sont bien plus rapides que des messages SMTP. 

© ENI Editions - All rigths reserved

- 11 -

Le protocole de transport SMTP pourra être utilisé dans le cas où les RPC ne peuvent pas être transportées entre  les deux partenaires. Il pourra s’agir d’un environnement particulièrement sécurisé qui interdit totalement les RPC.  Les demandes de modifications sont transmises via des messages RPC de type Demandes et Réponses en mode  synchrone.  Le  protocole  SMTP  peut,  lui,  fonctionner  de  manière  totalement  asynchrone,  ce  qui  à  bien  des  égards  représente  un  avantage.  En  fait,  avec  les  RPC,  toute  opération  entamée  doit  être  terminée  avant  de  passer  à  la  suivante.  Le  protocole  SMTP  permet  au  contraire  de  fonctionner  de  manière  asynchrone.  Ainsi,  il  est  possible  de  recevoir de multiples messages vers de multiples destinations différentes, qu’il s’agisse de contrôleurs de domaine  différents ou de partitions d’annuaire différentes.  Mode  synchrone  contre  mode  asynchrone  :  même  si  le  protocole  de  transport  SMTP  semble  séduisant  à  plus d’un titre (usage des certificats, messages authentifiés et cryptés, mode asynchrone, compression) le  fait qu’il ne peut pas être utilisé pour répliquer les partitions de domaines qui concernent les contrôleurs placés  sur des sites différents fait qu’il  ne  peut  être  utilisé  que  dans  de  rares  cas.  Vous  pourrez  par  exemple  l’utiliser  pour  répliquer  uniquement  les  partitions  de  schéma,  de  configuration  et  des  catalogues.  Comme  il  ne  peut  répliquer  les  partitions  de  domaine  dont  les  contrôleurs  sont  placés  sur  des  sites  différents,  son  cadre  d’utilisation est très limité et peu commun. 

6. Gestion des liens intersites et des coûts de réplication  La topologie de réplication intersites définit la réplication entre les sites par rapport à l’implémentation générale de  l’Active Directory dans le réseau de l’entreprise.  La conception de cette topologie nécessite la création d’éléments existant en tant qu’objets de l’annuaire. À ce titre,  ces  objets  possèdent  un  certain  nombre  d’attributs  que  nous  utiliserons  pour  concevoir  notre  solution.  La  solution  inclura  la  création  d’objets  liens  de  sites,  le  choix  des  protocoles  de  transport,  la  planification  des  heures  de  réplication et les coûts de liaisons, la mise en œ uvre de ponts de liaisons et des serveurs têtes de pont. 

a. Détermination de la planification et des coûts des liens intersites  La  mise  en  œ uvre  de  la  topologie  de  réplication  intersites  de  l’Active  Directory  nécessite  de  déterminer  la  planification  du  calendrier  de  réplication  entre  chaque  site  ainsi  que  les  coûts  associés  à  chaque  lien  de  communication intersites. Notez que, par défaut, la réplication des partitions de l’annuaire en intersites ne repose  pas sur le principe des notifications mais sur une planification "contrôlée" de ces réplications. Nous verrons plus loin  que dans certains cas, il est possible d’activer manuellement le support du mécanisme des notifications. Le schéma  suivant illustre notre topologie de réplication. 

Topologie de réplication Active Directory  Les paramètres qu’il faudra toujours déterminer sont :  La  planification  horaire  hebdomadaire  :  le  lien  de  site  vous  permet  de  déclarer  le  planning  hebdomadaire  de  réplication que vous souhaitez mettre en œ uvre. 

- 12 -

© ENI Editions - All rigths reserved

Configuration de l’échéancier hebdomadaire du lien intersites  L’écran  précédent  montre  que  les  réplications  sont  autorisées  le  samedi  et  le  dimande  tandis  qu’elles  sont  contrôlées les autres jours de la semaine.  Le coût du lien intersites : le coût du lien de site est représenté par une valeur arbitraire qui représente la priorité  associée au trafic entre les sites identifiés par le lien de sites. Plus le coût d’un lien ou d’une somme de liens est  élevé et plus la priorité de ce lien par rapport aux autres est faible. Dans le cas où plusieurs chemins sont possibles  en  tenant  compte  des  différentes  contraintes  horaires  et  de  fonctionnement,  la  réplication  Active  Directory  empruntera le chemin le moins coûteux. 

La modification du lien permet de paramétrer les planifications et le cycle  Vous  remarquerez  qu’un  lien  de  site  peut  contenir  plus  d’un  site  "branché"  sur  le  lien  intersites.  En  fait,  le  lien 

© ENI Editions - All rigths reserved

- 13 -

intersites est un élément virtuel qui permet de rendre disponibles des connexions "contrôlées".  Concernant les valeurs à déclarer sur les liens de site, vous pouvez décider de fixer un coût de 100 sur les liens de  sites  qui  forment  votre  "backbone",  et  fixer  un  coût  plus  élevé  ­  par  exemple  300  ou  500,  sur  les  liens  de  sites  correspondant aux sites satellites ou autres bureaux d’agences.  En procédant de cette manière, vous garantissez que les flux de réplication seront plutôt dirigés vers un contrôleur  de domaine situé sur un site faisant partie du backbone principal, en raison d’un coût inférieur.  Le site en question ne prendra l’initiative de communiquer avec un autre site que si le site le moins coûteux n’est  pas  disponible.  Ce  pourra  être  le  cas  en  cas  de  panne  ou  bien  si  le  lien  de  site  est  déclaré  indisponible  à  cette  heure dans la topologie de réplication Active Directory. 

b. Pourquoi désactiver le pontage par défaut de tous les liens de sites ?  Un pont de lien de sites  ­ en anglais, a Site Link Bridge ­ permet de chaîner ou marier plusieurs liens de sites. De  cette  manière,  les  contrôleurs  de  domaines  des  différents  sites  peuvent  emprunter  plusieurs  liens  de  sites  pour  communiquer directement.  Cependant, notez que, par défaut, il n’est pas nécessaire de créer des ponts. En effet, l’écran suivant montre que le  protocole IP dispose d’une propriété qui permet de relier entre eux tous les liens. 

Par défaut, le transport IP utilisé pour les communications intersites relie tous les liens de sites  À partir du moment où l’option Relier  tous  les  liens  du  site est activée sur le protocole IP, alors tous les liens de  sites  sont  considérés  comme  transitifs.  En  fait,  cela  signifie  que  tous  les  liens  de  sites  sont  "connectés"  sur  une  sorte de tube transitif jouant le rôle d’épine dorsale. Ainsi, dans un réseau TCP/IP entièrement routé, il n’est pas  utile de configurer des ponts de liens de sites.  Par contre, si les flux doivent être dirigés de manière particulière ­ dans le cas où, par exemple, le réseau ne serait  pas entièrement routé, alors vous pourrez désactiver cette option pour ne plus profiter de cette transitivité totale  des liens entre eux. Vous devrez alors configurer un ou plusieurs ponts de liens pour pouvoir former votre propre  maillage de communications réseau.  Alors que le protocole IP permet de rendre transitifs entre eux tous les sites de tous les liens de sites, le pont de  liens  de  sites  crée  un  ou  des  chemins  transitifs  égal  à  la  somme  des  liens  de  sites  individuels  membres  d’un  ou  plusieurs ponts.  Pour  conclure,  lorsque  le  réseau  est  entièrement  routé  et  que  vous  approuvez  les  objets  connexion  créés  par  le  KCC, alors l’option par défaut permettant de Relier tous les liens du site permet de créer un pont virtuel transitif 

- 14 -

© ENI Editions - All rigths reserved

qui rendra les plus grand services.  À l’inverse, pour créer de multiples zones de connectivité et "restreindre" ce même KCC aux chemins désignés par la  topologie de vos propres liens et ponts de liaisons, vous pourrez décider de désactiver le pontage sur le protocole  IP. À partir de ce moment, plus aucun lien de sites n’implémente de transitivité. 

c. Effets de la désactivation de la transitivité sur le KCC et avantages dans les grands réseaux  Les ponts de liaison de sites sont des composants de l’infrastructure Active Directory utilisés par le KCC seulement  lorsque la transitivité est désactivée.  Vous  pourrez  décider  de  désactiver  la  transitivité  ­  toujours  à  l’aide  de  l’option  Relier  tous  les  liens  du  site  et  préférer l’usage des ponts pour diminuer la charge processeur nécessaire au calcul d’une topologie de réplication  massivement transitive.  En  effet,  dans  les  très  grands  réseaux,  la  transitivité  des  liens  de  sites  deviendra  un  problème,  car  le  KCC  devra  tenir  compte  de  tous  les  chemins  possibles.  Microsoft  recommande  que  dans  les  forêts  Windows  2000  devant  supporter plusieurs centaines de sites (env. 300) ou dans les forêts Windows Server 2003 ou Windows Server 2008  devant supporter plusieurs milliers de sites (env. 3000), vous désactiviez l’option Relier tous les liens du site. De  cette  manière,  le  temps  de  calcul  du  KCC  sera  grandement  réduit  grâce  à  la  création  manuelle  de  vos  ponts  de  liaisons et à leur usage par le KCC. 

d. Effets de la désactivation de la transitivité sur la topologie DFS  La désactivation de la transitivité peut affecter la façon dont les clients DFS localisent le meilleur site, en fait le plus  proche. Le composant ISTG (Inter Site Topology Generator) utilise l’option Relier tous les liens du site pour pouvoir  calculer les coûts de liaisons intersites. 

e. À propos des algorithmes utilisés par le KCC/ISTG  Le KCC et l’ISTG sont responsables sur chaque contrôleur de domaine ISTG de chaque site de la création des objets  connexions  entrantes  vers  tous  les  contrôleurs  choisis  pour  communiquer  sur  les  autres  sites.  Finalement,  la  somme de tous les objets de connexion créés par chaque ISTG de tous les sites forme la topologie de réplication  intersites.  Un point important est que chaque ISTG de chaque site participe à la création de ses propres connexions.  Vous devez savoir que les contrôleurs de domaine Windows Server 2003 et Windows Server 2008 supportent deux  algorithmes  :  l’algorithme  utilisé  par  Windows  2000  Server  et  l’algorithme  utilisé  par  Windows  Server  2003  et  Windows  Server  2008.  Tant  que  le  forêt  fonctionne  en  mode  Windows  2000,  seul  l’algorithme Windows 2000 est  utilisé, quelle que soit la version des contrôleurs de domaine membres de la forêt. Une fois que la forêt ne contient  plus  que  des  contrôleurs  de  domaines  fonctionnant  sous  Windows  Server  2003  ou  Windows  Server  2008,  vous  pouvez décider de rehausser le niveau fonctionnel de la forêt vers respectivement le niveau fonctionnel Windows  Server  2003  ou  Windows  Server  2008.  À  partir  de  ce  moment,  tous  les  ISTG  de  la  forêt  utiliseront  le  nouvel  algorithme disponible sur les contrôleurs de domaine Windows Server 2003.  Comment  déterminer  s’il est urgent de penser à une évolution des KCC/ISTG ? Pour déterminer si oui ou  non, dans une forêt Windows 2000, une éventuelle surcharge CPU pourrait être causée par le KCC, et ainsi  évaluer  la  possibilité  de  moderniser  l’infrastructure  Windows  2000  en  étudiant  une  évolution  vers  Windows  Server  2003  ou  Windows  Server  2008,  vérifiez  que  la  condition  suivante  est  bien  remplie  :  D  représente  le  nombre  de  domaines  membres  de  la  forêt  Windows  2000.  S  représente  le  nombre  de  sites  déclarés  dans  la  topologie de réplication. (1 + D) * S^2 <= 100.000 

f. Création d’un nouveau pont entre liens de sites  L’opération de création d’un pont de liaison est extrêmement simple. Il suffit, à l’aide de la console de gestion MMC  Sites  et  services  Active  Directory,  de  demander  la  création  de  l’objet.  Il  ne  reste  plus  qu’à  associer  dans  la  colonne Liens de sites présents dans ce pont entre liens de sites au moins deux sites. 

© ENI Editions - All rigths reserved

- 15 -

Création d’un pont de liaison contenant deux liens de sites  Comme  vous  pouvez  le  constater  ­  il  en  est  de  même  pour  les  objets  Liens  de  sites  ­  les  ponts  virtualisent  de  multiples connexions en permettant de marier plus de deux liens de sites sur le même pont. 

g. Gestion des serveurs tête de pont  Un  serveur  tête  de  pont  est  un  serveur  Windows  2000  Server,  Windows  Server  2003  ou  Windows  Server  2008  jouant  le  rôle  de  contrôleur  de  domaine  responsable  des  communications  entre  les  autres  sites.  En  anglais,  les  serveurs têtes de pont sont appelés serveurs BHS pour Bridgehead Server.  En fait, ces serveurs, choisis et nommés par l’ISTG de chaque site, possèdent les objets connexion qui permettent  au site de communiquer avec les autres sites grâce aux autres serveurs têtes de pont des autres sites. Bien sûr,  quand un site dispose d’un seul et unique contrôleur de domaine, ce contrôleur joue forcément le rôle de serveur  tête de pont.  Les  serveurs  BHS  sont  responsables  des  communications  sur  les  partitions  qu’ils  possèdent.  Ce  point  signifie que sur un site comprenant deux contrôleurs de domaine de deux domaines différents, il existera  autant de BHS que de partitions à rendre disponibles avec les autres sites. 

- 16 -

© ENI Editions - All rigths reserved

Positionnement des serveurs têtes de ponts et des objets connexion  La figure ci­dessus illustre les points importants suivants :  ●

Chaque  site  possède  un  seul  et  unique  ISTG  qui  calcule  les  objets  connexion  utilisés  pour  les  communications intersites en IP (ou bien en SMTP). 

●

Chaque  contrôleur  fabrique  et  vérifie  ses  propres  objets  connexion  utilisés  pour  les  communications  intrasites en RPC sur IP. 

●

Chaque partition d’annuaire doit disposer d’un BHS par site. Le site de Paris dispose donc d’un BHS pour la  partition du domaine corpnet.com utilisé aussi pour les partitions de l’entreprise,  c’est­à­dire les partitions  de schéma et de configuration. 

●

Un  autre  contrôleur  de  domaine  ­  du  domaine  Mycorp.net,  joue  le  rôle  de  BHS  sur  cette  partition  uniquement.  Il  n’est,  en  effet,  pas  nécessaire  que  les  partitions  de  schéma  et  de  configuration  soient  répliquées par ailleurs. 

Sélection d’un serveur tête de pont privilégié Par défaut, le premier contrôleur de domaine installé sur un site joue automatiquement le rôle de serveur BHS pour  les partitions qu’il héberge. De fait, le serveur BHS de chaque site est sélectionné automatiquement. Vous pouvez  cependant  désigner  une  liste  de  serveurs  BHS  privilégiés.  Cette  opération  vous  permettra  de  garantir  une  plus  grande fiabilité des réplications d’annuaire intersites.  Notez aussi que dans le cas où un site devrait répliquer de nombreuses mises à jour, vous devrez vous assurer que  le BHS privilégié à des ressources suffisantes pour compresser, décompresser les données envoyées et reçues de  manière efficace.  © ENI Editions - All rigths reserved

- 17 -

Active Directory utilise un BHS à la fois. Par conséquent, dans le cas où le premier serveur BHS devient indisponible,  le prochain serveur BHS placé dans la liste des serveurs privilégiés sera alors utilisé. L’écran ci­dessous  illustre  la  déclaration des serveurs têtes de pont par rapport au protocole de transport utilisé. 

Déclaration du statut de serveur privilégié sur le transport IP  Vous  obtenez  cette  fenêtre  de  configuration  à  l’aide  de  la  console  de  gestion  MMC  Sites  et  services  Active  Directory  en  accédant  aux  propriétés  de  l’objet  serveur.  Dans  notre  exemple,  le  serveur  S1  est  donc  déclaré  comme étant un serveur tête de pont privilégié sur le protocole de transport intersites IP, pour les partitions qu’il  possède. Notez qu’il n’est pas impliqué dans les communications qui pourraient utiliser le transport intersites SMTP.  Les  serveurs  BHS  sont  sélectionnés  par  le  KCC  en  fonction  de  leur  ordre  d’arrivée  sur  le  site  Active  Directory. À partir du moment où vous déclarez le premier serveur BHS, à l’aide de la fenêtre ci­dessus, il  devient le seul et unique serveur tête de pont privilégié. Le KCC ne prendra pas l’initiative de nominer un autre  serveur BHS en cas de problème sur le serveur BHS S1. Bien sûr, si le site ne contient qu’un seul contrôleur, ce  n’est pas un problème. Par contre, si vous comptiez sur la sélection automatique d’un autre serveur BHS en cas  de problème sur celui­ci, la sélection n’aura pas lieu. Pour qu’elle puisse avoir lieu, vous devrez déclarer un autre  serveur tête de pont privilégié manuellement. Dans le cas où il y aurait plusieurs serveurs BHS privilégiés, le KCC  les choisira dans l’ordre dans lequel vous les avez déclarés serveurs têtes de pont privilégiés. 

h. Définition du générateur de topologie intersites  Sur chaque site, le serveur agissant en qualité d’ISTG, c’est­à­dire le générateur de topologie intersites, est promu  à ce statut par le KCC (pour rappel, le vérificateur de cohésion de connaissances ­ Knowledge Consistency Checker).  Il n’est donc pas nécessaire de réaliser quoi que ce soit.  L’ISTG disponible sur chaque site est responsable des opérations listées ci­dessous : 

- 18 -

1. 

Il sélectionne automatiquement un ou plusieurs contrôleurs de domaine pour devenir  des serveurs BHS. Ainsi, comme nous l’avons expliqué précédemment, la sélection d’un  autre contrôleur au statut de BHS sera réalisée automatiquement. 

2. 

Il invoque le KCC pour calculer la topologie de réplication et les objets de connexion  associés que le serveur de tête de pont utilisera pour communiquer avec les autres  serveurs de tête de pont des autres sites. 

© ENI Editions - All rigths reserved

Le  fait  d’installer  un  nouveau  contrôleur  de  domaine  fonctionnant  sous  Windows  Server  2008  n’implique  pas  qu’il  joue  le  rôle  de  générateur  de  topologie  intersites.  Vous  devrez  déclarer  le  nouveau  serveur  Windows Serveur 2008 comme nouveau serveur tête de pont privilégié pour le transport IP, ou SMTP, lorsque ce  transport est utilisé. 

Recommandations générales concernant la topologie de réplication Active Directory La  définition  et  la  mise  en  place  de  la  topologie  de  réplication  des  services  d’annuaires  Active  Directory  sont  des  points importants à plus d’un titre. Bien sûr, il en est de la stabilité de l’annuaire tout entier, mais il convient de ne  pas  oublier  les  services  connexes  tels  que  le  DNS,  les  services  d’authentification,  les  services  de  certificats,  les  serveurs Radius IAS et des applications d’entreprise telles que Microsoft Exchange Server.  Pour toutes ces raisons, et il y en a bien d’autres encore, il est recommandé de respecter le plus souvent possible  ces bonnes pratiques :  1. 

Disposez de plus d’un contrôleur de domaine par site : de cette manière, il n’existe pas  de point de défaillance. Cette considération devrait, si possible, être respectée même  lorsqu’il s’agit d’un site de taille moyenne. 

2. 

Positionnez un serveur de catalogue sur chaque site majeur : les recommandations  d’usage concernant les forêts Windows 2000 préconisaient de positionner un serveur  de catalogue par site Active Directory. Désormais, les contrôleurs de domaine  fonctionnant sous Windows Server 2003 et Windows Server 2008 permettent d’offrir au  site la gestion du cache de l’appartenance aux groupes universels. Vous pouvez ainsi  limiter le nombre de catalogues tout en garantissant de bonnes performances et une  tolérance de panne. Rappelez­vous que les informations sont cachées, par défaut,  pendant 8 heures. 

3. 

Prévoyez un plan de reprise des fonctions des maîtres d’opérations : créez un plan de  secours des fonctions vitales prises en charge par les maîtres d’opérations (FSMO). Pour  cela, nommez les serveurs vers lesquels vous tranférerez ou donnerez chacun des cinq  rôles de maîtres d’opérations. Vous pouvez, par exemple, créer des scripts manipulant  la commande Ntdsutil pour déclencher le déplacement ou forcer un contrôleur particulier  à prendre tel ou tel rôle. 

4. 

Veillez à sécuriser physiquement les contrôleurs de domaines déployés sur des sites  satellites : de nombreux exemples de problèmes de sécurité potentiels peuvent être  cités. Les plus importants concernent certainement les contrôleurs de domaine du  domaine racine de la forêt ainsi que les différents maîtres d’opérations. 

5. 

Modernisez les sites Active Directory les plus importants en mettant à niveau les  contrôleurs Windows 2000 Server et Windows Server 2003 vers Windows Server 2008.  Déplacez les rôles de maîtres d’opérations (FSMO) vers ces nouveaux contrôleurs, ainsi  que les rôles d’ISGT, vus précédemment ainsi que la fonction de GC (Global Catalog), si  nécessaire. 

© ENI Editions - All rigths reserved

- 19 -

Résolution des problèmes de réplication  La réplication ne se termine pas ou n’a pas lieu.  Les sites ne sont pas reliés par des liens de sites.  Aucun serveur de tête de pont n’existe dans le site.  La réplication est lente.  La topologie de site et la planification sont inefficaces.  Les ordinateurs clients reçoivent une réponse lente.  Aucun contrôleur de domaine n’est connecté dans le site.  Nombre insuffisant de contrôleurs de domaine.  La réplication augmente le trafic réseau.  Bande passante insuffisante.  La topologie de site est incorrecte.  Le KCC ne peut pas terminer la topologie.  Il y a une exception dans le KCC. 

© ENI Editions - All rigths reserved

- 1-

Contrôle des réplications urgentes en intersites  La  grande  majorité  des  systèmes  distribués  sont  contraints  de  disposer  de  certains  mécanismes  de  protection  qui  garantissent le bon fonctionnement de l’infrastructure. Il en est de même avec le service d’annuaire  Active  Directory,  notamment concernant les points ci­dessous :  ●

La  gestion  des  opérations  à  caractère  conflictuel  dans  un  environnement  multi  maître  distribué  grâce  aux  services offerts par les maîtres d’opérations simples (FSMO) de forêt et de domaines. Ce point a déjà été traité  précédemment. 

●

Les  problèmes  induits  par  la  latence  des  réplications  dans  des  réseaux  qui  peuvent  être  composés  de  centaines,  voire  de  plusieurs  milliers  de  sites.  C’est  sur  ce  point  que  les  "réplications  urgentes"  peuvent  solutionner bon nombre de problèmes. 

Ainsi, Active Directory est capable de gérer urgemment certains événements en contournant les réplications basées sur  les  notifications.  Les  réplications  urgentes  s’appuient  tout  naturellement  sur  le  protocole  RPC/IP.  En  fait,  il  s’agit  de  demandes de réplications notifiées mais envoyées immédiatement en ne tenant pas compte des délais fixés. Ainsi, la  période de pause on notify de 15 secondes pour les contrôleurs fonctionnant sous Windows Server 2003 et Windows  Server 2008 et de 5 minutes pour les contrôleurs fonctionnant sous Windows 2000 Server est ignorée. 

1. Événements pris en charge par les réplications urgentes  Par  défaut,  les  réplications  urgentes  ne  sont  dirigées  que  vers  les  contrôleurs  de  domaine  du  site  où  se  produit  l’opération. Les réplications urgentes ne traversent pas les liens de sites ou les connexions entre contrôleurs situés  sur des sites différents, à moins que vous n’ayez pris soin d’activer le support des notifications entre les sites. Dans  ce cas, les réplications urgentes transiteront sur le ou les liens intersites.  Les  contrôleurs  de  domaine  Active  Directory  fonctionnant  sous  Windows  2000  Server,  Windows  Server  2003  et  Windows Server 2008 déclenchent des réplications urgentes dans les cas listés ci­après.  ●

Blocage du compte après un certain nombre d’essais. Vous avez par exemple implémenté une stratégie trop  de blocage de comptes qui verrouille le compte des utilisateurs au bout de trois essais infructueux. 

●

Modification de la stratégie de verrouillage de comptes. 

●

Modification de la stratégie de mot de passe du domaine. 

●

Modifications des "secrets" de la LSA ­ Local Security Authority, tels que par exemple les mots de passe des  approbations de domaines. 

●

Modification du mot de passe d’un contrôleur de domaine. 

●

Modification de la machine qui accueille le maître d’opérations RID (RID Master FSMO). 

Le RID Master FSMO joue un rôle très important dans l’allocation des RID Pool sur les contrôleurs de domaines, en  particulier  lors  de  l’installation  d’un  nouveau  contrôleur,  lorsqu’il  ne  reste  dans  celui  que  20  %  des  500  RID  initialement  affectés  ou  encore  lorsqu’un  contrôleur  de  domaine  fait  l’objet  d’une  restauration.  En  effet,  dans  ce  dernier  cas,  le  RID  Pool  sera  purgé.  Pour  régénérer  un  nouveau  pool  de  RID,  la  machine  maître  d’opérations  RID  devra être pleinement opérationnelle.  Dans le cas où vos contrôleurs de domaine utilisent une valeur de "RID Block Size" différente de la valeur par défaut,  la demande du contrôleur est rejetée. Microsoft précise qu’il s’agit d’un problème et qu’il suffit remettre la valeur par  défaut, tel que cela est expliqué dans l’article "Domain controller has failed to obtain a new identifier pool". Le lien  http://support.microsoft.com/default.aspx?kbid=316201 vous permettra d’accéder à cet article. 

2. Verrouillage des comptes utilisateur et réplication urgente  Pour  faire  en  sorte  que  tout  contrôleur  de  domaine  d’un  grand  domaine  composé  de  plusieurs  centaines  de  contrôleurs de domaine puisse "instantanément" trouver la "meilleure bonne valeur", il fallait être certain de savoir  où la trouver ! 

© ENI Editions - All rigths reserved

- 1-

Ainsi,  les  contrôleurs  de  domaine  primaires  fonctionnant  sous  Windows  NT  Server  4.0,  Windows  2000  Server,  Windows Server 2003 et Windows Server 2008 de type maître d’opérations PDC Emaulator reçoivent les réplications  urgentes relatives aux blocages de comptes. Concernant Windows NT cela n’a rien d’étonnant puisque, quoi qu’il en  soit,  sous  Windows  NT  Server,  seule  la  machine  PDC  dispose  d’une  base  SAM  disponible  en  lecture  et  aussi  en  écriture.  La notion de maître d’opérations PDC Emulator demeure, quel que soit le mode de domaine. En effet, qu’un  domaine fonctionne en mode Windows 2000 mixte ou natif ou bien même en mode Windows Server 2003 ou  Windows  Server  2008,  il  est  toujours  possible  d’y  accueillir  des  ordinateurs  fonctionnant  sous  Windows  9x,  Windows NT 4.0, Windows 2000 et Windows XP Professionnel. Les ordinateurs dits "pré­Windows 2000" c’est­à­ dire Windows 9x et Windows NT 4.0 sont toujours obligés de solliciter les PDC pour réaliser les changements de  mots de passe des comptes d’ordinateurs et d’utilisateurs.  L’information de verrouillage d’un compte utilisateur est répliquée dans l’ordre spécifié ci­dessous :  ●

Le contrôleur de domaine possédant le rôle de maître d’opérations PDCE fait l’objet d’une réplication urgente. 

●

Le ou les contrôleurs de domaine du même domaine mais situés sur le même site que le maître d’opérations  PDCE font l’objet d’une réplication urgente. 

●

Le ou les contrôleurs de domaine du même domaine situés sur le même site que le contrôleur de domaine qui  a provoqué le blocage de comptes font l’objet d’une réplication urgente. 

●

Enfin,  le  ou  les  contrôleurs  de  domaine  du  même  domaine  qui  sont  situés  sur  des  sites  configurés  pour  permettre le passage des "notifications sur modification (et donc les réplications urgentes)" avec le site qui  contient le PDC Emulator ou le site sur lequel le compte utilisateur a fait l’objet du verrouillage. 

À  propos  du  verrouillage  des  comptes  utilisateur  :  quand  le  contrôleur  de  domaine  local  détecte  une  demande d’authentification avec un mauvais mot de passe, la demande d’authentification est réitérée vers le  contrôleur de domaine possédant le rôle de maître d’opérations PDC Emulator. De fait, c’est généralement sur ce  contrôleur particulier que le compte sera verrouillé. 

3. Changements de mots de passe et réplication Active Directory  La latence des systèmes de réplication utilisés avec les systèmes distribués est souvent au centre des problèmes de  maintenance  et  de  support.  En  effet,  des  informations  contradictoires  peuvent  être  disponibles  et  provoquer  de  nombreux  problèmes  particulièrement  concernant  la  sécurité  et  les  contrôles  d’accès.  Ainsi,  pour  apporter  une  solution  à  ces  inconvénients,  le  système  de  réplication  de  l’annuaire  Active  Directory  réalise  les  modifications  des  mots  de  passe  de  manière  spécifique  en  privilégiant  en  tout  premier  lieu  la  machine  maître  d’opérations  PDC  du  domaine.  Une opération de changement de mot de passe préfère donc la machine PDC Emulator sans aucune considération de  disponibilité  par  rapport  aux  liens  de  sites.  Ensuite,  la  réplication  du  nouveau  mot  de  passe  est  assurée  en  respectant les mécanismes que nous avons déjà présentés.  Comme  cela  est  déjà  le  cas  sous  Windows  NT  4.0,  si  le  contrôleur  utilisé  par  le  client  ne  dispose  pas  de  la  bonne  version du mot de passe, le contrôleur contactera le contrôleur de domaine possédant le rôle de maître d’opérations  PDC  Emulator.  Comme  il  s’agit  de  la  machine  qui  fait  office  de  contrôleur  privilégié  pour  ce  genre  d’opérations,  l’utilisateur est alors contrôlé comme il se doit.  Synchronisation urgente du mot de passe  Lorsqu’un  contrôleur  de  domaine  Windows  Server  2008,  Windows  Server  2003  ou  Windows  2000  Server  SP4  possédant le rôle de maître d’opérations PDC Emulator reçoit une demande de vérification de mot de passe pour le  compte  d’un  autre  contrôleur,  le  contrôleur  PDC  Emulator  réalise  une  synchronisation  urgente  du  mot  de  passe  du  compte utilisateur vers le contrôleur ayant transmis la demande. De cette manière, le contrôleur local dispose ­ sans  le moindre délai ­ de la "version la plus à jour" du mot de passe.  Changement de mots passe et sélection du PDC Emulator ou d’autres contrôleurs de domaine  Quel que soit le mode de fonctionnement des domaines Active Directory, les postes de travail Windows 9x, Windows  NT 4.0, Windows 2000, Windows XP Professionnel et Windows Vista sélectionnent toujours la machine possédant le  rôle de PDC Emulator, comme cela a toujours été le cas sous LAN Manager avec les domaines NT. Lorsque le domaine  atteint  le  niveau  fonctionnel  Windows  2000  natif  ou  supérieur  et  qu’il  n’est  donc  plus  possible  de  supporter  les  anciens  contrôleurs  secondaires  NT  4.0,  alors  si  le  PDC  Emulator  du  domaine  est  indisponible,  les  ordinateurs  Windows 2000, Windows XP Professionnel et Windows Vista pourront sélectionner un contrôleur local à leur site. 

- 2-

© ENI Editions - All rigths reserved

De cette manière, les sites distants ne sont plus "totalement dépendants" du site qui possède le PDC Emulator. La  mise à jour du contrôleur local permet de prendre en charge le changement de mot de passe sans erreur. Le mot de  passe  modifié  sera  ensuite  répliqué  en  respectant  la  topologie  de  réplication  et  le  PDC  Emulator  sera  mis  à  jour  lorsqu’il sera de nouveau disponible.  Changements de mots de passe et Client Active Directory  Pour réaliser une opération de changement de mot de passe, les postes de travail fonctionnant sous Windows 9x et  Windows NT n’ont, par défaut, aucune autre possibilité que de solliciter la machine PDC Emulator. Bien qu’il soit peu  judicieux d’investir dans des opérations de changement de configuration sur des ordinateurs certainement obsolètes,  le  Client  Active  Directory  (Directory  Service  Client  Pack)  permettra  à  ces  anciens  postes  de  travail  de  supporter  le  protocole  d’authentification  NTLM  v2  et  de  contacter  tout  contrôleur  de  domaine  Windows  2000  Server,  Windows  Server 2003 ou même Windows Server 2008. 

4. Gestion des "Bad Passwords" et optimisation des trafics  Si  certaines  des  connexions  réseau  intersites  sont  lentes,  il  pourra  être  intéressant  de  chercher  à  supprimer  ou  limiter la diffusion de certains flux.  Les contrôleurs Windows Server 2003 supportent un nouveau paramètre de stratégie qui vous permet de désactiver  l’usage du PDC Emulator lorsqu’une vérification de mot de passe est en échec via le contrôleur de domaine local.  Vous  trouverez  ce  paramètre  à  l’emplacement  suivant  :  Configuration  ordinateur/Modèles  d’administration/Système\Ouverture  de  session  réseau\Contacter  le  contrôleur  de  domaine  principal  lors  de  l’échec  de l’ouverture de session. Vous pouvez mettre en place ce paramètre à l’aide d’une stratégie de groupe.  Cette  contrainte  de  fonctionnement  empêchera  les  contrôles  de  mots  de  passe  des  contrôleurs  de  sites  vers  le  contrôleur PDC Emulator.  Lorsque  le  paramètre  Contacter  le  contrôleur  de  domaine  principal  lors  de  l’échec  de  l’ouverture  de  session est désactivé, le changement de mot de passe réalisé sur un contrôleur de domaine local à un site  sera répliqué normalement de manière non urgente. 

5. Activation des messages de notification de modifications sur un objet lien de site  Par  défaut,  les  objets  de  type  Lien  de  sites  n’autorisent  pas  le  passage  des  messages  de  notifications  habituellement utilisés avec les réplications intrasites.  Pour activer le support des messages de notification de modifications (change notification) sur un lien de site, vous  devrez  ­  à  l’aide  de  l’outil  ADSI  Edit  livré  avec  les  outils  de  support  de  Windows  Server  2003  ou  bien  la  version  intégrée aux composants de Windows Server 2008.  Généralement, les objets connexion sont créés par le KCC, lequel n’active pas le support des messages de  notifications.  Ce  point  est  normal  puisque  les  communications  intersites  sont  basées  sur  un  cycle  et  une  planification  et  pas  sur  les  notifications.  Vous  pourrez  cependant  créer  manuellement  vos  propres  connexions  IP  intersites et, dans ce cas précis, supporter les notifications.  De  plus,  la  modification  des  informations  contenues  dans  la  partition  de  configuration  nécessite  que  vous  soyez  membre du groupe  Administrateurs de l’entreprise ou que vous disposiez ­ via une opération de délégation ­ des  droits nécessaires sur l’objet à modifier.  Pour activer les notifications, procédez comme suit :  ■

À  l’aide  d’ADSI  Edit,  ouvrez  la  partition  de  Configuration  et  développez  :  CN= Configuration,DC=   Domaine_Racine_de la_Forêt puis CN=Sites. Ouvrez le conteneur CN=Inter­Site Transports, puis cliquez sur CN=IP. 

■

Sélectionnez  l’objet  lien  de  site  à  modifier  puis  ouvrez  ses  propriétés  (par  défaut,  il  s’agira  du  lien  de  site  par  défaut DEFAULTIPSITELINK). 

■

Tel que cela est spécifié sur l’écran ci­dessus, sélectionnez l’attribut options et remplacez la valeur  par  1. 

En fonction des paramètres à spécifier, la valeur de l’attribut « options »  correspondra à la combinaison de  chacune  des  valeurs  spécifiques.  Par  exemple,  si  la  valeur  décimale  du  paramètre  est  4,  convertissez  la 

© ENI Editions - All rigths reserved

- 3-

valeur  en  binaire,  c’est­à­dire  0100.  La  valeur  qui  permet  d’activer  les  notifications  est  1,  donc  en  binaire  0001.  Faites  une  opération  logique  de  OR,  tel  que  spécifié  ici  :  Valeur  au  départ  (4)  :  0100  ;  Valeur  pour  activer  les  notifications (1) : 0001 ; Valeur résultante du OR : 0101 et finalement la valeur 0101, soit 5 en décimal, combine les  paramètres  de  départ  plus  l’activation  des  notifications.  Procédez  de  la  même  manière  pour  combiner  d’autres  paramètres particuliers. 

6. Administration des mots de passe à l’aide de la DLL Acctinfo.dll  La DLL Acctinfo.dll est un composant additionnel livré dans le Kit de Ressources Techniques de Windows Server 2003.  Cette extension vous permet d’obtenir un nouvel onglet dans la console de gestion MMC Utilisateurs et ordinateurs  Active  Directory.  Cet  onglet  (Additional  Account  Info)  vous  permettra  d’obtenir  de  nombreuses  informations  très  intéressantes concernant le statut des comptes utilisateur.  DLL Acctinfo.dll et Windows Server 2008  Vous  pouvez  toujours  installer  la  DLL  Acctinfo.dll  sur  une  machine  disposant  des  outils  d’administration  Active  Directory sous Windows 2008 ou aussi sur une machine Windows Vista SP1 équipée des outils RSAT (Remote Server  Administration Tools).De plus, il vous sera possible de réaliser les opérations de déverrouillage et de changement de  mot de passe de manière très "conviviale et efficace", un point qui intéressera les administrateurs Active Directory.  Parmi les informations intéressantes, vous retrouverez :  ●

La date de modification du mot de passe de l’utilisateur, 

●

La date d’expiration du mot de passe de l’utilisateur, 

●

La date et l’heure de la dernière ouverture et fermeture de session réseau. 

●

La valeur du SID et du GUID de l’objet utilisateur. 

Ces informations ne sont pas directement disponibles au sein de l’annuaire car l’information est une valeur  qui  est  calculée  au  moment  où  elle  est  nécessaire.  La  DLL  Acctinfo.dll  réalise  ces  opérations  et  les  affiche  dans la fenêtre de propriétés Additional Account Info de l’objet utilisateur. 

Dans certains cas, il s’agit d’une information qui est stockée localement sur chaque contrôleur de domaine et  non répliquée globalement. C’est par exemple le cas des valeurs de date et d’heure de la dernière ouverture  et fermeture de session réseau. 

Installation de la DLL Acctinfo.dll La mise en œ uvre de la DLL Acctinfo.dll nécessite simplement son enregistrement. Copiez le fichier Acctinfo.dll dans  le  répertoire  C:\Windows\system32  puis  enregistrez  ce  composant  à  l’aide  de  la  commande  regsvr32  c:\Windows\system32\acctinfo.dll.  Une  fenêtre  de  confirmation  doit  vous  informer  que  l’opération  s’est déroulée  avec succès. La fenêtre ci­dessous montre les propriétés qui sont recensées par cette extension. 

- 4-

© ENI Editions - All rigths reserved

L’onglet Additional Account Info donne à l’administrateur de comptes toutes les informations intéressantes  Le  bouton  SID  History  vous  permettra  ­  lorsque  cette  information  existe  ­  de  consulter  la  valeur  de  l’attribut  SidHistory  utilisé  lors  des  consolidations  de  domaines  vers  l’Active  Directory.  L’outil  de  migration  de  comptes  d’utilisateurs,  d’ordinateurs,  de  groupes,  d’approbations,  de  profils  ADMT  2.0  ­  Active  Directory  Migration  Tool  ­  et  l’objet  COM  clonepr.dll  (CloneSecurityPrincipal  COM  object)  inclus  dans  les  outils  de  support  de  Windows  2000,  Windows  XP  et  Windows  Server  2003  vous  permettront  de  cloner  des  principes  de  sécurité  vers  des  domaines  Windows 2000 natif ou des domaines fonctionnant en niveau fonctionnel Windows Server 2003. 

La fonction "Set PW on Site DC" permet de changer le mot de passe directement sur le contrôleur de domaine du  site client  Le bouton Set PW On Site DC vous permet de diriger l’opération de changement de mot de passe. Par défaut, cette  fenêtre  sélectionne  le  site  du  contrôleur  actuellement  utilisé  par  l’administrateur.  Le  champ  User’s Computer  vous  permet,  en  cliquant  sur  le  bouton  Just  Find  Site  de  sélectionner  le  contrôleur  de  domaine  utilisé  par  le  poste  de 

© ENI Editions - All rigths reserved

- 5-

travail  de  l’utilisateur. Cette fonction est très pratique pour modifier le mot de passe de l’utilisateur  lorsque  l’on ne  sait pas précisément où est situé celui­ci.  L’écran ci­dessous synthétise les caractéristiques du compte utilisateur. Vous pouvez ainsi, via le bouton Domain PW  Info, obtenir les paramètres issus des stratégies qui s’appliquent sur l’objet utilisateur. 

Stratégies de comptes considérées pour l’utilisateur sélectionné 

À propos de l’attribut userAccountControl La  fenêtre  principale  offerte  par  Acctinfo.dll  affiche  la  valeur  de  l’attribut  Active  Directory  userAccountControl.  La  valeur de cet attribut est souvent inscrite dans les messages d’audit de sécurité en tant que "raison" de l’échec de  telle ou telle opération. Il convient ensuite de décoder la valeur, chose qui n’est guère facile.  L’écran ci­après montre l’interprétation de la valeur. Dans cet exemple, il est mis en évidence que le mot de passe ne  peut pas expirer et que l’utilisateur doit utiliser une carte à puce pour s’authentifier. Vous avez en quelques secondes  découvert la cause du problème d’authentification de l’utilisateur ! 

Décodage de l’attribut userAccountControl à l’aide du bouton User Account Control. 

- 6-

© ENI Editions - All rigths reserved

Critères  d’architecture  à  considérer  pour  définir  la  topologie  de  réplication intersites  La création de l’infrastructure de sites qui formera la topologie de réplication Active Directory nécessite un minimum de  planification.  Cependant,  il  se  peut  que  vous  ne  disposiez  pas  de  toutes  les  informations  nécessaires  pour  créer  la  meilleure topologie de sites au moment où vous commencerez réellement le déploiement de l’Active Directory.  Ce  point  n’est pas toujours dramatique et cela dépendra bien sûr souvent de l’importance des contraintes imposées  par  l’infrastructure  réseau.  Quoi  qu’il  en  soit,  il  sera  toujours  temps  de  modifier  ou  de  faire  évoluer  une  première  ébauche de l’infrastructure de sites suite à de nouvelles informations relatives au réseau physique. Il pourra en être de  même pour la mise en œ uvre prochaine d’une application intégrée au sein de l’annuaire Active Directory.  Les points ci­dessous sont les éléments de caractérisation et de définition Active Directory que vous devrez obtenir et  utiliser pour définir votre infrastructure de sites. Pour pouvoir commencer la conception de votre infrastructure de site,  réunissez les informations ci­dessous :  ●

La liste de tous les sites et leur emplacement, 

●

La topologie et les liens existants ainsi que les bandes passantes nominales et réellement disponibles, 

●

L’emplacement "idéal" des serveurs d’infrastructures tels que les serveurs DNS, les contrôleurs de domaines,  les catalogues globaux, 

●

Un inventaire des postes de travail et versions de systèmes d’exploitation pour chaque site géographique. 

En fonction de ces informations, vous pourrez définir une première architecture qui devra comprendre :  ●

la liste des liens de sites et ponts de liens de sites ; 

●

la localisation des contrôleurs de domaine sur les sites ; 

●

la localisation des catalogues globaux sur les sites ; 

●

la localisation des maîtres d’opérations sur les sites ; 

●

l’utilisation des liens de sites pour connecter les sites ; 

●

L’usage éventuel du protocole SMTP à la place du transport IP. Moyennant certaines restrictions, vous pouvez  utiliser le protocole SMTP (Simple Mail Transfer Protocol) pour effectuer la réplication vers les sites qui n’ont pas  de connexion IP (Internet Protocol) directe ou fiable. 

●

Les contraintes de sécurité imposées par les pare­feu vis­à­vis de l’infrastructure Active Directory (Réplication  d’annuaire et réplication du SYSVOL) 

La  réplication  intersites  dans  les  environnements  sécurisés  (pare­feu,  VPN,  etc.)  doit  faire  l’objet  de  configurations  particulières.  Pour  plus  d’informations,  consultez  le  document  Active  Directory  in  Networks  Segmented by Firewalls publié à l’adresse : http://www.microsoft.com/downloads/details. aspx?familyid=c2ef3846­ 43f0­4caf­9767­a9166368434e&displaylang=en 

Modélisation de la topologie des sites La  topologie  du  réseau  d’une  organisation  reflète  presque  toujours  ses  besoins  en  terme  de  communications.  Dans  certaines entreprises, il est nécessaire que l’organisation et l’efficacité du travail en équipe ne soient pas perturbées  lorsque  les  utilisateurs  travaillent  dans  des  endroits  géographiquement  éloignés.  Il  se  peut  aussi  que  certaines  compagnies soient composées d’un grand nombre de sites satellites plus petits connectés en étoile. Chaque entreprise  aura  bien  sûr  ses  propres  particularités  mais,  quoi  qu’il  en  soit,  elle  sera  basée  sur  des  modèles  de  topologie  classiques tels que ceux qui sont présentés ci­dessous :  ●

les anneaux ; 

© ENI Editions - All rigths reserved

- 1-

●

les étoiles ; 

●

des chaînages plus complexes basés sur ces topologies de base. 

La figure ci­dessous illustre ces grands types de topologie. 

Les communications basées sur différents modèles de topologie 

- 2-

© ENI Editions - All rigths reserved

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 En quoi les services de réplication intégrés à Active Directory sont­ils fondamentaux ?  2 Que signifie le terme Partition ?  3 De quel type sont les informations qui doivent être répliquées au sein d’un domaine donné ?  4 De quel type sont les informations qui doivent être répliquées entre des domaines d’une même forêt ?  5 Qu’entend­on par Partitions de l’annuaire d’applications ?  6 Quels types d’objets peuvent être stockés dans une partition de l’annuaire d’application ?  7 Sur quels contrôleurs de domaine d’une forêt les partitions de l’annuaire d’applications peuvent­elles être  répliquées ?  8 Quel outil faisant partie du système Windows Server 2003 ou Windows Server 2008 permet de créer des  partitions de l’annuaire d’applications ?  9 Qu’entend­on par Réplication Multimaîtres ?  10 Que se passe­t­il lorsque deux administrateurs modifient les membres d’un même groupe dans une forêt  fonctionnant en mode Windows 2000 ?  11 Que se passe­t­il lorsque deux administrateurs modifient les membres d’un même groupe dans une forêt  fonctionnant dans le niveau fonctionnel Windows Server 2003 ou Windows Server 2008 ?  12 Active Directory gère deux grands types de réplications. Lesquelles ?  13 Qu’appelle­t­on des réplications urgentes ?  14 Quels protocoles peuvent être utilisés pour répliquer les données de l’annuaire Active Directory ?  15 Est­il possible de répliquer la partition de domaine de deux contrôleurs de domaine du même domaine à l’aide  du protocole SMTP ?  16 Quelle commande vous permet de forcer une réplication Active Directory ?  17 Quelle est la latence de réplication au sein d’un site Active Directory comprenant des contrôleurs de domaine  Windows Server 2003 et/ou Windows Server 2008 ?  18 Où est stockée l’information qui permettra aux contrôleurs de domaine de répliquer correctement les  informations ?  19 Comment la topologie de réplication intra site est­elle construite ?  20 Quels sont les deux types de partenaires de réplication intra site ?  21 Quel est le rôle d’un objet site au sein de la topologie de réplication de la forêt Active Directory ?  22 Quel est le nom du lien de site par défaut créé lors de l’installation de l’Active Directory ?  23 Quel outil est utilisé pour gérer la topologie de réplication Active Directory ?  24 Quel est le rôle d’un pont de liaisons ?  25 Pourquoi n’est­il pas utile de créer des ponts de liaisons dans la configuration par défaut Active Directory ?  26 Que se passe­t­il si vous créez des Ponts de liaisons alors que le protocole IP relie tous les sites ?  27 Quel est le rôle d’un serveur tête de pont ?  28 Est­il possible d’avoir plusieurs serveurs BHS par site ?  29 Quel outil livré avec les Outils de support de Windows Server 2003 pouvez­vous utiliser pour surveiller en  temps réel les réplications Active Directory et forcer les réplications en intersites ?  30 Quels sont les outils Microsoft qui permettent de gérer la réplication 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  © ENI Editions - All rigths reserved

- 1-

point.  Nombre de points /30  Pour ce chapitre, votre score minimum doit être de 23 sur 30. 

3. Réponses  1 En quoi les services de réplication intégrés à Active Directory sont­ils fondamentaux ?  Les mécanismes de réplication permettent de garantir la stabilité de l’information offerte par les services d’annuaires  Active Directory en tout point du réseau.  2 Que signifie le terme Partition ?  Le  terme  partition  signifie  Partition  de  l’annuaire.  La  base  de  données  Active  Directory  est  composée  d’au  minimum  trois  partitions.  Le  moteur  de  réplication  Active  Directory  réplique  des  objets  et  attributs  d’objets,  lesquels  sont  contenus  dans  des  partitions.Lorsqu’il  s’agit  de  contrôleurs  de  domaine  fonctionnant  sous  Windows  2000  Server,  la  base Active Directory ne peut contenir que les trois partitions par défaut, auxquelles il convient d’ajouter les partitions  liées  à  la  fonction  de  catalogue  global.  Les  contrôleurs  Windows  Server  2003  et  Windows  Server  2008  peuvent  accueillir des partitions supplémentaires appelées partitions de l’annuaire d’application.  3 De quel type sont les informations qui doivent être répliquées au sein d’un domaine donné ?  Dans un domaine, les partitions de schéma, de configuration et de domaine doivent être répliquées.  4 De quel type sont les informations qui doivent être répliquées entre des domaines d’une même forêt ?  Au sein de la forêt, seules les partitions de schéma, de configuration et liées à la fonction de catalogue global doivent  être répliquées.  5 Qu’entend­on par Partitions de l’annuaire d’applications ?  Il s’agit d’un nouveau type de partitions supporté sur les contrôleurs de domaine fonctionnant sous Windows Server  2003.  Ces  partitions  sont  particulièrement  adaptées  pour  les  données  applicatives.  Ainsi,  une  partition  de  l’annuaire  d’application peut stocker des données propres à une application. De plus ces données peuvent être dynamiques car  soumises à une durée de vie (TTL).  6 Quels types d’objets peuvent être stockés dans une partition de l’annuaire d’application ?  Les partitions de l’annuaire d’applications peuvent stocker tout type d’objet, à l’exception des entités de sécurité. Notez  que ces données ne sont pas répliquées dans les catalogues.  7 Sur quels contrôleurs de domaine d’une forêt les partitions de l’annuaire d’applications peuvent­elles être  répliquées ?  Sur tout contrôleur de domaine de la forêt fonctionnant sous Windows Server 2003 ou Windows Server 2008.  8 Quel outil faisant partie du système Windows Server 2003 ou Windows Server 2008 permet de créer des  partitions de l’annuaire d’applications ?  Ntdsutil.  Vous  pouvez  utiliser  NTDSUTIL,  ADIS  Edit  ou  aussi  d’autres  outils  ou  commandes  supportant  le  protocole  LDAP. La méthode la plus pratique consiste à utiliser NTDSUTIL.  9 Qu’entend­on par Réplication Multimaîtres ?  Il  s’agit  du  modèle  de  réplication  utilisé  par  Active  Directory.  Dans  ce  modèle  n’importe  quel  contrôleur  de  domaine  accepte et réplique les modifications de l’annuaire. Par définition, tous les contrôleurs dispose des données disponibles  en lecture et aussi en écriture.  10 Que se passe­t­il lorsque deux administrateurs modifient les membres d’un même groupe dans une forêt  fonctionnant en mode Windows 2000 ?  Un conflit de réplication se produira puisque le même attribut aura été modifié dans le même cycle de réplication. La  dernière modification l’emportera et l’opération réalisée avant sera perdue.  11 Que se passe­t­il lorsque deux administrateurs modifient les membres d’un même groupe dans une forêt  fonctionnant dans le niveau fonctionnel Windows Server 2003 ou Windows Server 2008 ?  Lorsque  la  forêt  fonctionne  en  mode  Windows  Server  2003  ou  Windows  Server  2008,  la  réplication  LVR  est  opérationnelle. Les deux modifications seront donc prises en compte, indépendamment l’une de l’autre.  12 Active Directory gère deux grands types de réplications. Lesquelles ?  Active Directory utilise la réplication intra site pour répliquer rapidement les données d’un site tandis que la réplication  inter sites sera utilisée pour répliquer les données entre les sites en fonction du temps et d’un planning hebdomadaire.  13 Qu’appelle­t­on des réplications urgentes ?  Il s’agit de réplications concernant les mots de passe des utilisateurs, des ordinateurs, des approbations de domaines,  des changements réalisés dans la stratégie de comptes et de verrouillage de comptes du domaine.  14 Quels protocoles peuvent être utilisés pour répliquer les données de l’annuaire Active Directory ?  Les  réplications  intra  site  utilisent  les  RPC  sur  IP.  Les  réplications  inter  sites  utilisent  le  protocole  IP  ou  le  protocole 

- 2-

© ENI Editions - All rigths reserved

SMTP.  15 Est­il possible de répliquer la partition de domaine de deux contrôleurs de domaine du même domaine à l’aide  du protocole SMTP ?  Non.  Le  protocole  SMTP  ne  peut  être  utilisé  que  pour  répliquer  les  partitions  de  schéma,  de  configuration  et  de  catalogues.  16 Quelle commande vous permet de forcer une réplication Active Directory ?  Repadmin.  Cette  commande  est  disponible  de  base  sous  Windows  Server  2008.  Pour  en  disposer  sur  un  serveur  Windows Server 2003, vous devez installer les Outils de Support de Windows Server 2003.  17 Quelle est la latence de réplication au sein d’un site Active Directory comprenant des contrôleurs de domaine  Windows Server 2003 et/ou Windows Server 2008 ?  La latence de réplication est inférieure à une minute car les contrôleurs de domaine fonctionnant sous Windows Server  2003  respectent  une  notification  de  15  secondes.  Généralement,  entre  deux  contrôleurs  de  domaines  "voisins"  elle  aura lieue dans au plus 15 secondes. Les contrôleurs Windows 2000 Server implémente un délai de 5 minutes (300  secondes).Notez  que  pour  implémenter  le  timing  de  15  secondes,  la  forêt  doit  être  opérationnelle  dans  le  niveau  fonctionnel Windows Server 2003 ou Windows Server 2008.  18 Où est stockée l’information qui permettra aux contrôleurs de domaine de répliquer correctement les  informations ?  La topologie de réplication contient l’ensemble des informations utiles et est stockée dans la partition de configuration  de la forêt.  19 Comment la topologie de réplication intra site est­elle construite ?  Chaque contrôleur de domaine membre d’un site participe à sa création. Le composant responsable de cette opération  sur chaque site est appelé KCC.  20 Quels sont les deux types de partenaires de réplication intra site ?  Les partenaires directs et les partenaires indirects.  21 Quel est le rôle d’un objet site au sein de la topologie de réplication de la forêt Active Directory ?  Le site est une zone de connectivité rapide à laquelle on associe un ou plusieurs réseaux ou sous­réseaux IP.  22 Quel est le nom du lien de site par défaut créé lors de l’installation de l’Active Directory ?  DefaultIpSiteLink.  23 Quel outil est utilisé pour gérer la topologie de réplication Active Directory ?  La  console  de  gestion  MMC  Sites  et  services  Active  Directory.  Sur  les  contrôleurs  de  domaine  fonctionnant  sous  Windows  Server  2008,  vous  pouvez  aussi  utiliser  la  nouvelle  console  Gestionnaire  de  serveur/Rôles/Services  de  domaine Active Directory/Sites et services Active Directory.  24 Quel est le rôle d’un pont de liaisons ?  Un pont de liaison permet de rassembler plusieurs liens de sites. Ainsi, les réplications peuvent avoir lieues entre les  sites en passant par plus d’un lien de sites.  25 Pourquoi n’est­il pas utile de créer des ponts de liaisons dans la configuration par défaut Active Directory ?  Par défaut, le paramètre Relier tous les liens du site est activé au niveau du protocole IP dans le container Inter­Site  Transports.  26 Que se passe­t­il si vous créez des Ponts de liaisons alors que le protocole IP relie tous les sites ?  Les composants KCC et l’ISTG ignorent les Ponts de liaisons.  27 Quel est le rôle d’un serveur tête de pont ?  Le premier contrôleur de domaine d’un site joue le rôle de KCC et d’ISTG. Le module ISTG désigne le premier contrôleur  du site (c’est­à­dire lui­même) lequel devient responsable des communications vers les autres sites vers lequel il est  connecté. Le serveur tête de pont distant reçoit les modifications et les réplique vers les contrôleurs de son site.  28 Est­il possible d’avoir plusieurs serveurs BHS par site ?  Oui,  si  le  site  contient  des  contrôleurs  de  domaines  différents.  Un  serveur  tête  de  pont  ne  prend  en  charge  que  les  communications qu’il est lui­même capable de gérer. Par exemple, un BHS pour le domaine europe.company.com peut  transférer  les  modifications  pour  les  partitions  de  ce  domaine  et  aussi  du  schéma,  de  la  configuration  et  éventuellement des partitions de catalogues. Il ne pourra pas assurer la transmission des données d’un autre domaine  de la forêt.  29 Quel outil livré avec les Outils de support de Windows Server 2003 pouvez­vous utiliser pour surveiller en  temps réel les réplications Active Directory et forcer les réplications en intersites ?  L’outil Active Directory Replication Monitor (Replmon). L’outil Replmon n’est disponible ni sous Windows Server 2003, ni  sous  Windows  Server  2008.  Pour  en  disposer,  vous  pouvez  installer  les  Outils  de  Support  de  Windows  Server  2003  SP1.  30 Quels sont les outils Microsoft qui permettent de gérer la réplication Active Directory ?  La  console  de  gestion  MMC  Sites  et  services  Active  Directory  (Dssites.msc).  L’outil  de  la  ligne  de  commande  Repadmin.exe et l’outil graphique Active Directory Replication Monitor (Replmon).  © ENI Editions - All rigths reserved

- 3-

- 4-

© ENI Editions - All rigths reserved

Travaux pratiques  1. Recherche des serveurs maîtres d’opérations  L’objectif  de  cette  opération  consiste  à  identifier  les  contrôleurs  de  domaine  Windows  Server  2003  ou  Windows  Server 2008 qui détiennent les 5 rôles de maîtres d’opérations disponibles au sein d’une forêt Active Directory.  Pour localiser le maître de schéma, procédez de la manière suivante :  1. 

Sur un serveur fonctionnant sous Windows Serveur 2008 jouant le rôle de contrôleur de  domaine vous disposez des outils d’administration Active Directory. Si le serveur ne joue  pas le rôle de contrôleur de domaine, vous pouvez installer les fonctionnalités  d’administration souhaitées à l’aide du Gestionnaire de serveur/ Ajouts des  fonctionnalités. Pour utiliser l’outil Schéma Active Directory, n’oubliez pas au préalable de  taper la commande regsvr32 schmmgmt.dll.  Enfin, si vous réalisez cette opération sous Windows Server 2003, assurez­vous que les  Outils d’administration sont installés sur l’ordinateur que vous souhaitez utiliser. Si tel  n’est pas le cas et que vous utilisez un serveur Windows Server 2003, installez le  package Adminpak.msi présent dans le répertoire %Systemroot%\System32. Dans le  cas où vous utiliseriez un ordinateur fonctionnant sous Windows XP Professionnel  membre du domaine, alors connectez­vous à distance sur \\serverX\admin$\system32 ou  faites référence au répertoire i386 du CD­Rom d’installation de Windows Ser­ver 2003. 

2. 

Exécutez une console de gestion MMC. Dans le menu Fichier, cliquez sur  Ajouter/Supprimer un composant logiciel enfichable puis cliquez sur le bouton Ajouter.  Dans la liste, sélectionnez le composant Schéma Active Directory, puis cliquez à  nouveau sur Ajouter puis sur Fermer. 

3. 

Faites un clic droit sur Schéma Active Directory, puis cliquez sur Maître d’opérations. La  fenêtre affiche le contrôleur de schéma actuellement en ligne. 

Pour localiser le maître d’attribution de noms de domaines, procédez de la manière suivante :  1. 

Exécutez la console de gestion MMC Domaines et approbations Active Directory. 

2. 

Faites un clic droit sur Domaines et approbations Active Directory, puis cliquez sur  Maître d’opérations. La fenêtre affiche le contrôleur de maître d’attribution de noms de  domaines actuellement en ligne. 

Pour localiser l’émulateur de contrôleur de domaine principal, le maître de RID et le maître d’infrastructure, procédez  de la manière suivante :  1. 

Exécutez la console de gestion MMC Utilisateurs et ordinateurs Active Directory. 

2. 

Faites un clic droit sur Utilisateurs et ordinateurs Active Directory, puis cliquez sur  Maître d’opérations. La fenêtre affichera les trois onglets liés aux trois rôles de domaine  et spécifiera quels sont les maîtres d’opérations en ligne. 

2. Transfert d’un rôle de maître d’opérations  L’objectif de cette opération consiste à transmettre une fonction de Maître d’opérations  d’un ordinateur à un autre.  Cette opération pourra s’avérer utile en cas de maintenance de l’un des contrôleurs de domaine jouant un rôle de  maître d’opérations.  Notre  exercice  prendra  pour  exemple  le  maître  d’opérations  Emulateur  de  contrôleur  de  domaine  principal.  Ce  cas  sera certainement le plus pertinent pour ceux qui ont encore des ordinateurs fonctionnant sous Windows NT 4.0.  Pour  effectuer  cette  procédure,  vous  devez  être  membre  du  groupe  Admins  du  domaine  ou  du  groupe  Administrateurs de l’entreprise dans Active Directory. 

1. 

Ouvrez la console Utilisateurs et ordinateurs Active Directory. 

2. 

Dans l’arborescence de la console, cliquez avec le bouton droit sur Utilisateurs et  ordinateurs Active Directory, puis cliquez sur Se connecter au contrôleur de domaine. 

© ENI Editions - All rigths reserved

- 1-

3. 

Renseignez le nom du contrôleur de domaine vers lequel vous souhaitez réaliser  l’opération de transfert. 

4. 

Dans l’arborescence de la console, cliquez avec le bouton droit sur Utilisateurs et  ordinateurs Active Directory, pointez sur Toutes les tâches, puis cliquez sur Maîtres  d’opérations. 

5. 

Pour transférer le rôle, cliquez sur l’onglet PDC puis sur Modifier. 

Vous  venez  de  réaliser  le  transfert  du  rôle  de  Maître  d’opérations  de  type  PDC  Emulator  de  votre  contrôleur  de  domaine vers un autre contrôleur de votre domaine. 

3. Prise de rôle d’un maître d’opérations  L’objectif  de  cette  opération  consiste  à  prendre  possession  de  force  d’une  fonction  de  Maître  d’opérations.  Cette  opération pourra s’avérer utile en cas de maintenance de l’un des contrôleurs de domaine jouant un rôle de maître  d’opérations.  Notre  exercice  prendra  pour  exemple  le  maître  d’opérations  Emulateur  de  contrôleur  de  domaine  principal.  Pour  effectuer  cette  procédure,  vous  devez  être  membre  du  groupe  Admins  du  domaine  ou  du  groupe  Administrateurs de l’entreprise dans Active Directory. 

1. 

Ouvrez une invite de commandes puis tapez la commande : ntdsutil. 

2. 

À l’invite "ntdsutil", tapez : roles. 

3. 

À l’invite de maintenance des rôles FSMO, tapez : connexions. 

4. 

À l’invite des connexions serveur, tapez : conn to serv Nom_du_DC. 

5. 

Une fois connecté et authentifié, tapez : quit. 

6. 

À l’invite de maintenance des rôles FSMO, tapez : seize PDC, puis validez la fenêtre  graphique de confirmation à l’aide du bouton OK.  La  prise  de  force  d’un  rôle  de  maître  d’opérations  ne  devrait  être  réalisée  que  lorsqu’il  n’y  a  pas  d’autre  solution. Microsoft précise que la machine originale ne devrait plus être remise en route sur le réseau. 

Vous venez de réaliser la prise de possession de force du rôle de Maître d’opérations de type PDC Emulator de votre  contrôleur de domaine vers un autre contrôleur de votre domaine. 

4. Création d’un site Active Directory et déplacement d’un serveur  L’objectif  de  cette  opération  consiste  à  créer  un  nouveau  site  Active  Directory.  Cette  opération  permettra  à  l’entreprise de disposer d’une meilleure localisation des services ainsi que d’un meilleur contrôle des réplications.  Pour  exécuter  cette  procédure,  vous  devez  être  membre  du  groupe Admins  du  domaine (dans le domaine  racine  de  la  forêt)  ou  du  groupe  Administrateurs  de  l’entreprise  dans  Active  Directory,  ou  alors  les  droits  appropriés doivent vous avoir été confiés par délégation. 

1. 

Ouvrez la console de gestion MMC Sites et services Active Directory. Vous pouvez aussi  accéder au composant Sites et services Active Directory via le Gestionnaire de  serveur/Rôles/Services de domaine Active Directory/Sites et services Active Directory. 

2. 

Cliquez avec le bouton droit sur le dossier Sites, puis cliquez sur Nouveau site. 

3. 

Dans la zone Nom, tapez le nom du nouveau site. 

4. 

Sélectionnez un objet de liaison de sites puis cliquez sur OK.  Il est recommandé que les noms déclarés au niveau des sites soient tous déclarés avec un nom DNS. Si tel  n’est  pas  la  cas,  Microsoft  précise  que  l’accès  au  site  Active  Directory  sera  subordonné  à  l’utilisation  d’un 

- 2-

© ENI Editions - All rigths reserved

serveur utilisant le service DNS de Windows Server 2003 ou Windows Server 2008. 

Les sites Active Directory sont bien entendu des objets Ldap. Cependant, les noms donnés aux sites doivent  aussi  respecter  les  règles  de  nommage  du  DNS.  En  effet,  n’oubliez  pas  qu’un  site  Active  Directory  est  un  objet Ldap qui possède des données directement situées en dehors de son champ d’action. Ainsi, le nom du site  doit respecter le nom du domaine DNS et vice versa. 

Pour déplacer un contrôleur de domaine vers un autre site, procédez comme suit :  1. 

Dans l’arborescence de la console de gestion MMC Sites et services Active Directory,  positionnez­vous sur Premier­Site­par­defaut/Servers/Votre­serveur. 

2. 

Faites un clic droit et cliquez sur Déplacer. 

3. 

Sélectionnez le site qui devra contenir le serveur, puis validez en cliquant sur OK. 

5. Création des sous­réseaux IP Active Directory  L’objectif  de  cette  opération  consiste  à  déclarer  et  associer  les  différents  réseaux  et/ou  sous­réseaux  TCP/IP  dans  l’infrastructure de sites 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)  ou  du  groupe  Administrateurs  de  l’entreprise  dans  Active  Directory,  ou  alors  les  droits  appropriés doivent vous avoir été confiés par délégation. 

1. 

Ouvrez la console de gestion MMC Sites et services Active Directory. 

2. 

Dans l’arborescence de la console, déplacez­vous sur le container Sous­réseaux, puis  cliquez sur Nouveau sous­réseau. 

3. 

Dans la zone Adresse, tapez l’adresse IP du sous­réseau. 

4. 

Dans la zone Masque, tapez le masque de sous­réseau en vigueur. 

5. 

Dans la zone Sélectionnez un objet du site pour ce sous­réseau, associez le site  souhaité à ce sous­réseau, puis validez avec OK. 

L’effet de ce nommage automatique est visible, après coup, lorsque vous consultez les propriétés du site concerné  par  le  dit  sous­réseau.  La  figure  ci­dessous  montre  que  sur  le  site  de  Vancouver  les  sous­réseaux  sont  172.16.0.0/19, 172.16.128.0/19, 172.16.64.0/19. 

© ENI Editions - All rigths reserved

- 3-

  Vous  venez  de  créer  des  sous­réseaux  IP  dans  Active  Directory  et  de  les  associer  à  des  objets  Sites.  Ces  sous­ réseaux sont indispensables au bon fonctionnement de la sélection des contrôleurs de domaine. 

6. Ajout d’un serveur de catalogue sur un site  L’objectif  de  cette  opération  consiste  à  ajouter  un  nouveau  catalogue  global  au  sein  de  la  forêt  Active  Directory.  Il  s’agit d’une opération d’infrastructure importante puisqu’elle concerne la configuration, la topologie de réplication et  les volumes des flux de réplication en transit sur l’inter­réseau.  Pour exécuter cette procédure, vous devez être membre du groupe Admins du domaine (dans le domaine du  contrôleur  de  domaine  sélectionné)  ou  du  groupe  Administrateurs  de  l’entreprise,  ou  alors  les  droits  appropriés doivent vous avoir été confiés par délégation. 

- 4-

1. 

Ouvrez la console Sites et services Active Directory. 

2. 

Dans l’arborescence de la console, cliquez sur le contrôleur de domaine sur lequel vous  voulez activer ou désactiver la fonction de catalogue global. 

3. 

Dans le volet d’informations, cliquez avec le bouton droit sur NTDS Settings, puis cliquez  sur Propriétés. 

© ENI Editions - All rigths reserved

 

4. 

Cochez la case Catalogue global pour activer le catalogue global, ou supprimez la coche  si vous souhaitez le désactiver. 

5. 

Cliquez sur OK. 

Le  contrôleur  de  domaine  nouvellement  promu  ne  créera  les  enregistrements  DNS  relatifs  au  rôle  de  catalogue global que lorsqu’il aura reçu en réplication l’ensemble des partitions de domaine de la forêt. Par  conséquent,  soyez  vigilant  quant  aux  éventuelles  erreurs  de  résolutions  DNS  qui  pourraient  empêcher  la  bonne  réplication d’une partition et empêcher la disponibilité réelle du nouveau catalogue global.  Vous venez de créer un catalogue global au sein de votre forêt Active Directory sur un contrôleur de domaine donné.  Notez que vous devrez patienter le temps que toutes les partitions soient répliquées. 

7. Activation de la mise en cache de l’appartenance des groupes universels sur un site  L’objectif de cette opération consiste à activer la mise en cache de l’appartenance des groupes universels sur un site  donné. Il s’agit d’une opération d’infrastructure qui permettra de limiter la dépendance existante entre les contrôleurs  de domaine locaux à un site et la nécessité de contacter un catalogue global pour authentifier les utilisateurs dans un  domaine fonctionnant en mode Windows 2000 natif, Windows Server 2003 ou Windows Server 2008.  Pour  pouvoir  exécuter  cette  procédure,  vous  devez  être  membre  du  groupe  Admins  du  domaine  (dans  le  domaine  racine  de  la  forêt)  ou  Administrateurs  de  l’entreprise  dans  Active  Directory,  ou  bien  les  droits  appropriés doivent vous avoir été confiés par délégation. 

1. 

Ouvrez la console Sites et services Active Directory. 

2. 

Dans l’arborescence de la console, cliquez sur le site sur lequel vous souhaitez activer la  mise en cache des appartenances à un groupe universel. 

3. 

Dans le volet d’informations, cliquez avec le bouton droit sur Paramètres de site NTDS,  puis cliquez sur Propriétés. 

4. 

Activez la case à cocher Activer la mise en cache de l’appartenance au groupe  © ENI Editions - All rigths reserved

- 5-

universel.  5. 

Dans la liste Actualiser le cache de, cliquez sur un site à partir duquel ce site actualisera  son cache, ou acceptez <Par défaut> pour actualiser le cache à partir du site le plus  proche comportant un catalogue global. 

 

6. 

Validez. 

Cette fonctionnalité ne concerne que le cache des objets de type groupes universels dans le cadre de leur  utilisation lors de l’ouverture de session réseau au sein d’un domaine Active Directory. Les recherches Ldap  sur tous les objets de l’annuaire sont toujours réalisées vers les catalogues globaux. 

Pour activer cette fonctionnalité, il est nécessaire de disposer sur le site d’au moins un contrôleur de domaine  fonctionnant sous Windows Server 2003 ou Windows Server 2008. 

8. Création d’un objet de connexion intrasite  L’objectif  de  cette  opération  consiste  à  créer  un  nouvel  objet  de  connexion  intrasite.  Il  s’agit  d’une  opération  d’infrastructure qui permettra de rajouter un chemin de réplication supplémentaire entre les contrôleurs d’un site. 

- 6-

1. 

Ouvrez la console Sites et services Active Directory. 

2. 

Dans l’arborescence de la console, positionnez­vous sur l’objet NTDS Settings du  contrôleur sur lequel vous souhaitez associer un objet de connexion. 

3. 

Cliquez avec le bouton droit sur NTDS Settings et sélectionnez Nouvelle connexion à  Active Directory. 

4. 

Dans la fenêtre de recherche des contrôleurs de domaine, sélectionnez le contrôleur de  domaine partenaire. 

© ENI Editions - All rigths reserved

5. 

Par défaut, le nom proposé correspond à celui du partenaire. Validez votre choix en  cliquant sur le bouton OK. 

Une  fois  que  vous  avez  créé  le  nouvel  objet  connexion,  vous  devez  attendre  ou  provoquer  l’exécution  du  cycle  de  vérification de la topologie de réplication pour que la nouvelle connexion soit réellement en service. Cette opération  est décrite plus loin.  Dans  la  mesure  où  il  est  rare  d’avoir  sur  un  site  satellite  plus  de  deux  contrôleurs  de  domaine,  cette  opération  concerne  les  configurations  de  type  Campus  où  il  pourrait  y  avoir  plusieurs  milliers,  voire  des  dizaines de milliers d’utilisateurs et ordinateurs sur le même site géographique et aussi Active Directory. Le fait de  rajouter un objet de connexion Active Directory entre deux contrôleurs permet au contrôleur qui possède l’objet de  connexion d’être plus rapidement informé des éventuelles réplications de son partenaire direct. Une connexion plus  directe permet donc de moins utiliser la transitivité habituelle des réplications.  L’écran  suivant  illustre  la  nature  d’une  connexion  intrasite  (usage  des  RPC)  et  le  type  des  données  qui  seront  véhiculées. 

Affichage des caractéristiques d’un objet connexion créé manuellement  Comme vous pouvez le constater, une connexion créée manuellement utilise un cycle de contrôle fixé à 15 minutes,  tous les jours. 

© ENI Editions - All rigths reserved

- 7-

Planification des réplications sur un objet Connexion créé par l’administrateur  Vous venez de créer un objet connexion Active Directory entre deux contrôleurs de domaine situés sur le même site.  Vous avez aussi vérifié la nature des données qui seront transmises ainsi que le cycle de contrôle dans le cas où le  serveur source n’aurait pas notifié son partenaire de la présence de nouvelles informations à répliquer. 

9. Désactivation de la transitivité intersites  L’objectif de cette opération consiste à désactiver l’utilisation de la transitivité des communications intersites et inter  liens de sites.  Cette opération est une opération d’infrastructure qui permet un meilleur contrôle de la réplication mais nécessite la  création d’objets Ponts de liaison. Finalement, cette opération revient à activer ou à désactiver l’usage des ponts de  liaison intersites.  Pour  exécuter  cette  procédure,  vous  devez  être  membre  du  groupe Admins  du  domaine (dans le domaine  racine de la forêt) ou du groupe Administrateurs de l’entreprise dans Active Directory, ou alors vous devez  disposer des droits nécessaires par délégation. 

1. 

Ouvrez la console Sites et services Active Directory. 

2. 

Dans l’arborescence de la console, cliquez avec le bouton droit sur le dossier de transport  intersites IP, puis cliquez sur Propriétés. 

3. 

Pour désactiver la transitivité et créer des ponts de liaison de sites, décochez la case  Relier tous les liens du site.    L’option Relier tous les liens du site est disponible pour les transports intersites IP et SMTP.

10. Création d’un nouveau lien de sites et gestion de la réplication intersites  L’objectif de cette opération est de relier au moins deux sites Active Directory existant par un nouveau lien de site,  plutôt que d’utiliser le lien de site par défaut nommé DEFAULTIPSITELINK.  Pour  exécuter  cette  procédure,  vous  devez  être  membre  du  groupe Admins  du  domaine (dans le domaine  racine  de  la  forêt)  ou  du  groupe  Administrateurs  de  l’entreprise  dans  Active  Directory,  ou  alors  les  droits  appropriés doivent vous avoir été confiés par délégation. 

1. 

- 8-

Ouvrez la console Sites et services Active Directory. 

© ENI Editions - All rigths reserved

2. 

Dans l’arborescence de la console, positionnez­vous sur le protocole de transport inter­ sites IP, puis cliquez sur Lien vers un nouveau site. 

3. 

Dans le champ Nom, tapez le nom à donner à la liaison. Par exemple entre Paris et San  Francisco, vous pouvez nommer le lien intersites Paris­SF. 

4. 

À l’aide du bouton Ajouter, déclarez les sites qui pourront s’appuyer sur cette nouvelle  liaison de sites. 

5. 

Validez votre choix en cliquant sur le bouton OK. 

La configuration initiale du lien de site permet de créer l’objet et de déclarer les membres de cette nouvelle  liaison. Vous pourrez dans un deuxième temps modifier cet objet pour paramétrer le coût, la planification et  la fréquence de réplication de la liaison de sites. La figure ci­dessous illustre ces étapes : 

Sélection de la valeur de coût et du cycle de déclenchement des réplications  Pour rappel, plus un coût de réplication est bas et plus le chemin est meilleur. Notez aussi que lorsque les réplications  se produisent, elles continueront jusqu’à leur terme. Cela signifie que des réplications peuvent se produire en dehors  d’une plage autorisée.  L’écran  suivant  illustre  la  configuration  de  la  planification  des  heures  de  disponibilité  du  lien  Paris­SF.  Le  lien  est  globalement disponible à compter du vendredi soir 22H00, jusqu’au lundi matin 06H00. Ensuite, les réplications entre  Paris et San Francisco ne se produiront dans le semaine qu’entre 12H00 et 14H00. 

© ENI Editions - All rigths reserved

- 9-

 

11. Création d’un pont de liaison  L’objectif de cette opération est de relier au moins deux liaisons de sites Active Directory en utilisant un objet de type  pont  de  liaisons.  Cette  opération  est  une  opération  d’infrastructure  qui  vous  permettra  de  créer  votre  propre  topologie de réplication, sachant que vous aurez au préalable désactivé l’option par défaut Relier tous les liens du  site.  Pour  exécuter  cette  procédure,  vous  devez  être  membre  du  groupe Admins  du  domaine (dans le domaine  racine)  ou  du  groupe Administrateurs  de  l’entreprise  dans  Active  Directory,  ou  alors  les  droits  appropriés  doivent vous avoir été confiés par délégation. 

1. 

Ouvrez la console Sites et services Active Directory. 

2. 

Dans l’arborescence de la console, cliquez avec le bouton droit sur le dossier de transport  intersites IP et sélectionnez l’option Nouveau pont entre liens de sites. 

3. 

Dans la zone Nom, tapez un nom pour le pont de liaison de sites. 

4. 

Sélectionnez au moins deux liens de sites et cliquez sur Ajouter.    Si vous n’avez pas désactivé l’option Relier tous les liens du site, cette opération n’aura aucun effet.

12. Affectation des serveurs têtes de pont (BHS)  L’objectif de cette opération consiste à personnaliser la façon dont les serveurs têtes de pont ­ en anglais, BHS pour  Bridge Head Servers, sont sélectionnés dans le cas d’une défaillance du serveur tête de pont par défaut du site. Cette  procédure vous permet donc de sélectionner vos propres serveurs têtes de pont privilégiés.  Pour exécuter cette procédure, vous devez être membre du groupe Admins du domaine (dans le domaine du  contrôleur  de  domaine  sélectionné)  ou  du  groupe  Administrateurs  de  l’entreprise,  ou  alors  les  droits  appropriés doivent vous avoir été confiés par délégation. 

- 10 -

1. 

Ouvrez la console Sites et services Active Directory. 

2. 

Dans l’arborescence de la console, sélectionnez le serveur et faites un clic droit sur le  contrôleur de domaine que vous souhaitez désigner comme serveur tête de pont  privilégié, puis cliquez sur Propriétés. 

3. 

Dans l’onglet Général, ajoutez le ou les transports intersites pour lesquels le serveur  © ENI Editions - All rigths reserved

sera serveur tête de pont privilégié à l’aide du bouton Ajouter. 

Propriétés de l’objet contrôleur de domaine Booster 2003  Cet écran montre que le serveur joue le rôle de serveur tête de pont privilégié. Le fait  que cette fenêtre soit vide par défaut ne signifie pas que le serveur en question ne  puisse pas être un serveur tête de pont privilégié mais qu’il n’est pas contrôlé par  l’administrateur.  4. 

Validez votre sélection en cliquant sur le bouton OK.    Comme le montre l’écran, il est possible de gérer cette fonctionnalité sur le transport intersites IP et SMTP.

Par  défaut,  c’est  le  KCC  qui,  lors  de  la  construction  de  topologie  de  réplication  intersites  assigne  un  ou  plusieurs  serveurs  de  tête  de  pont  à  chaque  site  pour  garantir  le  bon  fonctionnement  des  réplications.  Microsoft recommande de conserver le fonctionnement par défaut, lequel est totalement automatique. Si le seul et  unique  serveur  tête  de  pont  "privilégié"  est  indisponible,  le  KCC  n’interviendra  pas  pour  nommer  un  nouveau  serveur tête de pont et rétablir les communications. 

L’ordre de sélection des éventuels différents serveurs têtes de pont privilégiés sera fonction de l’ordre dans  lequel l’administrateur a procédé aux différentes déclarations. 

Vous  venez  de  configurer  le  contrôleur  de  domaine  d’un  site  pour  qu’il  joue  le  rôle  de  serveur  tête  de  pont  (BHS)  privilégié. 

13. Forçage des réplications  L’objectif  de  cette  opération  consiste  à  forcer  les  réplications  des  partitions  communes  entre  deux  contrôleurs  de  domaines partenaires.  Pour exécuter cette procédure, vous devez être membre du groupe Admins du domaine (dans le domaine du  contrôleur  de  domaine  sélectionné)  ou  du  groupe  Administrateurs  de  l’entreprise,  ou  alors  les  droits 

© ENI Editions - All rigths reserved

- 11 -

appropriés doivent vous avoir été confiés par délégation. 

1. 

Ouvrez la console Sites et services Active Directory. 

2. 

Dans l’arborescence de la console, positionnez­vous sur le conteneur NTDS Settings du  contrôleur de domaine pour lequel vous souhaitez forcer la réplication. 

3. 

Cliquez avec le bouton droit sur la connexion qu’il faut solliciter pour répliquer les  données Active Directory, puis cliquez sur Répliquer maintenant. 

Un  message  vous  informe  que  la  connexion  a  été  correctement  répliquée.  Il  ne  reste  plus  qu’à  vérifier  si  les  informations attendues en provenance du contrôleur de domaine partenaire de réplication sont bien présentes sur le  contrôleur demandeur.  Le message d’erreur suivant apparaît lorsqu’un contrôleur de domaine partenaire de réplication ne répond pas à une  demande de réplication forcée : 

  La  commande  Repadmin  et  l’outil  de  réplication  Replmon  sont  deux  outils  utilisables  pour  forcer  une  réplication  entre  contrôleurs  de  domaine.  Ces  deux  outils  ne  sont  pas  distribués  avec  Windows  Serveur  2003.  Ils  font  partie  des  Outils  de  Support  livrés  sur  le  CD­Rom  d’installation  de  Windows  Server  2003.  Sur  les  serveurs fonctionnant sous Windows Server 2008 la commande Repadmin devient une commande système. Pour  disposer  de  l’outil graphique Replmon, vous devrez cependant installer les Outils de Support de Windows Server  2003 sur votre serveur Windows Server 2008. 

14. Utilisation de Repadmin et Replmon  La commande  Repadmin permet aux administrateurs ayant en charge la surveillance et le bon fonctionnement des  réplications  Active  Directory  de  diagnostiquer  les  problèmes  de  réplication  entre  contrôleurs  de  domaine.  Cette  commande permet de visualiser la topologie de réplication connue par chaque contrôleur de domaine mais peut aussi  réaliser de nombreuses opérations de contrôle et de forçage des réplications.  À la différence de Repadmin, l’outil Replmon est un outil graphique qui permettra aux administrateurs Active Directory  de  visualiser  et  surveiller  l’état  des  réplications  Active  Directory.  Par  exemple,  vous  pourrez  générer  des  rapports,  afficher les partenaires de réplication, forcer des réplications, déclencher le KCC, afficher les métadonnées des objets  Active Directory et faire des comparaisons entre contrôleurs.  Forçage des réplications avec Repadmin  L’objectif  de  cette  opération  consiste  à  forcer  les  réplications  des  partitions  communes  entre  deux  contrôleurs  de  domaines partenaires à l’aide de la commande Repadmin.exe.  1. 

Ouvrez une invite de commandes. 

2. 

Utilisez la commande Repadmin.exe pour déterminer les partenaires de réplication  directe du serveur source en tapant la commande suivante : Repadmin /showreps  nom_du_serveur_cible. Vous pouvez aussi utiliser la commande Repadmin /Showreps,  sans préciser de paramètre. Dans ce cas, toutes les connexions vers les éventuels  partenaires seront vérifiées.  Si le serveur cible peut être atteint, il affiche des données semblables à celles­ci : Dans  cet exemple, srv1 et srv2 sont dans le même domaine nommé support.company.com,  SiteX\srv1 Options DSA : (Aucune) objectGuid : 4a11d649-f9ab-11d2-b17f-00c04f5cb503

- 12 -

© ENI Editions - All rigths reserved

invocationID : 45d18b0b-f9ab-11d2-98b8-0000f87a546b ==== INBOUND NEIGHBORS ===================================== CN=Schema,CN=Configuration,DC=company,DC=com SiteX\srv2 via RPC objectGuid : d2e3badd-e07a-11d2-b573-0000f87a546b La dernière tentative du 1999-05-03 18:07.04 a été fructueuse. CN=Configuration,DC=company,DC=com SiteX\srv2 via RPC objectGuid : d2e3badd-e07a-11d2-b573-0000f87a546b La dernière tentative du 1999-05-03 18:07.05 a été fructueuse. DC=support,DC=company,DC=com SiteX\DC2 via RPC objectGuid : d2e3badd-e07a-11d2-b573-0000f87a546b La dernière tentative du 1999-05-03 18:07.09 a été fructueuse.   Seules les données intéressantes ont été indiquées. Dans la section Inbound Neighbors de la sortie, les partenaires de réplication directe  pour chaque partition d’annuaire sont identifiés comme dernière réplication.  3. 

Recherchez la partition d’annuaire à synchroniser et le serveur source avec lequel le  serveur cible sera synchronisé. Pour cela, notez le GUID du serveur source. 

4. 

Lancez la réplication à l’aide de Repadmin.exe en tapant la commande suivante :  repadmin /sync partition_annuaire nom_du_serveur_cible  objectGuid_du_serveur_source. Par exemple, pour lancer la réplication sur srv1 de  manière à répliquer les modifications à partir de srv2 tapez : repadmin /sync  dc=support,dc=company,dc=com srv1 d2e3badd­e07a­11d2­b573­0000f87a546b 

Si la réplication réussit, Repadmin.exe affiche le message suivant :  ReplicaSync() de la source : d2e3badd-e07a-11d2-b573-0000f87a5 46b, vers la destination : srv1 est réussi Vous  venez  d’utiliser  la  commande  Repadmin.exe  de  Windows  Server  2008  pour  déclencher  la  réplication  d’une  partition spécifique entre les contrôleurs de domaine srv1 et srv2.  Utilisation de Replmon  L’objectif de cette opération consiste à découvrir les nombreuses fonctionnalités disponibles dans l’outil Replmon.  La  première  étape  du  TP  consiste  à  désigner  les  serveurs  contrôleurs  de  domaines  à  analyser  et  contrôler.  La  deuxième étape vous permettra ensuite de découvrir les fonctionnalités les plus intéressantes de Replmon.  Étape 1  1. 

Ouvrez une invite de commandes et exécutez la commande Replmon. 

2. 

Dans le menu Edit, cliquez sur Add Monitored Server ... 

3. 

Pour réaliser la sélection des serveurs, activez l’option Search the directory for the  server to add. 

4. 

Sélectionnez le nom du domaine DNS souhaité, puis cliquez sur Next. 

5. 

Sélectionnez puis développez le site contenant le serveur à surveiller, puis choisissez le  contrôleur de domaine souhaité. 

6. 

Terminez cette opération en cliquant sur le bouton Finish. 

Vous venez de déclarer dans Replmon, un contrôleur de domaine d’un site donné, dans un domaine donné.  Étape 2  Statut du contrôleur de domaine  Les  écrans  suivants  permettent  d’avoir  un  check­up  complet  de  l’état  d’un  contrôleur  de  domaine.  Pour  y  parvenir,  cliquez avec le bouton droit sur l’un des contrôleurs à surveiller et demander l’affichage des propriétés.  L’onglet Server Flags dresse la liste de toutes les fonctions centrales prises en charge par le contrôleur de domaine.  Dans cet exemple, le serveur en question est un contrôleur de domaine non PDC Emulator et non GC (Global Catalog). 

© ENI Editions - All rigths reserved

- 13 -

Le service de temps W32 Time est opérationnel ainsi que le KDC, composant indispensable de l’Active Directory pour  les ouvertures de sessions réseau Kerberos. 

Affichage des fonctions centrales d’un contrôleur de domaine  L’onglet  FSMO  Roles  montre  qui  possède  quel  rôle  de  maître  d’opérations  et  permet  aussi  de  faire  une  véritable  opération sur le rôle.  Vous pouvez utiliser l’onglet FSMO Roles pour visualiser quel contrôleur possède quel rôle de maître d’opérations.  L’onglet Inbound Replication Connections montre l’état des connections au niveau des partitions. Cette granularité  est intéressante pour déterminer la nature d’un éventuel problème de réplication d’une partition telle que le schéma,  la configuration, le domaine ou même une partition de l’annuaire d’application.  Synchronisation forcée d’une partition Active Directory spécifique en mode Push  La figure suivante illustre les serveurs surveillés par Replmon. 

- 14 -

© ENI Editions - All rigths reserved

  Une fois que vous avez déclaré les serveurs que vous souhaitez surveiller, enregistrez cette liste à l’aide  du  menu  File  ­  Save  Monitored  List  As.  De  cette  manière,  vous  pourrez  recharger  cette  liste  de  serveurs  sans  devoir  les  déclarer à nouveau.  Dans cet exemple, le serveur S0 détient un réplica de la partition corpnet.corporate.com répliquée sur le site de San  Francisco et le site Premier­Site­par­defaut.  Pour synchroniser cette partition vers tous les serveurs de tous les sites, procédez de la manière suivante :  1. 

À l’invite de commande, lancez Replmon. 

2. 

Si vous disposez d’un fichier de configuration contenant tous les contrôleurs de domaine  que vous souhaitez surveiller, chargez­le à l’aide du menu File ­ Open Script. 

3. 

Positionnez­vous sur la partition dont vous souhaitez forcer la réplication. 

4. 

Faites un clic droit sur la partition et sélectionnez l’une des deux options suivants :  L’option Show Change Notifications to Replication Partners permet de notifier les  partenaires de réplication directs.  L’option Synchronize This Directory Partition with All Servers permet de répliquer la  partition vers tous les serveurs partenaires en mode Push. 

© ENI Editions - All rigths reserved

- 15 -

Choix des options de synchronisation d’une partition avec Replmon 

5. 

Une fois les options de réplication souhaitées sélectionnées et correctement comprises,  validez votre demande de réplication en cliquant sur le bouton OK. 

6. 

Finalement, vous pouvez enfin déclencher la réplication. 

Pendant  l’opération  de  réplication,  un  message  vous  informera  que  Replmon  pourra  être  indisponible  pendant  le  temps de l’opération.  Vous venez d’utiliser Replmon pour réaliser une réplication forcée en mode Push vers tous les contrôleurs de domaine  de la partition corpnet.corporate.com.  Pour  plus  de  renseignements  sur  Replmon,  référez­vous  au  site  de  Microsoft  via  Windows  Server  2003  Technical Reference / Tools and Settings Collection / Windows Support Tools / Active Directory Management  Tools  à  l’adresse  ci­dessous  :  http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/techref/en­us/Default.  asp? url=/Resources/Documentation/windowsserv/2003/all/techref/en­us/replmon.asp 

Pour  plus  de  renseignements  sur  Repadmin,  recherchez  «  Commande  Reference  »  sur  le  site  Microsoft  Technet/Windows Server 2008 Technical Library. 

- 16 -

© ENI Editions - All rigths reserved

Introduction  La notion d’emplacement est un point particulièrement important de toutes les infrastructures informatiques modernes.  En effet, qu’il s’agisse d’une entreprise de 100 personnes ou de 100.000 personnes (ou plus encore !), la définition et  l’emplacement  d’un  certain  nombre  de  "composants  d’infrastructure"  est  une  étape  capitale  pour  la  mise  en  œ uvre  opérationnelle et la pérenité de la solution globale.  Ce chapitre met l’accent sur l’emplacement des contrôleurs de domaine Windows 2000 Server, Windows Server 2003  et Windows Server 2008 en traitant particulièrement les serveurs de catalogue global, les serveurs DNS disposant de  zones intégrées à Active Directory ainsi que la nouvelle fonctionnalité de mise en cache de l’appartenance au groupe  universel pour les sites Active Directory disposant d’un contrôleur de domaine fonctionnant sous Windows Server 2003  ou Windows Server 2008. 

© ENI Editions - All rigths reserved

- 1-

Recherches LDAP et catalogues globaux  Les services de l’annuaire Active Directory sont disponibles au centre du système d’information de telle sorte que les  utilisateurs, les services et les applications puissent rechercher et aussi publier des informations intéressantes.  Pour  pouvoir  réaliser  des  recherches  dirigées  vers  les  services  d’annuaire  Active  Directory,  l’un  des  premiers  composants  fondamentaux  concerne  directement  l’ordinateur client. Ainsi, nous savons que les ordinateurs Windows  2000,  Windows  XP  et  ultérieurs  sont  des  clients  "naturels"  de  l’Active  Directory.  Dans  une  moindre  mesure,  les  ordinateurs fonctionnant sous Windows 9x ou Windows NT 4.0 peuvent être équipés du client Active Directory et ainsi,  utiliser  le  protocole  LDAP  pour  rechercher  des  informations  vers  l’annuaire Active Directory. Le deuxième élément est  bien sûr, l’annuaire lui­même, vers lequel les utilisateurs, les ordinateurs et les applications du réseau dirigeront leurs  requêtes.  Tous les clients LDAP supportant LDAP v2 (RFC 1777) ou bien LDAP v3 (RFC 3377) ont la possibilité de soumettre des  requêtes  LDAP  vers  Active  Directory.  Concernant  les  systèmes  d’exploitation  Microsoft,  les  systèmes  ci­dessous  sont  officiellement supportés par Microsoft :  ●

Windows 95 (avec le Client Active Directory) ; 

●

Windows 98 (avec le Client Active Directory) ; 

●

Windows NT 4.0 (avec le Client Active Directory) ; 

●

toute la famille des systèmes Windows 2000 ; 

●

Windows XP Professionnel ; 

●

la famille de systèmes Windows Server 2003 ; 

●

Windows Vista Professionnel, Entreprise et Intégrale ; 

●

la famille de systèmes Windows Server 2008. 

1. LDAP et la sécurité  Par  défaut,  l’annuaire  Active  Directory  est  très  protégé.  Il  est  donc  nécessaire  que  les  clients  s’authentifient  avant  qu’ils  puissent  envoyer  des  requêtes  LDAP  vers  un  serveur  d’annuaire  LDAP  Active  Directory.  Les  clients  s’authentifient  vers  l’Active  Directory  en  utilisant  les  mécanismes  de  sécurité  inclus  sur  les  contrôleurs  de  domaine.  Ainsi, les clients LDAP peuvent utiliser les mécanismes suivants :  ●

le protocole d’authentification Simple Authentication and Security Layer (SASL) ; 

●

le protocole Kerberos V5 ; 

●

le protocole NTLM. 

Les contrôleurs de domaine Active Directory ont aussi la possibilité d’accepter les requêtes LDAP en provenance de  clients anonymes (non authentifiés). 

2. Comment utiliser la commande LDP pour rechercher un objet via LDAP  Vous  pouvez  utiliser  la  commande  LDP,  incluse  dans  Windows  Server  2008  dans  le  dossier  %System  Root% \system32 ou bien utiliser celle qui est incluse dans les Outils de Support de Windows Server 2003. Cette commande  vous permettra de réaliser des recherches LDAP vers un annuaire LDAP tel que l’Active Directory.  ■

Dans le menu Connection, sélectionnez Bind et identifiez­vous avec un compte du domaine. 

■

Dans le menu Browse, sélectionnez Search. 

© ENI Editions - All rigths reserved

- 1-

■

Pour rechercher un utilisateur, utilisez l’attribut givenName pour le prénom et l’attribut sn pour le nom. 

Par exemple, la figure ci­après vous permet de rechercher dans le domaine Active Directory corp2003.corporate.net,  un utilisateur dont le nom est Smith ou Durand. 

Utilisation de l’outil LDP et syntaxe d’une recherche LDAP  Les deux requêtes ci­dessous sont un peu plus complexes.  ■

Pour rechercher un objet de la classe User, dont le prénom est Bob et dont le nom est Smith ou Durand, tapez la  syntaxe ci­dessous dans le champ Filter : (&(objectClass=user)(givenName=Bob)(|(sn=Smith)(sn=Durand))) 

■

Pour rechercher un objet de la classe User, dont le nom est Jones mais en excluant ceux qui ont un prénom tel que  John ou Jane et aussi ceux qui ne se sont pas connectés au moins 100 fois, tapez la commande ci­dessous : (& (objectClass=user)(sn=Jones)(!givenName=John)(!givenName=Jane)(!logonCount100)) 

■

Pour rechercher tous les utilisateurs qui ont un nom commençant par B, tapez la syntaxe ci­après dans le champ  Filter : (&(objectClass=user)(sn=B*)) 

■

Pour  rechercher  pour  tous  les  utilisateurs,  les  utilisateurs  qui  possèdent  un  répertoire  utilisateur  sur  G:\Utilisateurs,  tapez  la  syntaxe  ci­dessous  dans  le  champ  Filter  :  (&(objectClass=user)(home­ directory=G:\Utilisateurs)) 

À propos des opérateurs utilisés :  ●

Le symbole & représente l’opérateur ET. 

●

Le symbole | représente l’opérateur OU. 

●

Le point d’exclamation ! représente l’opérateur NOT. 

3.  Récupération  des  syntaxes  et  attributs  à  l’aide  de  la  console  Utilisateurs  et  ordinateurs Active Directory  Les syntaxes LDAP n’étant  pas  des  plus  naturelles,  vous  pouvez  utiliser  la  console  de  gestion  MMC  Utilisateurs et  ordinateurs  Active  Directory  pour  récupérer  les  syntaxes  et  noms  des  attributs  à  manipuler  à  l’aide  d’un  savant  copier­coller.  Par exemple, l’attribut qui gère le champ ville de l’adresse d’un utilisateur s’appelle, dans le schéma Active Directory,  "l" comme "location". Pour réaliser cette opération simple, procédez comme spécifié ci­dessous : 

- 2-

■

Lancez la console de gestion MMC Utilisateurs et ordinateurs Active Directory. 

■

Créez une nouvelle requête en utilisant l’assistant proposé. 

© ENI Editions - All rigths reserved

Utilisation de la fonction Requêtes sauvegardées pour récupérer les syntaxes LDAP 

■

Modifiez la requête précédemment créée. 

La "très utile" fenêtre de modification des requêtes  Il ne vous reste plus qu’à copier la syntaxe et à l’adapter en fonction de la requête à réaliser. 

Utilisation des recherches personnalisées pour tester les syntaxes 

© ENI Editions - All rigths reserved

- 3-

La  figure  ci­dessus  vous  permet  de  tester  les  syntaxes  que  vous  aurez  modifiées  directement,  sans  repasser  vers  LDP. 

4. Ajout, retrait de la fonction de catalogue global et ports TCP/IP  Les  contrôleurs  de  domaine  catalogue  globaux  sont  déclarés  par  les  membres  du  groupe  "Administrateurs  de  l’entreprise" à l’aide de la console de gestion MMC "Sites et services Active Directory" et d’une simple case à cocher. 

Activation du rôle Catalogue global sur le serveur S1  Cependant, le processus de construction des partitions, de la topologie de réplication ainsi que des mises à jour des  enregistrements  DNS  pour  déclarer  que  le  serveur  est  désormais  un  catalogue  global  est  plus  compliqué  qu’il  n’y  paraît.  Phase de promotion au rôle de catalogue global  Lorsqu’un  contrôleur  de  domaine  est  déclaré  pour  accueillir  la  fonction  de  catalogue  global,  un  réplica  partiel  en  lecture seule de toutes les partitions de domaine des domaines de la forêt est copié sur le contrôleur. La construction  est initialisée à l’aide de la réplication Active Directory immédiatement lorsqu’il s’agit de réplications intrasite, et lors  du  prochain  cycle  de  réplication  lorsqu’il  s’agit  de  réplication  intersites.  Chaque  partition  répliquée  devient  opérationnelle en lecture seule pour les recherches LDAP dirigées vers le nouveau catalogue global.  Phase de suppression du rôle de catalogue global  Il se peut qu’il soit nécessaire de supprimer un catalogue global sur un site donné au profit de la nouvelle fonction de  cache  de  l’appartenance aux groupes universels. Lorsqu’un contrôleur est dépromu de sa fonction de catalogue, le  KCC ­ Knowledge  Consistency  Checker ­ entame la suppression des réplicas en lecture seule, à l’aide d’un processus  asynchrone qui supprime les objets disponibles en lecture seule, petit à petit.  Le  temps  nécessaire  pour  réaliser  l’opération  de  suppression  varie  considérablement  entre  Windows  2000  Server,  Windows Server 2003 et Windows Server 2008. En effet, le KCC de Windows 2000 retire les objets par bloc de 500 à  chaque  déclenchement,  c’est­à­dire  par  défaut  toute  les  15  minutes.  Lorsqu’il  ne  reste  plus  d’objets  à  supprimer,  l’opération est terminée. Microsoft précise que la vitesse de suppression est d’environ 2000 objets par heure, ce qui  peut signifier en fonction du nombre d’objets à supprimer, que l’opération de suppression d’un réplica peut durer des  heures, voire des jours.  Le  KCC  de  Windows  Server  2003  ordonne  à  l’annuaire  de  prendre  en  charge  la  suppression  de  chaque  réplica  correspondant  à  chacun  des  domaines  catalogués  et  ne  réalise  plus  lui­même  la  suppression  des  objets.  De  cette  manière,  une  fois  l’instruction  reçue,  l’Active  Directory  commence  les  opérations  de  suppression.  Plutôt  que  de  - 4-

© ENI Editions - All rigths reserved

supprimer  un  nombre  précis  d’objets  par  cycle  géré  par  le  KCC,  Active  Directory  peut  continuer  progressivement  la  suppression des objets jusqu’à ce que le replica soit détruit, ou bien entamer une nouvelle série de suppressions, si  le travail n’est pas fini.  Le  moteur  de  réplication  Active  Directory  ­  DRS,  Directory  Replication  System,  gère  les  suppressions  de  replica  de  manière  à  ne  pas  stresser  les  réplications  de  production.  En  fait,  si  les  réplications  "normales"  le  nécessitent,  les  opérations de suppression seront pré­emptées et reprendront ultérieurement.  Sur  les  contrôleurs  de  domaines  fonctionnant  sous  Windows  Server  2003  ou  Windows  Server  2008,  vous  pourrez  consulter les journaux d’événements Active Directory et suivre les opérations de suppression d’un réplica ainsi que le  démarrage, la pause, la reprise et la bonne fin des opérations de suppression. Les événements enregistrés par le  KCC sont spécifiés ci­dessous :  Event ID 1744 : le contrôleur de domaine local n’est plus un catalogue global.  Event  ID  1659  :  la  suppresion  d’une  partition  d’annuaire  de  la  base  de  données  locale  a  été  repris,  y  compris  le  nombre approximatif d’objets restants à supprimer et le nombre de valeurs liées aux attributs restants à enlever.  Event ID 1660 : une partition d’annuaire spécifiée a été supprimée du contrôleur de domaine local.  Gestion  des  opérations  préemptées  :  sur  un  système  de  production  normalement  chargé,  la  suppression  d’une partition en lecture seule se produit aussi rapidement que possible en tâche de fond. Par contre, sur  un serveur surchargé par d’autres réplications ­ ce pourrait être le cas d’un contrôleur de domaine situé sur un site  important,  il  n’est  pas  facile  de  faire  une  estimation  du  temps  requis  pour  supprimer  des  données  du  catalogue  global.  Suppression de rôle et enregistrements DNS  Concernant les enregistrements DNS utilisés pour la localisation des services Active Directory, dès que le contrôleur  de  domaine  est  déclaré  comme  n’étant  plus  un  contrôleur  de  domaine  catalogue  global,  le  service  "Ouverture  de  session réseau" désenregistre les enregistrements de _gc. dans les zones DNS. Par conséquent, même si les réplicas  encore disponibles sur le contrôleur mettent plusieurs jours à être réellement supprimés, le dit contrôleur n’est plus  connu du réseau comme GC.  Pour éviter toute sollicitation pendant la phase de suppression des réplicas, le contrôleur de domaine refuse toutes  les requêtes LDAP dirigées sur le port 3268. 

5. Ports réseaux utilisés par les contrôleurs de domaine catalogues globaux  Lorsque  des  catalogues  doivent  opérés  dans  des  zones  sécurisées  du  réseau  de  l’entreprise,  il  est  nécessaire  de  configurer  les  pare­feu  de  telle  sorte  que  les  services  d’authentification  et  les  requêtes  LDAP  puissent  fonctionner.  Vous trouverez ci­dessous, les ports réseaux utilisés par les catalogues globaux :  LDAP ­ TCP 3268 (catalogue global).  LDAP ­ TCP 3269 (catalogue global via SSL).  LDAP ­ UDP et TCP 389.  LDAP ­ TCP 686 (SSL).  RPC/REPL ­ TCP 135 (RPC Endpoint port mapper).  Kerberos ­ UDP et TCP 88.  DNS ­ UDP et TCP 53.  SMB over IP (CIFS) ­ UDP et TCP 445. 

© ENI Editions - All rigths reserved

- 5-

Positionnement des catalogues globaux  Nous avons déjà appris qu’un catalogue global est un composant fondamental de l’infrastructure dans la mesure où il  joue le rôle de référentiel concernant les informations relatives à tous les objets d’une forêt Active Directory. La mise  en  cache  de  l’appartenance,  disponible  sur  les  contrôleurs  de  domaine  fonctionnant  sous  Windows  Server  2003  et  Windows  Serveur  2008,  a  pour  principal  objectif  de  réduire  le  trafic  mais  aussi  d’améliorer  l’ouverture  de  session  lorsque  les  connexions  réseaux  sont  particulièrement  lentes.  Ces  points  et  les  recommandations  concernant  l’emplacement de ces contrôleurs de domaine "particulierement importants" sont présentés ci­après. 

1. Authentifications et appartenance aux groupes universels de sécurité  Le système d’annuaire Active Directory crée automatiquement, sur le premier contrôleur de domaine installé dans une  forêt,  un  catalogue  global.  Dans  ce  cas,  nous  avons  l’habitude  de  parler  d’un  serveur  de  catalogue  global  ou  plus  familièrement d’un GC.  La fonction de catalogue est simple d’entretien puisqu’il est aisé de rajouter cette fonctionnalité à tout contrôleur de  domaine ou de considérer qu’il s’agit de transférer le rôle de catalogue à un autre contrôleur de domaine. En fait, un  transfert consiste à rajouter la fonctionnalité sur un contrôleur donné et à la retirer d’un autre contrôleur.  Appartenance aux groupes universels  Le  rôle  de  contrôleur  de  domaine  catalogue  global  est  particulièrement  important  car  il  permet  à  un  contrôleur  de  domaine  "non  GC"  de  disposer  des  informations  concernant  l’appartenance  éventuelle  d’un  utilisateur  à  tel  ou  tel  groupe universel. Pour rappel, peut­être est­il bon de souligner que les groupes universels de sécurité n’existent que  sur les catalogues globaux et pas sur les "simples" contrôleurs de domaine et qu’ils ne sont disponibles que lorsque  le  domaine  Active  Directory  fonctionne  dans  le  niveau  fonctionnel  Windows  Server  2008,  Windows  Server  2003  ou  Windows 2000 natif.  Recherches sur l’étendue de la forêt  Le catalogue global est capable d’assurer des recherches portant sur toute l’étendue de la forêt avec un très grande  performance, et ce, quel que soit l’endroit où l’objet est situé.  Résolution des suffixes UPN  Le  catalogue  global  sera  utilisé  pour  résoudre  le  nom  principal  de  l’utilisateur.  Nous  avons  déjà  vu  au  chapitre  qui  traite  des  nommages  que  le  nom  principal  de  l’utilisateur  ou  UPN  est  particulièrement  important  car  géré  d’une  manière  toute  spécifique.  En  effet,  le  catalogue  global  sera  invoqué  si  un  contrôleur  particulier  ne  parvient  pas  à  reconnaître  un  suffixe  UPN  donné.  Dans  l’absolu,  deux  types  d’erreurs  de  résolutions  de  suffixes  UPN  peuvent  se  produire et nécessiter le contact d’un catalogue global :  ●

Un suffixe UPN additionnel ne correspondant donc à aucun domaine Active Directory de la forêt a été ajouté  sur  la  dite  forêt.  Pour  rappel,  la  gestion  des  suffixes  UPN  est  réalisée  à  l’aide  la  console  de  gestion  MMC  "Domaines et approbations Active Directory". 

●

Un utilisateur dont l’objet utilisateur réside dans le domaine europe. corpnet. corporate.com utilise un suffixe  tel  que  [email protected].  Ce  deuxième  cas  se  produira  si  vous  souhaitez  altérer  le  suffixe  original pour simplifier (raccourcir) l’UPN original de l’utilisateur. 

2. Indisponibilité des catalogues globaux  Dans  l’absolu,  si  un  catalogue  global  du  site  du  client  n’est  pas  disponible,  un  autre  catalogue  global  sera  sélectionné. Cependant, une panne des communications réseaux vers un catalogue distant pourrait être encore une  cause de défaillance probable. Dans ce cas, si aucun catalogue global n’est disponible lorsqu’un utilisateur ouvre une  session dans le domaine fonctionnant dans les niveaux fonctionnels Windows Server 2008, Windows Server 2003 ou  Windows  2000  natif,  le  contrôleur  de  domaine  sollicité  utilisera  les  informations  mise  en  cache  de  l’ordinateur local  issues  de  la  précédente  ouverture  de  session  réussie.  Habituellement,  les  informations  d’authentification  mises  en  cache sont utilisées par les ordinateurs portables, lors d’une ouverture de session au domaine et lorsque l’ordinateur  n’y est pas connecté.  Dans le cas où l’utilisateur n’a jamais ouvert de session sur l’ordinateur et que par conséquent, il n’est pas possible  d’utiliser  les  informations  d’authentification  mises  en  cache,  alors  le  contrôleur  de  domaine  refuse  la  demande  de  connexion  et  l’utilisateur  ne  peut  pas  ouvrir  de  session  réseau.  Notez  tout  de  même  que  cette  méthode  n’est pas  appliquée  aux  administrateurs  du  domaine.  Ainsi,  les  administrateurs  du  domaine  peuvent  toujours  ouvrir  une  session vers le domaine même lorsqu’aucun serveur de catalogue global n’est disponible. 

© ENI Editions - All rigths reserved

- 1-

Il est pratiquement indispensable que les utilisateurs et les ordinateurs aient accès à un catalogue global.  Les catalogues globaux sont certes utilisés lors des ouvertures de session dans les domaines fonctionnant  dans  les  niveaux  fonctionnels  Windows  Server  2008,  Windows  Server  2003  et  aussi  dans  le  niveau  fonctionnel  Windows 2000 et ultérieurs mais aussi par des applications telles que Microsoft Exchange Server et Oulook. Notez  aussi  que  seuls  les  catalogues  répondent  aux  requêtes  dirigées  vers  le  port  TCP  3268.  Par  conséquent,  une  application qui ferait des recherches LDAP vers ce port serait dépendante des contrôleurs de domaine catalogues  globaux.  Microsoft  recommande  que  chaque  site  dispose  d’un  contrôleur  de  domaine  jouant  aussi  le  rôle  de  contrôleur de domaine. 

3. Personnalisation des attributs présents dans les catalogues globaux  Nous  venons  de  mettre  l’accent  sur  le  côté  "indispensable"  des  catalogues  globaux  et  sur  les  dépendances  qu’ils  introduisent. Toutefois, les catalogues ne doivent pas être considérés comme négatifs. Finalement, ils apportent des  solutions  à  des  problèmes  techniques  réels  et  sont  aussi  utiles  pour  "mieux  trouver"  tous  les  objets  connus  du  système d’annuaire.  Les  fonctions  de  recherches  pourront  ­  si  nécessaire  ­  être  personnalisées  pour  inclure  dans  les  catalogues  des  attributs supplémentaires plus intéressants. Il convient simplement de noter que la modification des attributs inclus  provoquera une augmentation du trafic pendant la phase de résynchronisation de tous les catalogues globaux de la  forêt, un point qui pourra être d’une importance capitale si l’entreprise concernée dispose de nombreux catalogues.  Pourquoi et quand modifier les attributs indexés par les catalogues globaux ?  Dans la mesure où les serveurs de type catalogues globaux sont des machines qui jouent un rôle particulièrement  critique  pour  l’ensemble  du  réseau  à  cause  de  leur  implication  dans  le  processus  d’ouverture  de  session  vers  le  domaine  Active  Directory,  il  est  fortement  recommandé  de  ne  pas  "jouer"  avec  les  catalogues  globaux.  Par  conséquent,  il  est  important  de  respecter  la  recommandation  suivante  :  Il  est  recommandé  de  n’ajouter  des  attributs  que  pour  rendre  service  aux  utilisateurs  ou  aux  applications  qui  sollicitent  fréquemment  l’annuaire  Active Directory.  Modification des attributs et impact sur la réplication Active Directory  En  fonction  de  la  fréquence  des  mises  à  jour  des  attributs  et  du  poids  de  chacun  d’eux,  l’impact  pourra  varier  considérablement. Comme, par définition, l’annuaire Active Directory réplique un ensemble des meilleurs attributs de  tous les objets de tous les domaines de la forêt, il est clair que plus ces attributs concerneront un nombre important  d’objets et plus le poids des réplications issus des modifications de ces attributs sera lourd. Bien sûr, cela dépendra  aussi  de  la  taille  de  chaque  attribut,  aussi  plus  l’attribut  modifié  sera  léger  et  plus  l’impact  sur  la  réplication  sera  minimisé.  Il est aussi très important de considérer les modifications relatives à un nombre d’objets limité dont la taille  des  attributs  seraient  plus  importante  et  dont  la  fréquence  de  modifications  des  attributs  seraient  plus  rapide ! 

4. Mise en cache de l’appartenance des groupes universels  Les  contrôleurs  de  domaine  Windows  Server  2003  et  Windows  Server  2008  peuvent  aider  à  rendre  l’infrastructure  Active Directory encore plus résistante aux défaillances. Effectivement, les variations inhérentes à la bande passante  disponible  d’une  connexion  intersites  ainsi  que  l’indisponibilité  d’un  contrôleur  de  domaine  peuvent  avoir  un  effet  désastreux sur la disponibilité des services d’authentification.  Les contrôleurs de domaine fonctionnant sous Windows Server 2003 et Windows Serveur 2008 peuvent être utilisés  pour éviter le déploiement d’un serveur de type catalogue global sur un site satellite comprenant peu d’utilisateurs.  Ainsi, sur ces sites vous pourrez :  ●

déployer  un  nouveau  contrôleur  de  domaine  fonctionnant  sous  Windows  Server  2003  ou  Windows  Server  2008.  Vous  avez  aussi  la  possibilité  de  procéder  au  remplacement  d’un  ancien  contrôleur  de  domaine  Windows 2000 Server, sachant qu’il n’est pas possible de réaliser une mise à niveau "in place" d’un serveur  Windows  2000  Server  vers  Windows  Server  2008  ou  mettre  à  niveau  un  ancien  contrôleur  de  domaine  Windows 2000 Server vers Windows Server 2003. 

●

Activer  la  mise  en  cache  de  l’appartenance  au  groupe  universel  pour  le  site  en  question  vers  un  autre  site  disposant d’un catalogue global. 

Dans le cas de la mise à niveau d’un contrôleur de domaine Windows 2000 Server jouant le rôle de catalogue  global, vous pourrez supprimer la fonction de catalogue global et ainsi minimiser les réplications intersites. 

- 2-

© ENI Editions - All rigths reserved

L’avantage de cette nouvelle fonctionnalité est que le contrôleur de domaine stocke les informations concernant les  groupes  universels  en  cache  juste  après  l’ouverture  de  session  de  l’utilisateur.  De  cette  manière,  les  groupes  universels  sont  présents  sur  le  site  même  lorsqu’il  n’y  a  pas  de  catalogue  global  sur  le  site,  grâce  à  l’aide  d’un  catalogue  situé  sur  un  site  distant  spécifié.  De  fait,  on  peut  dire  qu’il  peut  être  intéressant  de  mettre  à  niveau  un  certain  nombre  de  catalogues  globaux  fonctionnant  sous  Windows  2000  Server  vers  des  contrôleurs  de  domaine  fonctionnant sous Windows Server 2003 ne jouant plus le rôle de catalogue mais disposant de l’option Mise en cache  de l’appartenance au groupe universel. 

Activation de la mise en cache : le site local est aidé par le site de Cannes  Lors de la prochaine ouverture de session, le contrôleur de domaine récupère les informations d’appartenance aux  groupes universels à partir de son cache local plutôt que de contacter un serveur de catalogue global local ou distant.  Détermination du site à utiliser pour remplir et rafraîchir le cache des groupes universels La  figure  présentée  plus  haut  indique  que  vous  contrôlez  totalement  vers  quel  site  vous  souhaitez  diriger  les  requêtes  visant  à  vérifier  les  appartenances  aux  groupes  universels.  La  fenêtre  de  sélection  vous  permet  de  sélectionner  un  site  parmi  l’ensemble  des  sites  connus  de  la  configuration  Active  Directory.  Toutefois,  il  n’est  pas  obligatoire  de  faire  une  sélection  et  vous  pourriez  donc  conserver  la  valeur  par  défaut.  En  effet,  le  contrôleur  de  domaine analyse la topologie de sites Active Directory et détermine le meilleur site à contacter sur la base du coût le  plus faible. Comme cela est aussi le cas pour le DRS ­ Directory Replication System  ­ la détermination de la meilleure  route à emprunter sera réalisée par le service ISM, c’est­à­dire le service "Messagerie intersites".  L’interface graphique de la console de gestion MMC "Sites et services Active Directory" utilisée pour déclarer  le site préféré à utiliser pour résoudre les appartenances aux groupes universels ne vérifie pas la présence  réelle d’un catalogue global sur le site considéré. Dans le cas où le site ne disposerait pas de catalogue global, un  autre site sera choisi sur la base des coûts de liens de sites et un événement 1668 sera enregistré dans le journal  d’événements Active Directory. 

Configuration de la durée de vie du cache des groupes universels et recommandations Chaque contrôleur de domaine d’un site donné stocke les informations d’appartenance aux groupes universels dans  sa mémoire cache pour une durée de vie de huit heures. De plus, Microsoft précise que chaque contrôleur est capable  de  rafraîchir  jusqu’à  500  appartenances  de  groupes  universels  simultanément.  La  clé  de  registre  ci­dessous  vous  permettra de configurer correctement la gestion du rafraîchissement du cache.  HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\  Paramètres 

Cache Membership Refresh  Interval (minutes) 

Cached Member­ship Staleness  (minutes) 

Valeur 

Description 

DWORD 480 

La valeur est exprimée en  minutes, donc 8 heures. Ce  paramètre permet de déclarer la  valeur du rafraîchissement du  cache. Cette valeur pourrait par  exemple être changée pour ne  réaliser qu’un seul  rafraîchissement par jour (1440  minutes). Il n’est pas recommandé  de baisser cette valeur car plus  elle est basse et plus le trafic  réseau augmente, ce qui n’est  pas l’objet de la fonction de cache  des groupes universels.  

DWORD 10080 

© ENI Editions - All rigths reserved

La valeur est exprimée en  minutes, donc 7 jours. Ce  paramètre permet de déclarer la  durée de vie maximale des  enregistrements contenus dans le  cache. Si la valeur contenue dans  le cache est plus vieille que la 

- 3-

valeur du paramètre et qu’aucun  catalogue n’est disponible, alors  l’utilisateur ne pourra pas se  connecter. La valeur par défaut  est recommandée.  

Cached Member­ship Refresh  Limit 

DWORD 500 

Ce paramètre définit le nombre  maximum d’utilisateurs et  d’ordinateurs rafraîchis  simultanément. Microsoft  recommande d’augmenter cette  valeur si l’événement 1669 se  produit ou si le site contient plus  de 500 utilisateurs et ordinateurs.  Notez que lorsqu’un site  comprend plus de 500 utilisateurs,  il est recommandé de disposer  d’un catalogue global sur le site.  Notez que si vous augmentez le  nombre d’utilisateurs cachés, vous  devrez considérer une  augmentation du trafic de mise à  jour lié au catalogue global.  

Attention à la syntaxe des paramètres : les paramètres de clés de registre spécifiés ci­dessus contiennent la  chaine  de  caractères  "(minutes)".  Cette  chaine  de  caractère  fait  partie  du  nom  de  la  clé  et  doit  donc  être  incluse  dans  le  nom  de  l’entrée  au  moment  de  la  création.  Par  exemple,  la  valeur  "Cached  Membership  Refresh  Interval (minutes)" est correctement libellée alors que la valeur "Cached Membership Refresh Interval" ne l’est pas. 

5. Bonnes pratiques pour déterminer le positionnement des catalogues globaux  En résumé, l’appartenance aux groupes universels est un élément critique du processus d’ouverture de session. Si le  contrôleur  de  domaine  ne  parvient  pas  à  vérifier  ces  appartenances,  l’utilisateur  ne  peut  ouvrir  de  session.  Pour  y  parvenir, il doit pouvoir accéder à un catalogue global ou à ses informations mises en cache. Sans Windows Server  2003 ou Windows Server 2008, si le contrôleur de domaine accède au serveur de catalogue global par l’intermédiaire  d’une connexion intersites, les utilisateurs ne peuvent ouvrir de session si la liaison n’est pas disponible.  Microsoft  recommande  de  positionner  un  contrôleur  de  domaine  global  catalogue  lorsque  la  liaison  intersites  peut  supporter  le  trafic  de  réplication  causé  par  le  catalogue  global.  Dans  le  cas  où  le  trafic  de  réplication  est  trop  important  par  rapport  aux  possibilités  de  la  liaison  intersites,  installez  un  contrôleur  de  domaine  fonctionnant  sous  Windows  Server  2003  ou  Windows  Server  2008  et  activez  la  fonction  de  mise  en  cache  de  l’appartenance  aux  groupes universels sur le site. 

- 4-

© ENI Editions - All rigths reserved

Planification  et  critères  contrôleurs de domaine 

d’emplacement 

et 

d’affectation 

des 

Pour pouvoir réellement déterminer le nombre de contrôleurs de domaines, de serveurs DNS, de serveurs de catalogue  global  ­  et  aussi  d’autres  serveurs  d’applications  d’entreprises  telles  que  Microsoft  Exchange  Server  ou  Microsoft  System  Center  Configuration  Manager  2007  ­  vous  devez  d’abord  concevoir  la  topologie  de  sites  Active  Directory  (note  :  cette  remarque  n’est  vraie  que  lorsqu’on  est  vraiment  confronté  à  une  problématique  de  communications  multisites complexe).  Dans l’hypothèse où cette étape n’aurait pas été réalisée, vous devrez néanmoins disposer des informations minimum  qui vous permettront de positionner correctement vos serveurs d’infrastructure.  Les rôles que nous allons considérer sont spécifiés ci­dessous :  ●

gestion de l’emplacement des contrôleurs de domaine ; 

●

gestion de l’emplacement des serveurs de catalogue global ; 

●

gestion de l’utilisation de la fonction de mise en cache de l’appartenance aux groupes universels ; 

●

gestion de l’emplacement des serveurs possédant des zones DNS intégrées à l’annuaire Active Directory. 

L’idée  de  cette  partie  est  de  clarifier  les  bonnes  et  mauvaises  pratiques  afin  de  préserver  la  disponibilité  de  l’infrastructure tout en minimisant les coûts et la complexité de la solution.  Quand placer un contrôleur de domaine sur un site ? ●

Lorsqu’un site accueille de nombreux utilisateurs, il est bien sûr recommandé d’installer au moins un contrôleur  de domaine. Le seuil minimum qui nécessite la mise en place d’un contrôleur de domaine n’est pas clairement  défini  par  les  labs  de  Microsoft,  mais  on  peut  considérer  qu’au­delà  d’une  vingtaine  d’ordinateurs,  il  est  vraiment nécessaire de disposer localement d’un contrôleur de domaine. 

●

Lorsque  des  applications  s’appuient  sur  les  services  d’annuaires  Active  Directory.  Il  pourra  s’agir  d’une  application  telle  que  Microsoft  Exchange  Server  mais  d’autres  applications  peuvent  devoir  accéder  à  toutes  sortes d’informations contenues dans l’Active Directory. 

●

Lorsque le site contient des ressources protégées par les services de sécurité du domaine. 

Soyez vigilant quant à l’emplacement qui hébergera physiquement un ordinateur jouant le rôle de contrôleur  de  domaine.  Le  local  doit  disposer  d’un  accès  contrôlé  de  telle  sorte  qu’il  soit  difficile  d’accéder  aux  disques  durs de la machine. Si un intrus peut accéder physiquement à un contrôleur, il a inévitablement un accès physique à  des données critiques qui concernent l’intégralité d’un domaine Active Directory. Une personne malveillante pourrait  par exemple utiliser un outil de dépannage tel que ERD Commander pour accéder aux disques du serveur et ensuite  utiliser des outils de décodage des mots de passe pour découvrir le mot de passe de l’administrateur du domaine. 

Pour  répondre  à  cette  problématique,  Windows  Server  2008  peut  être  installé  en  tant  que  contrôleur  de  domaine  en  lecture  seule.  De  cette  manière,  aucune  structure  en  rapport  avec  les  mots  de  passe  n’est  physiquement  stockée.  L’exposition du serveur pourra aussi être minimisée en installant Windows Server 2008 en  mode Server Core, de manière à encore réduire la surface d’attaque. 

Combien d’utilisateurs par contrôleur de domaine Active Directory ? La détermination du nombre de contrôleurs de domaine en fonction du nombre d’utilisateurs est un point de passage  obligé. La meilleure façon de réaliser ce type d’estimation est d’utiliser l’outil Microsoft Active Directory Sizer. Cet outil  est  disponible  sur  le  site  de  Microsoft  à  l’adresse  ci­dessous  :  http://www.microsoft.com/windows2000/techinfo/reskit/tools/new/adsizer­o.asp.  Téléchargez du site de Microsoft, le document intitulé "Performance Tuning Guidelines for Windows Server 2008". Ce  document contient les paramètres de performances à appliquer sur les serveurs Windows Server 2008, rôle par rôle.  L’outil AD Sizer vous permettra de déterminer le processeur, la taille de la RAM et vous donnera un certain nombre de 

© ENI Editions - All rigths reserved

- 1-

valeurs moyennes correspondant à l’activité simulée de votre Active Directory.  À  propos  des  performances  :  les  machines  dont  nous  disposons  aujourd’hui  sont  largement  surdimensionnées  par  rapport aux charges et besoins que nous leur faisons supporter. Pour s’en convaincre, il suffit de positionner un audit  des  performances  sur  un  contrôleur  de  domaine  ou  d’étudier  certains  documents  de  référence  fournis  par  Microsoft.  Lors de tests menés par MCS chez un des grands clients de Microsoft, il a été testé la configuration ci­après.  ●

Un  seul  contrôleur  de  domaine  de  type  quadri  processeurs  Xeon  équipé  de  512  Mo  de  RAM  peut  supporter  17000 utilisateurs pour prendre en charge les ouvertures de sessions réseaux et les authentifications réseaux. 

●

Un  seul  catalogue  global  de  type  bi­processeurs  équipé  de  1  Go  de  RAM  peut  supporter  10000  utilisateurs  LDAP ainsi que l’activité associée à Exchange Server. 

●

Un seul contrôleur de domaine de type quadri­processeurs équipé de 1 Go de RAM hébergeant des zones DNS  dans Active Directory peut fournir des services de résolution de noms pour plus de 10000 ordinateurs. 

Ces  tests  ont  été  réalisés  courant  2000.  Si  l’on  considère  les  performances  des  machines  actuelles  ainsi  que  les  améliorations  de  performances  apportées  par  Windows  Server  2003  et  Windows  Server  2008,  il  est  évident  que  les  évaluations réalisées plus haut sont largement obsolètes.  Pour plus d’informations sur les mesures de performances réalisées par Microsoft, consultez le document intitulé "Sizing  Guidelines  for  Windows  2000  Domain  Controller  and  Global  Catalog  Server"  David  B.  Cross,  Microsoft  Consulting  Services,  disponible  à  l’adresse  ci­dessous  :  http://download.microsoft.com/download/9/e/5/9e586ee0­d06a­4a50­ bf6e­1c9f57857d79/DCSizing.doc  Comment améliorer la disponibilité du domaine sur un site ? Bien qu’un contrôleur de domaine Active Directory puisse supporter des milliers d’utilisateurs, vous serez certainement  amené  à  installer  sur  les  sites  les  plus  importants  un  deuxième  contrôleur  de  domaine.  De  cette  manière,  vous  disposerez  toujours  localement  sur  le  site  de  l’autonomie  nécessaire  à  la  poursuite  des  activités  normales  de  l’entreprise. 

- 2-

© ENI Editions - All rigths reserved

Planification et critères d’emplacement et d’affectation des catalogues  globaux  Nous avons vu à quel point les serveurs de catalogue global sont importants. Il est clair que si chaque site dispose de  son propre catalogue global, chaque site est vraiment autonome. Par conséquent, il peut résister à une panne totale  des communications réseaux avec le reste de l’infrastructure.  Une telle configuration peut sembler intéressante mais malheureusement, si la forêt Active Directory est composée de  plusieurs domaines et s’il y a de nombreux sites, donc de nombreux catalogues globaux, alors les flux de réplication de  ces contrôleurs de domaine seront particulièrement lourds sur les liens inter­sites.  Cette approche peut nous faire admettre l’idée suivante : "déclarons autant de catalogues globaux que le permet le réseau,  mais pas plus ...". Les questions et réponses ci­dessous vous permettront de décider si oui ou non, il est judicieux que  tel ou tel contrôleur de domaine joue aussi le rôle de catalogue global.  Quel est l’espace disque actuellement disponible sur le contrôleur de domaine ? Le disque doit être capable d’accueillir "partiellement" toutes les partitions de tous les domaines. Si ce catalogue doit  être  particulièrement  stressé  par  une  application  qui  génère  beaucoup  de  requêtes  LDAP,  vérifiez  que  le  serveur  dispose des ressources matérielles nécessaires pour satisfaire vos exigences de performances.  Est­il important de disposer d’une redondance en local sur le site ? Dans  le  cas  où  une  application  d’entreprise  serait  particulièrement  dépendante  d’un  serveur  de  catalogue  global,  il  serait judicieux de prévoir une redondance de ce serveur. La redondance pourra être envisagée de deux manières :  ●

redondance d’un serveur de catalogue global sur le site local, 

●

redondance d’un serveur de catalogue global sur un site distant. 

La  première  option  est  parfaite  tandis  que  la  seconde  ne  protègera  pas  contre  les  défaillances  des  communications  intersites.  Cas des serveurs de catalogue global dans les forêts mono domaine Lorsqu’une forêt Active Directory n’est composée que d’un seul et unique domaine, il est recommandé de déclarer tous  les  contrôleurs  de  domaine  du  domaine  comme  étant  des  catalogues  globaux.  En  effet,  comme  le  domaine  est  déjà  connu du domaine (!), le contrôleur peut dans ce cas être un catalogue global sans ne jamais rien répliquer ! L’avantage  le  plus  important  est  que  tous  les  contrôleurs  de  domaine  peuvent  répondre  à  des  requêtes  dirigées  sur  le  port  TCP  3268. 

© ENI Editions - All rigths reserved

- 1-

Planification  et  critères  d’emplacement  et  d’affectation  des  serveurs  DNS Active Directory  Le service de résolutions DNS est fondamental au bon fonctionnement du service d’annuaire Active Directory. Si les DNS  tombent, l’Active Directory tombe aussi, et l’ensemble des services d’infrastructure qui en dépendent ...  Plus encore que la problèmatique des catalogues globaux, les services DNS doivent donc faire l’objet d’une attention  toute particulière. Les recommandations ci­dessous vous permettront de faire les bons choix.  Disposez d’au moins un serveur DNS par site Si  le  contrôleur  de  domaine  du  site  dispose  d’une  zone  intégrée  Active  Directory  correspondant  au  domaine  géré,  le  contrôleur de domaine local du site fait automatiquement autorité pour la zone. Il est donc, de fait, aussi capable de  maintenir  tous  les  enregistrements  de  services  (SRV  RR)  nécessaires  au  bon  fonctionnement  de  l’annuaire  Active  Directory.  Dans la mesure où tous les ordinateurs clients du site ont pour principal serveur DNS le contrôleur de domaine du site,  il  est  intéressant  d’exploiter  les  zones  DNS  dynamiques  sécurisées  offertes  par  Windows  Server  2008  et  Windows  Server 2003.  Profitez des nouvelles partitions de l’annuaire d’applications Active Directory Par  défaut,  les  contrôleurs  de  domaine  fonctionnant  sous  Windows  Server  2008  et  Windows  Server  2003  disposent  automatiquement d’une partition de l’annuaire d’applications. Par rapport à Windows 2000 Server, l’avantage de cette  nouvelle approche permet de minimiser l’activité sur la partition du domaine Active Directory.  Dans le cadre des infrastructures Active Directory composées d’un nombre restreint de contrôleurs de domaine, l’usage  des partitions de l’annuaire d’applications disponibles sur les serveurs Windows Server 2008 et Windows Server 2003,  n’est  pas  particulièrement  important.  Par  contre,  il  convient  de  rappeler  que  les  données  des  zones  DNS  ne  sont  répliquées que vers les contrôleurs de domaine jouant le rôle de serveur DNS.  À l’inverse, les contrôleurs de domaine Windows 2000 Server accueillent les zones DNS intégrées à Active Directory au  sein de la partition de domaine. Par conséquent, tous les contrôleurs de domaine Windows 2000 possèdent tous les  enregistrements de ressources des zones DNS, qu’ils soient ou non serveurs DNS.  Tout contrôleur de domaine d’un site doit être un serveur DNS Il se peut que vous disposiez sur un site donné d’un contrôleur de domaine local et d’un serveur DNS éloigné. Même s’il  semble que cela complique la configuration globale en multipliant les serveurs DNS, il est dommage que les ordinateurs  du  réseau  local  contactent  un  serveur  DNS  distant  pour  localiser  le  contrôleur  de  domaine  du  domaine  situé  localement !  N’oubliez pas que le DNS est ­ presque ­ sans entretien puisqu’il est dynamique, sécurisé et se réplique à l’aide de la  réplication Active Directory.  Configurez tous les clients DNS du réseau pour utiliser deux serveurs DNS Deux solutions valent mieux qu’une ! Mais surtout, lorsque le seul serveur DNS déclaré n’est pas disponible les ennuis  commencent.  Il  est  en  effet  impossible  de  localiser  un  contrôleur  Active  Directory  à  l’aide  des  mécanismes  LDAP,  Kerberos.  Dans  ce  cas,  il  reste  toujours  la  connectivité  NT  qui  permettra  de  considérer  le  domaine  Active  Directory  comme  un  simple  domaine  NT  4.0  pour  réaliser  une  authentification  NTLM  v2.  Dans  ce  cas,  plus  de  stratégies  de  groupe,  plus  de  messagerie  Exchange  Server,  plus  de  certificats  Active  Directory  pour  la  signature  numérique  et  le  cryptage ... 

Utilisation de deux serveurs DNS  La bonne pratique consiste donc à utiliser simplement le contrôleur de domaine du site local comme serveur DNS. La  zone  DNS  est  intégrée  dans  Active  Directory  dans  une  partition  de  l’annuaire  d’applications  ou  dans  la  partition  du  domaine si le domaine doit héberger une zone DNS intégrée dans Active Directory sur des serveurs fonctionnant sous  Windows Server 2008, Windows Server 2003 et aussi sur des serveurs fonctionnant sous Windows 2000 Server. 

© ENI Editions - All rigths reserved

- 1-

Positionnement des maîtres d’opérations  Nous  avons  déjà  vu  que  les  maîtres  d’opérations,  aussi  appelés  FSMO  pour Flexible  Single  Master  Operations, étaient  impliqués dans de nombreuses opérations. Ces opérations sont pour la plupart en rapport avec la gestion des conflits  de configuration ou de sécurité potentiels et de fait, il devient important de considérer aussi cette problématique. 

1. Rôle des contrôleurs maîtres d’opérations  Avant  de  présenter  les  bonnes  règles  de  conduite  qui  concernent  le  positionnement  des  contrôleurs  de  domaine  maîtres  d’opérations,  il  convient  de  rapidement  rappeler  les  grands  rôles  de  maîtres  d’opérations  ainsi  que  leurs  resposanbilités. Pour rappel, les maîtres d’opérations ont déjà été traités précédemment au chapitre qui traite de la  nature des domaines et des forêts.  Les  services  d’annuaires Active Directory connaissent cinq rôles de maîtres d’opérations. Deux maîtres d’opérations  dédiés aux services de la forêt et trois maîtres d’opérations dédiés aux services de chacun des domaines de la forêt.  Concernant la forêt, celle­ci dispose des deux maîtres d’opérations listés ci­dessous :  ●

Le  maître  de  schéma  dont  la  responsabilité  est  de  contrôler  toutes  les  mises  à  jour  et  modifications  du  schéma. Pour mettre à jour le schéma d’une forêt, vous devez accéder au maître de schéma et être membre  du  groupe  de  sécurité  universel  "Administrateur  de  schéma".  Il  ne  peut  exister  qu’un  seul  contrôleur  de  domaine maître de schéma sur l’ensemble de la forêt. 

Migration vers AD DS ­ Étapes préliminaires. L’installation du premier contrôleur de domaine Windows Server  2008  dans  la  forêt  nécessite  que  celle­ci  soit  préparée  en  étendant  le  schéma  à  l’aide  de  la  commande  Adprep/Forestprep sur le maître de schéma. 

●

Le maître d’attribution de noms de domaine dont la responsabilité est de contrôler l’ajout ou la suppression  de domaines au sein de la forêt. Il ne peut exister qu’un seul maître d’attribution de noms de domaine sur  l’ensemble  de  la  forêt.  En  fait,  supprimer  ou  ajouter  un  domaine  signifie  surtout  ajouter  ou  supprimer  une  partition et de fait, il est indispensable d’être membre du groupe de sécurité universel des "Administrateurs  de l’entreprise". Le maître d’attribution de noms de domaine permet donc d’ajouter, supprimer tous les types  de partitions ainsi que de gérer des objets de références croisées. Par rapport à la version qui existait sous  Windows 2000 Server, les maîtres d’attribution de noms de domaine fonctionnant sous Windows Server 2008  ou  Windows  Server  2003  prennent  désormais  en  charge  les  fonctionnalités  de  renommage  des  domaines  Active Directory. 

Concernant le domaine, celui­ci dispose de trois maîtres d’opérations listés ci­dessous :  ●

Le  maître  d’émulateur  PDC  joue  le  rôle  de  contrôleur  principal  de  domaine  Windows  NT.  Il  traite  les  modifications  de  mot  de  passe  des  clients  et  réplique  les  mises  à  jour  à  destination  des  contrôleurs  secondaires de domaine NT. Bien sûr, il ne peut exister qu’un seul contrôleur de domaine jouant le rôle de  maître d’émulateur PDC dans chaque domaine de la forêt. Le maître d’émulateur PDC est également chargé  de maintenir la synchronisation de l’heure sur tous les contrôleurs de domaine du domaine. Notez aussi que  l’émulateur  PDC  reçoit  en  priorité  la  réplication  des  changements  de  mot  de  passe  effectués  par  d’autres  contrôleurs de domaine du domaine. 

Par  défaut,  le  maître  d’émulateur  PDC  interdit  toute  possibilité  d’écrasement  des  objets  de  stratégie  de  groupe. En effet, la Stratégie de groupe du domaine réduit les risques de conflits de réplication en désignant  le contrôleur de domaine jouant le rôle d’émulateur PDC pour ce domaine, comme serveur préféré pour réaliser les  modifications des GPO. 

La figure suivante vous permet de contrôler la façon dont la console de gestion MMC "Editeur d’objets de stratégie de  groupe" sélectionne un contrôleur de domaine pour finalement ouvrir ou modifier un objet stratégie de groupe géré  au  sein  de  l’Active  Directory.  Par  exemple,  pour  déterminer  quel  contrôleur  de  domaine  le  composant  logiciel  enfichable "Editeur d’objet Stratégie de groupe" utilise, jouez sur les paramètres ci­dessous :  Utiliser  le  contrôleur  principal  de  domaine  :  indique  que  l’Éditeur  d’objet  stratégie  de  groupe  lit  et  écrit  les  modifications dans le contrôleur de domaine désigné en tant que maître d’opérations PDC pour le domaine.  Hériter  des  composants  Active  Directory  :  indique  que  l’Éditeur  d’objet  stratégie  de  groupe  lit  et  écrit  les  modifications  dans  le  contrôleur  de  domaine  que  les  composants  logiciels  enfichables  Utilisateurs  et  ordinateurs  Active Directory ou Sites et services Active Directory utilisent. 

© ENI Editions - All rigths reserved

- 1-

Utilise tout contrôleur de domaine disponible : indique que l’Éditeur d’objet stratégie de groupe peut lire et écrire  les modifications dans tout contrôleur de domaine disponible.  Si vous désactivez ce paramètre ou si vous ne le configurez pas, l’Éditeur d’objet stratégie de groupe utilise  le contrôleur de domaine désigné comme le maître des opérations de contrôleur de domaine principal pour le  domaine. Ainsi, comme toutes les opérations d’édition de GPO sont dirigées vers le PDC Emulator il ne peut y avoir  deux  administrateurs  différents  qui  modifient  le  même  GPO.  Notez  toutefois  que  l’administrateur  a  toujours  la  possibilité de modifier un GPO sur un autre contrôleur. Ce paramètre permet de forcer un contrôleur de domaine  préféré mais n’empêche aucunement un administrateur de changer de contrôleur. 

Configuration à l’aide d’une stratégie de groupe de la sélection des contrôleurs des domaines  Par  défaut,  la  stratégie  de  groupe  du  domaine  n’implémente  aucune  valeur  particulière  pour  la  gestion  de  l’option  Sélection du contrôleur de domaine de la stratégie de groupe. La valeur par défaut de ce paramètre est Utiliser le  contrôleur principal de domaine.  ●

Le maître des identificateurs relatifs (RID, Relative IDentifier) alloue des séquences d’ID relatifs (RID) à  chacun  des  différents  contrôleurs  de  domaine  de  son  domaine.  Bien  entendu,  il  ne  peut  exister  qu’un  seul  contrôleur de domaine jouant le rôle de maître RID dans chaque domaine de la forêt. 

●

Le maître d’infrastructure est responsable de la mise à jour des références des objets de son domaine sur  les  objets  des  autres  domaines.  Il  maintient  l’identification  de  l’objet  en  fonction  de  son  déplacement  (changement  du  DN)  au  sein  d’un  domaine,  en  fonction  de  son  déplacement  au  sein  d’un  autre  domaine  (changement du DN et du SID), sachant que l’identificateur global unique (GUID) ne change jamais quel que  soit l’emplacement  de  l’objet. Il compare ses données à celles du catalogue global qui, lui­même, reçoit des  mises  à  jour  régulières  de  tous  les  domaines  par  le  biais  de  réplications.  Les  données  du  catalogue  global  sont ainsi actualisées en permanence. Si le maître d’infrastructure trouve des données qui ne sont pas à jour,  il demande les données mises à jour à un catalogue global et les réplique ensuite vers les autres contrôleurs  de domaine du domaine. 

Migration vers AD DS ­ Étapes préliminaires. Si le contrôleur de domaine est le premier contrôleur de domaine  fonctionnant  sous  Windows  Server  2008  dans  un  domaine  Windows  2000,  le  domaine  doit  être  préparé  à  l’aide  de  la  commande  adprep/domainprep/gpprep  sur  le  maître  d’infrastructure.  Lorsqu’il  s’agit  d’un  domaine  fonctionnant dans le niveau fonctionnel Windows Server 2003, le paramètre /gpprep pourra être ignoré. Il suffira  donc de lancer la commande adprep/domainprep sur le maître d’infrastructure. 

- 2-

© ENI Editions - All rigths reserved

Le  rôle  de  maître  d’infrastructure  ne  doit  pas  être  attribué  au  contrôleur  de  domaine  qui  héberge  le  catalogue global, sauf si le domaine ne comporte qu’un seul contrôleur de domaine, ce qui est plutôt rare ! Si  le  maître  d’infrastructure  et  le  catalogue  global  sont  situés  sur  le  même  contrôleur,  le  maître  d’infrastructure  ne  trouvera  jamais  de  données  non  actualisées.  Par  conséquent,  il  ne  répliquera  jamais  les  modifications  sur  les  autres contrôleurs de domaine du domaine. 

Notez  que  cette  dernière  remarque  ne  s’applique  que  dans  le  cas  où  tous  les  contrôleurs  de  domaine  du  domaine  ne  sont  pas  des  catalogues  globaux.  À  l’inverse,  si  tous  les  contrôleurs  de  domaine  sont  des  catalogues globaux alors le maître d’infrastructure peut être l’un d’entre eux. 

2. Recommandations générales concernant l’emplacement des maîtres d’opérations  Généralement,  il  n’est  pas  nécessaire  de  déplacer  les  rôles  des  maîtres  d’opérations.  Cependant,  il  se  peut  qu’en  fonction  de  la  topologie  du  réseau  ou  bien  d’une  défaillance  d’un  contrôleur  de  domaine  jouant  le  rôle  d’un maître  d’opérations,  vous  soyez  contraint  de  prévoir  le  déplacement  de  certains  maîtres  d’opérations  afin  d’optimiser  les  performances ou de minimiser les risques en cas de perte d’un contrôleur.  Les bonnes pratiques ci­dessous vous permettront d’atteindre ces objectifs :  ●

Dans  une  forêt  composée  d’un  seul  et  unique  domaine,  concentrez  tous  les  maîtres  d’opérations  sur  le  premier  contrôleur  de  domaine  de  la  forêt.  Ensuite,  désignez  tous  les  contrôleurs  de  domaine  en  tant  que  serveur de catalogue global. 

●

Dans une forêt composée de multiples domaines, dans le domaine racine de la forêt, si tous les contrôleurs  sont  des  catalogues  globaux,  concentrez  tous  les  rôles,  y  compris  catalogue,  sur  le  premier  contrôleur.  Si  certains contrôleurs ne sont pas des catalogues globaux, alors déplacez tous les rôles sur un contrôleur qui  n’est pas un serveur de catalogue global. 

●

Ensuite,  dans  chaque  domaine  enfant,  laissez  les  rôles  d’émulateur  PDC,  de  maître  RID  et  de  maître  d’infrastructure  sur  le  premier  serveur  du  domaine  et  assurez­  vous  que  ce  serveur  ne  soit  jamais  désigné  comme serveur de catalogue global. 

Pour  vous  prémunir  de  petits  incidents,  toujours  gênants,  lesquels  peuvent  empirer  lors  d’un  scénario  catastrophe, désignez un autre contrôleur du même domaine comme maître d’opérations en attente. Faites  en sorte de désigner une machine contrôleur de domaine "non catalogue global" dans le cas de la forêt composée  d’un seul et unique domaine où tous les contrôleurs de domaine le sont aussi. Il est recommandé que le contrôleur  de domaine jouant le rôle de serveur de secours se trouve dans le même site que le serveur en panne. 

3. Emplacement du contrôleur maître de schéma  Lorsque le maître de schéma n’est pas disponible, le schéma ne peut pas être modifié. Par défaut, il est très logique  que  le  premier  contrôleur  de  domaine  du  premier  domaine  de  la  forêt  exécute  le  rôle  de  maître  de  schéma.  Les  recommandations  ci­dessous  vous  permettront  de  faire  les  bons  choix  pour  garantir  une  grande  disponibilité  du  maître de schéma :  ●

Prévoyez un contrôleur maître de schéma de secours : il pourra assurer le service de contrôleur de schéma en  cas de sinistre. Notez qu’il n’est pas vital ou urgent de réparer le contrôleur maître d’opération  de  schéma,  sauf quand il est urgent de faire une modification du dit schéma ! D’un point de vue du choix de matériels, la  charge lors des modifications de schéma est normalement acceptable et les modifications sont souvent peu  nombreuses. 

●

Quand  mettre  à  niveau  le  schéma  sur  le  maître  de  schéma  ?  La  mise  à  niveau  du  schéma  d’une  forêt  Windows  2000  ou  Windows  Server  2003  est  réalisée  à  l’aide  de  la  commande  ADprep /Forestprep  située  dans  le  répertoire  \i386  du  CD­Rom  de  Windows  Server  2008.  Le  processus  de  mise  à  niveau  du  schéma  consomme environs 60 % de la performance CPU sur un ordinateur équipé d’un Pentium 4 Hyper Threading  avec 1 Mo de cache et 1 Go de RAM pendant une période de 10 minutes. Le processus sollicité est bien sûr  Lsass.exe  par  une  série  de  commandes  Ldifde.exe  qui  incorpore  les  nouvelles  classes  et  attributs  du  schéma.  Microsoft  recommande  de  réaliser  la  mise  à  niveau  du  schéma  localement  sur  le  contrôleur  de 

© ENI Editions - All rigths reserved

- 3-

schéma en dehors des heures habituelles de bureau. 

4. Emplacement du contrôleur maître d’opérations de noms de domaines  Lorsque le contrôleur maître d’attribution de noms de domaine n’est pas disponible, il n’est plus possible ni d’ajouter,  ni  de  supprimer  de  domaines.  Comme  cela  est  le  cas  avec  le  maître  de  schéma,  le  premier  contrôleur  de  domaine  d’une nouvelle forêt possède le rôle de maître d’attribution de noms de domaine. Les recommandations ci­dessous  vous permettront de faire les bons choix pour garantir une grande disponibilité du contrôleur de maître d’attribution  de noms de domaine :  ●

Prévoyez un contrôleur maître d’attribution de noms de domaine de secours : il pourra assurer le service de  contrôleur de maître d’attribution de noms de domaine en cas de sinistre. Notez qu’il n’est pas vital ou urgent  de réparer le contrôleur maître d’attribution de noms de domaine, sauf quand il est urgent de faire l’ajout ou  la  suppression  d’un  domaine  !  D’un  point  de  vue  du  choix  de  matériels,  la  charge  lors  des  opérations  du  maître d’attribution de noms de domaine est normalement acceptable. L’ajout et la suppression de domaines  sont des tâches peu fréquentes, par conséquent la charge moyenne du serveur pendant ces opérations est  minime et ne nécessite donc pas de machine particulièrement puissante. 

●

Le maître d’attribution de noms de domaine doit­il résider sur un catalogue ? Si la forêt est configurée pour  utiliser  le  mode  par  défaut  ­  niveau  fonctionnel  Windows  2000,  il  est  indispensable  de  positionner  le  contrôleur  maître  d’attribution  de  noms  de  domaine  sur  un  serveur  hébergeant  le  catalogue  global.  Par  contre, une fois que la forêt sera configurée pour utiliser le niveau fonctionnel de forêt Windows Server 2003  ou Windows Server 2008, vous pourrez, si vous le souhaitez, vous dispenser de placer le maître d’attribution  de noms de domaine sur un serveur de type catalogue global. 

5. Emplacement du contrôleur maître d’opérations de PDC Emulator  Lorsque le maître d’opération PDC Emulator n’est pas disponible au niveau d’un domaine donné, il est fréquent que  de petits ennuis apparaissent. En effet, ce contrôleur de domaine agit en tant que contrôleur de domaine principal  pour prendre en charge les anciens contrôleurs secondaires NT encore disponibles lorsque le domaine fonctionne en  mode  domaine  Windows  version  préliminaire  (Windows  Server  2003  interim)  ou  Windows  2000  mixte.  Le  premier  contrôleur de domaine créé dans un nouveau domaine agit en tant que contrôleur maître d’opérations PDC Emulator.  Les recommandations ci­dessous vous permettront de faire les bons choix pour garantir une grande disponibilité du  contrôleur maître d’opérations PDC Emulator :  ●

Prévoyez un contrôleur maître d’opérations PDC Emulator : utilisez un contrôleur de domaine très disponible.  Tous les contrôleurs de domaine accèdent régulièrement et souvent à cette machine pour les modifications de  mot  de  passe,  la  gestion  du  mauvais  mot  de  passe,  la  synchronisation  horaire  entre  contrôleurs  des  différents domaines de la forêt et, bien sûr, la prise en charge des synchronisations des anciens contrôleurs  secondaires de domaine. 

●

Quelle charge prévoir sur le serveur contrôleur maître d’opérations de PDC Emulator ? Il est recommandé de  prévoir  une  machine  très  disponible,  lorsque  le  domaine  fonctionne  dans  le  niveau  fonctionnel  Windows  version  préliminaire  (Windows  Server  2003  interim)  ou  Windows  2000  mixte  et  qu’il  contient  de  nombreux  contrôleurs  de  domaine  NT.  Mettez  en  place  une  analyse  des  performances  et  surveillez  l’usage  des  ressources matérielles telles que le processeur et la mémoire, puis augmentez les ressources si nécessaire. 

Notez que le fait que la machine soit surchargée à certaines heures ne signifie pas qu’il faille réaliser une évolution du  matériel.  La  période  de  charge  peut  être  de  courte  durée,  être  imperceptible  pour  les  utilisateurs  et  donc  être  ignorée. Il peut être plus rentable de faire évoluer les systèmes d’exploitation clients de Windows XP Professionnel  vers Windows Vista ou de supprimer les anciens contrôleurs Windows NT que d’investir dans le matériel affecté au  maître d’opérations PDC Emulator.  Les règles ci­dessous vous aideront à optimiser le rôle de maître d’opérations de PDC Emulator : 

- 4-

●

Sur un contrôleur maître d’opérations PDC Emulator, faites en sorte d’éviter de cumuler ce rôle avec celui de  catalogue global. 

●

Si cela ne suffit pas encore, faites en sorte que ce contrôleur soit moins sélectionné par les ordinateurs clients  en réduisant la priorité et le poids de l’enregistrement de service (SRV). Cette opération vous permettra de  favoriser l’authentification des autres contrôleurs de domaine du site. 

●

Comme  cela  est  le  cas  depuis  longtemps  sous  Windows  NT,  positionnez  ce  serveur  au  centre  de  votre  infrastructure pour qu’il soit disponible pour le plus grand nombre d’utilisateurs du domaine. 

© ENI Editions - All rigths reserved

6. Emplacement du maître d’opérations RID  Le contrôleur de domaine maître d’opérations RID gère le pool d’identificateurs relatifs alloués à chaque contrôleur de  domaine du domaine. Chaque fois qu’un contrôleur de domaine crée un nouvel élément de sécurité, tel qu’un objet  utilisateur,  un  groupe,  un  ordinateur,  une  approbation,  le  maître  d’opérations  RID  attribue  un  SID  à  l’objet  nouvellement créé.  Par défaut, la taille du pool de RID de chaque contrôleur de domaine est fixée à 500 RID, lequel pool est regénéré  lorsqu’il atteint 80 % sous Windows 2000 Server et 50 % sous Windows Server 2003. Par conséquent, tant que le  pool de RID d’un contrôleur n’est pas vide, il n’est pas urgent de contacter le maître d’opérations RID du domaine. Les  recommandations  ci­dessous  vous  permettront  de  faire  les  bons  choix  pour  garantir  une  grande  disponibilité  du  contrôleur maître d’opérations RID :  ●

Dans la mesure où la fonction première d’un domaine est de gérer la sécurité sur la base des SID créés dans  un  domaine  Windows,  faites  en  sorte  de  disposer  d’un  contrôleur  de  domaine  maître  d’opérations  RID  hautement disponible. Si ce contrôleur est disponible, il n’y aura jamais de problème de création d’éléments  de  sécurité  et  il  ne  sera  pas  nécessaire  de  réaliser  une  affectation  du  rôle  vers  un  autre  contrôleur  de  domaine en urgence pour pouvoir créer un ordinateur, un utilisateur ou bien un groupe de sécurité. 

●

Le  contrôleur  maître  d’opérations  RID  ne  doit  pas  être  une  machine  particulièrement  puissante  puisque  le  pool de RID est géré au fil de l’eau lorsqu’il atteint le niveau spécifié plus haut. 

●

Il  est  recommandé  de  placer  le  contrôleur  maître  des  opérations  RID  sur  le  site  où  le  plus  grand  nombre  d’objets est créé. 

●

Disponibilité du maître d’opérations RID. Vous pouvez vérifier le bon fonctionnement du RID FSMO ainsi que  l’allocation et la distribution au sein du pool de RID à l’aide de la commande DCDiag /Test:RIDMANAGER /V. 

7. Emplacement du maître d’opérations d’infrastructure  Le  maître  d’infrastructure  est  chargé  de  conserver  la  cohérence  des  objets  lorsque  ceux­ci  sont  utilisés  entre  des  domaines  différents.  Il  doit  effectuer  le  plus  rapidement  possible  les  mises  à  jour  de  ces  références  entre  les  domaines. Bien entendu, il n’existe qu’un seul et unique maître d’infrastructure par domaine. Les recommandations ci­ dessous  vous  permettront  de  faire  les  bons  choix  pour  garantir  une  grande  disponibilité  du  contrôleur  maître  d’opération d’infrastructure :  ●

L’indisponibilité  du  contrôleur  maître  d’opérations  d’infrastructure  n’est  pas  particulièrement  importante  ou  dramatique.  Il  en  résultera  une  incohérence  des  noms  d’objets  entre  les  domaines  de  la  forêt  et,  dans  l’absolu,  cela  gênera  surtout  les  administrateurs  des  ressources  qui  manipulent  les  utilisateurs  ou  groupes  altérés. 

●

Le contrôleur maître d’opérations RID ne doit pas être une machine particulièrement puissante. 

●

Une  déconnexion  de  courte  durée  du  maître  d’infrastructure est négligeable car elle n’a  aucun  effet  sur  les  utilisateurs du domaine. 

●

Sur un contrôleur maître d’opérations PDC Emulator, faites en sorte d’éviter de cumuler ce rôle avec celui de  catalogue global. 

●

Évitez de confier le rôle de maître d’infrastructure à un contrôleur de domaine de type catalogue global car ­  comme cela a déjà été expliqué précédemment, un contrôleur de domaine maître d’opérations d’infrastructure  ne doit pas cumuler la fonction de catalogue global sous peine de ne pas être capable de réaliser sa tâche de  mise à jour des références des objets situés dans d’autres domaines. 

●

Faites en sorte que le site sur lequel le contrôleur de domaine maître d’infrastructure est positionné dispose  d’un  contrôleur  de  domaine  de  type  catalogue  global.  Les  données  à  maintenir  à  jour  nécessitent  que  le  maître d’infrastructure communique avec un catalogue global. 

8. Prise de contrôle forcée des maîtres d’opérations 

© ENI Editions - All rigths reserved

- 5-

L’objectif  principal  des  fonctions  de  maîtres  d’opérations  est  de  garantir  que  les  opérations  les  plus  critiques  pour  l’intégrité de certaines opérations soient préservées. Pour s’en convaincre, nous pouvons nous poser les questions  suivantes :  ●

Que  se  passerait­il  si  deux  contrôleurs  de  domaine,  maître  d’opération  de  schéma,  modifiaient  les  déclarations d’un même attribut ? 

●

Que se passerait­il si deux administrateurs différents créaient tous les deux, deux utilisateurs différents avec  le même SID ? 

●

Que se passerait­il si un administrateur de l’entreprise entreprenait de supprimer le domaine Active Directory  qu’un autre administrateur serait justement en train de créer ? 

Normalement,  ces  cas  ne  pourront  jamais  se  produire,  justement  grâce  au  contrôle  de  l’unicité  de  ces  opérations.  Toutefois,  il  pourrait  être  facile  de  contrarier  cette  belle  mécanique,  tout  simplement  en  restaurant  un  ancien  contrôleur possédant un rôle déjà opérationnel sur un autre contrôleur du domaine ou de la forêt.  C’est pour cette raison, qu’il est indispensable de respecter les consignes listées ci­dessous :  ●

Ne prenez le contrôle forcé (en anglais, to seize a role) d’un maître d’opérations que lorsqu’il est impossible de  restaurer  normalement  le  véritable  propriétaire  du  rôle  ou  que  vous  ne  prévoyez  pas  de  réaliser  une  opération de restauration forcée. 

●

Si la machine qui possède le rôle est sujette à un dysfonctionnement de quelque fonction que ce soit et que  vous  souhaitez  prendre  possession  d’un  rôle  pour  le  rendre  opérationnel  sur  une  autre  machine,  déconnectez physiquement le contrôleur de domaine défaillant du réseau et ne le rebranchez plus jamais. 

Les recommandations ci­dessous vous permettront de faire les bons choix pour bien gérer les pannes suceptibles de  se produire sur les contrôleurs maîtres d’opérations :  ●

En fonction de la période d’interruption d’un rôle donné, déterminez un plan d’action approprié. Par exemple,  si la panne est de courte durée, attendez que le véritable propriétaire du rôle soit de nouveau disponible. 

●

Si la panne est plus longue, vous pouvez décider en fonction de l’importance des opérations que vous devez  réaliser  de  prendre  le  rôle  de  force.  Finalement,  ces  choix  sont  les  vôtres  et  dépendront  de  la  durée  de  la  panne. 

La liste des consignes ci­dessous vous aidera à mieux décider de l’urgence de telle ou telle récupération urgente d’un  rôle de maître d’opérations :  Défaillance du maître d’opérations PDC Emulator  Il faut considérer qu’il est urgent de réparer rapidement son éventuelle indisponibilité. Les anciens clients Windows  NT ou Windows 9x ne disposant pas du client Active Directory ne peuvent plus réaliser de changements de mot de  passe.  Ce  sera  particulièrement  problématique,  si  l’utilisateur  est  obligé  de  le  changer  pour  cause  d’expiration  de  celui­ci.  Défaillance du maître d’opérations d’infrastructure  L’absence temporaire du maître d’opérations d’infrastructure est vraiment transparente pour les utilisateurs. Il n’est  donc pas nécessaire d’entreprendre quoi que ce soit, sauf si la panne est particulièrement longue.  Défaillance  des  maîtres  d’opérations  de  schéma,  de  maître  d’opérations  RID  et  de  maître  d’opérations  d’attribution de noms de domaine  Ces  rôles  de  forêt  et  de  domaines,  même  s’ils  sont  vitaux  pour  réaliser  avec  succès  certaines  opérations  critiques,  sont sans effets sur l’activité des utilisateurs. De plus, ils sont rarement utilisés par les administrateurs, si ce n’est le  maître  des  opérations  de  RID,  eût  égard  aux  opérations  de  création  des  comptes  d’ordinateurs  et  d’utilisateur  ou  lorsqu’un contrôleur de domaine fait l’objet d’une restauration Active Directory.  Ne  rebranchez  jamais  sur  le  réseau  un  ancien  maître  d’opérations.  Microsoft  recommande  fortement  de  déconnecter  physiquement  tout  contrôleur  de  domaine  ayant  possédé  un  rôle  dont  le  contrôle  a  été  forcé  vers  un  autre  contrôleur.  Un  contrôleur  de  domaine  dont  le  rôle  de  contrôleur  maître  d’opérations  de  schéma,  d’attribution de noms de domaine ou RID ne doit jamais être remis en marche sur le réseau de production. Dans  l’absolu,  si  une  telle  machine  était  remise  en  service,  et  qu’elle  était  capable  de  répliquer  ses  partitions  Active  Directory, nous pouvons penser que les données FSMO les plus récentes seraient répliquées vers ce contrôleur et  qu’il perdrait de fait ses anciens statuts de maître d’opérations. Le problème vient du fait que nous ne sommes pas  assurés  que  cette  opération  de  réplication  puisse  se  dérouler  ­  puisque  le  contrôleur  est  sujet  à  un  dysfonctionnement. 

- 6-

© ENI Editions - All rigths reserved

9. Bonnes pratiques à respecter et emplacement des maîtres d’opérations  Les  risques  de  dysfonctionnement  des  services  offerts  par  les  contrôleurs  de  domaine  maîtres  d’opérations  sont  rares mais existent. Au fur et à mesure des évolutions de l’infrastructure Active Directory, vous devez toujours avoir à  l’esprit la disponibilité et le positionnement des fonctions FSMO ­ Flexible Single Master Operations, comme cela était la  cas, lorsqu’il s’agissait de domaines NT et du rôle de PDC.  Bien que vous puissiez affecter les rôles de maîtres d’opérations à n’importe lequel de vos contrôleurs de domaines,  essayez de respecter les bonnes pratiques proposées ci­dessous :  ●

Laissez les deux rôles de forêt ensemble sur un seul contrôleur de domaine du domaine racine de la forêt. 

●

Faites en sorte que ces deux rôles soient pris en charge par un contrôleur de domaine catalogue global. 

●

Placez les trois rôles de maîtres d’opérations de domaine sur le même contrôleur de domaine. 

●

Dans une forêt comprenant de multiples domaines Active Directory, ne placez pas les trois rôles de maîtres  d’opérations d’un domaine sur un contrôleur de domaine de type catalogue, à moins que tous les contrôleurs  du domaine ne soient des catalogues. 

●

Choisissez  les  machines  les  plus  puissantes  pour  les  contrôleurs  de  domaines  maîtres  d’opérations  de  domaines plutôt que pour les contrôleurs maîtres d’opérations de forêt. 

Pour  que  les  rôles  de  maîtres  d’opérations  soient  globalement  connus,  la  topologie  de  réplication  Active  Directory doit être opérationnelle pour tous les contrôleurs de tous les domaines de la forêt. Cette condition  est obligatoire pour garantir que tous les contrôleurs de domaines reçoivent bien ces informations. 

De plus, pour que la réplication Active Directory fonctionne, il est nécessaire que les services de localisation  des contrôleurs de domaines soient opérationnels et que les zones DNS possèdent tous les enregistrements  de ressources nécessaires. 

Si les contrôleurs de domaines ne sont pas capables de résoudre les enregistrements de ressources de la  zone  _msdcs.Racine_dela_Forêt,  ils  ne  pourront  pas  répliquer.  Dans  le  même  ordre  d’idées,  pour  pouvoir  contacter les contrôleurs de domaine maîtres d’opérations, il est aussi indispensable que les serveurs DNS soient  opérationnels. 

© ENI Editions - All rigths reserved

- 7-

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 En quoi les services de réplication intégrés à Active Directory sont­ils fondamentaux ?  2 Que signifie le terme Partition ?  3 De quel type sont les informations qui doivent être répliquées au sein d’un domaine donné ?  4 De quel type sont les informations qui doivent être répliquées entre des domaines d’une même forêt ?  5 Qu’entend­on par Partitions de l’annuaire d’applications ?  6 Quels types d’objets peuvent être stockés dans une partition de l’annuaire d’application ?  7 Sur quels contrôleurs de domaine d’une forêt les partitions de l’annuaire d’applications peuvent­elles être  répliquées ?  8 Quel outil faisant partie du système Windows Server 2003 ou Windows Server 2008 permet de créer des  partitions de l’annuaire d’applications ?  9 Qu’entend­on par Réplication Multimaîtres ?  10 Que se passe­t­il lorsque deux administrateurs modifient les membres d’un même groupe dans une forêt  fonctionnant en mode Windows 2000 ?  11 Que se passe­t­il lorsque deux administrateurs modifient les membres d’un même groupe dans une forêt  fonctionnant dans le niveau fonctionnel Windows Server 2003 ou Windows Server 2008 ?  12 Active Directory gère deux grands types de réplications. Lesquelles ?  13 Qu’appelle­t­on des réplications urgentes ?  14 Quels protocoles peuvent être utilisés pour répliquer les données de l’annuaire Active Directory ?  15 Est­il possible de répliquer la partition de domaine de deux contrôleurs de domaine du même domaine à l’aide  du protocole SMTP ?  16 Quelle commande vous permet de forcer une réplication Active Directory ?  17 Quelle est la latence de réplication au sein d’un site Active Directory comprenant des contrôleurs de domaine  Windows Server 2003 et/ou Windows Server 2008 ?  18 Où est stockée l’information qui permettra aux contrôleurs de domaine de répliquer correctement les  informations ?  19 Comment la topologie de réplication intra site est­elle construite ?  20 Quels sont les deux types de partenaires de réplication intra site ?  21 Quel est le rôle d’un objet site au sein de la topologie de réplication de la forêt Active Directory ?  22 Quel est le nom du lien de site par défaut créé lors de l’installation de l’Active Directory ?  23 Quel outil est utilisé pour gérer la topologie de réplication Active Directory ?  24 Quel est le rôle d’un pont de liaisons ?  25 Pourquoi n’est­il pas utile de créer des ponts de liaisons dans la configuration par défaut Active Directory ?  26 Que se passe­t­il si vous créez des Ponts de liaisons alors que le protocole IP relie tous les sites ?  27 Quel est le rôle d’un serveur tête de pont ?  28 Est­il possible d’avoir plusieurs serveurs BHS par site ?  29 Quel outil livré avec les Outils de support de Windows Server 2003 pouvez­vous utiliser pour surveiller en  temps réel les réplications Active Directory et forcer les réplications en intersites ?  30 Quels sont les outils Microsoft qui permettent de gérer la réplication 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  © ENI Editions - All rigths reserved

- 1-

point.  Nombre de points /30  Pour ce chapitre, votre score minimum doit être de 23 sur 30. 

3. Réponses  1 En quoi les services de réplication intégrés à Active Directory sont­ils fondamentaux ?  Les mécanismes de réplication permettent de garantir la stabilité de l’information offerte par les services d’annuaires  Active Directory en tout point du réseau.  2 Que signifie le terme Partition ?  Le  terme  partition  signifie  Partition  de  l’annuaire.  La  base  de  données  Active  Directory  est  composée  d’au  minimum  trois  partitions.  Le  moteur  de  réplication  Active  Directory  réplique  des  objets  et  attributs  d’objets,  lesquels  sont  contenus  dans  des  partitions.Lorsqu’il  s’agit  de  contrôleurs  de  domaine  fonctionnant  sous  Windows  2000  Server,  la  base Active Directory ne peut contenir que les trois partitions par défaut, auxquelles il convient d’ajouter les partitions  liées  à  la  fonction  de  catalogue  global.  Les  contrôleurs  Windows  Server  2003  et  Windows  Server  2008  peuvent  accueillir des partitions supplémentaires appelées partitions de l’annuaire d’application.  3 De quel type sont les informations qui doivent être répliquées au sein d’un domaine donné ?  Dans un domaine, les partitions de schéma, de configuration et de domaine doivent être répliquées.  4 De quel type sont les informations qui doivent être répliquées entre des domaines d’une même forêt ?  Au sein de la forêt, seules les partitions de schéma, de configuration et liées à la fonction de catalogue global doivent  être répliquées.  5 Qu’entend­on par Partitions de l’annuaire d’applications ?  Il s’agit d’un nouveau type de partitions supporté sur les contrôleurs de domaine fonctionnant sous Windows Server  2003.  Ces  partitions  sont  particulièrement  adaptées  pour  les  données  applicatives.  Ainsi,  une  partition  de  l’annuaire  d’application peut stocker des données propres à une application. De plus ces données peuvent être dynamiques car  soumises à une durée de vie (TTL).  6 Quels types d’objets peuvent être stockés dans une partition de l’annuaire d’application ?  Les partitions de l’annuaire d’applications peuvent stocker tout type d’objet, à l’exception des entités de sécurité. Notez  que ces données ne sont pas répliquées dans les catalogues.  7 Sur quels contrôleurs de domaine d’une forêt les partitions de l’annuaire d’applications peuvent­elles être  répliquées ?  Sur tout contrôleur de domaine de la forêt fonctionnant sous Windows Server 2003 ou Windows Server 2008.  8 Quel outil faisant partie du système Windows Server 2003 ou Windows Server 2008 permet de créer des  partitions de l’annuaire d’applications ?  Ntdsutil.  Vous  pouvez  utiliser  NTDSUTIL,  ADIS  Edit  ou  aussi  d’autres  outils  ou  commandes  supportant  le  protocole  LDAP. La méthode la plus pratique consiste à utiliser NTDSUTIL.  9 Qu’entend­on par Réplication Multimaîtres ?  Il  s’agit  du  modèle  de  réplication  utilisé  par  Active  Directory.  Dans  ce  modèle  n’importe  quel  contrôleur  de  domaine  accepte et réplique les modifications de l’annuaire. Par définition, tous les contrôleurs dispose des données disponibles  en lecture et aussi en écriture.  10 Que se passe­t­il lorsque deux administrateurs modifient les membres d’un même groupe dans une forêt  fonctionnant en mode Windows 2000 ?  Un conflit de réplication se produira puisque le même attribut aura été modifié dans le même cycle de réplication. La  dernière modification l’emportera et l’opération réalisée avant sera perdue.  11 Que se passe­t­il lorsque deux administrateurs modifient les membres d’un même groupe dans une forêt  fonctionnant dans le niveau fonctionnel Windows Server 2003 ou Windows Server 2008 ?  Lorsque  la  forêt  fonctionne  en  mode  Windows  Server  2003  ou  Windows  Server  2008,  la  réplication  LVR  est  opérationnelle. Les deux modifications seront donc prises en compte, indépendamment l’une de l’autre.  12 Active Directory gère deux grands types de réplications. Lesquelles ?  Active Directory utilise la réplication intra site pour répliquer rapidement les données d’un site tandis que la réplication  inter sites sera utilisée pour répliquer les données entre les sites en fonction du temps et d’un planning hebdomadaire.  13 Qu’appelle­t­on des réplications urgentes ?  Il s’agit de réplications concernant les mots de passe des utilisateurs, des ordinateurs, des approbations de domaines,  des changements réalisés dans la stratégie de comptes et de verrouillage de comptes du domaine.  14 Quels protocoles peuvent être utilisés pour répliquer les données de l’annuaire Active Directory ?  Les  réplications  intra  site  utilisent  les  RPC  sur  IP.  Les  réplications  inter  sites  utilisent  le  protocole  IP  ou  le  protocole 

- 2-

© ENI Editions - All rigths reserved

SMTP.  15 Est­il possible de répliquer la partition de domaine de deux contrôleurs de domaine du même domaine à l’aide  du protocole SMTP ?  Non.  Le  protocole  SMTP  ne  peut  être  utilisé  que  pour  répliquer  les  partitions  de  schéma,  de  configuration  et  de  catalogues.  16 Quelle commande vous permet de forcer une réplication Active Directory ?  Repadmin.  Cette  commande  est  disponible  de  base  sous  Windows  Server  2008.  Pour  en  disposer  sur  un  serveur  Windows Server 2003, vous devez installer les Outils de Support de Windows Server 2003.  17 Quelle est la latence de réplication au sein d’un site Active Directory comprenant des contrôleurs de domaine  Windows Server 2003 et/ou Windows Server 2008 ?  La latence de réplication est inférieure à une minute car les contrôleurs de domaine fonctionnant sous Windows Server  2003  respectent  une  notification  de  15  secondes.  Généralement,  entre  deux  contrôleurs  de  domaines  "voisins"  elle  aura lieue dans au plus 15 secondes. Les contrôleurs Windows 2000 Server implémente un délai de 5 minutes (300  secondes).Notez  que  pour  implémenter  le  timing  de  15  secondes,  la  forêt  doit  être  opérationnelle  dans  le  niveau  fonctionnel Windows Server 2003 ou Windows Server 2008.  18 Où est stockée l’information qui permettra aux contrôleurs de domaine de répliquer correctement les  informations ?  La topologie de réplication contient l’ensemble des informations utiles et est stockée dans la partition de configuration  de la forêt.  19 Comment la topologie de réplication intra site est­elle construite ?  Chaque contrôleur de domaine membre d’un site participe à sa création. Le composant responsable de cette opération  sur chaque site est appelé KCC.  20 Quels sont les deux types de partenaires de réplication intra site ?  Les partenaires directs et les partenaires indirects.  21 Quel est le rôle d’un objet site au sein de la topologie de réplication de la forêt Active Directory ?  Le site est une zone de connectivité rapide à laquelle on associe un ou plusieurs réseaux ou sous­réseaux IP.  22 Quel est le nom du lien de site par défaut créé lors de l’installation de l’Active Directory ?  DefaultIpSiteLink.  23 Quel outil est utilisé pour gérer la topologie de réplication Active Directory ?  La  console  de  gestion  MMC  Sites  et  services  Active  Directory.  Sur  les  contrôleurs  de  domaine  fonctionnant  sous  Windows  Server  2008,  vous  pouvez  aussi  utiliser  la  nouvelle  console  Gestionnaire  de  serveur/Rôles/Services  de  domaine Active Directory/Sites et services Active Directory.  24 Quel est le rôle d’un pont de liaisons ?  Un pont de liaison permet de rassembler plusieurs liens de sites. Ainsi, les réplications peuvent avoir lieues entre les  sites en passant par plus d’un lien de sites.  25 Pourquoi n’est­il pas utile de créer des ponts de liaisons dans la configuration par défaut Active Directory ?  Par défaut, le paramètre Relier tous les liens du site est activé au niveau du protocole IP dans le container Inter­Site  Transports.  26 Que se passe­t­il si vous créez des Ponts de liaisons alors que le protocole IP relie tous les sites ?  Les composants KCC et l’ISTG ignorent les Ponts de liaisons.  27 Quel est le rôle d’un serveur tête de pont ?  Le premier contrôleur de domaine d’un site joue le rôle de KCC et d’ISTG. Le module ISTG désigne le premier contrôleur  du site (c’est­à­dire lui­même) lequel devient responsable des communications vers les autres sites vers lequel il est  connecté. Le serveur tête de pont distant reçoit les modifications et les réplique vers les contrôleurs de son site.  28 Est­il possible d’avoir plusieurs serveurs BHS par site ?  Oui,  si  le  site  contient  des  contrôleurs  de  domaines  différents.  Un  serveur  tête  de  pont  ne  prend  en  charge  que  les  communications qu’il est lui­même capable de gérer. Par exemple, un BHS pour le domaine europe.company.com peut  transférer  les  modifications  pour  les  partitions  de  ce  domaine  et  aussi  du  schéma,  de  la  configuration  et  éventuellement des partitions de catalogues. Il ne pourra pas assurer la transmission des données d’un autre domaine  de la forêt.  29 Quel outil livré avec les Outils de support de Windows Server 2003 pouvez­vous utiliser pour surveiller en  temps réel les réplications Active Directory et forcer les réplications en intersites ?  L’outil Active Directory Replication Monitor (Replmon). L’outil Replmon n’est disponible ni sous Windows Server 2003, ni  sous  Windows  Server  2008.  Pour  en  disposer,  vous  pouvez  installer  les  Outils  de  Support  de  Windows  Server  2003  SP1.  30 Quels sont les outils Microsoft qui permettent de gérer la réplication Active Directory ?  La  console  de  gestion  MMC  Sites  et  services  Active  Directory  (Dssites.msc).  L’outil  de  la  ligne  de  commande  Repadmin.exe et l’outil graphique Active Directory Replication Monitor (Replmon).  © ENI Editions - All rigths reserved

- 3-

- 4-

© ENI Editions - All rigths reserved

Travaux pratiques  1. Contrôle des opérations du KCC  L’objectif  de  cette  opération  consiste  à  désactiver  le  fonctionnement  du  KCC.  Vous  pouvez  désactiver  le  KCC  soit  totalement,  soit  uniquement  concernant  la  génération  automatique  des  connexions  intrasite  ou  concernant  la  génération des connexions intersites.  Dans ce cas, vous devrez créer manuellement les objets de connexion ou laissez fonctionner le KCC pendant un laps  de temps qui lui permette de construire une première ébauche de la topologie de réplication.  Pour réaliser cette opération, procédez de la manière suivante :  1. 

Exécutez la commande Ldp.exe. 

2. 

Dans le menu Connexion, cliquez sur Se connecter. 

3. 

Tapez le nom de serveur d’un contrôleur de domaine, vérifiez que le paramètre de port  est 389, assurez­vous que l’option connectionless est désactivée puis validez par OK.  Lorsque la connexion est réalisée, les données spécifiques au serveur sont affichées. 

4. 

Dans le menu Connexion, cliquez sur Lier. Tapez le nom d’utilisateur, le mot de passe et  le nom de domaine (à format DNS) dans les zones appropriées, puis cliquez sur OK. Si la  liaison est correcte, un message dans le volet droit affichera que vous êtes authentifié  avec le DN de l’utilisateur utilisé. 

5. 

Dans le menu Affichage, sélectionnez Arborescence. Dans la zone Nom unique de base,  tapez le nom unique de l’objet site dans la configuration de la forêt. Par exemple, tapez :  CN = Default­First­Site­Name, CN = sites, CN = configuration, DC = corpnet, DC =  com. 

6. 

Développez la vue à partir de l’objet CN = NTDS Site Settings. Double cliquez sur cet  objet. LDP doit afficher dans le volet droit, les paramètres actuels des attributs de cet  objet. 

7. 

Recherchez, la valeur de l’attribut Options. Par défaut, cet attribut n’est pas présent et la  modification n’en sera que plus facile.  Si l’attribut Options est présent et que la valeur retournée est différente de  zéro, alors cela signifie que des paramètres sont déjà spécifiés. Dans ce cas,  vous devrez au préalable déterminer les bits utilisés. 

8. 

Dans le volet droit de l’outil Ldp, repérez le début de la sortie pour l’objet NTDS Site  Settings et faites une copie de la valeur du DN, c’est­à­dire CN = NTDS Site Settings, CN  = Default­First­Site­Name, CN = sites, CN = configuration, DC = corpnet, DC = com. 

9. 

Dans le menu Parcourir, cliquez sur Modifier puis, dans la zone DN, collez la valeur  copiée à l’étape précédente. 

10. 

Dans la zone Attribut, tapez le nom de l’attribut dont il faut changer la valeur : options. 

11. 

Dans la zone Valeurs, tapez la valeur appropriée :  ●

pour désactiver la génération intrasite réalisée automatiquement par le KCC,  déclarez la valeur 1 (décimal), 

●

pour désactiver la génération de intersite réalisée par le KCC, déclarez la valeur  16 (décimal), 

●

pour désactiver la valeur intrasite et intersites déclarez la valeur 17 (décimal). 

© ENI Editions - All rigths reserved

- 1-

 

12. 

Dans la zone Opération, cliquez sur Replace, sur le bouton Enter, puis sur Run. Vous  obtiendrez alors, dans le volet droit, le retour d’exécution réussie.  Pour vérifier que le paramètre est bien considéré par le KCC, utilisez la commande Replmon pour générer un  rapport de la configuration du site.    Cette opération a été réalisée avec Ldp, mais peut aussi être réalisée à l’aide de l’outil ADSI Edit.

Vous avez utilisé la commande LDP, pour changer la valeur de l’attribut Options du container NTDS Site Settings sur  un site donné et ainsi contrôler le fonctionnement ou non du KCC pour gérer les connexions intersites, intrasites ou  les deux. 

2. Ajout et suppression d’un catalogue global  L’objectif  de  cette  opération  consiste  à  activer  et  désactiver  lorsque  cela  est  nécessaire,  la  fonction  de  catalogue  global. Il s’agit d’une opération d’infrastructure qui a un impact sur la disponibilité des services d’annuaire ainsi que  sur la performance de la réplication d’annuaire dans un réseau d’entreprise composé de nombreux sites.  Pour réaliser cette opération, procédez de la manière suivante :  1. 

Ouvrez la console de gestion MMC Sites et services Active Directory. 

2. 

Dans l’arborescence de la console, cliquez sur le contrôleur de domaine dans lequel vous  voulez activer ou désactiver le catalogue global. 

3. 

Cliquez avec le bouton droit sur NTDS Settings, puis cliquez sur Propriétés. 

4. 

Cochez la case Catalogue global pour activer le catalogue global, ou supprimez la coche  si vous souhaitez le désactiver.  Pour exécuter cette procédure, vous devez être membre du groupe Admins du domaine (dans le domaine du  contrôleur de domaine sélectionné) ou du groupe Administrateurs de l’entreprise. 

L’activation  d’un  catalogue  global  risque  de  provoquer  une  augmentation  du  trafic  lié  à  la  réplication  et  ne  sera réellement opérationnel que lorsque toutes les partitions de la forêt Active Directory seront disponible  en tant que réplicas en lecture seule. 

- 2-

© ENI Editions - All rigths reserved

3. Vérification de la suppression des enregistrements SRV  L’objectif  de  cette  opération  consiste  à  nettoyer  les  enregistrements  de  ressources  de  type  SRV  laissés  par  les  contrôleurs de domaine Active Directory obsolètes n’ayant pas fait l’objet d’une procédure de suppression "propre".  Cette  opération  peut  être  qualifiée  d’opération d’entretien  et  évitera  les  erreurs  ou  lenteurs  de  résolutions  liées  à  des serveurs inexistants au sein des zones DNS utilisées par les services d’infrastructure Active Directory.  Pour réaliser cette opération, procédez de la manière suivante :  1. 

Ouvrez une invite de commande. 

2. 

Pour supprimer les anciens enregistrements SRV d’un contrôleur spécifique dans un  domaine donné, tapez la commande ci­dessous :  nltest /server: /dsderegdns: 

Le détail des paramètres est listé ci­dessous :  /server  Ce paramètre vous permet de spécifier le contrôleur de domaine sollicité pour traiter la demande. Dans le cas où ce  paramètre est omis, alors la machine locale est utilisée.  /dsderegdns  Ce paramètre vous permet de spécifier le nom complet du contrôleur de domaine que vous souhaitez supprimer des  zones DNS.  /dregdns  Le  paramètre  /dsregdns  vous  permettra  aussi  de  forcer  les  enregistrements  d’un  contrôleur  de  domaine  donné  à  condition que la commande soit exécutée localement sur le contrôleur de domaine souhaité.  Par  exemple,  tapez  la  commande  :  nltest  /server:srv1.company.com  /dsderegdns:tests.company.com.  De  cette  manière,  vous  supprimerez  tous  les  enregistrements  de  ressources  obsolètes  du  contrôleur  de  domaine  tests.company.com à partir du serveur dont le nom est srv1.company.com.  Vous venez d’utiliser la commande Nltest intégrée à Windows Server 2008 pour désenregistrer les enregistrements  de services obsolètes d’un contrôleur de domaine dans une zone DNS. 

© ENI Editions - All rigths reserved

- 3-

Technologie IntelliMirror  1. Introduction  La technologie de gestion et d’administration IntelliMirror est un ensemble de fonctions puissantes développées pour  accroître  la  disponibilité  des  systèmes  Windows  et  réduire  le  coût  total  de  possession  des  ordinateurs  fonctionnant  sous Windows 2000, Windows XP Professionnel, Windows Vista et les familles de systèmes Windows Server 2003 et  2008.  IntelliMirror  fait  appel  à  des  “stratégies”  pour  implémenter  les  mécanismes  de  gestion  des  modifications  et  des  changements de configuration. De cette manière, la technologie permet aux utilisateurs d’interagir avec un réseau de  plus  en  plus  dynamique.  Les  utilisateurs  peuvent  facilement  retrouver  leurs  données,  leurs  logiciels  et  leurs  paramètres  au  sein  d’un  environnement  informatique  distribué,  qu’ils  soient  connectés  ou  non.  La  technologie  IntelliMirror est directement intégrée au cœ ur de Windows 2000 et des versions ultérieures.  Pour profiter des nouvelles fonctionnalités offertes par la technologie IntelliMirror, il est obligatoire de disposer  d’un  environnement  de  domaine  Active  Directory  et  de  postes  de  travail  fonctionnant  sous  Windows  2000,  Windows XP Professionnel ou Windows Vista. Les postes de travail pré­Windows 2000 c’est­à­dire Windows 9x et  Windows NT, ne peuvent pas utiliser la technologie IntelliMirror et ce, même s’ils disposent du client Active Directory.  IntelliMirror s’articule autour de trois fonctions principales :  ●

la gestion des données des utilisateurs ; 

●

la gestion des paramètres des utilisateurs et des ordinateurs ; 

●

l’installation et la maintenance des logiciels pour les utilisateurs et aussi pour les ordinateurs. 

Bien sûr, vous pourrez utiliser tout ou partie de ces services en fonction des besoins des différentes populations de  l’entreprise. 

2. Apports pour l’entreprise  Comme les fonctions IntelliMirror sont implémentées via des composants intégrés au système d’exploitation Windows  et au cœ ur des services de domaine Active Directory, la technologie peut être utilisée du plus petit au plus grand des  réseaux.  De  cette  manière,  si  les  méthodes  d’administration  et  de  gestion  des  changements  de  configuration  évoluent, alors il sera possible de disposer d’un environnement à la fois sûr et contrôlé.  En  effet,  à  partir  du  moment  où  les  paramètres  de  gestion  et  de  configuration  ne  sont  plus  directement  sur  les  ordinateurs clients du réseau mais dans des “stratégies”  mises à disposition par l’annuaire Active Directory, alors le  poste de travail “lourd” devient un poste de travail “maîtrisé”, car intelligent.  La technologie IntelliMirror est une solution distribuée où les clients intelligents du réseau interagissent avec  les  services  d’infrastructure  Active  Directory  mis  à  leur  disposition.  Bien  qu’il  soit  possible  d’intégrer  dans  Active  Directory  des  terminaux  de  type  Windows  XP  Embedded,  ces  clients  ne  disposent  que  de  fonctionnalités  IntelliMirror limitées. 

Dans le même ordre d’idées, Windows XP Edition Familiale et Windows Vista Edition Familiale ne supportent  pas les stratégies de groupe pour la bonne raison qu’il n’est pas possible d’intégrer ce type de client au sein  d’un domaine. 

IntelliMirror permet une gestion des modifications et des changements de configuration qui s’appuie sur deux grands  types de stratégies :  ●

Les  stratégies  locales  :  tous  les  ordinateurs  fonctionnant  sous  Windows  2000,  Windows  XP  Professionnel,  Windows Server 2003, Windows Vista ou même Windows Server 2008 possèdent une stratégie locale et ce,  qu’il s’agisse de machines membres d’un domaine ou de machines autonomes. Nous découvrirons plus loin que  lorsqu’un ordinateur est membre d’un domaine Active Directory, alors la ou les stratégies issues du domaine  gagnent sur la stratégie locale. 

© ENI Editions - All rigths reserved

- 1-

Sur les systèmes Windows Server 2003 et Windows Server 2008, la stratégie locale est stockée localement  sur la machine dans le répertoire %Systemroot%\System32\ GroupPolicy. 

●

Les stratégies de groupe : une stratégie de groupe permet d’appliquer de manière centralisée et uniforme à  des  groupes  d’utilisateurs  et/ou  à  des  groupes  d’ordinateurs,  les  contraintes  de  gestion  et  les  normes  en  vigueur  dans  l’entreprise.  Un  groupe  correspond  à  un  ensemble  d’objets  stockés  dans  l’annuaire  Active  Directory. La gestion centralisée de plusieurs utilisateurs et ordinateurs permet de réduire considérablement le  temps et les efforts de gestion d’un administrateur. Une fois qu’une stratégie de groupe est mise en place, le  système peut l’appliquer de manière cyclique et, presque totalement dynamique, sans qu’aucune intervention  ultérieure ne soit nécessaire. 

Stratégies locales ou stratégies de groupe ? La technologie de gestion et de changement des configurations a  pour  objet  de  gérer  le  cycle  de  vie  des  ordinateurs  et  des  utilisateurs.  Une  telle  gestion  pourra  en  fonction  des besoins utiliser, tantôt des stratégies locales, tantôt des stratégies de groupe. Vous pourrez aussi utiliser un  mixte  des  deux  types  de  stratégies  et  ainsi  définir  les  paramètres  et  les  possibilités  qui  seront  affectés  à  des  utilisateurs  ou  à  des  ordinateurs.  Les  stratégies  locales  sont  définies  sur  un  ordinateur  local,  tandis  que  les  stratégies  de  groupe  sont  configurées  et  s’appliquent  à  des  ensembles  d’utilisateurs  ou  d’ordinateurs,  par  l’intermédiaire de Active Directory. Les stratégies de groupe permettent à IntelliMirror de centraliser et de simplifier  la gestion des modifications et de la configuration. 

Les stratégies de groupe sont appelées en anglais “GPO ­ Group Policy Object” et ce terme est régulièrement  utilisé dans la littérature Active Directory. 

Il  est  possible  d’utiliser  un  ordinateur  en  mode  non  connecté  ou  en  mode  connecté.  Ce  sera  bien  entendu  un  cas  classique  d’utilisation  des  ordinateurs  portables.  Les  utilisateurs  peuvent,  en  fonction  de  leurs  activités,  passer  régulièrement d’un mode à l’autre au cours de la journée.  Avantages pour l’entreprise L’un  des  principaux  bénéfices  pour  l’entreprise  est  une  bien  meilleure  productivité  des  utilisateurs.  L’idée  est  que  l’ordinateur doit être le plus disponible possible, le plus efficace, et aussi le plus autonome vis­à­vis de sa dépendance  par  rapport  à  l’infrastructure  dont  il  fait  partie.  Avec  l’initiative  ZAW  (Zero  Administration  for  Windows)  lancée  par  Microsoft  en  1996  avec  NT  4.0  et  le  ZAK  (Zero  Administration  Kit)  qui  était  un  ensemble  d’outils  de  gestion  et  de  procédures, aujourd’hui IntelliMirror permet de grandement améliorer la qualité des services pris en charge de base  par l’infrastructure Windows.  Avantages pour les utilisateurs L’utilisateur peut tirer le meilleur de son ordinateur. L’ordinateur est disponible car fiable, tant du point de vue matériel  que des logiciels qui l’équipe. Les paramètres de l’ordinateur et les données de l’utilisateur le suivent toujours, qu’il  travaille en mode connecté ou non. Ces petites améliorations rendent de grands services en améliorant la disponibilité  des  données  et  de  l’environnement  de  travail.  De  plus,  comme  ces  fonctions  sont  simples  d’usage,  elles  sont  transparentes  pour  les  utilisateurs.  Les  utilisateurs  peuvent  ouvrir  une  session  sur  n’importe  quel  ordinateur  et  accéder  à  leurs  propres  données  et  applications  sans  réellement  savoir  où  ces  données  se  trouvent  physiquement  (utilisation  du  service  DFS,  accès  aux  dossiers  hors  connexion,  utilisation  des  profils  utilisateurs,  installation  et  maintenance des logiciels via les services de gestion des logiciels, installation des mises à jour et correctifs Windows  via les services WSUS ­ Windows Server Update Services). 

3. Évolutions apportées aux GPO par les clients Windows Vista  Windows  Vista  incorpore  de  nouvelles  fonctionnalités  qui  font  progresser  les  mécanismes  liés  à  l’infrastructure  de  stratégie de groupe, améliorent la détection réseau et permettent une bien plus grande capacité de gestion pour les  administrateurs.  De  l’extérieur,  les  grands  principes  apportés  par  Windows  2000  Server  sont  toujours  valides  mais  Windows  Vista  fournit une évolution importante de l’infrastructure de stratégie de groupe. Sous Windows 2000 Server, Windows XP  Professionnel et Windows Server 2003, le traitement des stratégies de groupe se déroulait au travers du processus  Winlogon.  Sur  ces  plates­formes,  Winlogon  est  un  composant  en  charge  de  nombreuses  fonctions  telles  que  l’ouverture  de  session  locale  et  les  opérations  relatives  aux  stratégies  de  groupe.  Sous  Windows  Vista,  les  stratégies  de  groupe  disposent d’un service de traitement dédié. De plus, le traitement et l’application des stratégies est renforcée de telle  sorte qu’il est impossible de l’arrêter ou qu’un administrateur puisse prendre possession des autorisations définies sur  la  stratégie  de  groupe  pour  les  désactiver.  Toutes  ces  modifications  améliorent  la  fiabilité  globale  du  moteur  de  la  stratégie de groupe.  - 2-

© ENI Editions - All rigths reserved

a. Amélioration de la détection réseau (Network Location Awareness)  Sous  Windows  2000,  Windows  XP  Professionnel  et  Windows  Server  2003,  les  mécanismes  de  traitement  des  stratégies de groupe auraient essayé de déterminer la nature du lien réseau (lien lent ou lien rapide). En fonction du  lien, cette information aurait été utilisée pour sélectionner les paramètres de stratégie à appliquer. Cette méthode  est  toujours  d’actualité  avec  Windows  Vista,  cependant  le  mode  de  calcul  permettant  de  déterminer  la  bande  passante a été radicalement modifié. Sur les anciennes plates­formes, la détermination de la vitesse utilisait l’envoi  de paquets ICMP (Internet Control Message Protocol) vers les contrôleurs de domaine. Si au départ, l’idée est bonne,  dans  la  pratique  plusieurs  problèmes  sont  apparus  car  il  est  devenu  de  plus  en  plus  fréquent  que  le  support  des  messages ICMP soit désactivé pour stopper les réponses au ping. Ensuite, lorsque la connexion s’établissait via des  liens à latence élevée, tels que des liens satellites, les calculs pouvaient être faux. Dans ces situations, il n’était pas  possible de garantir que le lien était ou pas assez rapide.  Un autre problème des systèmes fonctionnant sous Windows XP Professionnel concerne la non reconnaissance du  mode mise en veille ou mise en veille prolongée. Il était évidemment nécessaire de pouvoir actualiser les stratégies  de groupe après la sortie de l’état de mise en veille, mise en veille prolongée, ou simplement lorsque l’ordinateur se  connecte après une absence prolongée.  Les  systèmes  fonctionnant  sous  Windows  Vista  mettent  les  paramètres  de  connectivité  réseau  en  temps  réel.  La  principale  modification  concerne  le  moteur  de  stratégie  de  groupe,  qui  utilise  maintenant  le  gestionnaire  NLA  2.0  (Network  Location  Awareness  2.0).  Les  composants  du  service  NLA  alertent  le  moteur  des  stratégies  dès  qu’un  contrôleur de domaine est disponible et déclenche, si nécessaire, un rafraîchissement des stratégies de groupe. 

b. Multiples stratégies locales (LGPO)  Habituellement, les stratégies locales sont utilisées pour permettre aux administrateurs des machines fonctionnant  sous Windows 2000, Windows XP, Windows Server 2003 ou Windows Vista de configurer les paramètres de sécurité  ou de registre sur ces machines, lorsqu’une infrastructure de GPO n’est pas disponible. En général, ce cas se produit  pour des machines de type "Kiosque" (machines en libre service), des machines situées dans des environnements  publics ou même des machines de test ou de démonstration.  La  limite  des  stratégies  locales  réside  dans  le  fait  que  les  plates­formes  Windows  2000,  Windows  XP  et  Windows  Server  2003  ne  supportent  qu’une  seule  et  unique  stratégie  locale,  ce  point  étant  particulièrement  problématique  lorsqu’il est nécessaire de gérer des paramètres différents pour différents utilisateurs.  Windows  Vista  corrige  cette  limitation  en  permettant  la  création  de  multiples  stratégies  de  groupe  locales  ­ LGPO,  Local Group Policies Objects, applicables aux entités suivantes :  ●

Tout utilisateur local de la machine, spécifié par son nom. 

●

Les utilisateurs membres du groupe Administrateur de la machine locale. 

●

Les utilisateurs non membres du groupe Administrateur de la machine locale. 

Attention ! Un utilisateur donné n’est affecté que par une seule et unique des stratégies locales présentées  ci­dessus, et ce, en fonction de la déclaration faite. De plus, il convient de préciser que lorsque l’ordinateur  Windows  Vista  fait  partie  d’un  domaine  Active  Directory,  les  stratégies  de  groupes  s’appliquent,  comme  à  l’accoutumé  en  respectant  l’ordre  Site  /  Domaine  /  OUs,  en  restant  prioritaires  sur  les  paramètres  déclarés  localement.  Notez que, dans le cas où il serait souhaité de ne pas rendre possible l’utilisation de cette nouvelle fonctionnalité, les  administrateurs ont la possibilité de désactiver le fonctionnement des LGPO sur les machines Windows Vista. 

© ENI Editions - All rigths reserved

- 3-

Désactivation du traitement des objets de stratégies de groupe locaux.  La figure précédente montre la possibilité de désactiver cette nouvelle fonctionnalité lorsqu’il est souhaité qu’elle ne  puisse pas être utilisée. 

c. Meilleure gestion des messages d’événements  Windows  Vista  est  équipé  d’un  nouveau  système  de  journal  d’événements.  Le  moteur  de  stratégie  de  groupe  exploite  le  nouveau  système  de  journalisation,  Windows  Eventing  6.0  en  fractionnant  les  événements  en  deux  parties.  La  partie  utilisant  le  journal  système  consigne  les  problèmes  de  stratégie  de  groupe,  tandis  que  la  partie  utilisant  le  journal  d’applications  est  spécifique  aux  différentes  stratégies  de  groupe,  et  stocke  les  événements  opérationnels. Ce nouveau système remplace le volumineux fichier de dépannage userenv.log. 

d. Anciens ADM et nouveaux ADMX  Dans les versions de Windows précédentes à Windows Vista, la création d’un nouvel objet GPO génère un ensemble  de fichiers ADM représentant à peu près 5 Mo. De fait, un nombre important d’objets GPO entraînera la création d’un  grand  nombre  de  fichiers  identiques  dans  le  SYSVOL  lesquels  seront  forcément  répliqués  sur  les  différents  contrôleurs de domaine du domaine.  Les nouvelles stratégies de groupe de Windows Vista apportent une réponse à cette problématique en introduisant  un nouveau format basé sur XML pour les fichiers de définition de stratégie : les fichiers ADMX. De plus, les fichiers  ADMX (nouveau format de fichiers pour les modèles administratifs de Windows Vista et Windows Server 2008 basé  sur XML) ne sont plus dépendants du langage et sont désormais accompagnés d’un fichier ADML (nouveau format de  fichiers contenant les données spécifiques aux langages utilisés par la nouvelle console de gestion des stratégies de  groupe de Windows Vista SP1 (via RSAT ­ Remote Server Administration Tools) ou Windows Server 2008 disponible en  téléchargement via le site de Microsoft) spécifique à chaque langue. Vous pouvez facilement ajouter des langues en  ajoutant simplement des fichiers ADML pour accompagner un fichier ADMX.  Outre  le  changement  de  structure  de  fichiers,  le  nouveau  format  ADMX  prend  en  charge  le  magasin  central.  Ce  nouvel espace de stockage évite la réplication d’informations dupliquées et facilite la mise à jour d’un fichier ADMX en  un  point  unique.  Les  administrateurs  définissant  des  stratégies  de  groupe  à  partir  d’un  poste  d’administration  Windows Vista ont automatiquement accès aux nouveaux fichiers ADMX mis à jour dans le magasin central.  Windows Vista fourni plus de cent trente fichiers ADMX ­ Windows Server 2008 en fourni plus de cent quarante, pour  remplacer les six à huit fichiers ADM fournis dans les versions précédentes de Windows.  Ces fichiers sont stockés dans le répertoire C:\Windows\PolicyDefinitions, tandis que les fichiers de langages  ADML sont stockés dans un sous­répertoire spécifique à la langue (par exemple fr­FR pour la France et en­ US pour les langages anglais/américain).  Il  est  important  d’avoir  à  l’esprit  que  les  systèmes  fonctionnant  sous  Windows  Vista  et  Windows  Server  2008  stockent les paramètres de stratégies de groupe différemment. Les nouveaux fichiers ADMX succèdent aux anciens  fichiers  ADM  en  offrant  de  nombreuses  nouvelles  possibilités,  telles  que  le  chargement  dynamique,  le  support  de  multiples langages ainsi que la possibilité de centraliser les modèles sur les contrôleurs de domaine.  Important ! Les plates­formes Windows Vista et Windows Server 2008 continuent de supporter les anciens  formats  de  modèles  basés  sur  les  fichiers  ADM.  Cependant,  Microsoft  encourage  la  conversion  des  fichiers  ADM vers le nouveau format ADMX en utilisant l’outil  ADMX Migrator disponible sur le site de Microsoft. Cet outil  gratuit fonctionne sur Windows Server 2008, Windows Vista, Windows XP SP2, Windows Server 2003 SP1 ou > et  nécessite la console MMC 3.0 et l’installation préalable Microsoft .NET version 2.0. 

- 4-

© ENI Editions - All rigths reserved

e. Windows Vista prend en charge de nombreuses nouvelles catégories  Par  rapport  à  Windows  XP  Professionnel  SP2,  Windows  Vista  rajoute  environ  huit  cents  nouveaux  paramètres  de  stratégie. Mais le plus remarquable concerne de nouvelles catégories n’ayant jamais existées ou pour lesquelles des  contrôles faisaient défaut. Parmi ces évolutions, les plus intéressantes concernent les paramètres de réseau câblé et  sans fil, les paramètres du pare­feu Windows en mode avancé, les paramètres IPSec, les paramètres de Gestion des  impressions ainsi que ceux du Desktop Shell, de l’Assistance à distance et autres fonctions Tablet PC. On remarquera  aussi, la gestion des unités de stockage amovibles, la gestion de l’alimentation, le contrôle des comptes utilisateur,  la gestion des rapports d’erreurs Windows, la protection de l’accès réseau et les paramètres de Windows Defender.  Attention ! Pour créer ou modifier des GPO qui utilisent des paramètres Windows Vista, vous devez utiliser  impérativement  un  ordinateur  Windows  Vista,  ou  un  serveur  Windows  Server  2008.  Notez  que  l’administration  de  certaines  nouvelles  fonctionnalités  nécessitera  le  SP1  de  Windows  Vista  ainsi  que  le  module  additionnel RSAT (Remote Server Administration Tool). Ce point est particulièrement vrai concernant les nouvelles  Préférences des stratégies de groupe.  Comme vous pouvez le constater, Windows Vista modernise de manière importante les objets GPO et la manière de  les gérer. Ils intégrent un plus grand nombre de paramètres configurables pour augmenter le contrôle et la sécurité  des systèmes. 

4.  Nouveautés  apportées  aux  postes  clients  grâce  aux  évolutions  des  stratégies  de  groupe de Windows Server 2008  Windows Server 2008 permet une prise en charge plus riche concernant la gestion et la configuration des systèmes  fonctionnant sous Windows Vista. Ainsi, de nouvelles catégories font leur apparition pour permettre à l’entreprise de  mieux tirer parti des avancées et progrès réalisés sur les systèmes d’exploitation clients.  Parmi celles­ci, nous pouvons remarquer : 

a. La gestion centralisée des paramètres de gestion de l’alimentation  Cette  fonctionnalité  permettra,  à  n’en  point  douter,  de  réaliser  des  économies  substantielles  dans  les  réseaux  de  toutes tailles. 

Les paramètres de gestion de l’alimentation sont pris en charge via les stratégies de groupe de Windows Server  2008.  Plusieurs  dizaines  de  paramètres  permettent  une  administration  totalement  centralisée,  grâce  aux  stratégies  de  groupe. Ces paramètres sont situés à l’emplacement suivant : Configuration de l’ordinateur ­ Stratégies ­ Modèles  d’administration ­ Système ­ Gestion de l’alimentation.  Attention ! Ces paramètres ne concernent que les postes de travail fonctionnant sous Windows Vista et pas  les systèmes fonctionnant sous Windows XP Professionnel. 

© ENI Editions - All rigths reserved

- 5-

■

La  possibilité  de  gérer  les  installations  de  périphériques  USB  non  autorisées  ainsi  que  la  délégation  de  l’installation des pilotes d’impression à certains utilisateurs. 

Configuration des restrictions d’installation des périphériques 

La gestion centralisée des restrictions de fonctionnement des périphériques USB vous permet de créer des  politiques adaptées pour les différents types de périphériques tels que les disques et clés USB, les lecteurs  et  graveurs  de  CD  et  DVD­RW.  Ces  paramètres  sont  situés  à  l’emplacement  suivant  :  Configuration  de  l’ordinateur  ­  Stratégies  ­  Modèles  d’administration  ­  Système  ­  Installation  de  périphériques  ­  Restriction  d’installation de périphériques. Attention ! Ces paramètres ne concernent que les postes de travail fonctionnant  sous Windows Vista et pas les systèmes fonctionnant sous Windows XP Professionnel. 

b. Améliorations apportées aux paramètres de sécurité  Les stratégies de sécurité de Windows Server 2008 rassemblent désormais l’ensemble des paramètres IPSec et de  pare­feu. Cette rationalisation de l’interface est plus cohérente avec la plupart des scénarios de déploiement. 

Le pare­feu Windows avec fonctions avancées intègre les règles de pare­feu entrantes et sortantes ainsi que les  règles de sécurité IPSec en un seul point.  De plus les nouveaux assistants permettent une mise en œ uvre plus rapide des configurations de type isolation au  sein d’un domaine Active Directory. 

- 6-

© ENI Editions - All rigths reserved

c. Meilleure gestion des paramètres liés à Internet Explorer  Sur les plates­formes fonctionnant sous Windows XP Professionnel ou Windows Server 2003, il pouvait arriver que  les  paramètres  utilisés  sur  la  machine  locale  prennent  le  pas  sur  les  paramètres  contenus  dans  un  objet  GPO.  Ce  type d’incident pouvait notamment se produire lors de l’édition des paramètres d’Internet Explorer contenus dans un  objet GPO. Désormais, Windows Server 2008 ne permet plus ce genre d’altération des paramètres. 

d. Assignement des imprimantes en fonction du site Active Directory  Les  stratégies  de  groupe  de  Windows  Server  2008  permettent  désormais  de  prendre  en  charge  la  problématique  des  connexions  aux  imprimantes  dans  les  environnements  ou  les  utilisateurs  se  déplacent.  Attention  au  fait  qu’un  nouvel emplacement ne sera connu qu’après le cycle de rafraîchissement de l’objet stratégie de groupe.  Ces  paramètres  sont  disponibles  en  tant  que  paramètres  ordinateur  et  utilisateur.  Ils  sont  situés  à  l’emplacement suivant : … ­ Stratégies ­ Modèles d’administration ­ Imprimantes. 

e. Délégation de l’installation des pilotes d’impression via les GPO  Les  administrateurs  ont  désormais  la  possibilité  de  déléguer  aux  utilisateurs  la  possibilité  d’installer  des  pilotes  d’impression.  Cette  fonctionnalité  réduit  la  nécessité  de  donner  à  des  utilisateurs  des  privilèges  de  type  "administrateur".  Il  convient  cependant  de  faire  remarquer  que  cette  fonctionnalité  n’est  supportée  qu’à  partir  de  Windows Vista. 

Délégation de l’installation des pilotes de périphériques 

Attention ! Cette stratégie nécessite que les pilotes de périphériques en question soient des pilotes signés.  Les  pilotes  non  signés  ne  sont  pas  concernés  par  ce  paramètre  et  devront  donc  être  installés,  comme  à  l’accoutumé,  par  des  administrateurs.  Ces  paramètres  sont  situés  à  l’emplacement  suivant  :  Configuration  de  l’ordinateur ­ Stratégies ­ Modèles d’administration ­ Système ­ Installation de pilotes. 

f. Nouveaux objets "GPO Starter"  Windows Server 2008 améliore la gestion des objets stratégies de groupe en permettant la création de modèles de  stratégies de groupe lesquelles sont appelés objets "GPO Starter". Il est ainsi possible de créer une bibliothèque de  GPO, lesquels serviront par la suite de point de départ. 

© ENI Editions - All rigths reserved

- 7-

Création du stockage au sein du domaine, la toute première fois.  Une fois le stockage créé, il est alors possible de créer les nouveaux objets "GPO Starter", sachant que leur unique  objet est de servir de modèle de stratégies de groupe. 

Création des nouveaux objets "GPO Starter".  Une  fois  votre  collection  de  modèles  créée  en  fonction  de  vos  besoins,  il  ne  reste  plus  qu’à  créer  des  objets  stratégies de groupe sur la base de ces modèles à l’aide de l’option Objet Starter GPO source. Enfin, on notera qu’il  est possible d’utiliser l’option Enregistrer en tant que fichier CAB… pour transporter un objet "GPO Starter" vers un  autre environnement Active Directory. L’import/export est ainsi facilité en incluant dans un seul et unique fichier Cab,  l’ensemble des fichiers constituant l’objet stratégie de groupe. 

Exportation d’un objet "GPO Starter". 

g. Paramètres du protocole NAP ­ Network Access Protection  Le  protocole  NAP  est  une  technologie  qui  permet  aux  administrateurs  de  définir  sous  quelles  conditions  certains 

- 8-

© ENI Editions - All rigths reserved

accès seront ou non accordés pour accéder au réseau interne de l’entreprise. Il pourra, par exemple, s’agir du cas  d’un  ordinateur  portable  dont  l’anti­virus,  l’anti­spyware  ou  le  pare­feu  présentent  des  erreurs  de  configuration  jugées  dangereuses.  Les  défauts  de  configuration  ayant  été  détectés  par  le  client  NAP,  celui­ci  pourra  prendre  l’initiative  en  permettant  à  l’ordinateur  de  contacter  un  serveur  de  "remediation"  pour  corriger  les  problèmes  précédemment détectés. Les stratégies de groupe de Windows Server 2008 intégrent l’ensemble des paramètres de  configuration  NAP  du  poste  de  travail  Windows  Vista  en  permettant  de  spécifier  les  différents  paramètres  de  cryptage vers les serveurs de type "Health Registration Authority". 

Interface de gestion des fonctions NAP 

5. Nouvelles préférences des stratégies de groupe de Windows Server 2008  Les  serveurs  Windows  Server  2008  apportent  un  nouvel  espace  de  gestion  au  sein  des  stratégies  de  groupe.  Ce  nouvel espace appelé "Préférences" permet aux administrateurs de configurer, déployer, administrer et gérer tous les  paramètres  système  et  applications  qu’ils  n’étaient  pas  capable  de  gérer  en  utilisant  les  stratégies  de  groupe.  En  général,  il  était  alors  nécessaire  de  créer  des  scripts  de  démarrage  ou  d’ouverture de session. Grâce aux nouvelles  "Préférences des stratégies de groupe", il n’est plus nécessaire de mettre au point des scripts complexes pour réaliser  des fonctions simples et élémentaires telles que des connexions réseau ou imprimantes, la planification de tâches de  maintenance  ou  même  configurer  les  détails  ou  le  contenu  du  menu  Démarrer  ou  tout  autre  paramètre  de  l’environnement.  Plutôt que d’intégrer les paramètres directement dans l’image de référence ou de les créer via un script, pas  toujours  facilement  maintenable,  Microsoft  recommande  d’utiliser  les  nouvelles  "Préférences".  Les  scripts  seront  donc  utilisés  en  dernier  recours,  lorsqu’il  ne  sera  pas  possible,  ni  par  les  stratégies  de  groupe,  ni  par  les  nouvelles options de Préférences de réaliser une opération de configuration particulière. 

a. Préférences ou stratégies de groupe ?  Les  préférences  de  stratégies  de  groupe  sont  complémentaires  aux  stratégies  de  groupe.  La  compréhension  du  concept  de  complémentarité  est  cruciale  pour  tirer  partie  des  préférences  de  stratégies  de  groupe.  Le  tableau  ci­ après positionne côte à côte les deux technologies.  Préférences de stratégies de  groupe  Ne sont pas réappliquées.  Application 

Ne désactivent pas l’interface. 

© ENI Editions - All rigths reserved

Objets stratégies de groupe 

Sont appliqués, voir réappliqués.  Désactivent l’interface. 

- 9-

Appliquées une fois ou via  rafraîchissement. 

Via rafraîchissement. 

Création simple d’items pour le  registre, les fichiers, …  

L’ajout de paramètre nécessite  que l’application utilise le registre,  plus la création de modèles  administratifs.  

Souplesse  Import de paramètres de registre  en local ou à distance 

Ne peuvent pas gérer le contenu  des fichiers, des dossiers, … 

Stratégie locale 

Pas de préférence avec les  stratégies locales. 

Supportés via une stratégie locale  (local GPO). 

Dépendances 

Supporte les applications non  conçues pour utiliser les GPO.  

Nécessite des applications  supportant les GPO.  Les paramètres originaux ne sont  pas altérés.  

Stockage 

Écrasement des paramètres  originaux. Pas de restauration  des paramètres en cas de  suppression des préférences. 

Le ciblage est très fin en fonction  de critères sélectionnable via une  interface graphique.  Ciblage et Filtrage 

Interface utilisateur 

Les paramètres sont sous la clé  \Policy.  La suppression d’une stratégie de  groupe restaure les paramètres  d’origine. 

Le filtrage est basé sur des  requêtes WMI qu’il faut écrire,  puis associer sur l’objet GPO. 

Le ciblage est possible au niveau  de chaque item géré par les  préférences. 

Le filtrage s’applique au niveau de  chaque GPO. 

L’interface permet de définir tous  les paramètres de manière très  intuitive.  

L’interface permet de contrôler les  paramètres les plus importants. 

À la question "Comment choisir entre déployer un paramètre de configuration via un objet GPO ou via l’usage des  Préférences des GPO ?", la réflexion que l’on devra tenir pourra s’appuyer sur la logique ci­dessous :  ●

Désirez­vous forcer le paramètre ? Si oui, utilisez un objet GPO. Si non, utilisez les Préférences. 

●

Les  paramètres  de  l’application  ou  du  composant  à  configurer  supportent­ils  une  gestion  de  type  GPO  et  souhaitez­vous  en  forcer  l’application  ?  Si  oui,  utilisez  un  objet  GPO.  Si  non,  utilisez  les  Préférences  et  désactivez l’option Appliquer une fois et ne plus réappliquer. 

Attention ! Lorsqu’un paramètre donné est déclaré dans un objet GPO et aussi en tant qu’élément de type  Préférence de stratégie de groupe, le paramètre déclaré dans l’objet GPO sera toujours appliqué. Les objets  GPO sont donc traités de manière prioritaire par rapport aux Préférences de stratégies de groupe. 

- 10 -

© ENI Editions - All rigths reserved

Configuration de l’option Appliquer une fois et ne plus réappliquer.  Les  paramètres  des  éléments  contenus  dans  les  préférences  sont  appliqués  lors  du  rafraîchissement  des  objets  stratégies  de  groupe.  Par  défaut,  les  préférences  sont  donc  réappliquées,  c’est­à­dire  réécrites,  au  démarrage  de  l’ordinateur ou lors de l’ouverture de session. Ce mode de fonctionnement assure que les éléments pris en charge  via les Préférences sont dans un état connu, de la même manière que cela est le cas avec les paramètres déclarés  habituellement dans des objets stratégies de groupe.  Attention ! Si l’option Appliquer une fois et ne plus réappliquer est sélectionnée, alors les Préférences sont  appliquées  sur  l’ordinateur  ou  l’utilisateur  uniquement  la  première  fois.  Ce  mode  de  fonctionnement  intéressera  les  administrateurs  qui  souhaitent  offrir  à  certains  utilisateurs  un  environnement  de  départ  que  ces  mêmes utilisateurs pourront modifier si nécessaire.  Ce  mode  de  fonctionnement  peut  aussi  aider  à  personnaliser  l’environnement  par  défaut  mis  à  la  disposition  des  utilisateurs, sans pour autant modifier le profil par défaut utilisé pour créer le profil de l’utilisateur lors de sa première  ouverture de session. 

b. Déploiement et prise en charge des Préférences de stratégies de groupe  L’implémentation  des  Préférences  de  stratégies  de  groupe  est  issue  du  rachat  du  produit  PolicyMaker  Standard  Edition de la société Desktop Standard. Microsoft a aussi fait l’acquisition du produit GPOVault lequel a été adapté  pour  devenir  Advanced  Group  Policy  Management  (AGPM),  et  distribué  comme  élément  du  Microsoft  Desktop  Optimization Pack for Software Assurance.  Ainsi, aujourd’hui, les Préférences des GPO sont disponibles de deux manières :  ●

À l’aide des nouveaux outils d’administration intégrés à Windows Server 2008. 

●

À l’aide de RSAT (Remote Server Administration Tools for Windows Vista), lequel sera disponible sous la forme  d’un  téléchargement  quelques  semaines  après  la  disponibilité  de  Windows  Server  2008  ainsi  que  celle  du  SP1 de Windows Vista. Cette deuxième solution permet aux environnements de domaine basés sur Windows  Server 2003 de supporter les nouvelles Préférences de stratégies de groupe. 

Du  point  de  vue  des  postes  de  travail  clients,  la  prise  en  charge  des  options  et  paramètres  définis  dans  les  Préférences, est assurée sur les systèmes ci­dessous : 

© ENI Editions - All rigths reserved

- 11 -

●

Windows Vista RTM ou ultérieur. 

●

Windows Server 2003 SP1 ou ultérieur. 

●

Windows XP SP2 ou ultérieur. 

Attention  !  Le  support  des  Préférences  des  GPO  nécessite  l’installation  des  CSE  (Client­Side  Extensions)  nécessaires.  Ce  composant  sera  disponible  via  un  téléchargement  du  site  de  Microsoft,  sachant  qu’il  sera  inclus dans la version finale de Windows Server 2008. Notez que l’usage des nouvelles fonctionnalités offertes par  les Préférences ne nécessite aucune licence additionnelle. La figure ci­dessous illustre l’application de cette mise à  jour dans le cas de Windows Vista. 

Installation du package de mise à jour "Windows6.0­KB943729­x86" pour une machine Windows Vista US 32  bits. 

Installation du module "PreferencesCSE" à partir du package KB943729 (version RC)  L’installation  du  composant  assure  la  prise  en  charge  des  différentes  opérations  supportées  par  les  préférences  sous la forme de plusieurs DLL (Dynamic Link Library) intégrées en tant que composants de type GPE (Group Policy  Extensions). 

- 12 -

© ENI Editions - All rigths reserved

La DLL Gpprefcl.dll prend en charge les fonctions de "Group Policy Drive Maps" à la clé GPExtensions. 

c. Familles de paramètres pris en charge par les Préférences de stratégies de groupe  Grâce  à  l’utilisation  des  Préférences  de  stratégies  de  groupe,  vous  pourrez  prendre  en  charge  les  familles  de  paramètres suivants :  Paramètres Windows :  ●

Applications : ce nœ ud de configuration permet aux développeurs d’application d’insérer des ensembles de  paramètres adaptés à leurs applications. 

●

Mappages  de  lecteurs  :  ce  nœ ud  de  configuration  permet  aux  administrateurs  de  créer,  modifier  ou  supprimer des connexions réseau. Il est aussi possible de gérer la visibilité de chaque unité. Cette nouvelle  extension  permet  de  gérer  toutes  les  connexions  réseau  sans  implémenter  de  scripts.  Il  est  possible  de  déclarer  de  multiples  éléments  de  type  "Mappages  de  lecteurs"  en  fonctions  de  multiples  conditions  telles  que  les  appartenances  à  des  groupes,  des  requêtes  LDAP  pures  vers  tout  attribut  disponible  dans  les  services  de  domaine  Active  Directory  ou  même  des  informations  en  rapport  avec  le  matériel.  unités  d’organisation OU. 

●

Environnement : ce nœ ud de configuration permet aux administrateurs de créer, modifier ou supprimer des  variables d’environnement utilisateur ou système. Cette nouvelle extension est très intéressante pour gérer  de manière centralisée l’ensemble des variables d’environnement à utiliser. 

●

Fichiers : ce nœ ud de configuration permet aux administrateurs de créer, modifier ou supprimer des fichiers.  Il est aussi possible de gérer l’ensemble des attributs. Cette nouvelle extension est très intéressante pour  copier des fichiers de configuration dans les dossiers du profil des utilisateurs. Cela peut être le cas avec des  fichiers nécessaires à la personnalisation de certaines applications via le dossier AppData. 

●

Dossiers  :  ce  nœ ud  de  configuration  permet  aux  administrateurs  de  créer,  modifier  ou  supprimer  des  dossiers.  Il  est  aussi  possible  de  gérer  certains  attributs  de  dossiers.  Cette  nouvelle  extension  est  très  intéressante  dans  le  cadre  de  la  maintenance  des  dossiers  temporaires.  Vous  pouvez  ainsi  décider  de  supprimer certains dossiers tels que ceux créés dans la racine du disque système ou purger le contenu du  dossier temporaire de Windows de manière régulière. 

●

Fichiers  .Ini  :  ce  nœ ud  de  configuration  permet  aux  administrateurs  de  créer,  modifier  ou  supprimer  des  sections ou propriétés dans les fichiers de configuration de type fichiers .Ini. 

●

Registre  :  ce  nœ ud  de  configuration  permet  aux  administrateurs  de  créer,  modifier  ou  supprimer  des  paramètres de registre. 

●

Partages  réseau  ­  disponible  dans  les  Préférences  ordinateur  :  ce  nœ ud  de  configuration  permet  aux  administrateurs  de  créer,  modifier  ou  supprimer  des  partages  réseau.  Notez  que  cette  extension  permet  d’activer ou non l’utilisation du mode ABE (Access Based Enumeration). 

●

Raccourcis : ce nœ ud de configuration permet aux administrateurs de créer, modifier ou supprimer des objets 

© ENI Editions - All rigths reserved

- 13 -

raccourcis. Cette nouvelle extension permet de manipuler les objets de type FSO (File System Object), les URL  ainsi que la quasi­totalité des objets de l’environnement Windows (Shell Objects) tels que les extensions du  panneau de configuration, la corbeille, l’explorateur, etc.  Paramètres du panneau de configuration : 

- 14 -

●

Sources de données : ce nœ ud de configuration permet aux administrateurs de créer, modifier ou supprimer  des DSN (Data Source Names) ODBC (Open DataBase Connectivity). 

●

Périphériques  :  ce  nœ ud  de  configuration  permet  aux  administrateurs  de  forcer  l’activation  ou  la  désactivation du fonctionnement de certains pilotes de périphériques ou de certaines classes de pilotes. 

●

Options  de  dossiers  :  ce  nœ ud  de  configuration  permet  aux  administrateurs  de  contrôler  les  différentes  options propres aux dossiers Windows. Il est ainsi possible de gérer les associations propres aux fichiers. 

●

Paramètres  Internet  :  ce  nœ ud  de  configuration  permet  aux  administrateurs  de  contrôler  l’ensemble  des  paramètres  d’Internet  Explorer  pour  Internet  Explorer  5  et  6  et  aussi  Internet  Explorer  7.  En  général,  ces  paramètres  sont  pris  en  charge  par  un  objet  stratégie  de  groupe,  de  manière  à  imposer  et  à  interdire  la  modification  de  ces  paramètres.  L’utilisation  des  Préférences  peut  permettre  de  définir  une  configuration  Internet Explorer par défaut que les utilisateurs pourront alors changer, s’ils le jugent nécessaire. Notez que  certains  paramètres  peuvent  être  complètement  contrôlés  via  un  objet  GPO,  tandis  que  d’autres  peuvent  être simplement proposés via un élément déclaré en tant que Préférence. 

●

Utilisateur et groupes locaux : ce nœ ud de configuration permet aux administrateurs de créer, modifier ou  supprimer  des  utilisateurs  et/ou  groupes  d’utilisateurs  localement  sur  les  ordinateurs.  Cette  fonctionnalité  est  très  intéressante  pour  garantir  un  bon  niveau  de  cohérence  des  comptes  locaux  des  machines.  Il  est  ainsi  plus  facile  de  gérer  le  contenu  des  groupes  importants  tels  que  les  groupes  Utilisateurs  et  Administrateurs locaux des machines. 

●

Options réseau : ce nœ ud de configuration permet aux administrateurs de créer, modifier ou supprimer des  éléments de connexions de type VPN (Virtual Private Network) ou Dial­Up. Cette nouvelle extension est très  intéressante  pour  configurer  les  éléments  de  connexions  des  utilisateurs  distants  sur  leur  ordinateur  portable  de  manière  régulière.  De  cette  manière,  vous  pouvez  facilement  maintenir  l’ensemble  des  paramètres de manière centralisée, et ce, en fonction de multiples critères. 

●

Options  d’alimentation  :  ce  nœ ud  de  configuration  permet  aux  administrateurs  de  créer,  modifier  ou  supprimer les profils de gestion de l’énergie. 

●

Imprimantes  :  ce  nœ ud  de  configuration  permet  aux  administrateurs  de  créer,  modifier  ou  supprimer  des  imprimantes  locales,  réseau  ou  connectées  en  TCP/IP.  Les  stratégies  de  groupe  de  Windows  Vista  supportent  nativement  le  déploiement  des  imprimantes.  Cependant,  cela  ne  concerne  que  les  imprimantes  partagées  et  nécessite  une  extension  du  schéma  Active  Directory.  L’utilisation  des  Préférences  vous  permettra  de  déployer  des  imprimantes  locales,  partagées  ou  connectées  en  TCP/IP  sur  les  postes  fonctionnant sous Windows Vista et aussi sous Windows XP SP2. Cette extension permet aussi de déclarer  l’imprimante par défaut. 

●

Options  régionales  :  ce  nœ ud  de  configuration  permet  aux  administrateurs  de  contrôler  les  paramètres  régionaux. 

●

Tâches  planifiées  :  ce  nœ ud  de  configuration  permet  aux  administrateurs  de  créer,  modifier  ou  supprimer  des  tâches  planifiées.  Il  est  aussi  possible  de  créer  des  tâches  immédiates,  mais  seulement  pour  les  ordinateurs  fonctionnant  sous  Windows  XP.  Cette  nouvelle  extension  est  très  intéressante  pour,  par  exemple, déclarer des tâches de maintenance périodiques. 

●

Services  :  ce  nœ ud  de  configuration  permet  aux  administrateurs  de  contrôler  les  différentes  options  des  services  Windows.  Il  est  possible  de  gérer  les  options  de  démarrage,  de  déclencher  des  actions  de  type  "Start / Stop / Restart", de configurer le compte associé à l’exécution du service ainsi que les propriétés de  récupération en cas d’incident. 

●

Menu Démarrer : ce nœ ud de configuration permet aux administrateurs de contrôler l’ensemble des options  du menu Démarrer pour les machines Windows XP et Windows Vista. 

© ENI Editions - All rigths reserved

Les différentes familles de paramètres pris en charge par les Préférences des objets stratégies de groupe de  Windows Server 2008. 

d. Opérations et Actions sur les Eléments des Préférences  La majorité des extensions inclues dans les nouvelles Préférences de Windows Server 2008 supportent les actions  de contrôle de type "Création, Suppression, Remplacer ou Mettre à jour".  Enfin,  sur  chaque  élément,  l’onglet  Commun  permet  de  personnaliser  le  comportement  lors  du  traitement  des  Préférences. La figure ci­dessous illustre ces nombreuses options. 

© ENI Editions - All rigths reserved

- 15 -

Configuration du comportement d’un élément de type Préférences. 

e. Arrêter le traitement des éléments de cette extension si une erreur survient  Par  défaut,  toute  erreur  d’interprétation  ou  d’exécution  est  ignorée.  De  cette  manière,  le  traitement  des  éléments  des Préférences de la même extension peut continuer. Vous pouvez décider de stopper le traitement des éléments  supplémentaires  de  cette  extension  en  activant  cette  option.  Notez  que  ce  paramètre  est  géré  de  manière  indépendante  pour  chaque  objet  stratégie  de  groupe.  Les  autres  objets  GPO  ne  sont  donc  pas  affectés  par  l’activation de cette option. 

f. Exécuter dans le contexte de sécurité de l’utilisateur connecté (option de stratégie utilisateur)  Cette option, non sélectionnée par défaut, permet de spécifier s’il est nécessaire de traiter l’élément concerné dans  le  contexte  de  l’utilisateur  en  session.  Par  défaut,  le  compte  System  Local  est  utilisé,  permettant  aux  Préférences  d’accéder  aux  variables  d’environnement  du  système  et  des  ressources  locales  à  la  machine.  Pour  accéder,  aux  variables de l’utilisateur, il est donc nécessaire d’activer cette option. 

g. Supprimer l’élément lorsqu’il n’est plus appliqué  À la différence des paramètres de stratégies de groupe qui sont supprimés lorsqu’un objet GPO ne s’applique plus,  les  paramètres  de  Préférences  ne  sont  pas  supprimés.  Dans  le  cas  où  il  est  souhaité  de  retirer  les  éléments  préalablement appliqués, il sera nécessaire d’activer cette option sur l’élément à supprimer. 

h. Appliquer une fois et ne pas réappliquer  Nous savons que les stratégies de groupe s’appliquent de manière régulière sur les ordinateurs et les utilisateurs.  Pour rappel, les objets GPO s’appliquent au démarrage de l’ordinateur, à l’ouverture de session de l’utilisateur, ainsi  qu’à  un  intervalle  dans  la  valeur  est,  par  défaut,  fixée  à  90  minutes  plus  une  période  de  temps  variable  comprise  entre 0 et 30 minutes. Ce rafraîchissement périodique pourra, de fait, provoquer le rétablissement des paramètres  contenus dans les Préférences, même si l’utilisateur en session a effectué des changements sur ces éléments dans  son environnement de travail. Pour éviter le rafraîchissement de ces éléments et donc l’application systématique des  paramètres originaux, il sera nécessaire d’activer cette option. 

i. Ciblage au niveau de l’élément de Préférences  Cette  fonctionnalité  est  certainement  la  plus  puissante.  En  effet,  il  est  possible  au  niveau  de  chaque  élément  de  Préférences  déclaré  de  définir  les  utilisateurs  et/ou  les  ordinateurs  qui  seront  affectés.  Nous  savons  que  depuis  Windows  2000,  le  ciblage  des  objets  stratégies  de  groupe  est  basé  sur  la  nature  du  SOM  (Scope  of  Management),  c’est­à­dire  la  structure  SDOU,  Site/Domaine/OUs,  sur  laquelle  les  objets  stratégies  de  groupe  sont  appliqués.  Windows  XP  Professionnel  apporte  aux  administrateurs  la  possibilité  d’appliquer  des  filtres  WMI,  ces  filtres  WMI  jouant le rôle d’autant de condition à respecter pour appliquer tel ou tel GPO de l’étendue de gestion.  À  la  différence  du  filtrage  WMI  des  objets  stratégies  de  groupe  qui  agit  sur  l’intégralité  des  paramètres  contenus  dans l’objet GPO, les éléments des Préférences des stratégies de groupe supportent un ciblage naturel au niveau de  chaque élément.  Grâce  aux  préférences  et  à  la  capacité  de  ciblage  disponible  sur  chaque  élément,  il  est  possible  de  créer  un  seul  objet  GPO  contenant  des  milliers  de  conditions  pour  appliquer  tel  ou  tel  paramètre  sur  telle  ou  telle  sélection  spécifique de cibles.  La figure ci­dessous illustre la création d’une nouvelle cible basée sur l’appartenance de l’ordinateur à un site et à un  domaine Active Directory donné ainsi que l’appartenance de l’ordinateur à un groupe de sécurité. 

- 16 -

© ENI Editions - All rigths reserved

Utilisation de l’éditeur de ciblage sur un élément de Préférences. 

j. Utilisation des variables au sein de l’éditeur de cibles  Lors de la déclaration des différentes conditions d’application d’un élément, l’administrateur a la possibilité d’utiliser  les  nombreuses  variables  système  prises  en  charge  par  les  extensions  des  Préférences  de  stratégies  de  groupe.  L’ensemble  de  ces  variables  peut  être  utilisé  au  niveau  de  toutes  les  propriétés  définissables  au  niveau  des  éléments ou du ciblage spécifique de chaque élément. Bien qu’il soit possible de directement taper les valeurs de ces  nombreuses variables, il est recommandé d’utiliser la touche [F3] afin d’accéder au sélecteur de variable.  Cette  facilité  évitera  les  immanquables  erreurs  de  syntaxes  et  vous  permettra  de  facilement  utiliser  des  combinaisons  complexes  de  variables  d’environnement  dans  la  définition  des  règles  de  ciblages  rendu  hautement  dynamique. 

© ENI Editions - All rigths reserved

- 17 -

Utilisation du sélecteur de variables à l’aide de la touche [F3]. 

k. Suivi de l’exécution des Préférences des stratégies de groupe  Les Préférences de stratégies de groupe supportent de manière intégrale les analyses RSoP prises en charge par la  nouvelle console de gestion des stratégies de groupe version 6.0.0.1. La figure ci­après illustre une analyse réalisée  à l’aide de la GPMC de Windows Server 2008, incluant le traitement des nouvelles Préférences. 

- 18 -

© ENI Editions - All rigths reserved

Vérification du bon fonctionnement des extensions CSE des Préférences de stratégies de groupe. 

Affichage des paramètres appliqués sur chaque élément déclaré.  La figure ci­dessus montre les paramètres appliqués sur l’objet Menu Démarrer [Windows Vista].  Notez que l’interface du rapport RSoP (Resultant Set of Policy) précise que, dans la catégorie affichée, les paramètres  les plus proches du niveau supérieur du rapport sont utilisés prioritairement pour la résolution des conflits. Dans cet  exemple,  les  paramètres  contenus  dans  l’objet  stratégie  de  groupe  "Experts  Preferences  v1"  sont  appliqués  avec  succès  (Résultat  :  Opération  réussie).  Enfin,  parmi  les  nombreux  paramètres  définis,  le  paramètre Général  intitulé  "Nombre de programmes dans le menu Démarrer" a pris la valeur 12. 

© ENI Editions - All rigths reserved

- 19 -

Comme  cela  est  le  cas  concernant  l’analyse  de  l’application  des  objets  stratégies  de  groupe  sur  les  machines  Windows  XP  Professionnel,  la  nouvelle  console  de  gestion  des  stratégies  de  groupe  sera  l’outil  de  choix  à  utiliser  pour l’analyse et la simulation de l’application des paramètres contenus dans les objets GPO et les Préférences des  objets GPO.  Pour plus de renseignements sur les nouvelles Préférences de stratégies de groupe, vous pouvez consulter  le  site  de  Microsoft  et  chercher  Group  Policy  Preferences.  Vous  pouvez  aussi  consulter  le  site  Microsoft  Technet  dédié  aux  stratégies  de  groupe,  en  utilisant  le  lien  suivant  :  http://technet.microsoft.com/en­ us/windowsserver/grouppolicy/default.aspx 

- 20 -

© ENI Editions - All rigths reserved

Création et configuration d’objets stratégies de groupe  1. Introduction  Les objets stratégies de groupe sont caractérisés par les points ci­dessous :  ●

Il s’agit d’objets appartenant aux services d’annuaire Active Directory dont le principal objectif est d’aider les  administrateurs  du  réseau  Windows  à  offrir  aux  utilisateurs  un  outil  et  un  environnement  de  travail  adapté  encore plus fiable, plus sécurisé, donc plus performant. 

●

Les  stratégies  de  groupe  permettent  de  simplifier  l’administration  en  centralisant  les  paramètres  dans  l’annuaire Active Directory, donc à l’extérieur des ordinateurs. 

●

L’administration est plus fine, plus performante, plus riche, mais aussi plus simple ! 

●

Les paramètres des utilisateurs s’appliquent indépendamment des ordinateurs. 

Nous découvrirons plus loin le mode de traitement par boucle de rappel. Ce mode permet de gérer certaines  situations et fait que dans ce cas précis, les paramètres utilisateurs peuvent ne pas être “considérés” sur les  ordinateurs qui implémentent ce mode de fonctionnement. 

●

Les paramètres ordinateurs s’appliquent indépendamment des utilisateurs. 

2. Stratégies de groupe et relation avec les technologies  Les  stratégies  de  groupe  intégrent  un  nombre  important  de  technologies.  Il  est  indispensable  de  savoir  “Qui  fait  quoi” ? Le tableau ci­après liste les technologies à utilisées pour rendre le meilleur service.  Technologies utilisées pour mettre en œuvre le  service 

Fonctionnalités 

Active Directory   Stratégie de groupe  Fichiers hors connexion  Gestion des données utilisateur Active Directory  Gestionnaire de synchronisation  Quotas de disque  Profils d’utilisateurs itinérants  Active Directory  Installation et maintenance des logiciels Active  Directory 

Stratégie de groupe  Windows Installer  Active Directory 

Gestion des paramètres utilisateur  Profils d’utilisateurs itinérants 

Gestion des paramètres ordinateur 

Comptes d’utilisateurs et d’ordinateurs Active  Directory  Active Directory 

Services d’installation à distance (RIS) 

Stratégie de groupe  Services d’installation à distance 

© ENI Editions - All rigths reserved

- 1-

Le  tableau  ci­dessus  montre  à  quel  point  les  services  d’annuaire  Active  Directory  sont  indispensables  pour  la  technologie IntelliMirror.  La suite de ce chapitre introduit les détails d’un objets stratégie de groupe au sein des services d’annuaire  Active Directory. 

3. Que contient une stratégie de groupe ?  Une  stratégie  de  groupe  est  composée  de  différents  types  ou  familles  de  paramètres,  lesquels  sont  présentés  ci­ dessous.  Une  fois  que  nous  aurons  bien  appréhendé  les  possibilités  intrinsèques  des  objets  stratégies  de  groupe,  nous détaillerons l’implémentation de ces objets au sein d’une infrastructure Active Directory. 

a. Modèles administratifs  Un  objet  stratégie  de  groupe  intègre  des  modèles  qui  prennent  en  charge  les  paramètres  du  registre  situés  aux  emplacements suivants : pour les paramètres utilisateurs, la clé HKEY_CURRENT_USER et, pour les ordinateurs, la  clé HKEY_LOCAL_ MACHINE. Ces modèles sont implémentés sous la forme de fichiers .adm lesquels sont au départ  situés dans le répertoire %Systemroot\inf. Grâce à ces modèles, et à ceux qui sont livrés avec les différents Kit de  Ressources Techniques d’Office (versions 2000, XP, 2003 et 2007), vous pourrez aussi configurer très finement tous  les détails de ces suites bureautiques. Bien entendu, vous pourrez aussi créer vos propres modèles et les intégrer à  l’intérieur d’objets stratégies de groupe pour diffuser vos paramètres vers tout ou partie du réseau de l’entreprise.  Ces  modèles  sont  appelés  Modèles  administratifs,  ou  “Administrative  Templates”  en  anglais.  Les  informations  de  registre  “ordinateur”  stockées  à  la  clé  de  registre  HKEY_LOCAL_MACHINE,  sont  physiquement  placées  dans  GPT\Machine\Registry.pol,  tandis  que  les  informations  de  registre  “utilisateur”  stockées  à  la  clé  HKEY_CURRENT_USER  sont  physiquement  placées  dans  GPT\User\Registry.pol.  Il  n’est  pas  possible de modifier directement les fichiers .pol qui adoptent un format binaire compressé. Ces fichiers binaires ne  sont  que  le  résultat  des  manipulations  réalisées  à  l’aide  de  la  console  de  gestion  MMC  “Editeur  d’objets  de  stratégie de groupe”.  Les  modèles  d’administration  vous  permettront  de  contrôler  le  comportement  et  la  présentation  du  bureau,  la  gestion des fonctions de recherches d’imprimantes ainsi que, par exemple, la possibilité de bloquer l’accès aux outils  d’édition du registre.  Le tableau ci­dessous liste les différents modèles livrés sur les systèmes Windows 2000, Windows XP Professionnel  et les systèmes de la famille Windows Server 2003.  Nom du modèle dans %Systemroot%\inf 

Rôle/description 

System.adm 

Ensemble des paramètres système. 

Inetres.adm 

Ensemble des paramètres d’Internet Explorer. 

Wmplayer.adm 

Ensemble des paramètres de Windows Media Player.  Cette fonction n’est pas disponible sur Windows XP  64 bits Edition et sur Windows Server 2003 64 bits  Editions. 

Conf.adm 

Ensemble des paramètres de NetMeeting. Cette  fonction n’est pas disponible sur Windows XP 64 bits  Edition et sur Windows Server 2003 64 bits Editions. 

Wuau.adm 

Ensemble de paramètres des services Windows  Update. 

Modèles spécifiques aux anciens systèmes Vous  trouverez  dans  le  répertoire  %Systemroot%\inf  tous  les  fichiers  de  types  modèles,  dont  les  modèles  administratifs  utilisés  par  les  stratégies  locales  et  les  stratégies  de  groupe.  Les  modèles  spécifiés  ci­dessous sont  disponibles  dans  le  système  à  des  fins  de  compatibilité  avec  les  anciennes  stratégies  système  utilisables  sur  les  ordinateur fonctionnant sous Windows NT et Windows 9x.  Common.adm 

- 2-

© ENI Editions - All rigths reserved

Ce modèle est spécifique aux systèmes d’exploitation NT/Win95/98 et est utilisable via Poledit, l’éditeur de stratégies  système de Windows 9x et Windows NT.  L’utilitaire de stratégies système de Windows 9x et Windows NT était livré au sein du système Windows 2000. Cela  n’est plus le cas sous Windows XP Professionnel et Windows Server 2003.  Windows.adm  Spécifique à Windows 9x.  Winnt.adm  Spécifique à Windows NT 4.0.  Inetset.ADM  Paramètres Internet Explorer de type Internet spécifiques aux systèmes pré Windows 2000.  Inetcorp.ADM  Paramètres Internet Explorer de type Corporate spécifiques aux systèmes pré Windows 2000. 

Objet stratégie de groupe contenant des modèles non supportés  La figure précédente montre une stratégie de groupe personnalisée contenant les modèles additionnels de Microsoft  Office 2003 mais aussi des modèles non supportés. En effet, ces modèles sont prévus pour être utilisés par Poledit,  l’éditeur de stratégies système de Windows NT 4.0 et Windows 9x.  Le fait que certains modèles incompatibles soient “rangés” dans le nœ ud “Modèles d’administration non pris  en  charge”  ne  signifie  pas  que  l’objet  stratégie  de  groupe  soit  invalide.  L’objet  est  toujours  opérationnel  pour  tout  ce  qui  est  valide.  Il  s’agit  juste  d’une  information  pour  avertir  l’administrateur  d’un  problème  d’administration potentiel. 

b. Règles de sécurité pour les ordinateurs et modèles de sécurité  Les stratégies de groupe vous permettent de réaliser de nombreuses tâches pénibles de manière homogène pour  protéger les ressources de l’ordinateur des nombreuses agressions possibles du réseau. Ainsi, vous pouvez intégrer  dans une stratégie de groupe vos propres modèles de sécurité, les modèles étant eux­mêmes fabriqués à l’aide de  la  console  de  gestion  des  Modèles  de  sécurité.  Une  fois  un  modèle  créé,  vous  pouvez  ensuite  l’intégrer  dans  une  stratégie  de  groupe  pour  qu’il  soit  à  la  disposition  des  ordinateurs  souhaités.  Les  règles  de  sécurité  intégrent  les  éléments de configuration ci­dessous : 

© ENI Editions - All rigths reserved

- 3-

●

paramètres d’authentification réseau et accès aux ressources, 

●

configuration des réglages des messages d’audit dans les journaux de sécurité, 

●

la vérification de l’appartenance à des groupes de sécurité spécifiés. 

La figure ci­après illustre parfaitement les grandes catégories d’éléments que vous pourrez contrôler à l’aide d’une  stratégie de groupe. Ces catégories sont listées ci­dessous :  ●

les  paramètres  des  Stratégies  de  comptes  du  domaine  mais  aussi  des  machines  locales  lorsqu’il  est  nécessaire de gérer aussi les paramètres de stratégies de comptes locaux, 

●

les stratégies locales de sécurité, c’est­à­dire  les  stratégies  d’audit, d’attribution  des  droits  systèmes  ainsi  que les nombreuses options de sécurité, 

●

les paramètres de journaux d’événements, 

●

la  gestion  des  groupes  restreints.  Cette  fonctionnalité  permet  de  garantir  que  les  groupes  “importants”  contiennent bien les membres qui doivent s’y trouver et aucune autre personne non habilitée. 

●

les paramètres de sécurité des services. Vous pourrez par exemple déléguer le droit de stopper, mettre en  pause et démarrer un service particulier à un utilisateur particulier. 

●

les paramètres de sécurité sur les clés du registre et des répertoires disque de l’ordinateur, 

●

les paramètres de clé publique, de restriction logicielle et de stratégies IPSec dans Active Directory. 

Stratégie de groupe et famille de paramètres de sécurité 

Les modèles de sécurité sont placés dans le répertoire %Systemroot%\Security\Templates et sont ensuite  importables au sein d’un objet stratégie de groupe.  Les  modèles  de  sécurité  prédéfinis  sont  fournis  comme  point  de  départ.  Ils  pourront  vous  servir  pour  créer  vos  propres stratégies de sécurité à l’aide de la console de gestion MMC “Modèles de sécurité”. Une fois vos modèles mis  au  point  vous  pourrez  configurer  des  dizaines,  des  centaines  ou  milliers  d’ordinateurs  en  important  vos  modèles  dans une stratégie de groupe. 

- 4-

© ENI Editions - All rigths reserved

Les  modèles  sont  aussi  utilisables  pour  servir  de  référence  dans  le  cadre  de  l’analyse  d’éventuelles  défaillances de sécurité à l’aide de la console de gestion MMC “Configuration et analyse de la sécurité”.  Les différents modèles livrés sur un serveur Windows Server 2003 sont brièvement décrits ci­dessous :  Modèle “Setup security.inf”, Sécurité par défaut Ce modèle est créé au cours de l’installation de l’ordinateur. Il contient l’ensemble des paramètres de sécurité par  défaut. Il peut être utilisé sur les serveurs et les ordinateurs clients.  Il  est  fortement  recommandé  de  ne  pas  appliquer  ce  modèle  à  l’aide  d’une  stratégie  de  groupe.  Compte  tenu  du  volume  d’informations  contenu  dans  ce  modèle  (702  Ko),  il  pourrait  sérieusement  dégrader  les  performances.  De  plus,  ce  modèle  ne  doit  pas  être  appliqué  à  un  serveur  de  type  contrôleur  de  domaine.  Vous  pouvez,  par  contre,  appliquer  tout  ou  partie  des  paramètres  contenus  dans  ce  modèle  dans  le  cadre  d’une  récupération d’urgence. Pour appliquer tout ou partie de ce modèle, utilisez la commande Secedit. 

Sécurité par défaut du contrôleur de domaine (DC security.inf) Ce  modèle  est  automatiquement  créé  lorsqu’un  serveur  est  promu  contrôleur  de  domaine.  Il  contient  tous  les  paramètres de sécurité par défaut des répertoires, fichiers, registre et autres services système. Il peut être appliqué  à l’aide de la console de gestion MMC “Configuration et analyse de la sécurité” ou à l’aide de la commande Secedit.  Modèle “Compatible” : Compatws.inf Ce  modèle  contient  les  autorisations  par  défaut  initialement  accordées  aux  groupes  locaux  Administrateurs,  Utilisateurs  avec  pouvoir  et  Utilisateurs.  Normalement,  les  membres  du  groupe  local  Utilisateurs  doivent  être  capables  de  faire  fonctionner  les  applications  disposant  du  logo  Windows  2000  ou  Windows  XP  Compatible.  Cependant, il est toujours possible que les utilisateurs ne puissent pas exécuter des applications incompatibles.  Vous pourrez alors opter pour l’une des deux solutions ci­dessous :  ●

autoriser les membres du groupe Utilisateurs à devenir membres du groupe Utilisateurs avec pouvoir, 

●

donner plus de droits au groupe Utilisateurs. 

Le  modèle  “Compatible”  est  destiné  à  éviter  que  vous  choisissiez  le  premier  choix.  En  effet,  la  deuxième  option  modifiera les autorisations par défaut des fichiers et de certaines clés du registre accordées au groupe Utilisateurs.    N’appliquez pas le modèle “Compatible” aux contrôleurs de domaine.

Modèle “Sécurisé” : Secure*.inf Ce modèle définit de meilleurs paramètres de sécurité que ceux obtenus à l’issue de l’installation du système. Parmi  les paramètres modifiés, vous retrouverez les paramètres de mot de passe, de verrouillage de compte et d’analyse  plus détaillés. Pour aller dans le même sens, l’utilisation du protocole d’authentification LAN Manager et NTLM sont  désactivés.  De  fait,  les  clients  sont  configurés  pour  n’envoyer  que  des  réponses  de  type  NTLMv2  tandis  que  les  serveurs refusent les réponses LAN Manager.  Le modèle de sécurité Securews.inf impose que tous les contrôleurs de domaine contenant les comptes de  tous  les  utilisateurs  qui  se  connectent  au  client  doivent  exécuter  Windows  NT  4.0  Service  Pack  4  ou  une  version ultérieure. 

Les  ordinateurs  de  type  Windows  for  Workgroups  3.11,  Windows  95  et  Windows  98  qui  ne  sont  pas  équipées  du  Client  Active  Directory  prennent  en  charge  uniquement  LAN  Manager.  Il  n’y  a  donc  aucun  support de l’authentification NTLM. 

Notez  aussi  que  le  modèle  “Sécurisé”  active  la  signature  des  paquets  SMB  (Server  Message  Block)  côté  serveur,  habituellement désactivée par défaut.  Windows  Me  (Millennium  Edition)  n’a  pas  besoin  du  client  Active  Directory  pour  s’authentifier.  En  effet,  Windows Me prend en charge NTLMv2 sans modification supplémentaire. 

© ENI Editions - All rigths reserved

- 5-

Modèle “Hautement sécurisé” : hisec*.inf Ce  modèle  est  une  version  encore  plus  sécurisée  du  modèle  précédent.  Il  impose  donc  des  restrictions  supplémentaires en terme de cryptage et des signatures nécessaires pour l’authentification et pour les données qui  circulent sur les canaux sécurisés et entre les clients et les serveurs SMB. Par exemple, alors que le modèle Sécurisé  impose aux serveurs de refuser les réponses de LAN Manager, le modèle Hautement sécurisé leur impose de refuser  les réponses de LAN Manager et aussi les réponses NTLM. Sur le même principe, alors que le modèle Sécurisé active  la signature des paquets SMB côté serveur, le modèle Hautement sécurisé l’exige. En outre, le modèle Hautement  sécurisé  exige  un  cryptage  renforcé  et  la  signature  pour  les  données  de  canaux  sécurisés  qui  établissent  des  relations de confiance de domaine à membre et de domaine à domaine.  Modèle “Sécurité de la racine du système” : Rootsec.inf Ce modèle spécifie les autorisations sur la racine des disques. Par défaut, Rootsec.inf définit ces autorisations pour  la racine du lecteur système. Vous pouvez utiliser ce modèle pour réappliquer les autorisations d’accès au répertoire  racine  si  elles  ont  été  modifiées  par  inadvertance  ou  vous  pouvez  modifier  le  modèle  pour  appliquer  les  mêmes  autorisations d’accès à la racine à d’autres volumes.  Le modèle “Sécurité de la racine du système” n’écrase pas les autorisations explicites définies sur les objets  enfants.  Il  propage  uniquement  les  autorisations  qui  ont  été  héritées  et  aucunement  les  autorisations  explicites. 

Modèle “Aucun SID utilisateur Terminal Server” : Notssid.inf Les  droits  par  défaut  sur  les  disques  ainsi  que  les  listes  de  contrôle  d’accès  du  registre  situées  sur  les  serveurs  accordent des autorisations à un identificateur de sécurité (SID) spécifique à Terminal Server. Le SID Terminal Server  est utilisé uniquement lorsque Terminal Server est exécuté en mode de compatibilité d’application. Si Terminal Server  n’est  pas  opérationnel  sur  le  serveur  en  question,  ce  modèle  peut  être  appliqué  pour  supprimer  les  SID  Terminal  Server inutiles.  Recommandations concernant l’usage des modèles Ces modèles de sécurité ont été conçus pour être utilisés sur des ordinateurs disposant au départ des paramètres  de sécurité par défaut. En fait, ces modèles sont implémentés de manière incrémentielle au­dessus des paramètres  de  sécurité  par  défaut,  s’ils  sont  présents  sur  l’ordinateur.  Il  faut  donc  être  conscient  qu’ils  n’installent  pas  les  paramètres de sécurité par défaut avant d’effectuer les modifications.  Les modèles de sécurité prédéfinis ne doivent pas être appliqués aux systèmes de production sans avoir été validés  au préalable.  Vous  ne  pouvez  pas  sécuriser  des  systèmes  Windows  2000,  Windows  XP  ou  Windows  Vista  installés  sur  des  systèmes de fichiers FAT (File Allocation Table).  La figure suivante montre les nombreux fichiers de types modèles de sécurité présents sur un système fonctionnant  sous Windows Server 2003. 

De nombreux modèles de sécurité sont disponibles sur le site Microsoft en téléchargement 

- 6-

© ENI Editions - All rigths reserved

Vous  trouverez  le  “Windows  Server  2003  Security  http://www.microsoft.com/downloads/details.aspx?FamilyId =   521EA6C7B4DB&displaylang=en  ainsi  que  le  “Windows  XP  Security  with  http://www.microsoft.com/downloads/details.aspx?FamilyId =   09A8A229F118&displaylang=en 

Guide” 

SP2" 

à 

à 

l’adresse  suivante  :  8A2643C1­0685­4D89­B655­ l’adresse  suivante  :  2D3E25BC­F434­4CC6­A5A7­

Les  guides  de  sécurité  publiés  sur  le  site  de  Microsoft  existent  pour  les  systèmes  de  la  famille  Windows  2000,  Windows  XP  Professionnel  et  la  famille  Windows  Server  2003.  Ils  existent  aussi  pour  Microsoft  Exchange  2000  et  Microsoft Exchange Server 2003. Ils décrivent les fonctionnalités et tous les détails des paramètres de configuration  et  leur  meilleur  cadre  d’utilisation  ainsi  que  les  effets  négatifs  qu’ils  pourraient  générés.  Par  exemple,  le  guide  de  Windows XP Professionnel SP2 décrit les modèles de sécurité qui prennent en charge les nouveaux paramètres du  firewall Windows qui remplace le précédent ICF (Internet Connection Firewall), ainsi que de nombreuses informations  sur  la  sécurisation  des  ports  TCP/IP,  du  protocole  RPC  (Remote  Procedure  Call),  des  nouvelles  fonctionnalités  de  protection mémoire et la sécurisation des services Internet (Internet Explorer, Outlook Express, etc.).  Sécurisation  de  Windows  Vista  :  vous  trouverez  en  téléchargement  sur  le  site  de  Microsoft  le  Guide  de  sécurité  de  Windows  Vista.  Il  fournit  des  centaines  de  recommandations  et  procédures  pour  renforcer  au  maximum  le  niveau  de  sécurité  du  système.  De  multiples  configurations  sont  proposées  sachant  que  la  configuration recommandée est appelée Enterprise Client. Ce guide propose aussi une configuration appelée SSLF  (Specialized Security ­ Limited Functionality), laquelle limite de manière considérable les fonctionnalités intégrées à  Windows Vista. Ce guide téléchargeable à l’adresse ci­dessous contient aussi le fichier Windows  Vista  Security  Guide  Settings.xls,  et  l’outil  GPOAccelerator  tool  pour  vous  aider  à  implémenter  les  différentes  recommandations. http://go.microsoft.com/fwlink/?LinkId=74028  Le  Guide  de  sécurité  de  Windows  Vista  est  aussi  disponible  en  ligne  sur  le  site  Microsoft  Technet  à  l’adresse  :  http://technet.microsoft.com/en­us/bb629420.aspx 

c. Gestion des applications  Les  services  de  gestion  des  logiciels  sont  l’un  des  éléments  les  plus  importants  qui  soit.  La  problématique  liée  au  fonctionnement des applications a nécessité la mise en œ uvre de systèmes d’exploitation lourds tels que Windows  NT ou les différentes versions de noyaux basés sur Unix. Pour s’en convaincre, il suffit de constater qu’il en est de  même avec Apple. Effectivement, la dernière version Mac OSX (noyau Darwin) est basée sur un dérivé de Nextstep,  lui­même basé sur un Unix de type BSD.  Cette complexité, tant des systèmes que des applications n’a eu de cesse de provoquer les nombreux problèmes de  fonctionnement “post  déploiement”. En  effet,  quel  que  soit  le  système  d’exploitation (Windows, Unix, Mac OS), les  systèmes  sont  fragiles  dès  lors  que  les  configurations  changent  !  Il  était  donc  indispensable  de  progresser  sur  ce  point pour pouvoir rendre le poste de travail plus dynamique qu’il ne l’était.  Les  composants  de  gestion  et  de  maintenance  des  logiciels  intégrés  au  cœ ur  de  Windows  2000  et  des  versions  ultérieures  via  le  moteur  d’installation  Windows  Installer  sont  des  éléments  essentiels.  Ensuite,  vous  aurez  la  possibilité d’utiliser cette technologie pour finalement intégrer les applications à déployer à l’aide d’objets stratégies  de groupe.  La figure suivante illustre ce principe. 

L’application Adobe Acrobat Reader est attribuée aux ordinateurs concernés par cette stratégie de groupe 

© ENI Editions - All rigths reserved

- 7-

Nous découvrirons plus loin que les applications peuvent être déployées, supprimées, mises à niveau dans la même  famille  de  produit  ou  de  manière  concurrentielle,  mais  qu’aussi  il  sera  possible  de  “patcher”  toute  application  déployée via IntelliMirror, c’est­à­dire à l’aide d’Active Directory et des stratégies de groupe.  Comme le montre la figure précédente, les services d’installation vous permettront de déployer les applications vers  des  ordinateurs.  De  cette  manière,  tous  les  utilisateurs  des  dits  ordinateurs  auront  la  possibilité  d’utiliser  les  applications. Les applications pourront aussi être déployées vers des utilisateurs, de telle sorte que les applications  ne concernent que les utilisateurs visés, et ce quelle que soit la machine.  Le déploiement des logiciels à l’aide des stratégies de groupe est traité en détail dans le chapitre suivant.  Pour  en  savoir  plus  sur  les  caractéristiques  du  service  Windows  Installer,  les  différentes  versions  et  ses  grands principes de fonctionnement, reportez­vous au chapitre suivant ou au site MSDN (Microsoft Developer  Network)  à  l’adresse  suivante  :  http://msdn.microsoft.com/library/default.asp?url = /library/en­ us/msi/setup/about_windows_installer.asp  WSUS  3.0  et  SCCM  2007  :  à  propos  des  autres  technologies  et  outils  Microsoft  qui  permettent  de  patcher  les  logiciels et les systèmes d’exploitation.  La technologie de gestion et de maintenance des logiciels est directement dépendante de ce que permet de faire le  moteur  Windows  Installer.  Le  moteur  a  été  conçu  pour  prendre  en  charge  les  applications  conformes  aux  spécifications Windows 2000 et ultérieures. Ainsi, il n’est pas envisagé, du moins pour le moment, de faire en sorte  que le service Windows Installer prenne en charge le passage des correctifs propres aux systèmes d’exploitation.  La stratégie de Microsoft est très claire : les systèmes d’exploitation doivent évoluer à leur rythme et les applications  aussi.  Ainsi,  pour  deux  problématiques  différentes,  la  stratégie  veut  qu’il  y  ait  deux  technologies  de  gestion  différentes : une pour les systèmes et une pour les applications. Les systèmes utilisent les services Windows Update  disponibles via http (et le protocole de transfert intelligent de fichiers BITS) ou la version WSUS 3.0.  Les  services  WSUS  permettent  de  mieux  contrôler  le  passage  des  patchs  à  l’intérieur  du  réseau  de  l’entreprise,  sachant que SCCM 2007 (System Center Configuration Manager 2007) intègre lui aussi une gestion des correctifs très  sophistiquée avec un suivi avancé et des rapports très détaillés.  En plus des méthodes présentées plus haut, il est toujours possible d’obtenir les correctifs et autres mises à  jour  via  Internet  au  travers  de  deux  sites  distincts  :  les  correctifs  Windows  sont  disponibles  sur  le  site  Windows  Update  à  l’adresse  :  http://windowsupdate.microsoft.com  ;  les  correctifs  Office  sont  disponibles  sur  le  site Office Update à l’adresse : http://office.microsoft.com/officeupdate 

●

WSUS  peut  sur  les  ordinateurs  du  réseau  détecter  les  mises  à  jour  non  réussies  et  autres  manques  de  correctifs. 

●

WSUS  permet  la  suppression  des  correctifs  et  la  définition  des  fréquences  auxquelles  les  ordinateurs  du  réseau doivent s’assurer qu’ils sont bien à jour. 

●

Pour les installations qui ne nécessitent pas le redémarrage de l’ordinateur, le passage des correctifs peut  être complètement silencieux, donc transparent pour les utilisateurs. 

●

Les  serveurs  WSUS  peuvent  être  chaînés  entre  eux  avec  une  indépendance  ou  non  des  pouvoirs  d’administration. 

●

Le transfert des correctifs utilise la technologie BITS ­ Background Intelligent Transfer Service, et le moteur  Windows Installer pour être non agressif vis­à­vis de la bande passante disponible sur le réseau. 

●

Les téléchargements disposent d’une gestion des points d’arrêt et le moteur BITS est capable de travailler  en mode delta de fichiers binaires compressés. 

●

WSUS  offre  aux  administrateurs  la  possibilité  d’utiliser  de  nouveaux  rapports  pour  réaliser  toutes  les  statistiques utiles concernant le passage des correctifs. 

●

WSUS est une plate­forme centrale de gestion des modifications. 

Pour  plus  d’informations  sur  WUS,  consultez  http://www.microsoft.com/windowsserversystem/wus/default.mspx  http://www.microsoft.com/technet/security/topics/patch/default.mspx 

les 

liens 

Pour pouvoir installer les services WSUS 3.0 vous devez disposer des éléments suivants : 

- 8-

© ENI Editions - All rigths reserved

ci­dessous 

:  et 

●

Windows Server 2003 SP1 ou SP2 

●

IIS 6.0 

●

Microsoft .NET Framework 2.0 

●

Microsoft Management Console 3.0 

●

Microsoft Report Viewer 

●

L’installation  de  Microsoft  SQL  Server  2005  SP1  n’est  pas  obligatoire.  Dans  ce  cas,  le  programme  d’installation de WSUS installera une base MSDE (Windows Internal Database). 

À propos du support des services WSUS 3.0 et Windows Server 2008  Microsoft a publié début mars 2008 la version SP1 des services WSUS 3.0 en version x86 et aussi x64. Cette version  de WSUS supporte les fonctionnalités ci­dessous :  ●

Support de Window Server 2008. 

●

Intégration des WSUS au sein du Gestionnaire de serveur de Windows Server 2008. 

●

Nouvelles API client. 

●

Support des mécanismes de distribution pour les plates­formes non Windows. 

●

Amélioration de l’enregistrement des Clients. 

●

Filtrage des Mises à jour par Catégories et Classification. 

●

Rapport du statut des mises à jour pour chaque client. 

●

Publication  avancée  des  drivers  via  les  API  d’administration  existantes  et  les  catalogues  fournis  par  les  fournisseurs de pilotes. 

●

Support de la notion de "bundles" (ensemble de patchs). 

●

Support de conditions d’applications (prerequisites). 

Le  SP1  de  WSUS  3.0  est  disponible  sur  le  site  Microsoft  Connect  en  version  RC.  La  version  finale  du  SP1  devrait être livrée peu après le lancement officiel de Windows Server 2008 et ainsi permettre une intégration  parfaite sur Windows Server 2008. Microsoft a récemment annoncé que la prochaine version majeure des services  WSUS  sera  directement  intégrée  à  la  prochaine  version  majeure  de  Windows  Server  (nom  de  code  Windows  7  Server). 

d. Gestion de l’exécution des scripts  Les stratégies de groupe vous permettent de déclarer différents niveaux de scripts. Il est ainsi possible de déclarer  des scripts aux moments suivants :  ●

Scripts au démarrage de l’ordinateur, 

●

Scripts à l’ouverture de session de l’utilisateur, 

●

Scripts à la fermeture de session de l’utilisateur, 

●

Scripts à l’arrêt de l’ordinateur. 

© ENI Editions - All rigths reserved

- 9-

Les stratégies de groupe permettent une meilleure prise en charge de l’exécution des scripts  En plus de gérer l’exécution des scripts à ces moments importants, vous pourrez aussi déclarer de multiples scripts  les uns derrière les autres. Chaque script déclaré est directement stocké dans le volume système à un emplacement  tel  que  celui­ci : %Systemroot%\Windows\SYSVOL\sysvol\Corp2003.Corporate.net\Policies\ {C8C119A6­1426­44EE­ 849F­324A3B76820C}\Machine\Scripts\Startup.  Les scripts que vous utiliserez pourront être écrits sur la base des technologies de scripts prises en charge de base,  c’est­à­dire les scripts VBScript et JScript au travers de WSH ­ Windows Scripting Host. 

e. Gestion des services d’installation à distance RIS  Les  services  d’installation  à  distance  RIS  (Remote  Installation  Services)  permettent  de  déployer  un  système  d’exploitation  sur  des  ordinateurs.  Ils  supportent  un  mécanisme  qui  permet  aux  ordinateurs  du  réseau  de  se  connecter au serveur RIS lorsque le poste de travail invoque un “Boot from network” à l’aide de la touche [F12] de  l’ordinateur.  Un  serveur  RIS  fonctionnant  sous  Windows  Server  2003  peut  prendre  en  charge  l’installation  et  le  déploiement d’images RIS de types Windows Server 2003, Edition Standard et Entreprise, Windows 2000 Server et  Advanced Server, Windows 2000 et Windows XP Professionnel. Les services RIS peuvent être utilisés pour installer  un système d’exploitation complet sur une nouvelle machine ou bien pour restaurer une configuration particulière sur  système défaillant. 

Choix des options offertes aux utilisateurs qui invoqueront le service  La figure illustre les options “utilisateur” que vous pourrez gérer. 

- 10 -

© ENI Editions - All rigths reserved

Liste des opérations autorisées et non autorisées accordées aux utilisateurs des services d’installation à distance  Les  seuls  paramètres  destinés  aux  utilisateurs  qui  solliciteront  un  serveur  RIS  sont  déclarés  sur  cette  fenêtre.  En  fonction  de  ou  des  stratégies  de  groupe  qui  concernent  un  utilisateur  donné,  les  paramètres  gagnant  seront  appliqués.  Les services WDS remplacent RIS  À partir de Windows Server 2003 SP1, il est possible de remplacer l’utilisation des services RIS par les services WDS  (Windows Deployment Services), via WAIK (Windows Automated Installation Kit). Ce package existe sous la forme d’une  image ISO (fichier.img) d’environ 1 Go. En utilisant Windows AIK, vous pourrez réaliser des installations automatisées  de Windows Vista, capturer des images Windows via ImageX et créer vos propres images Windows PE 2.0.  Pour  télécharger  WAIK  (incluant  les  services  WDS),  recherchez  sur  le  site  Microsoft  le  terme  "Windows  Automated Installation Kit (AIK)". Notez que les services WDS inclus dans WAIK sont intégrés dans le SP2 de  Windows  Server  2003  et  que  Windows  Server  2008  dispose  d’une  version  plus  sophistiquée  des  services  WDS,  notamment par le support du déploiement des images en mode multicast. 

f. Gestion des paramètres de configuration et de sécurité d’Internet Explorer  La configuration est particulièrement riche. En effet, Internet Explorer est un composant très important de la plate­ forme  Windows,  au  même  titre  que  peut  l’être  le  shell  (le  bureau)  de  Windows  !  Dans  la  mesure  où  IE  et  ses  composants  sont  souvent  sollicités,  sécuriser  IE  revient  à  grandement  sécuriser  le  système.  À  quoi  bon  sécuriser  l’OS, si les applications ne le sont pas, et vice versa. Pour ceux qui ont utilisé IEAK ­ Internet Explorer Administration  Kit, pour personnaliser Internet Explorer 4.0, 5.0 ou 6.0, vous retrouverez tous ces paramètres dans les stratégies  de groupe. 

© ENI Editions - All rigths reserved

- 11 -

Paramètres “Utilisateur” de type Configuration générale 

Paramètres “Utilisateur” à caractère administratif  Les paramètres d’Internet Explorer sont ventilés dans trois grandes rubriques :  ●

Dans  la  partie  Ordinateur  à  l’emplacement  Configuration  ordinateur/Modèles  d’administration/  Composants  Windows/Internet  Explorer  pour  tout  ce  qui  est  en  rapport  avec  les  zones  de  sécurité  Internet,  les  paramètres  de  proxy  pour  l’ordinateur,  de  telle  sorte  que  les  utilisateurs  n’auront  pas  la  possibilité d’altérer cette valeur ainsi que les paramètres de mise à jour d’Internet Explorer, ses composants  et aussi les composants tiers. 

●

Dans  la  partie  Utilisateur  à  l’emplacement  Configuration  utilisateur/Paramètres  Windows/  Maintenance  de Internet Explorer pour tout ce qui est en rapport avec la personnalisation de l’interface, des connexions,  des  URL  principales,  des  favoris,  des  paramètres  de  sécurité  et  Authenticode  et  de  la  configuration  des  programmes par défaut Internet. 

●

Dans  la  partie  Utilisateur  à  l’emplacement  Configuration  utilisateur/Modèles  d’administration/  Composants  Windows/Internet  Explorer pour tout ce qui traite des options du panneau de configuration  Internet,  des  pages  hors  connexion,  des  menus  du  navigateur,  des  barres  d’outils  et  des  contrôles  autorisés. 

g. Redirection des dossiers utilisateurs (dossiers spéciaux)  Les stratégies de groupe vous offrent la possibilité de rediriger certains dossiers spéciaux vers des emplacements  réseau  à  l’aide  d’une  extension  intégrée  aux  stratégies  de  groupe.  Cette  extension  qui  est  aussi  un  principe,  est 

- 12 -

© ENI Editions - All rigths reserved

appelée “Redirection de dossiers”.  La redirection de dossiers est une stratégie de groupe de type Utilisateurs. Cela signifie qu’un utilisateur pour lequel  vous configurez la redirection de dossiers devra faire l’objet de l’application d’une stratégie de groupe le concernant.  Après avoir créé la stratégie de groupe et l’avoir associée au conteneur adéquat, un administrateur peut désigner  les  dossiers  qui  devront  être  redirigés  et  vers  quel  emplacement  local  ou  réseau.  Cette  option  est  située  à  l’emplacement  suivant  dans  l’objet  de  stratégie  de  groupe  :  Configuration  Utilisateur\Paramètres  Windows\Redirection de dossiers.  Les dossiers spéciaux sont au nombre de quatre :  ●

Application Data, 

●

Bureau, 

●

Mes documents, 

●

Menu Démarrer. 

Le nœ ud “Redirection de dossiers” comporte uniquement ces dossiers, dits “Spéciaux”. Il n’est pas possible  de rajouter d’autres dossiers contrôlés par la redirection de dossiers.  Plusieurs  niveaux  de  redirection  sont  possibles.  En  allant  dans  les  propriétés  du  dossier  à  rediriger,  vous  pouvez  choisir parmi les deux grands modes présentés ci­dessous :  ●

Le premier mode est appelé redirection de dossiers de base. Il est relativement efficace puisqu’il permettra  à l’administrateur de :  ●

Rediriger vers l’emplacement suivant : permet de rediriger le dossier vers une destination de votre  choix.  L’usage  de  la  variable  %username%  vous  permettra  d’utiliser  un  répertoire  pour  chaque  utilisateur. 

●

Rediriger  vers  l’emplacement de l’utilisateur  local : ce choix revient au comportement par défaut  pour le choix de l’emplacement du dossier en l’absence de redirection par l’administrateur. 

Les  administrateurs  souhaiteront  fréquemment  utiliser  cette  fonctionnalité  pour  rediriger  automatiquement  les  dossiers d’un utilisateur vers un dossier nouvellement créé pour chaque utilisateur.  La  variable  %username%  peut  être  utilisée  dans  le  chemin  de  redirection,  permettant  au  système  de  créer  dynamiquement un dossier nouvellement redirigé pour chaque utilisateur auquel l’objet de stratégie s’applique. La  redirection des dossiers spéciaux est particulièrement intéressante car elle a été conçue pour répondre aux besoins  des  utilisateurs  avec  l’avantage  d’être  simple  en  mise  en  œ uvre  et  quasiment  sans  entretien  pour  les  administrateurs.  L’écran suivant illustre cette première possibilité. 

© ENI Editions - All rigths reserved

- 13 -

Redirection de dossier en mode “De base” 

●

Le  deuxième  mode  de  fonctionnement  est  appelé  redirection  avancée.  À  la  différence  du  paramètre  “De  base”,  ce  mode  permet  à  l’administrateur  de  spécifier  des  emplacements  différents  pour  les  dossiers  redirigés en fonction de l’adhésion des utilisateurs à un groupe de sécurité. Le paramètre Aucune stratégie  administrative n’est spécifiée permet au profil d’utilisateur, et non à la Stratégie de groupe, de déterminer  l’emplacement  du  dossier.  Dans  ce  cas,  l’onglet  Paramètres  n’est  pas  disponible.  Si  vous  sélectionnez  le  paramètre  Suivre  le  dossier  Mes  documents,  le  dossier  Mes  images  reste  un  sous­dossier  de  Mes  documents quel que soit l’emplacement vers lequel Mes documents est redirigé. 

Ce  mode  de  fonctionnement  est  très  pratique  car  il  est  possible  de  déclarer  des  centaines  de  groupes  dont  les  membres seront redirigés vers tel ou telle destination. Une seule et unique stratégie de groupe pourrait donc être  utilisée pour des milliers d’utilisateurs.  Vous pourrez choisir l’emplacement du dossier cible de la manière suivante : 

- 14 -

●

Créer  un  dossier  pour  chaque  utilisateur  dans  le  chemin  d’accès  racine  :  ce  choix  ajoute  au  chemin  un  dossier nommé en fonction de la variable d’environnement %username%. 

●

Rediriger vers l’emplacement suivant : ce choix vous permet de spécifier un chemin d’accès réseau de type  UNC ou un chemin valide localement, tel que C:\Nom_Dossier. 

●

Rediriger vers l’emplacement du profil utilisateur local : ce choix revient au comportement par défaut pour  le choix de l’emplacement du dossier en l’absence de redirection imposée par l’administrateur. 

●

Rediriger  vers  le  dossier  d’accueil  de  l’utilisateur  :  cette  option  est  très  intéressante  si  vous  avez  déjà  déployé  des  dossiers  utilisateurs  (home  directories)  et  que  vous  désirez  les  utiliser  en  tant  que  “Mes  documents”. Bien sûr, cette option n’est disponible que pour le dossier Mes Documents. 

© ENI Editions - All rigths reserved

Redirection Avancée du dossier spécial Mes documents  L’écran ci­dessous illustre les différents choix de la sélection de la destination. 

Sélection automatique de la destination 

h. Qu’est­ce qu’une stratégie de groupe ? 

© ENI Editions - All rigths reserved

- 15 -

Dans  le  cadre  de  l’administration  des  systèmes  et  de  la  politique  globale  de  sécurisation,  les  services  d’annuaire  Active Directory mettent à la disposition des administrateurs les objets stratégies de groupe.  Grâce  à  ces  objets  qui  sont  les  éléments  fondamentaux  de  la  technologie  IntelliMirror,  les  personnels  ayant  en  charge  les  tâches  de  configuration  et  d’administration  des  systèmes,  des  applications  et  des  services  de  sécurité  peuvent définir et gérer de manière centralisée ou décentralisée tous les types de configuration visant à administrer  les ordinateurs et les utilisateurs.  Les stratégies de groupe respectent les principes listés ci­dessous :  ●

Ces  objets  sont  stockés  dans  un  domaine  et  se  répliquent  sur  tous  les  contrôleurs  de  domaine  dudit  domaine. 

●

Ils ne sont disponibles que dans un environnement Active Directory. 

●

Ils  s’appliquent  aux  utilisateurs  et  aux  ordinateurs  d’un  site,  d’un  domaine  ou  d’une  unité  d’organisation  auquel  l’objet  de  stratégie  de  groupe  est  lié.  Il  s’agit  du  mécanisme  principal  par  lequel  une  stratégie  de  groupe est utilisée dans un environnement Active Directory. 

i. Qu’est­ce qu’une stratégie locale ?  Un  seul  objet  de  type  “stratégie  de  groupe  local”  est  stocké  sur  chaque  ordinateur.  Les  objets  de  stratégie  de  groupe locaux sont les moins influents dans un environnement Active Directory.  En outre, ils ne possèdent qu’un sous­ensemble des paramètres présents dans les objets de stratégie de groupe  basés sur Active Directory. Vous pouvez ouvrir la stratégie local d’un ordinateur ou de tous les utilisateurs locaux en  utilisation la console de gestion MMC “Editeur d’objets de stratégie de groupe”. Vous pouvez lancer cette console en  exécutant le fichier de console Gpedit.msc.  Les fichiers relatifs au stockage de la stratégie sont situés aux emplacements listés ci­dessous :  ●

La partie ordinateur est située à l’emplacement : %Systemroot%\System32\GroupPolicy\User\Registry.pol 

●

La partie utilisateur est située à l’emplacement : %Systemroot%\System32\GroupPolicy\Machine\Registry.pol 

Tous les systèmes Windows 2000 et ultérieurs possèdent un objet de stratégie de groupe local. Ce point est vrai,  que les ordinateurs fassent partie ou non d’un environnement de domaine Active Directory.  L’écran suivant illustre comment procéder pour ouvrir et modifier la stratégie de l’ordinateur local. 

- 16 -

© ENI Editions - All rigths reserved

Ouverture d’une stratégie sur l’ordinateur local  La stratégie locale est appliquée dès le démarrage de l’ordinateur pour la machine et tous les utilisateurs ouvrant  une session locale. Dans le cadre d’une ouverture de session réseau de domaine, il est clair qu’une fois authentifié  par le domaine, une ouverture de session locale à l’ordinateur a lieu pour l’utilisateur authentifié dans le domaine.  Limitations de l’objet de stratégie de groupe local  Les objets de stratégie de groupe locaux ne prennent pas en charge certaines extensions, telles que “Redirection de  dossiers” ou “Installation logicielle de stratégie de groupe”. Les objets de stratégie de groupe locaux prennent en  charge  de  nombreux  paramètres  de  sécurité,  mais  l’extension  Paramètres  de  sécurité  de  l’Éditeur  d’objets  de  stratégie de groupe ne prend pas en charge la gestion à distance des objets de stratégie de groupe locaux.  Par exemple, la ligne de commande gpedit.msc /gpcomputer:"PC­Marketing­01" vous permet de modifier l’objet de  stratégie de groupe local sur PC­Marketing­01, mais le nœ ud “Paramètres de sécurité” n’apparaîtra pas.  Si les objets de stratégie de groupe locaux sont toujours traités, ils sont les moins influents dans un environnement  Active Directory, car les objets de stratégie de groupe basés sur Active Directory ont toujours priorité.  À ce stade, s’il n’existe pas de stratégies de groupe spécifiques définies au sein du domaine Active Directory, seule la  stratégie  de  groupe  du  domaine  Active  Directory  est  appliquée  (le  traitement  des  stratégies  de  groupe  dans  l’environnement Active Directory est traité plus loin).  Dans  le  cas  où  vous  souhaiteriez  que  pour  des  ordinateurs  non  membres  d’un  domaine,  la  stratégie  locale  soit  appliquée à tous les utilisateurs à l’exception des administrateurs, ce qui par défaut n’est pas le cas, vous pourriez  consulter  l’article  de  la  base  de  connaissances  Microsoft  293655  à  l’adresse  :  http://support.microsoft.com/default.aspx?scid=kb;fr;293655 

4. Structure physique d’une stratégie de groupe  Les informations qui concernent un objet stratégie de groupe sont stockées à deux emplacements importants :  ●

le conteneur Stratégie de groupe ou GPC (Group Policy Container), 

●

le modèle de Stratégie de groupe ou GPT (Group Policy Template). 

a. Objet Conteneur de Stratégie de groupe 

© ENI Editions - All rigths reserved

- 17 -

L’objet conteneur Stratégie de groupe est un objet de l’annuaire qui contient uniquement l’état de l’objet Stratégie  de  groupe,  ses  informations  de  version,  les  informations  de  filtre  WMI  dont  il  pourrait  disposer  et  une  liste  des  composants dont les paramètres se trouvent dans l’objet Stratégie de groupe. 

Emplacement du conteneur des objets stratégies de groupe dans Active Directory  Comme vous pouvez le constater, l’emplacement de ce conteneur est situé au sein de la partition du domaine dans  le conteneur System/Policies. Les ordinateurs du domaine peuvent accéder au conteneur Stratégie de groupe pour  localiser  des  modèles  Stratégie  de  groupe.  Les  contrôleurs  de  domaine  y  accéderont,  lorsque  nécessaire,  pour  obtenir  des  informations  de  version.  Ce  paramètre  est  très  important  pour  garantir  la  bonne  réplication  de  la  dernière version de l’objet Stratégie de groupe. 

Propriétés d’un objet stratégie de groupe  L’écran ci­dessous illustre les propriétés de l’objet GPO dont le GUID est 0E531984­BC90­49BF­A790­7E665B6CCE04  et correspond à une stratégie de groupe dont le nom est “Users Cert ­ Auto Enroll”. 

- 18 -

© ENI Editions - All rigths reserved

Information concernant un objet Stratégie de groupe  L’attribut  gPCUserExtensionNames  déclare  les  extensions  CSE  (Client  Side  Extensions)  utilisées  pour  appliquer  et  mettre  en  œ uvre  les  paramètres  contenus  dans  la  stratégie  de  groupe.  Par  exemple,  pour  implémenter  les  paramètres  de  sécurité  IPSec,  l’objet  référencé  sous  le  GUID  E437BC1C­AA7D­11D2­A382­00C04F991E27  sera  invoqué et réalisera les opérations nécessaires.  Ces  différentes  extensions,  déclarées  au  niveau  de  l’objet lui­même,  permettent  d’assurer  la  prise  en  charge  des  fonctions ci­dessous :  ●

la redirection des dossiers ; 

●

les paramètres de registre inclus dans les modèles administratifs ; 

●

les paramètres de quotas de disques ; 

●

les paramètres de QoS ; 

●

l’application des scripts ; 

●

l’application des paramètres de sécurité ; 

●

les paramètres de maintenance d’Internet Explorer ; 

●

les paramètres de récupération EFS (Encrypted File System) ; 

●

l’installation et la maintenance des applications ; 

●

l’application des paramètres de sécurité IP (IPSec). 

Cette  figure  montre  très  clairement  qu’un  objet  Stratégie  de  groupe  est  stocké  à  un  emplacement  réseau  traditionnel  s’appuyant  sur  une  connexion  UNC.  Dans  notre  exemple,  la  valeur  de  l’attribut  gPCFileSysPath  pointe  vers  le  chemin  DFS  :  \\Corp2003.Corporate.net\SysVol\Corp2003.Corporate.net\Policies\  {0E531984­BC90­49BF­

© ENI Editions - All rigths reserved

- 19 -

A790­7E665B6CCE04} 

b. Modèle de la stratégie de groupe  Nous  venons  de  voir  que  les  attributs  d’un  objet  stratégie  de  groupe  situé  dans  le  conteneur  System/Policies  du  domaine permettaient d’en décrire les caractéristiques les plus fondamentales et nécessaires.  Mais qu’en est­il du contenu réel de la stratégie ?  En fait, une stratégie de groupe est basée sur un modèle de départ. Ce modèle est une arborescence de dossiers  située  dans  le  dossier  SYSVOL  d’un  contrôleur  de  domaine.  Chaque  fois  que  vous  créez  un  nouvel  objet  GPO,  le  contrôleur  de  domaine  sollicité  crée  le  modèle  Stratégie  de  groupe  correspondant.  Ce  modèle  contiendra  tous  les  paramètres  et  informations  de  stratégie  de  groupe,  y  compris  les  modèles  d’administration,  les  paramètres  de  sécurité, l’installation et la maintenance des logiciels, etc.  Les ordinateurs clients du domaine se connecteront au dossier SYSVOL par le biais d’un chemin tel que celui qui est  spécifié  ci­après  :  \\Corp2003.Corporate.net\SysVol\Corp2003.Corporate.net\Policies\  {0E531984­BC90­49BF­A790­ 7E665B6CCE04}  Le contenu de ce répertoire contiendra le modèle GPT du GPO à appliquer. Le nom du dossier du modèle correspond  à  l’identificateur  unique  global  (GUID)  de  l’objet  Stratégie  de  groupe.  Il  s’agit  du  même  numéro  que  celui  qui  est  utilisé par Active Directory pour identifier l’objet au sein du conteneur Stratégie de groupe.  Pour qu’un ordinateur client de l’annuaire Active Directory soit capable d’accéder aux stratégies de groupe, il  doit  être  capable  d’accéder  au  volume  système  partagé  Sysvol.  Pour  ce  faire,  il  est  indispensable  que  le  service “Système de fichiers distribués” soit opérationnel sur tous les contrôleurs de domaine. 

La partie cliente DFS est intégrée dans le redirecteur Microsoft mais peut être désactivée à l’aide d’une clé  de registre. Si tel était le cas, le client ne pourrait parcourir le volume \\DomainAD.com\Sysvol et ne pourrait  donc pas implémenter les paramètres contenus dans les stratégies de groupe. 

c. Composants d’une stratégie de groupe  La  stratégie  de  groupe  contient  de  multiples  paramètres  très  spécifiques.  Il  faudra  donc  que  l’ordinateur  dispose  d’une certaine capacité à “traiter” de multiples catégories de paramètres, tous aussi différents les uns des autres.  La  figure  suivante  montre  que  les  paramètres  des  stratégies  de  groupe  sont  pris  en  charge  par  les  modèles  suivants. 

- 20 -

© ENI Editions - All rigths reserved

Composants du moteur de traitement des stratégies de groupe  Processus  Winlogon.exe  :  il  s’agit  d’un  composant  central  du  système  d’exploitation  qui  fournit  les  services  d’ouverture  de  session  interactive.  Le  processus  Winlogon  est  le  composant  au  sein  duquel  le  GPE  fonctionne.  Winlogon est le seul et unique composant du système qui interagit avec le GPE.  Userenv.dll  :  userenv.dll  fonctionne  au  sein  de  Winlogon  et  héberge  le  GPE  ainsi  que  la  gestion  des  modèles  d’administration.  GPE Group Policy Engine : il s’agit du module central de gestion des stratégies de groupe. Il prend en charge toutes  les fonctionnalités grâce aux multiples CSE. Le GPE fonctionne au sein de Userenv.dll.  CSE  Client  Side  Extensions  :  il  s’agit  des  extensions  spécialisées  capables  de  prendre  en  charge  les  différents  paramètres à implémenter.  L’ensemble  des  composants  de  type  CSE  sont  déclarés  dans  le  HKLM\Software\Microsoft\Windows NT\Current Version\Winlogon\GPExtensions. 

registre 

à 

la 

clé 

Nous verrons plus loin lors de la vérification de bonne exécution des stratégies de groupe qu’il est important  de  connaître  ces  extensions.  En  effet,  une  stratégie  de  groupe  peut  connaître  certains  problèmes  spécifiques  relatifs  à  des  paramètres  très  particuliers  qui  mettent  en  cause  l’intégrité  du  composant  ou  de  l’extension CSE.  Au fur et à mesure que les systèmes Windows disposent de nouvelles fonctionnalités, les composants CSE ci­dessus  sont  modifiés  pour  considérer  ces  nouvelles  fonctionnalités.  Généralement,  les  nouvelles  fonctionnalités  et  paramètres associés sont implémentés avec les nouvelles versions de systèmes et les services packs.  Le  moteur  de  gestion  des  stratégies  de  groupe  GPE  ­  Group  Policy  Engine,  étant  extensible,  il  est  probable  que  Microsoft rajoute d’autres extensions CSE à l’avenir. 

d. Modèles de stratégie de groupe ADMX pour Windows Vista  Bien  que  les  principes  fondamentaux  qui  concernent  les  stratégies  de  groupe  soient  quelque  part  immuables  de  Windows 2000 à Windows Vista en passant par Windows XP, force est de constaté que Windows Vista et Windows  Server 2008 apportent leur lot de nouveautés. Nous avons vu précédemment que le contenu des objets stratégies  de groupe de Windows Vista s’était enrichi de manière significative avec plus de deux mille quatre cent paramètres  prise en charge de base, soit plus de huit cent nouveaux paramètres par rapport à son aîné Windows XP.  Pour rappel, nous avons aussi présenté que de nouvelles familles de paramètres faisaient leur apparition. Ainsi, les  modèles de Windows Vista prennent en charge la gestion de l’alimentation, le contrôle de l’installation des pilotes de  périphériques, une gestion uniforme et centralisée des paramètres de sécurité du pare­feu et des règles IPSec ainsi  que le déploiement des imprimantes en fonction des sites. Voila donc, ce qu’il en est des nouvelles fonctionnalités à  caractère fonctionnel.  Concernant les particularités de l’implémentation Windows Vista, les modèles des stratégies de groupe évoluent et  sont désormais structurés via XML. Ce point ne choquera personne, puisqu’aujourd’hui, tout fichier de configuration  se  doit  d’être  en  XML  !  Selon  Microsoft,  l’usage  du  XML  structure  le  fichier  très  clairement  de  telle  sorte  que  les  administrateurs pourront créer plus facilement de nouveaux modèles.  Il convient maintenant de comprendre les effets qu’aura ce nouveau format de modèle sur le reste de l’infrastructure.  Ces points sont présentés ci­dessous :  ●

Les  nouveaux  fichiers  ADMX  de  Windows  Vista  ou  Windows  Server  2008  ne  sont  pas  chargeables  sur  Windows XP ou Windows Server 2003. 

●

Bien que les objets GPO construits à partir de Windows Vista ou Windows Server 2008 puissent résider sur  des  contrôleurs  de  domaine  Windows  2000  Server  ou  Windows  Server  2003,  il  n’est  pas  possible  de  les  éditer sur ces plates­formes. 

●

L’édition  des  stratégies  de  groupe  créées  sous  Windows  Vista  ou  Windows  Server  2008  nécessite  l’utilisation de Windows Server 2008 ou de Windows Vista. 

●

À  l’inverse,  les  outils  de  Windows  Vista  ou  Windows  Server  2008  supportent,  sans  aucun  problème,  l’ouverture et l’édition des objets stratégies de groupe de Windows XP ou Windows Server 2003. 

Note  :  Microsoft  recommande  que  les  administrateurs  utilisent  toujours  les  outils  d’administration  les  plus  récents. En effet, il convient de rappeler que ce sont les outils qui "font" les opérations pour lesquelles on  les sollicite. Il est donc important de limiter l’utilisation d’outils plus anciens vers des plates­formes plus modernes.  Concernant les stratégies de groupe, la recommandation consiste donc à utiliser obligatoirement Windows Vista et 

© ENI Editions - All rigths reserved

- 21 -

la  console  de  gestion  des  stratégies  de  groupe  de  Windows  Vista  pour  gérer  les  objets  GPO  basés  sur  les  nouveaux  modèles  ADMX.  La  même  machine  sera  aussi  utilisée  pour  gérer  les  objets  stratégies  de  groupe  des  systèmes plus anciens tels que Windows 2000, Windows XP et Windows Server 2003.  La figure ci­dessous illustre le cas de l’utilisation d’un modèle d’administration de type ADM à l’aide de la console de  Windows Server 2008 ou de Windows Vista. 

Importation de modèle ADM au sein de la console de Windows Vista 

Les paramètres sont visibles dans la rubrique Modèles d’administration classiques (ADM). 

●

Les fichiers ADM remplacés par de nouveaux fichiers ADMX, sont ignorés. Ce point concerne uniquement les  fichiers  centraux  tels  que  le  bien  connu  System.adm  ainsi  que  les  fichiers  additionnels  Inetres.adm,  Conf.adm,  Wmplayer.adm  et  Wuau.adm.  Les  modifications  apportées  à  ces  fichiers  ADM  devront  donc  être  répercutées vers leurs nouveaux homologues au format ADMX. 

●

À la différence des fichiers ADM qui existent en de multiples langues, les ADMX sont, à l’image de Windows  Vista,  Office  2007  et  Windows  Server  2008,  c’est­à­dire  "language  neutral".  En  effet,  les  fichiers  ADMX  ne  contiennent  aucune  référence  au  langage  mais  uniquement  des  données  de  structure.  Ce  point  signifie  qu’aucune information de description des paramètres des stratégies de groupe n’est stockée dans un fichier  de  type  ADMX.  Ces  informations  sont  désormais  stockées  dans  des  fichiers  de  description  séparés  dont  l’extension est ADML. 

Fichiers  ADMX  et  ADML  :  cette  nouvelle  fonctionnalité  permet  d’utiliser  une  seule  et  unique  version  d’un  même fichier ADMX tout en disposant de multiples versions de fichiers ADML. De cette manière, il est facile de  disposer de n fichiers de langages différents, sachant que la console d’édition des stratégies de groupe chargera  automatiquement  le  fichier  de  langue  en  fonction  du  langage  du  système  d’exploitation.  Cette  nouvelle  fonctionnalité est bien sûr très intéressante pour les administrateurs qui pourront travailler sur un même modèle  ADMX, mais disposer d’un fichier ADML adapté à leur langue. 

- 22 -

© ENI Editions - All rigths reserved

Le dossier \systemroot\PolicyDefinitions\fr­FR et les fichiers ADML 

Pour  pouvoir  disposer  de  plusieurs  langages  sur  le  même  ordinateur,  il  suffit  de  copier  dans  le  dossier  de  langage  adéquat,  par  exemple,  en­US  pour  le  langage  anglais/états  unis,  les  fichiers  de  langages  nécessaires. 

●

À propos des fichiers .POL : comme cela était le cas pour les fichiers ADM de Windows 2000 ou Windows XP,  les  fichiers  ADMX  de  Windows  Vista  et  Windows  Server  2008  ne  sont  que  des  modèles.  En  effet,  les  paramètres  configurés  sur  la  base  de  ces  modèles  sont  finalement  encodés  dans  un  fichier  Registry.Pol.  Ainsi, lorsque des modifications de paramètres sont basées sur des fichiers de modèles ADM ou ADMX, toutes  les données sont finalement combinées dans un minuscule fichier .Pol de quelques kilo­octets. 

Attention ! Même si les paramètres existant précédemment sous Windows XP sur la base de modèles ADM  s’appliquent  le  plus  souvent  sous  Windows  Vista,  les  nouveaux  paramètres  de  stratégies  de  groupe  de  Windows  Vista,  soit  plus  de  800  !,  nécessitent  la  création  d’un  nouvel  objet  GPO  créé  à  partir  d’une  machine  Windows Vista. Cette remarque ne concerne que les nouveaux paramètres de Windows Vista puisque ceux­ci ne  sont implémentés qu’au travers des nouveaux modèles ADMX. Comme nous l’avons vu précédemment, les anciens  ADM sont toujours insérables et utilisables par toutes les machines les supportant, Windows Vista y compris.  Création du "Central Store" : Stockage des modèles de GPO  Dans les versions précédentes de Windows, lorsqu’un nouvel objet stratégie de groupe était créé, tous les modèles  insérés par défaut dans l’objet GPO étaient stockés au sein du GPO. En fonction des versions de Windows, l’espace  consommé par un seul GPO pouvait donc facilement atteindre 4, voire 5 Mo.  Certaines  opérations  d’infrastructures,  telles  que,  par  exemple,  la  mise  à  niveau  des  contrôleurs  de  domaines  de  Windows  2000  Server  vers  Windows  Server  2003,  pouvaient  provoquer  des  pics  de  réplication  importants,  notamment lorsque tous les modèles de GPO ­ fichiers ADM, devaient être répliqués vers tous les autres contrôleurs  de domaine.  Les systèmes fonctionnant sous Windows Vista et Windows Server 2008 permettent de minimiser la réplication de  tous les modèles inutilement copiés dans chaque objet GPO en mettant en œ uvre un point de stockage centralisé au  sein du SYSVOL contenant l’ensemble des nouveaux fichiers ADMX. En plus de cette optimisation possible, il convient  de préciser que tous les GPO créés sous Windows Vista ne contiennent plus de modèles. 

© ENI Editions - All rigths reserved

- 23 -

Structure physique d’un GPO sur un contrôleur de domaine Windows Server 2008. Les volumineux fichiers ADM  ont disparu ! 

Le fait de créer les GPO à partir d’une station d’administration Windows Vista fait économiser pas moins de 4  Mo par GPO, puisqu’aucun ADM, ni ADMX n’y est inséré. Enfin, dans un deuxième temps, la mise en œ uvre de  DFS­R  (Distributed  File  System  ­  Replication)  pour  la  réplication  du  SYSVOL  permettra  de  ne  répliquer  que  les  différences (delta binaires) des fichiers !  Le tableau ci­après résume les différentes opérations possibles en fonction de la station d’administration utilisée, à  savoir,  la  console  GPMC  disponible  en  téléchargement  pour  Windows  XP  SP2  et  Windows  Server  2003  ou  bien  la  console GPMC disponible de base sous Windows Server 2008 ou Windows Vista.  Fonctionnalités supportées 

GPMC Windows Vista 

GPMC Windows XP SP2 

Peut gérer Windows Server 2003,  Windows XP et Windows 2000. 

Oui  

Oui  

Peut gérer Windows Vista et  Windows Server 2008. 

Oui  

Non 

Support multilangues. 

Oui  

Non 

Lecture des fichiers ADM  personnalisés. 

Oui  

Oui  

Emplacement par défaut des  modèles. 

En local 

GPO 

Utilisation du "Central store". 

Oui  

Non 

Évite les fichiers dupliqués dans le  SYSVOL. 

Oui  

Non 

Possibilité de rajouter des  modèles spécifiques.  

Fichiers ADM seulement 

Fichiers ADM seulement 

Méthode de comparaison des  fichiers. 

Numéro de version 

Timestamp 

e. Création du "Central Store" au sein du SYSVOL  La  création  du  stockage  centralisé  des  modèles  de  GPO  au  format  ADMX  de  Windows  Vista  est  une  procédure  manuelle. La structure est directement créée au sein du volume système SYSVOL sur l’un des contrôleurs de domaine 

- 24 -

© ENI Editions - All rigths reserved

du  domaine.  Ensuite,  le  moteur  de  réplication  FRS  (File  Replication  Service),  prendra  en  charge  la  réplication  du  nouveau dossier vers tous les contrôleurs du domaine.  Une bonne pratique consiste à créer le "Central Store" sur le contrôleur de domaine jouant te rôle de FSMO  PDCE (Primary Domain Controller Emulator). En effet, par défaut, les outils d’administration tels que la GPMC  ou l’éditeur d’objets stratégies de groupe sélectionnent toujours le PDC de manière privilégiée. 

Lorsqu’aucun  "Central  Store"  n’existe,  la  console  l’éditeur  d’objets  stratégies  de  groupe  utilise  les  fichiers  ADMX et ADML situés dans le répertoire local de Windows Vista \systemroot\PolicyDefinitions. 

Structure du SYVOL préparé avec le "Central Store".  Pour créer le stockage centralisé, procédez comme suit :  ■

Créez le dossier racine du stockage centralisé suivant : %systemroot%\sysvol\domain\policies\PolicyDefinitions 

■

Créez un sous­dossier pour chaque langage à prendre en charge. Par exemple, pour la France et les États­Unis,  créez les dossiers fr­FR et en­US. 

■

Chargez le nouveau stockage centralisé avec les fichiers ADMX et ADML. Cette opération est très simple puisqu’il  suffit  de  copier  tous  les  fichiers  ADMX  contenus  dans  le  dossier  %systemroot%\PolicyDefinitions  d’une  machine  Windows  Vista  vers  le  dossier  créé  au  départ  dans  le  SYSVOL,  c’est­à­dire  :  %systemroot% \sysvol\domain\policies\PolicyDefinitions 

f. Recommandations sur l’administration des GPO en environnement Windows Vista  Nous avons vu que les postes de travail Windows Vista supportent un nombre important de nouveaux paramètres  contrôlables  à  l’aide  des  GPOs.  Les  recommandations  ci­dessous  ont  pour  objet  de  faciliter  l’application  des  paramètres  de  configuration  de  type  Windows  XP  vers  Windows  Vista  et  de  respecter  les  meilleures  bonnes  pratiques pour exploiter au maximum les aspects les plus intéressants de Windows Vista et Windows Server 2008.  ●

Faites évoluer les stations d’administration Windows XP vers Windows Vista. Utilisez la nouvelle console de  gestion des stratégies de groupe intégrée à Windows Vista pour toutes les opérations de gestion des GPO. 

●

Créez un stockage centralisé et gérez de manière centralisée l’ensemble des modèles Vista/Windows Server  2008. 

© ENI Editions - All rigths reserved

- 25 -

●

Créez de nouveau GPO, ou mettez à jour les anciens, pour y inclure les nouvelles possibilités de Windows  Vista et Windows Server 2008. 

Pour plus d’informations sur les nouveaux modèles ADMX ainsi que la mise en place du “Central Store, vous  pourrez vous référer au document intitulé "Managing Group Policy ADMX Files Step­by­Step Guide" disponible  sur le site de Microsoft à l’adresse : http://go.microsoft.com/fwlink/?LinkId=75124 

5. Application des stratégies de groupe dans l’environnement Active Directory  a. Application à l’aide du modèle S,D,OU et ordre de traitement  L’application des stratégies de groupe est un processus pris en charge intégralement par l’ordinateur client. Il n’y a  aucun trafic initié de l’Active Directory vers le poste de travail.  Les stratégies de groupe qui s’appliquent à un utilisateur ou un ordinateur ou aux deux, n’ont pas toutes les mêmes  priorités ; cependant, l’ordre dans lequel elles sont appliquées respecte la formule L,S,D,OU. Cette formule signifie  stratégie  Locale,  puis  stratégies  du  Site,  puis  stratégies  du  Domaine,  puis  stratégies  des  Unités  d’Organisation  contenant l’objet ordinateur et utilisateur donné.  Les paramètres de stratégie de groupe sont donc traités dans l’ordre suivant : 

- 26 -

●

Objet  de  stratégie  de  groupe  local : chaque ordinateur dispose d’un objet de stratégie de groupe stocké  localement. Il sert au traitement des paramètres par défaut de l’ordinateur et de l’utilisateur que la machine  soit ou non dans un domaine Active Directory. 

●

Site : ensuite, les objets de stratégie de groupe liés au site auquel l’ordinateur appartient sont traités. Le  traitement de plus d’une  stratégie  s’effectue dans l’ordre spécifié par l’administrateur,  sous  l’onglet Objets  de stratégie de groupe liés pour le site dans la console de gestion des stratégies de groupe GPMC (Group  Policy  Management  Console),  sachant  que  l’objet  de  stratégie  de  groupe  situé  au  plus  haut  sera  celui  qui  disposera de la plus forte priorité. 

●

Domaine  :  l’application  de  plusieurs  stratégies  de  groupe  liées  au  domaine  s’effectue  suivant  le  même  principe de gestion des priorités. 

●

Unités  d’Organisation  :  finalement,  les  objets  de  stratégie  de  groupe  liés  à  l’unité  d’organisation  la  plus  élevée dans la hiérarchie Active Directory sont traités en premier, suivis des objets de stratégie de groupe  liés à une unité d’organisation enfant, et ainsi de suite. 

© ENI Editions - All rigths reserved

Étendue de gestion Active Directory et rafraîchissement des stratégies de groupe  L’écran ci­dessus  illustre  l’étendue de gestion de l’infrastructure Active Directory. Les conteneurs Sites, Domaine et  Unités d’Organisation sont présents et contiennent un ordinateur et un utilisateur. La séquence ci­dessous explique  le processus complet de traitement des stratégies de groupe ordinateur et utilisateur en commençant par la mise en  route de l’ordinateur et en terminant par l’ouverture de session d’un utilisateur sur l’ordinateur :  1.  Le  réseau  démarre.  Le  service  RPCSS  (Remote  Procedure  Call  System  Service)  et  le  fournisseur  MUP  (Multiple  Universal Naming Convention Provider) démarrent.  À  propos  du  mode  synchrone  et  asynchrone  :  les  postes  de  travail  fonctionnant  sous  Windows  XP  ou  Windows Vista démarrent de manière asynchrone et n’ont donc pas besoin d’attendre que les composants  réseau soient complètement initialisés. Contrairement à Windows XP ou Windows Vista, Windows 2000 utilise la  même  séquence  mais  de  manière  totalement  synchrone.  La  mise  en  œ uvre  du  mode  asynchrone  permet  d’accélérer  de  manière  significative  le  démarrage  du  système  d’exploitation.  Les  machines  Windows  2000  ne  supportent pas le mode asynchrone, mais les machines Windows XP Professionnel ou Windows Vista peuvent être  configurées via un paramètre de stratégie de groupe pour fonctionner, comme les ordinateurs Windows 2000, de  manière synchrone.  2. Une liste correctement ordonnée des objets de stratégie de groupe est obtenue pour l’ordinateur.  Les  facteurs  suivants peuvent avoir une incidence sur la composition de la liste :  ●

L’ordinateur  est­il  membre  d’un  domaine  Active  Directory  ?  Si  oui,  alors  il  devra  considérer  le  processus  de  découverte des stratégies de groupe et appliquer celles qui le concernent. 

●

Sur quel site Active Directory l’ordinateur est­il situé ? 

●

Par rapport à la dernière exécution de la découverte des objets stratégie de groupe par l’ordinateur, y a­t­il  des modifications concernant la liste des stratégies à appliquer et/ou les stratégies de groupe ont­elles été  modifiées ? Si oui, le traitement se poursuit, si non, aucun traitement n’a lieu. 

À propos du mode “Appliquer les stratégies même si elles n’ont pas changé ...” Un paramètre de stratégie  de  groupe  permet  de  changer  le  comportement  par  défaut  des  stratégies  de  groupe  pour  réappliquer  les  stratégies même lorsqu’elles n’ont pas changé. Ce paramètre permet de garantir le bon état des configurations et  de maintenir un très haut niveau de sécurité. 

●

Certaines  stratégies  disposent­elles  du  mode  obligatoire  ?  Cette  opération  permet  d’appliquer  la  stratégie  disposant  de  ce  mode,  même  si  les  unités  d’organisation  enfants  utilisent  l’option  Bloquer  l’héritage  des  stratégies. Sous Windows 2000, ce mode était appelé “ne pas passer outre”. 

3.  À  ce  stade,  les  stratégies  de  groupe  sont  connues  et  appliquées  à  l’ordinateur.  Pour  obtenir  des  informations  détaillées concernant l’application des stratégies “ordinateur”, vous pouvez activer les journaux détaillés par le biais  d’une stratégie.  4. Les scripts de démarrage s’exécutent de manière masquée et en mode synchrone, les uns après les autres. Par  défaut, chaque script doit se terminer pour que le suivant puisse démarrer. Dans le cas où un script serait “bloqué”,  un délai d’exécution de 10 minutes (600 secondes) au plus sera appliqué avant de poursuivre avec le script suivant,  si nécessaire. Plusieurs paramètres de stratégie sont disponibles pour ajuster ce comportement.  Attention au traitement en mode asynchrone en tâche de fond : Windows XP Professionnel n’attend pas le  démarrage  complet  du  réseau  pour  démarrer.  Après  l’ouverture  de  session,  la  stratégie  est  traitée  en  arrière­plan dès que le réseau devient disponible. Cela signifie que l’ordinateur continue d’utiliser les paramètres  de  stratégie  antérieurs  au  démarrage  et  à  l’ouverture  de  session.  Par  conséquent,  il  peut  être  nécessaire  et  obligatoire de réaliser plusieurs ouvertures de session successives après la modification d’une stratégie pour que  les  paramètres  soient  réellement  opérationnels.  Ce  comportement  est  contrôlé  par  le  paramètre  figurant  dans  Configuration  ordinateur\Modèles  d’administration\Système\Ouverture  de  session\  Toujours  attendre  le  réseau  lors  du  démarrage  de  l’ordinateur et de l’ouverture  de  session.  Notez  que  cette  fonctionnalité  ne  concerne  que  Windows XP et n’est pas disponible pour Windows 2000 ou Windows Server 2003.  5. L’utilisateur ouvre sa session vers un domaine Active Directory.  6. Après authentification de l’utilisateur, le profil utilisateur est chargé selon les paramètres de stratégie en vigueur.  Une  liste  correctement  ordonnée  des  objets  de  stratégie  de  groupe  est  obtenue  pour  l’utilisateur  en  session.  Toutefois,  comme  dans  le  cas  du  démarrage  de  la  machine,  un  certain  nombre  de  facteurs  pourront  avoir  une  incidence sur la composition de la liste à appliquer : 

© ENI Editions - All rigths reserved

- 27 -

●

L’utilisateur  appartient­il  à  un  domaine  ?  Dans  ce  cas,  il  est  soumis  à  la  stratégie  de  groupe  via  Active  Directory. 

●

Le  bouclage  est­il  activé  ?  Si  oui,  ce  mode  est  configuré  pour  fonctionner  en  mode  fusion  ou  en  mode  remplacement ? 

Le bouclage, en anglais Loopback Processing Mode, permet de gérer la configuration des machines en libre  service. Ce comportement très particulier est détaillé plus loin. 

●

Quel  est  l’emplacement  de  l’utilisateur  dans  Active  Directory  ?  Sur  quel  site,  dans  quel  domaine  et  dans  quelle hiérarchie d’unités d’organisation ? 

●

Certaines  stratégies  disposent­elles  du  mode  obligatoire  ?  Cette  opération  permet  d’appliquer  la  stratégie  disposant  de  ce  mode,  même  si  les  unités  d’organisation  enfants  utilisent  l’option  Bloquer  l’héritage  des  stratégies. 

7. Les stratégies de groupe sont enfin déterminées et appliquées à l’utilisateur en session.  8. Les scripts d’ouverture de session s’exécutent avec les mêmes principes que ceux qui concernent les ordinateurs.  9. Finalement, le chargement de l’interface utilisateur a lieu en fonction des paramètres déclarés dans les stratégies  de groupe. 

b. Domaines Active Directory et domaines NT : L, S, D, OU et 4, L, S, D, OU  Il  se  peut  que  l’environnement  de  production  comprenne  encore  des  domaines  Windows  NT  approuvés.  De  tels  domaines, comprenant donc des utilisateurs de domaines Windows NT, peuvent être approuvés à travailler sur des  ordinateurs  membres  d’un  domaine  Active  Directory.  Ils  pourront  bien  sûr,  en  fonction  de  leurs  droits,  accéder  à  toute ressource du domaine ou des autres domaines Windows, membres de la forêt.  Trois grands cas devront être considérés :  ●

Si l’ordinateur (Windows 2000 ou supérieur) se trouve dans un domaine Windows NT et que l’utilisateur se  trouve  dans  Active  Directory,  seule  la  stratégie  système  de  l’ordinateur  est  traitée  (et  non  celle  de  l’utilisateur)  lorsque  l’utilisateur  ouvre  une  session.  Ensuite,  uniquement  la  stratégie  de  groupe  utilisateur  est traitée. 

●

Si l’ordinateur se trouve dans Active Directory et que l’utilisateur se trouve dans un domaine Windows NT, la  stratégie  de  groupe  ordinateur  (et  non  celle  de  l’utilisateur)  est  traitée  au  démarrage  de  l’ordinateur.  Lorsque l’utilisateur ouvre sa session, seule la stratégie système de l’utilisateur est traitée. 

●

Si les comptes ordinateur et utilisateur appartiennent à un domaine Windows NT, seule la stratégie système  est appliquée lorsque l’utilisateur ouvre sa session. 

Ne  confondez  pas  “Stratégies  Système”  et  “stratégies  de  groupe”.  Les  stratégies  système,  en  anglais  System  Policy,  étaient  mises  en  œ uvre  dans  les  environnements  de  domaine  NT  pour  les  ordinateurs  fonctionnant  sous  Windows  9x  et  Windows  NT  4.0.  L’utilitaire  de  configuration  Poledit,  permettait  la  création  de  deux fichiers spécifiques. Le premier, le fichier Config.pol, était dédié aux ordinateurs fonctionnant sous Windows  9x,  tandis  que  le  second,  le  fichier  NTconfig.pol,  était  dédié  aux  ordinateurs  fonctionnant  sous  Windows  NT  4.0.  Ces  deux  fichiers  devaient  ensuite  être  placés  dans  le  répertoire  habituel  des  scripts  Netlogon  (anciennement  \System32\Repl\Import\  Scripts).  L’utilitaire  de  configuration  des  stratégies  système  était  livré  dans  le  système  Windows  NT  4.0  et  aussi  Windows  2000.  Cet  utilitaire  n’est  plus  livré  avec  Windows  XP  Professionnel  ni  les  versions ultérieures, mais peut toujours être utilisé, si nécessaire. 

c.  Liaisons  des  stratégies  de  groupe  sur  les  objets  Sites,  Domaine  et  Unités  d’organisation  et  de  l’héritage  Comme nous venons de le voir, une stratégie de groupe peut être liée au niveau de multiples conteneurs de types  S,D,OU au sein d’une hiérarchie Active Directory.  Ainsi, vous avez la possibilité de lier de multiples stratégies de groupe sur le même domaine ou la même OU, ou de  n’en  lier  aucun.  Dans  ce  cas,  vous  bénéficierez  des  mécanismes  d’héritage.  Si  plusieurs  objets  de  stratégie  de  groupe sont liés à une unité d’organisation, vous aurez la possibilité de contrôler leur ordre d’application en agissant  - 28 -

© ENI Editions - All rigths reserved

sur l’onglet Objets de stratégie de groupe liés pour l’unité d’organisation dans la console GPMC. 

Gestion de l’ordre de traitement sur un conteneur Active Directory donné  L’objet stratégie de groupe possédant l’ordre des liens le plus bas est traité en dernier et reçoit donc la priorité la  plus  élevée.  La  figure  ci­dessus est représentative des informations qu’il  est  nécessaire  de “manipuler” et  de  bien  percevoir pour comprendre pourquoi telle stratégie de groupe sera plus considérée qu’une autre.  Les  informations  ci­dessous  vous  permettront  de  bien  comprendre  l’importance  des  paramètres  des  stratégies  de  groupe liées sur un conteneur donné.  L’ordre  des  liens  :  ce  paramètre  vous  permettra  de  gérer  l’ordre  de  traitement  des  stratégies  par  le  GPE,  Group  Policy Engine. Comme cela a déjà été expliqué plus haut, la stratégie de groupe avec l’ordre des liens le plus bas est  traité en dernier et est donc la plus prioritaire.  Appliqué : le lien d’un objet de stratégie de groupe peut être appliqué, désactivé ou les deux. Par défaut, le lien d’un  objet de stratégie de groupe n’est ni appliqué ni désactivé. Méfiez­vous de cette option. Quand le lien est activé, la  stratégie de groupe est bien “reliée” sur le conteneur. Quand le lien est dit Appliqué, alors la stratégie de groupe en  question a priorité sur le paramètre Bloquer l’héritage sur un domaine ou une unité d’organisation. De plus, si vous  activez Appliqué et désactivez Lien activé pour un lien, alors l’objet de stratégie de groupe ne s’applique pas.  Bloquer l’héritage : cette option protège le conteneur de l’héritage issu d’autres conteneurs de niveaux supérieurs.  Notez toutefois que l’activation de l’option Bloquer l’héritage ne dévie pas les paramètres de stratégie de groupe  des  objets  de  stratégie  de  groupe  qui  sont  directement  liés  au  domaine.  Remarquez  que  le  blocage  de  l’héritage  appliqué sur une unité d’organisation est symbolisé par un point d’exclamation de couleur bleue placé sur l’OU. 

d. Liaisons et attribut gPLink  Les  objets  conteneurs  de  type  Sites,  Domaines  et  Unités  d’organisation  sont  les  seules  classes  d’objets  de  l’annuaire à disposer de l’usage de l’attribut gPLink.  Cet  attribut  est  fondamental  puisqu’il  permet  à  différents  types  de  conteneurs  de  “s’accrocher  sur  des  objets  stratégies de groupe”. En effet, l’attribut gPLink dont l’OID est 1.2.840.113556.1.4.891 est un attribut utilisé par les  classes Site, Organizational­Unit et Sam­Domain. Pour information, la version Windows Server 2003 du schéma Active  Directory prévoit que l’attribut gPLink soit aussi disponible pour le conteneur “Configuration” qui accueille la partition  Active Directory de configuration. 

e. Sélection du contrôleur de domaine préféré  La console de gestion des stratégies de groupe utilise le contrôleur de domaine jouant le rôle de maître d’opération  de PDC Emulator de chaque domaine Emulateur de contrôleur principal de domaine, comme contrôleur de domaine  par défaut, pour toutes les opérations de création et de modification des stratégies de groupe.  Afin  d’éviter  les  conflits  de  réplication,  il  est  recommandé  de  choisir  un  contrôleur  parmi  ceux  dont  vous  disposez  comme  favori  des  opérations  qui  concernent  l’administration  des  stratégies  de  groupe.  En  effet,  nous  avons  vu  précédemment que les objets stratégies de groupe étaient composés de deux parties distinctes : la partie conteneur  de stratégie de groupe au sein de la partition de domaine Active Directory et la partie modèle de stratégie de groupe  au  sein  du  volume  partagé  SYSVOL.  Ces  deux  espaces  de  stockage  utilisent  des  mécanismes  de  réplication  indépendants.  Par  conséquent,  si  deux  administrateurs  modifient  pendant  le  même  cycle  de  réplication  un  même  objet  stratégie  de  groupe  sur  des  contrôleurs  de  domaine  différents,  les  modifications  apportées  par  l’un  des  administrateurs risquent d’être perdues. 

© ENI Editions - All rigths reserved

- 29 -

Par  défaut,  la  console  de  gestion  des  stratégies  de  groupe  utilise  l’émulateur  PDC  du  domaine  pour  garantir  que  tous  les  administrateurs  utilisent  le  même  contrôleur  de  domaine.  Cependant,  il  se  peut  que  vous  souhaitiez  ponctuellement solliciter un contrôleur de domaine particulier situé sur un site distant.  Si  plusieurs  administrateurs  gèrent  le  même  stratégie  de  groupe  au  même  moment,  il  est  recommandé  qu’ils  sélectionnent  le  même  contrôleur  de  domaine.  Cette  sélection  permettra  d’éviter  les  collisions  de  réplication  au  niveau du service de réplication de fichiers FRS (File Replication Service).  La  console  de  gestion  de  stratégies  de  groupe  vous  permet  de  changer  le  contrôleur  actif  qui  réalisera  les  modifications.  Cette  opération  est,  dans  notre  exemple,  une  tâche  manuelle  qui  sera  réalisée  en  fonction  des  besoins  d’administration.  Vous aurez cependant la possibilité de changer la façon dont le contrôleur de domaine par défaut est sélectionné.  Vous  pourrez  par  exemple  créer  une  nouvelle  stratégie  de  groupe  à  l’usage  des  administrateurs  et  paramétrer  ainsi : Configuration utilisateur/Modèles d’administration/Système/Stratégie de groupe/Sélection du contrôleur  de  domaine  de  la  stratégie  de  groupe.  Activez  l’option  puis  sélectionnez  parmi  les  trois  choix  proposés  celui  qui  convient le mieux à votre besoin. 

Sélection automatique du contrôleur de domaine pour les opérations de modifications des objets stratégies de  groupe  Utiliser  le  contrôleur  principal  de  domaine  :  il  s’agit  de  l’option  par  défaut.  Ce  choix  indique  que  le  composant  Éditeur d’objet stratégie de groupe lit et écrit les modifications dans le contrôleur de domaine désigné en tant que  maître d’opérations PDC Emulator pour le domaine dans lequel l’opération est réalisée.  Hériter des composants Active Directory : ce choix indique que le composant Éditeur d’objet stratégie de groupe  lit et écrit les modifications dans le contrôleur de domaine que la console de gestion MMC Utilisateurs et ordinateurs  Active Directory ou Sites et services Active Directory utilisent.  Utilise tout contrôleur de domaine disponible : ce choix indique au composant Éditeur d’objet stratégie de groupe  qu’il peut utiliser tout contrôleur de domaine disponible.  Si vous désactivez ce paramètre ou si vous ne le configurez pas, l’Éditeur d’objet stratégie de groupe utilise  le contrôleur de domaine désigné comme le maître des opérations de contrôleur de domaine principal pour le  domaine. 

6. Création d’une stratégie de groupe avec les outils Active Directory  Les  stratégies  de  groupe  peuvent  être  créées  de  deux  manières.  La  première  méthode  utilise  les  outils  livrées  de  base avec Windows 2000 Server ou Windows Server 2003. Dans ce cas, il s’agira des outils de gestion MMC tels que  Utilisateurs  et  ordinateurs  Active  Directory  et  Sites  et  Services  Active  Directory.  La  seconde  méthode  utilise  la 

- 30 -

© ENI Editions - All rigths reserved

nouvelle console Gestion des stratégies de groupe appelée en anglais GPMC (Group Policy Management Console).  Cet outil n’est pas livré de base avec Windows Server 2003 car il n’était pas disponible en avril 2003 au moment de la  disponibilité  de  Windows  Server  2003.  Ce  composant  d’administration  est  remarquable  et  en  l’utilisant,  on  pourrait  presque dire que la gestion des stratégies de groupe est une chose facile !  La  console  de  gestion  GPMC  est  disponible  en  téléchargement  gratuit  sur  le  site  de  Microsoft  à  l’adresse  :  http://www.microsoft.com/downloads/details.aspx?FamilyId =   0A6D4C24­8CBD­4B35­9272­ DD3CBFC81887&displaylang=en  La  console  de  gestion  des  stratégies  de  groupe  nécessite  un  ordinateur  fonctionnant  sous  Windows  XP  Professionnel SP1 équipé du Framework .Net.  Au  départ,  la  console  de  gestion  des  stratégies  de  groupe  était  réservée  aux  possesseurs  d’une  licence  Windows  Server  2003.  L’accord  de  licence  de  la  version  GPMC  SP1  permet  l’usage  de  cette  nouvelle  console  à  tous  les  possesseurs d’une licence Windows Server 2003 mais aussi Windows 2000 Server. 

a. Utilisation de la console de gestion MMC Utilisateurs et ordinateurs Active Directory  La figure ci­après montre la liste des liaisons vers les objets stratégies de groupe de l’unité d’organisation Finance. 

Utilisation de la fenêtre originale de gestion des stratégies de groupe  Vous  pouvez  remarquer  la  recommandation  intégrée  dans  l’interface  graphique  de  la  console  “Utilisateurs  et  ordinateurs  Active  Directory”.  Un  lien  Internet  vous  renvoie  sur  le  site  de  Microsoft  à  l’adresse  http://www.microsoft.com/windowsserver2003/gpmc/default.  mspx.  Vous  y  trouverez  toutes  les  informations  nécessaires et un lien qui vous permettra de télécharger la GPMC.  Pour accéder à cette fenêtre et créer une stratégie de groupe, procédez comme suit :  ■

Lancez la console de gestion MMC “Utilisateurs et ordinateurs Active Directory”. 

■

Positionnez­vous  sur  le  domaine  ou  sur  le  conteneur  de  type  Unité  d’organisation.  Accédez  à  la  fenêtre  des  propriétés. 

© ENI Editions - All rigths reserved

- 31 -

■

Cliquez sur l’onglet Stratégie de groupe. 

■

Cliquez sur le bouton Nouveau. 

L’objet créé est lié sur le conteneur sélectionné.  Dans le cas où l’objet stratégie de groupe aurait déjà été créé, vous pourrez le sélectionner à l’aide de la fenêtre de  sélection présentée ci­dessous : 

Sélection des stratégies à lier sur un conteneur à partir des différents domaines de la forêt  Dans  notre  exemple,  il  est  possible  d’accéder  aux  objets  stratégies  de  groupe  des  domaines  Corp2003.Corporate.net et partners.corporate.net. 

b. Utilisation de la console de gestion MMC “Sites et services Active Directory”  La  console  de  gestion  MMC “Sites  et  services  Active  Directory”  vous  permettra  de  gérer  les  stratégies  de  groupe  associées  aux  sites  Active  Directory.  La  méthode  est  rigoureusement  la  même  que  pour  les  stratégies  de  groupe  liées sur les conteneurs de types domaines et unités d’organisation.  ■

Lancez la console de gestion MMC “Sites et services Active Directory”. 

■

Positionnez­vous sur le site souhaité. Accédez à la fenêtre des propriétés. 

■

Cliquez sur l’onglet Stratégie de groupe et créez ou modifiez une nouvelle stratégie. 

7. Création d’une stratégie de groupe avec la GPMC  Dans presque tous les cas, Microsoft recommande que les administrateurs utilisent les dernières versions des outils  d’administration. Dans la mesure où ces outils “font” ce que nous leur demandons, il est bon de pouvoir compter sur  des outils plus performants tant d’un point de vue de la stabilité, que des facultés de ces outils à simplifier certaines  tâches complexes voir impossibles. Rappelons que les outils d’administration de Windows Server 2003 (Adminpak.msi)  sont disponibles en téléchargement sur le site de Microsoft depuis la version Bêta 3 de Windows Server 2003 et qu’il  en a été de même pour la console de gestion des stratégies de groupe dès la disponibilité de la version finale.  Les opérations suivantes concernent la console de gestion des stratégies de groupe GPMC. 

a. Création d’une stratégie de groupe non liée  Dans l’arborescence de la console : 

- 32 -

© ENI Editions - All rigths reserved

■

Effectuez  un  clic  droit  sur  Objets  de  stratégie  de  groupe  dans  la  forêt  et  le  domaine  où  vous  souhaitez  créer  l’objet  de  stratégie  de  groupe  (GPO,  Group  Policy  Object).  Pour  vous  positionner,  suivez  le  chemin  Nom  de  la  forêt/Domaines/Nom du domaine/Objets de stratégie de groupe. 

■

Cliquez sur Nouveau. 

■

Dans la boîte de dialogue Nouvel objet GPO, indiquez un nom pour le nouvel objet de stratégie de groupe, puis  cliquez sur OK. 

b. Création d’une stratégie de groupe liée  Dans l’arborescence de la console :  ■

Effectuez un clic droit sur le nom du domaine, dans la forêt dans laquelle vous souhaitez créer et lier un objet de  stratégie de groupe. Pour vous positionner, suivez le chemin Nom de la forêt/Domaines/Nom du domaine puis  allez jusqu’au conteneur souhaité. 

■

Cliquez sur Créer et lier un objet de stratégie de groupe ici. 

■

Dans la boîte de dialogue Nouvel objet GPO, indiquez un nom pour le nouvel objet de stratégie de groupe, puis  cliquez sur OK. 

c. Gestion des liens de stratégies de groupe  La  gestion  des  liaisons  est  une  opération  simple  techniquement,  mais  lourde  de  conséquence  vis­à­vis  de  l’infrastructure  d’administration  Active  Directory.  En  effet,  la  création  d’un  lien  peut  rendre  de  grands  services  à  certains  ordinateurs  et/ou  utilisateurs  mais  peut  aussi  provoquer  des  gênes  voire  des  dysfonctionnements  à  d’autres.  C’est pour cette raison que la console de gestion GPMC a été conçue. Nous présenterons plus loin les fonctionnalités  de modélisation et d’analyse indispensables à une gestion plus facile et moins risquée des stratégies de groupe.  Liaison d’une stratégie de groupe existante ■

Pour lier un objet de stratégie de groupe existant, effectuez un clic droit sur le domaine ou l’unité d’organisation  dans le domaine, puis cliquez sur Lier un objet de stratégie de groupe existant. 

■

Dans  la  boîte  de  dialogue  Sélectionner  un  objet  GPO,  cliquez  sur  l’objet  de  stratégie  de  groupe  que  vous  souhaitez lier, puis sur OK. 

Désactivation d’un lien de stratégie de groupe ■

Positionnez­vous sur la forêt contenant le domaine, le site ou l’unité d’organisation qui comporte le lien d’objet de  stratégie de groupe que vous souhaitez désactiver. 

■

Effectuez  un  clic  droit  sur  le  lien  d’objet  de  stratégie  de  groupe  souhaité  :  une  coche  en  regard  de Lien  activé  indique que le lien est actuellement activé. 

■

Cliquez sur Lien activé pour supprimer la coche et désactiver le lien. 

Pour effectuer cette opération, vous devez disposer de l’autorisation Lier les objets GPO pour le domaine,  le  site  ou  l’unité  d’organisation  contenant  le  lien  d’objet  de  stratégie  de  groupe.  Si  tel  n’est  pas  le  cas,  l’option Lien activé n’est pas disponible. 

d. Suppression d’une stratégie de groupe  ■

Positionnez­vous  dans  l’arborescence  de  la  console  de  gestion  des  stratégies  de  groupe,  double  cliquez  sur  Objets  de  stratégie  de  groupe  dans  la  forêt  et  le  domaine  contenant  l’objet  de  stratégie  de  groupe  que  vous 

© ENI Editions - All rigths reserved

- 33 -

souhaitez supprimer.  ■

Cliquez avec le bouton droit sur l’objet de stratégie de groupe, puis cliquez sur Supprimer. 

■

Lorsque vous êtes invité à confirmer la suppression, cliquez sur OK. 

Pour  créer  un  objet  de  stratégie  de  groupe,  vous  devez  disposer  de  privilèges  de  création  d’objets  de  stratégie de groupe. Par défaut, seuls les administrateurs du domaine, les administrateurs de l’entreprise et  les membres du groupe Propriétaires créateurs de stratégie de groupe peuvent créer des objets de stratégie de  groupe. 

Pour  supprimer  un  objet  de  stratégie  de  groupe,  vous  devez  disposer  des  autorisations  Modifier  les  paramètres, Supprimer et Modifier la sécurité pour l’objet de stratégie de groupe. 

e. Désactivation d’une stratégie de groupe  ■

Pour désactiver tout ou partie d’un objet stratégie de groupe positionnez­vous sur l’objet stratégie de groupe qui  contient  les  paramètres  utilisateur  ou  ordinateur  que  vous  souhaitez  désactiver,  pointez  sur  État  GPO,  puis  effectuez l’une des actions suivantes :  ●

Cliquez sur  Paramètres utilisateur désactivés  pour  désactiver  les  paramètres  utilisateur  de  l’objet. Une  coche  en  regard  de  Paramètres  utilisateur  désactivés  indique  que  les  paramètres  utilisateur  sont  désactivés. 

●

Cliquez sur Paramètres ordinateur désactivés pour désactiver les paramètres ordinateur de l’objet. Une  coche  en  regard  de  Paramètres  ordinateur  désactivés  indique  que  les  paramètres  ordinateur  sont  désactivés. 

Pour désactiver un objet stratégie de groupe, vous devez disposer de l’autorisation Modifier sur l’objet de  stratégie de groupe. 

Vous  pouvez  également  modifier  l’état d’un  objet  de  stratégie  de  groupe  à  partir  de  l’onglet Détails  d’un  objet de stratégie de groupe. 

8. Administration du déploiement  a. Gestion des conflits de traitement des stratégies de groupe  Conflits entre les paramètres Comme  cela  était  le  cas  avec  les  stratégies  système  de  Windows  NT,  les  paramètres  contrôlés  par  une  stratégie  peuvent être positionnés de différentes façons.  Non configuré : cet état signifie que le paramètre n’est pas géré. Il n’y a donc aucun traitement particulier à réaliser.  Activé  :  cet  état  signifie  que  le  paramètre  est  activé.  Si  plusieurs  stratégies  de  groupe  concernent  le  même  paramètre  pour  le  même  objet  ordinateur  ou  utilisateur,  alors  le  dernier  paramètre  appliqué,  c’est­à­dire  celui  qui  dispose de la plus forte priorité, gagnera.  Désactivé : cet état signifie que le paramètre est désactivé. Si plusieurs stratégies de groupe concernent le même  paramètre  pour  le  même  objet  ordinateur  ou  utilisateur,  alors  le  dernier  paramètre  appliqué,  c’est­à­dire  celui  qui  dispose de la plus forte priorité, gagnera.  Ne pas passer outre Un  administrateur  peut  définir  une  stratégie  à  un  niveau  plus  élevé  pour  qu’elle  soit  toujours  appliquée.  Ce  processus,  appelé  “contrôle  obligatoire”  avec  la  GPMC,  était  auparavant  désigné  sous  le  terme  “Ne  pas  passer  outre”.  Un  administrateur  peut  aussi  définir  un  conteneur  pour  bloquer  l’application  des  stratégies  des  niveaux  - 34 -

© ENI Editions - All rigths reserved

supérieurs.  Une  stratégie  définie  par  l’administrateur  à  un  niveau  supérieur  afin  d’être  appliquée  continuera  de  l’être  même avec un blocage de niveau supérieur défini.  L’écran suivant montre l’option habituelle Ne pas passer outre. 

L’option Ne pas passer outre et Bloquer l’héritage de stratégies de la console de gestion MMC “Utilisateurs et  ordinateur Active Directory” 

Bloquer l’héritage Vous pouvez décider de bloquer l’héritage de stratégie pour un domaine ou une unité d’organisation. L’utilisation du  blocage d’héritage empêche les objets de stratégie de groupe liés à des sites, domaines ou unités d’organisation de  niveaux supérieurs d’être automatiquement hérités par le ou les niveaux enfants. Par défaut, les conteneurs enfants  héritent de l’ensemble des objets de stratégie de groupe parent, mais il peut parfois être utile de bloquer l’héritage.  Par exemple, si vous souhaitez appliquer un ensemble unique de stratégies à un domaine entier à l’exception d’une  unité  d’organisation,  vous  pouvez  lier  les  objets  de  stratégie  de  groupe  requis  au  niveau  du  domaine  (à  partir  duquel toutes les unités d’organisation héritent des stratégies par défaut), puis bloquer l’héritage  uniquement  sur  l’unité d’organisation à laquelle les stratégies ne doivent pas être appliquées.  Cette possibilité est montrée sur la figure précédente.  Pour réaliser cette opération à l’aide de la console gestion des stratégies de groupe GPMC, procédez comme suit :  ■

Positionnez­vous sur le domaine ou une unité d’organisation. 

■

Effectuez un clic droit sur le conteneur sélectionné. 

■

Choisissez l’option Bloquer l’héritage. 

b. Gestion du filtrage du déploiement des stratégies de groupe 

© ENI Editions - All rigths reserved

- 35 -

Le  filtrage  de  sécurité  permet  de  redéfinir  les  utilisateurs  et  les  ordinateurs  qui  recevront  et  appliqueront  les  paramètres d’un objet de stratégie de groupe.  À l’aide du filtrage de sécurité, vous pouvez spécifier que seules certaines entités de sécurité d’un conteneur auquel  est  lié  l’objet  de  stratégie  de  groupe  appliquent  l’objet  de  stratégie  de  groupe.  Le  filtrage  de  groupe  de  sécurité  détermine  si  l’objet  de  stratégie  de  groupe  s’applique  dans  son  ensemble  à  des  groupes,  des  utilisateurs  ou  des  ordinateurs.  Afin  que  l’objet de stratégie de groupe s’applique  à  un  utilisateur  ou  à  un  ordinateur  donné,  cet  utilisateur  ou  cet  ordinateur doit posséder deux autorisations indispensables :  ●

il doit être capable d’ouvrir, donc de Lire la stratégie de groupe, 

●

il doit aussi disposer de l’autorisation Appliquer  la  stratégie  de  groupe sur l’objet de stratégie de groupe,  que ce soit de manière explicite ou via l’appartenance habituelle à un groupe. 

Autorisations par défaut sur les objets stratégies de groupe : par défaut, la valeur des autorisations Lire et  Appliquer  la  stratégie  de  groupe  est  définie  à  Autorisé  pour  tous  les  objets  de  stratégie  de  groupe  du  groupe  Utilisateurs  authentifiés.  Notez  que  pour  que  les  administrateurs  puissent  appliquer  une  stratégie  de  groupe,  les  autorisations  par  défaut  des  groupes  “Administrateurs  de  l’entreprise”  et  “Administrateurs  du  domaine” ne sont pas suffisants. Vous devrez donc, dans ce cas précis, rajouter pour le groupe des “Admins du  domaine” le droit Appliquer la stratégie de groupe.  L’exemple suivant illustre une opération de filtrage réalisée à l’aide de la GPMC. 

Utilisation du filtrage pour cibler l’application des stratégies de groupe  Le  groupe  Utilisateurs  authentifiés  inclut  des  utilisateurs  et  des  ordinateurs.  C’est  de  cette  manière  que  tous  les  utilisateurs  authentifiés  reçoivent  les  paramètres  d’un  nouvel  objet  de  stratégie  de  groupe  lorsque  celui­ci  est  appliqué à une unité d’organisation, à un domaine ou à un site. Comme le montre la figure précédente, vous pouvez  modifier ces autorisations pour limiter l’étendue à un ensemble spécifique d’utilisateurs, de groupes ou d’ordinateurs  dans l’unité d’organisation, le domaine ou le site.  La  figure  précédente  montre  aussi  que  la  console  MMC  Gestion  des  stratégies  de  groupe  gère  ces  autorisations  comme une seule unité. Du coup, la déclaration à réaliser est plus facile. Pour modifier le filtrage de sécurité, vous  pouvez ajouter ou supprimer des groupes dans la section Filtrage de sécurité sous l’onglet Étendue d’un objet de  stratégie de groupe. En pratique, il n’est pas nécessaire de créer les deux entrées (Lire et Appliquer la stratégie  de  groupe)  car  la  console  GPMC  les  définit  automatiquement.  Par  contre,  il  est  toujours  possible  d’éditer  et  de  modifier les autorisations en mode avancé. Pour ce faire, vous pouvez ouvrir l’éditeur de liste de contrôle d’accès en  cliquant sur le bouton Avancé sous l’onglet Délégation de l’objet de stratégie de groupe. 

- 36 -

© ENI Editions - All rigths reserved

Affichage de la fenêtre de gestion des droits avancés 

c. Points importants  ●

Les  objets  stratégies  de  groupe  peuvent  seulement  être  liés  à  des  sites,  des  domaines  et  des  unités  d’organisation. 

●

Dans le cadre des principes de la technologie IntelliMirror, les objets de stratégie de groupe ne peuvent pas  être directement liés à des utilisateurs, des ordinateurs ou des groupes de sécurité. 

●

Le filtrage de sécurité vous permettra de limiter la portée d’un objet stratégie de groupe pour qu’il s’applique  uniquement à un groupe, à un utilisateur ou à un ordinateur unique. 

●

Les  autorisations  Lire  et  Appliquer  la  stratégie  de  groupe  ne  sont  pas  suffisantes  pour  garantir  qu’une  stratégie de groupe soit appliquée pour un utilisateur ou un ordinateur donné. L’objet stratégie de groupe  doit  aussi  être  lié  à  un  site,  à  un  domaine  ou  à  une  unité  d’organisation  contenant  l’utilisateur  ou  l’ordinateur, que ce soit directement ou via les mécanismes d’héritage. 

●

L’emplacement  des  groupes  de  sécurité  dans  Active  Directory  n’a  rien  à  voir  avec  le  filtrage  à  l’aide  des  groupes de sécurité. Les groupes n’ont aucune relation directe avec le traitement des stratégies de groupe.  Les groupes ne sont qu’un moyen de gérer les autorisations sur des objets. Ils permettent d’obtenir le droit  Lire et Appliquer la stratégie de groupe. 

●

Filtrage à l’aide de l’interface WMI. 

Attention  aux  conflits  entre  paramètres  et  aux  options  Ne  pas  passer  outre  et  Bloquer  l’héritage  des  objets stratégies de groupe sur les conteneurs de type unités d’organisation. 

d. Définition de filtres WMI 

© ENI Editions - All rigths reserved

- 37 -

Fonctionnement des filtres WMI Vous pouvez utiliser des filtres WMI pour déterminer de façon dynamique la portée des stratégies de groupe à partir  des attributs connus de types utilisateur ou ordinateur. De cette façon, vous pouvez étendre les capacités de filtrage  des objets stratégie de groupe au­delà des mécanismes de filtrage de sécurité présentés précédemment.  Un  filtre  WMI  est  associé  à  un  objet  stratégie  de  groupe.  Lorsque  vous  appliquez  un  objet  stratégie  de  groupe  à  l’ordinateur de destination, Active Directory évalue le filtre sur l’ordinateur de destination. Un filtre WMI se compose  d’une  ou  de  plusieurs  requêtes  évaluées  par  Active  Directory  en  fonction  de  l’espace  de  stockage  WMI  de  l’ordinateur de destination. Si la valeur totale des requêtes est “faux” (false), Active Directory n’applique pas l’objet  stratégie de groupe. Si toutes les requêtes sont vraies (true), alors Active Directory applique la stratégie de groupe.  Les  requêtes  WMI  sont  écrites  à  l’aide  du  langage  WQL  ­  WMI  Query  Language.  Ce  langage  est  très  proche  du  langage SQL et il permet d’interroger l’intégralité de l’espace de stockage WMI.  Chaque objet stratégie de groupe ne peut comporter qu’un seul filtre WMI qui peut contenir de multiples conditions.  Vous pouvez en revanche lier un même filtre WMI à de multiples objets stratégie de groupe. L’interface de la console  de gestion des stratégies de groupe vous permet de créer, d’importer, d’exporter, de copier et de coller des filtres  WMI très facilement.  Comment créer un filtre WMI ? ■

Ouvrez la console de Gestion des stratégies de groupe. 

■

Dans l’arborescence de la console, effectuez un clic droit sur Filtres WMI dans la forêt et le domaine dans lesquels  vous  souhaitez  créer  un  filtre  WMI.  Pour  y  parvenir,  positionnez­vous  sur Nom  de  la  forêt/  Domaines/Nom  du  domaine/Filtres WMI. 

■

Cliquez sur Nouveau. 

■

Dans la boîte de dialogue Nouveau filtre WMI, entrez un nom pour le nouveau filtre, puis une description dans la  zone Description. 

■

Cliquez sur Ajouter. 

■

Dans la boîte de dialogue Requête WMI, sélectionnez l’Espace de noms ou laissez l’espace de noms par défaut,  root\CIMv2. 

■

Dans la zone Requête, entrez une requête WMI, puis cliquez sur OK. 

■

Pour ajouter d’autres requêtes, répétez les trois dernières étapes pour chaque nouvelle requête. 

■

Après avoir ajouté toutes les requêtes, cliquez sur Enregistrer. 

Création de filtres WMI et privilèges nécessaires : pour pouvoir créer des filtres WMI, vous devez disposer  des privilèges nécessaires à cette opération. Les groupes Administrateurs de domaines, Administrateurs de  l’entreprise et Propriétaires créateurs de la stratégie de groupe bénéficient, par défaut, de cette autorisation.  La figure illustre les détails relatifs à la création du filtre. Comme expliqué plus haut, vous devez déclarer le nom du  filtre, une description, l’espace WMI sur lequel porte la requête ainsi que le contenu de la dite requête. 

- 38 -

© ENI Editions - All rigths reserved

Enregistrement de la requête WMI dans le filtre  Une fois le ou les filtres WMI créés, il ne vous reste plus qu’à associer un filtre à la stratégie de groupe concernée  par l’opération de filtrage.  Comment associer un filtre WMI à un objet stratégie de groupe particulier ?  ■

Ouvrez la console de Gestion des stratégies de groupe. 

■

Dans l’arborescence de la console, positionnez­vous sur l’objet stratégie de groupe pour lequel vous souhaitez lier  un  filtre  WMI.  Pour  y  parvenir,  positionnez­vous  sur  Nom  de  la  forêt/Domaines/Nom  du  domaine/Objets  de  stratégie de groupe, puis cliquez sur l’objet stratégie de groupe. 

■

Dans le volet des résultats, sous l’onglet Étendue, sous Filtrage WMI, sélectionnez un filtre WMI dans la zone de  liste déroulante. 

■

Lorsque vous êtes invité à confirmer la sélection, cliquez sur Oui. 

L’écran suivant illustre cette opération réalisée à l’aide de la console de gestion des stratégies. 

© ENI Editions - All rigths reserved

- 39 -

Association du filtre OS Win2000 STD and AS sur la stratégie Paramètres DNS globaux 

■

Vous avez aussi la possibilité de vous positionner sur le nœ ud Filtres WMI et de sélectionner directement l’objet  filtre  WMI  qui  vous  intéresse  pour  contrôler  les  liaisons  sur  lesquelles  il  est  lié,  les  autorisations  relatives  à  la  délégation de contrôle sur les filtres WMI et le contenu du code du filtre. 

■

Vous pouvez aussi lier un filtre WMI à un objet de stratégie de groupe en appliquant la méthode suivante : dans  l’arborescence  de  la  console,  faites  un  glisser­déplacer  du  filtre  WMI  vers  l’objet  de  stratégie  de  groupe  auquel  vous  souhaitez  le  lier.  Pour  lier  un  filtre  WMI  à  un  objet  de  stratégie  de  groupe,  vous  devez  disposer  des  autorisations de modification sur un objet de stratégie de groupe. Un seul filtre WMI peut être lié à un objet de  stratégie de groupe. Si vous essayez de lier un filtre WMI à un objet de stratégie de groupe auquel un filtre WMI  est déjà lié, le système vous demandera si vous souhaitez remplacer l’ancien filtre par le nouveau. Vous pouvez  seulement lier un filtre WMI à un objet de stratégie de groupe du même domaine. 

■

Pour  supprimer  un  filtre  WMI,  dans  l’arborescence  de  la  console,  effectuez  un  clic  droit  sur  le  filtre  WMI  à  supprimer, puis cliquez sur Supprimer. Lorsque vous êtes invité à confirmer la suppression du filtre WMI, cliquez  sur Oui. 

Les ordinateurs clients fonctionnant sous Windows 2000 ignorent les filtres WMI. Ils continuent d’appliquer  les  stratégies  de  groupe  en  fonction  de  l’étendue  de  gestion  et  du  filtrage  de  sécurité.  De  plus,  pour  pleinement supporter les filtres WMI, les ordinateurs clients fonctionnant sous Windows XP Professionnel doivent  utiliser le SP2. 

Les  filtres  WMI  sont  disponibles  uniquement  dans  les  domaines  possédant  au  moins  un  contrôleur  de  domaine Windows Server 2003. Si tel n’est pas le cas, la console de gestion des stratégies de groupe GPMC  n’affichera pas les options WMI. 

Vous trouverez ci­dessous quelques exemples de scripts WMI. 

- 40 -

●

Filtrage  WMI  sur  la  version  de  système  d’exploitation  Root\CimV2; Select * from Win32_OperatingSystem where Caption = “Microsoft Windows 2000  Advanced  Server” OR Caption = “Microsoft Windows 2000 Server” 

●

Filtrage  WMI  sur  la  version  d’un  fixe  de  type  QFE  Root\cimv2 ; select * from Win32_QuickFixEngineering 

© ENI Editions - All rigths reserved

where HotFixID =’q147222’  ●

Filtrage  WMI  sur  un  paramètre  de  configuration  réseau  (Multicast)  Select * from Win32_NetworkProtocol  where SupportsMulticasting = true 

●

Filtrage  WMI  sur  le  modèle  d’ordinateur  Root\CimV2; Select * from Win32_ComputerSystem where manufacturer  = "Toshiba"  and  Model  =   “Tecra  8000" OR Model = ”Tecra 8100" 

Pour plus de renseignements sur l’interface WMI, vous pouvez vous référer aux adresses spécifiées ci­dessous :  ●

Windows  Server  2003  Management  Services  http://www.microsoft.com/windowsserver2003/technologies/management/default.mspx 

●

Microsoft Management Web site : http://www.microsoft.com/management 

●

Windows  Management  Instrumentation  Web  url=/library/en­us/dnanchor/html/anch_wmi.asp 

●

Microsoft Technet Script Center : http://www.microsoft.com/technet/scriptcenter 

●

Reportez­vous au répertoire programme de la console de gestion des stratégies de groupe (GPMC), c’est­à­ dire  le  répertoire  %programfiles%\gpmc\scripts.  Ce  répertoire  contient  de  nombreux  scripts  WMI  mis  à  disposition pour l’automatisation de certaines opérations qui concernent les stratégies de groupe. 

site 

: 

: 

http://msdn.microsoft.com/library/default.asp?

© ENI Editions - All rigths reserved

- 41 -

Configuration des paramètres d’actualisation des stratégies de groupe  1. Rafraîchissement des stratégies de groupe  a. Rafraîchissement des stratégies en tâche de fond  En plus du traitement qui est réalisé lors de la phase de démarrage de l’ordinateur  et  d’ouverture de session de  l’utilisateur, les stratégies de groupe s’appliquent en tâche de fond et de manière périodique.  Les  différents  composants  d’extensions  réappliquent  leurs  paramètres  seulement  lorsque  cela  est  nécessaire,  ou  bien lorsqu’une stratégie impose de réappliquer systématiquement les paramètres, peut­être pour des raisons de  sécurité ou d’état de la configuration.  Les composants client spécialisés dans l’installation des logiciels ou la redirection des dossiers ne réappliquent leurs  paramètres qu’au démarrage de l’ordinateur et à l’ouverture de session des utilisateurs. 

b. Cycle de rafraîchissement  Par  défaut,  les  stratégies  de  groupe  sont  vérifiées  toutes  les  90  minutes  auxquelles  est  ajoutée  une  valeur  aléatoire  comprise  entre  0  et  30  minutes.  Finalement,  le  temps  maximum  de  rafraîchissement  peut  atteindre  120  minutes.  Nous  verrons  plus  loin  qu’il  est  possible  de  contrôler  chaque  CSE  ­  Client  Side  Extensions,  de  telle  sorte  que  certaines extensions, comme par exemple, les paramètres de sécurité d’Internet Explorer soient toujours appliqués,  même lorsque les stratégies ne sont pas modifiées.  Ce mode de fonctionnement permet de garantir l’état et la conformité de la configuration d’une machine. 

c. Rafraîchissement à la demande  Il  est  possible  d’éviter  le  redémarrage  de  l’ordinateur  ainsi  que  la  réouverture  d’une  session  en  utilisant  la  commande Gpupdate. Notez que par défaut, les utilisateurs ont cette possibilité, qui certes n’est pas dangereuse,  mais peut générer un flux réseau non négligeable.  La  commande  Gpupdate.exe  est  initiée  côté  client.  Il  n’est  pas  possible  de  déclencher  à  distance  un  rafraîchissement des stratégies de groupe en fonctionnant en mode “notify” du serveur vers le client. 

2. Configuration de la fréquence de rafraîchissement des stratégies de groupe  Vous pouvez personnaliser la fréquence d’actualisation des stratégies de groupe de type utilisateur et/ou ordinateur  en fonction de vos besoins. Pour réaliser cette opération, procédez comme spécifié ci­dessous :  ■

Sélectionnez  puis  ouvrez  l’objet  stratégie  de  groupe  approprié.  Positionnez­vous  dans  la  partie  Configuration  utilisateur  ou Configuration  ordinateur  en  fonction  du  besoin  puis  Modèles d’administration/Système.  Cliquez  sur Stratégie de groupe, puis double cliquez sur l’un des paramètres suivants :  Intervalle d’actualisation de la stratégie de groupe pour les utilisateurs (la valeur par défaut est de 90 minutes,  plus une valeur comprise entre 0 et 30 minutes).  Intervalle d’actualisation de la stratégie de groupe pour les ordinateurs (la valeur par défaut est de 90 minutes,  plus une valeur comprise entre 0 et 30 minutes).  Intervalle d’actualisation de la stratégie de groupe pour les contrôleurs de domaine (la valeur par défaut est de  5 minutes). 

■

Sélectionnez Activé. 

© ENI Editions - All rigths reserved

- 1-

■

Définissez l’intervalle d’actualisation en minutes. 

  ■

Définissez  le  décalage  aléatoire,  puis  cliquez  sur  OK.  Si  vous  avez  désactivé  ces  paramètres,  la  stratégie  de  groupe est mise à jour par défaut toutes les 90 minutes. Pour spécifier que la stratégie de groupe ne doit jamais  être mise à jour lorsque l’ordinateur est en cours d’utilisation, sélectionnez l’option  Désactiver l’actualisation en  tâche de fond des stratégies de groupe. 

Si  vous  sélectionnez  0  minute,  l’ordinateur  tente  de  mettre  à  jour  la  stratégie  utilisateur  toutes  les  7  secondes. Ce mode de tests ou de démonstration ne doit pas être utilisé en production sur des centaines de  machines. 

3. Rafraîchissement à l’aide de Gpupdate.exe  La commande Gpupdate.exe vous permet d’invoquer le processus de découverte et d’actualisation des stratégies de  groupe pour actualiser les informations en vigueur.  Cette  commande  existe  sous  Windows  XP  Professionnel  et  Windows  Server  2003,  mais  pas  sur  les  systèmes  fonctionnant  sous  Windows  2000.  Pour  information,  les  machines  fonctionnant  sous  Windows  2000  utilisent  la  commande Secedit.exe, laquelle prend en charge les mêmes fonctionnalités de rafraîchissement.  Un exemple de syntaxe de la commande Secedit est donné ci­dessous. Par exemple, pour forcer immédiatement les  ordinateurs et les utilisateurs à réappliquer leurs paramètres sans attendre, vous pouvez utiliser les commandes ci­ dessous :  ●

Pour la partie ordinateur, utilisez : Secedit /RefreshPolicy MACHINE_POLICY /Enforce 

●

Pour la partie utilisateur, utilisez : Secedit /RefreshPolicy USER_POLICY /Enforce 

Le fait que la commande Secedit soit remplacée par la commande Gpupdate ne signifie pas que Secedit ait  disparu.  Les  paramètres  de  Secedit  [/configure,  /analyze,  /import,  /export,  /validate,  /generaterollback]  sont  toujours  disponibles.  Seul  le  paramètre /RefreshPolicy a été supprimé et décalé vers la commande Gpupdate.exe. 

- 2-

© ENI Editions - All rigths reserved

Concernant les ordinateurs fonctionnant sous Windows Server 2003 ou Windows XP Professionnel, la syntaxe de la  commande Gpupdate est spécifiée ci­après.  gpupdate [/target:{ordinateur|utilisateur}] [/force] [/wait:valeur] [/logoff] [/boot]

4. Traitement des composants des stratégies de groupe sur les liaisons lentes  Quand le composant GPE (Group Policy Engine), détecte une liaison lente, il positionne un paramètre pour prévenir les  différents  composants  d’extension  client  (CSE  ­  Client  Side  Extensions)  qu’un  traitement  de  stratégie  de  groupe  devrait être réalisé sur un lien de type “lent”.  Les valeurs par défaut des différents composants se comportent par défaut de la manière suivante :  ●

Les paramètres de sécurité sont appliqués : pour des raisons de sécurité, il n’est  pas  possible  de  spécifier  que les paramètres de sécurité ne soient pas appliqués sous prétexte que les performances du réseau à un  instant donné sont lentes. 

●

Modèles administratifs : pour des raisons nécessaires au bon fonctionnement des stratégies de groupe, les  modèles administratifs ne peuvent pas être désactivés. 

●

Installation et maintenance des logiciels : lorsque le réseau est considéré comme lent, alors les composants  d’installation  et  de  maintenance  des  logiciels  sont  désactivés.  De  cette  manière,  le  réseau  n’est  pas  surchargé par des trafics trop volumineux. 

●

L’exécution des scripts est désactivée. 

●

La redirection des dossiers est désactivée. 

a. Traitement des paramètres de stratégie de groupe non modifiés  Par défaut, chaque extension spécialisée côté client (à l’exception de l’extension  Service  d’installation à distance),  applique uniquement les paramètres de stratégie de groupe qui ont été modifiés depuis la dernière application de  la stratégie de groupe. Par conséquent, le traitement est très optimisé et, généralement, il ne sera pas nécessaire  de modifier la façon dont les stratégies de groupe sont évaluées et appliquées.  Cependant, il se peut que pour des raisons de sécurité, vous vouliez garantir la bonne application des paramètres  spécifiés dans les stratégies de groupe.  Qu’en est­il de la modification des paramètres locaux ?  Dans le cas où un paramètre contrôlé par une stratégie de groupe serait modifié “en live” au cours d’une session et  si la stratégie de groupe n’était pas modifiée, alors la modification faite par l’utilisateur restera en place.  Pour  aider  à  la  résolution  de  ce  phénomène,  vous  avez  la  possibilité  de  configurer  chaque  extension  client  pour  traiter  l’application  systématique  de  tous  les  paramètres  contenus  dans  la  stratégie,  qu’ils  aient  été  ou  non  modifiés. Cette configuration peut être accomplie à l’aide des paramètres de stratégies de groupe inclus dans les  modèles d’administration. 

b. Activation de la détection de liens lents  La  détection  de  liens  lents  est  activable  très  simplement  en  accédant  à  la  fenêtre  de  configuration  ci­dessous  disponible  à  l’emplacement  suivant  : Configuration  ordinateur/Modèles  d’administration\Système\Stratégie  de  groupe/Détection d’une liaison lente de stratégie de groupe 

© ENI Editions - All rigths reserved

- 3-

Activation de la détection de liens lents  Lorsque vous activez cette fonctionnalité, la valeur 500 Kbits/s est automatiquement sélectionnée. 

c. Forçage de l’application des paramètres de stratégie même lorsqu’ils n’ont pas changé  La  figure  suivante  illustre  l’activation  de  l’option  Traiter  même  si  les  objets  Stratégie  de  groupe  n’ont  pas  été  modifiés sur l’extension CSE spécialisée dans le traitement de la maintenance d’Internet Explorer. 

  Notez que la liste des extensions client est contrôlable à l’aide des modèles administratifs.  Vous aurez remarqué l’option Ne pas appliquer lors des traitements en tâche de fond périodiques. Cette option  empêche  le  système  de  mettre  à  jour  les  stratégies  concernées  en  tâche  de  fond  lorsque  cet  ordinateur  est  en  - 4-

© ENI Editions - All rigths reserved

cours d’utilisation. Les mises à jour en tâche de fond pendant que l’utilisateur travaille, ne sont pas recommandées.  En effet, il se peut que cela puisse perturber l’utilisateur, provoquer l’arrêt d’un programme ou même, dans de rares  cas, endommager les données.  Les composants dont vous pouvez contrôler le traitement lorsque les informations n’ont pas été modifiées sont :  ●

la stratégie de traitement du registre ; 

●

la stratégie de Maintenance Internet Explorer ; 

●

la stratégie d’installation des logiciels ; 

●

la stratégie de Redirection des dossiers ; 

●

la stratégie des scripts ; 

●

la stratégie de sécurité ; 

●

la stratégie de sécurité IP ; 

●

la stratégie sans fils ; 

●

la stratégie de récupération EFS ; 

●

la stratégie de quotas de disques. 

5. Interdiction du rafraîchissement pour les utilisateurs  Par défaut, les utilisateurs ont la possibilité de lancer la commande Gpupdate. De cette manière, ils peuvent rafraîchir  les  informations  de  configuration  obtenues  à  l’aide  des  stratégies  de  groupe,  sans  redémarrer  complètement  l’ordinateur.  Le paramètre Supprimer la capacité de l’utilisateur à invoquer l’actualisation de la stratégie de l’ordinateur situé  à  l’emplacement Configuration  ordinateur/Modèles  d’administration/Système/Stratégie  de  groupe,  vous  permet  de contrôler la possibilité qu’a l’utilisateur d’invoquer une actualisation de la stratégie de l’ordinateur.  Si vous activez ce paramètre, les utilisateurs ne pourront plus invoquer d’actualisation de la stratégie de l’ordinateur.  La  stratégie  de  l’ordinateur  continuera  à  être  appliquée  au  démarrage  ou  lorsqu’une  actualisation  officielle  de  la  stratégie  se  produit.  Si  vous  désactivez  ou  si  vous  ne  configurez  pas  ce  paramètre,  le  comportement  par  défaut  s’applique.  Par défaut, la stratégie de l’ordinateur est appliquée lors du démarrage de l’ordinateur. Elle s’applique également à  un intervalle d’actualisation spécifié ou lorsqu’elle est invoquée manuellement par l’utilisateur.  Ce  paramètre  ne  s’applique  pas  aux  administrateurs.  Les  administrateurs  peuvent  demander  une  actualisation de la stratégie de l’ordinateur  à  n’importe quel moment, quelle que soit la configuration de la  stratégie. Ce paramètre nécessite que l’ordinateur soit redémarré. 

6. Traitement par boucle de rappel (Loopback)  Le traitement par boucle de rappel est une fonctionnalité particulière destinée à des ordinateurs à usage ciblé, tels  que les machines libres services placées dans des endroits publics tels que des aéroports ou les halls de gares.  Par  défaut,  les  stratégies  de  groupe  d’un  utilisateur  déterminent  l’ensemble  des  paramètres  à  appliquer  lorsque  l’utilisateur ouvre une session sur n’importe quel ordinateur du réseau.  Dans  le  cas  d’un  poste  libre  service,  il  ne  s’agit  donc  pas  de  l’ordinateur  habituel  de  l’utilisateur,  il  n’est  pas  souhaitable que l’environnement de production de l’utilisateur soit “déployé” de la sorte.  Pour  y  parvenir,  vous  devrez  mettre  en œ uvre  sur  ces  ordinateurs  libre  service  le  mode  “Traitement par boucle de  rappel” en anglais Loopback Processing Mode. Pour cela, vous pourrez créer une stratégie de groupe qui permettra de  déterminer  la  partie  utilisateur  de  l’environnement  de  l’utilisateur  d’une  manière  particulière.  Ce  paramètre  de 

© ENI Editions - All rigths reserved

- 5-

configuration  important  est  placé  dans  la  partie  ordinateur  à  l’emplacement  suivant  :  Configuration  ordinateur/Modèles d’administration/Système/Stratégie  de  groupe/Mode  traitement  de  la  boucle  de  rappel  de  la stratégie de groupe  Comme  vous  pouvez  le  constater,  il  s’agit  d’un  paramètre  de  type  ordinateur.  Par  conséquent,  ce  mode  de  fonctionnement s’appliquera à l’ensemble des utilisateurs qui ouvriront une session sur l’ordinateur concerné par ce  mode de fonctionnement. 

Déclaration du traitement par boucle de rappel  Le traitement par boucle de rappel peut être exécuté selon deux modes :  ●

Remplacer  :  ce  mode  remplace  les  paramètres  utilisateur  définis  dans  les  objets  Stratégie  de  groupe  de  l’utilisateur par les paramètres utilisateur contenu dans la stratégie appliquée sur l’ordinateur. 

●

Fusionner  :  ce  mode  combine  les  paramètres  utilisateur  définis  dans  les  objets  stratégie  de  groupe  de  l’ordinateur avec les paramètres utilisateur habituellement appliqués à l’utilisateur. En cas de paramètres en  conflit, les paramètres utilisateur des objets stratégie de groupe de l’ordinateur sont, bien sûr, prioritaires sur  les paramètres habituels de l’utilisateur. 

Comme  vous  pouvez  le  constater,  les  paramètres  utilisateur  de  la  stratégie  de  groupe  qui  concerne  l’ordinateur,  sont  appliqués  en  remplaçant  ou  en  fusionnant  les  habituels  paramètres  utilisateur  de  la  stratégie qui concerne l’utilisateur. De cette manière, la machine l’emporte au détriment de l’utilisateur. 

- 6-

© ENI Editions - All rigths reserved

Gestion des stratégies de groupe à l’aide de la GPMC  1. Opération de sauvegarde et restauration des stratégies de groupe  La sauvegarde des stratégies de groupe était jusqu’à l’apparition de la console de gestion des stratégies de groupe,  une opération réservée aux outils de sauvegarde et de restauration Active Directory.  Désormais,  vous  pouvez  utiliser  la  console  de  gestion  des  stratégies  de  groupe  pour  sauvegarder  un  objet  de  stratégie de groupe, qu’il soit dans un domaine Windows 2000, Windows Server 2003 ou Windows Server 2008. Pour  réaliser cette opération, procédez comme suit :  ■

Ouvrez Gestion des stratégies de groupe. 

■

Dans l’arborescence de la console, double cliquez sur Objets de stratégie de groupe dans la forêt et le domaine  contenant les stratégies de groupe que vous souhaitez sauvegarder. 

■

Pour  sauvegarder  un  seul  objet  de  stratégie  de  groupe,  effectuez  un  clic  droit  sur  ce  dernier,  puis  cliquez  sur  Sauvegarder.  Pour  sauvegarder  tous  les  objets  de  stratégie  de  groupe  du  domaine,  effectuez  un  clic  droit  sur  Objets  de  stratégie de groupe, puis cliquez sur Sauvegarder tout. 

■

Dans  la  boîte  de  dialogue  Sauvegarder  l’objet  de  stratégie  de  groupe,  dans  la  zone  Emplacement,  entrez  le  chemin d’accès de l’emplacement auquel vous souhaitez stocker les sauvegardes, puis cliquez sur OK. 

■

Dans  la  zone  Description,  entrez  une  description  des  objets  de  stratégie  de  groupe  que  vous  souhaitez  sauvegarder,  puis  cliquez  sur  Sauvegarder.  Si  vous  sauvegardez  plusieurs  objets  de  stratégie  de  groupe,  la  description s’appliquera à l’ensemble des objets de stratégie de groupe que vous sauvegardez. 

■

Une fois l’opération terminée, cliquez sur OK. 

Les objets stratégies de groupe contiennent de nombreux paramètres de configuration. Il est donc important  de  penser  à  la  sécurisation  des  stratégies  de  groupe  sauvegardées.  Assurez­vous  que  seuls  les  administrateurs autorisés ont accès au dossier vers lequel vous exportez l’objet de stratégie de groupe. 

Pour exécuter cette procédure, vous devez disposer des autorisations de Lecture pour l’objet de stratégie de  groupe  et  des  autorisations  Écriture  pour  le  dossier  contenant  la  sauvegarde  de  l’objet  de  stratégie  de  groupe. 

■

Pour exécuter une sauvegarde de vos stratégies de groupe en ligne de commande, utilisez un des scripts inclus  dans  le  répertoire  %Programfiles%\gpmc\Scripts.  Positionnez­vous  dans  le  répertoire  contenant  les  scripts  puis  utilisez la commande ci­dessous : BackupAllGPOs C:\Backup­AllGPOs /comment:"ALL GPOs" 

© ENI Editions - All rigths reserved

- 1-

Sauvegarde des stratégies de groupe via le script BackupAllGPOs.wsf  La restauration d’un objet stratégie de groupe est aussi simple que l’opération de sauvegarde.  ■

Effectuez un clic droit sur Objets de stratégie de groupe, puis sélectionnez Gérer les sauvegardes. 

■

Dans  la  boîte  de  dialogue Gérer  les  sauvegardes,  dans  la  zone  Emplacement  de  sauvegarde,  tapez  le  chemin  d’accès  du  dossier  de  sauvegarde.  Vous  pouvez  aussi  cliquer  sur  Parcourir  pour  accéder  au  dossier  de  sauvegarde. 

Vous pouvez disposer de multiples répertoires de sauvegarde. Chaque répertoire de sauvegarde contient un fichier  nommé Manifest.xml qui contient le descriptif des éléments sauvegardés.  ■

Dans la zone Objets GPO sauvegardés, sélectionnez l’objet de stratégie de groupe que vous souhaitez restaurer  dans la liste des sauvegardes d’objets de stratégie de groupe qui s’affiche, puis cliquez sur Restaurer. 

■

Lorsque vous êtes invité à confirmer l’opération de restauration, cliquez sur OK. 

Pour restaurer un objet de stratégie de groupe existant, vous devez disposer des autorisations Modifier les  paramètres, supprimer, modifier la sécurité sur l’objet de stratégie de groupe et des autorisations de Lecture  sur le dossier contenant la sauvegarde de l’objet de stratégie de groupe. 

Vous devez détenir les privilèges permettant de créer des objets de stratégie de groupe dans le domaine et  les  autorisations  de  Lecture  sur  l’emplacement  du  système  de  fichiers  de  l’objet  de  stratégie  de  groupe  sauvegardé pour restaurer un objet de stratégie de groupe qui a été supprimé. 

Vous  pouvez  également  restaurer  un  objet  de  stratégie  de  groupe  existant  ou  supprimé  à  l’aide  de  la  fonction  Gérer  les  sauvegardes,  en  effectuant  un  clic  droit  sur  Domaines  ou  sur  Objets  de  stratégie  de  groupe. 

Attention : les scripts initialement inclus avec la GPMC SP1 (prévue pour Windows XP SP2 ou Windows Server 2003)  ne  sont  plus  livrés  sur  les  serveurs  fonctionnant  sous  Windows  Server  2008.  Ils  sont  cependant  disponibles  en  téléchargement à l’adresse suivante : http://go.microsoft.com/fwlink/?LinkId = 106342 

2. Opération de copie de stratégies de groupe  Une opération de copie permet de transférer les paramètres d’un objet stratégie de groupe existant vers un nouvel  objet stratégie de groupe.  Pourquoi utiliser la fonctionnalité de copie de la GPMC ?  Les  opérations  de  copie  sont  adaptées  au  déplacement  d’une  stratégie  de  groupe  entre  des  environnements  de  - 2-

© ENI Editions - All rigths reserved

production, ainsi qu’entre un domaine de tests et un environnement de production. Pour réaliser ces opérations, il est  nécessaire qu’il existe une relation d’approbation entre les domaines source et de destination.  Le nouvel objet stratégie de groupe créé lors de l’opération de copie se voit attribuer un nouvel identificateur global  unique (GUID, Globally Unique Identifier) et ses liens éventuels sont supprimés.  Vous  pouvez  utiliser  une  opération  de  copie  pour  transférer  les  paramètres  vers  un  nouvel  objet  de  stratégie  de  groupe appartenant au même domaine, à un autre domaine de la même forêt ou à un domaine d’une autre forêt.  Une  opération  de  copie  utilise  un  objet  de  stratégie  de  groupe  existant  dans  Active  Directory  comme  source.  Une  approbation est donc nécessaire entre les domaines source et de destination.  La copie est similaire à la sauvegarde suivie d’une importation, mais ne comporte pas d’étape de système de fichiers  intermédiaire. Un nouvel objet de stratégie de groupe est créé dans le cadre de l’opération de copie. 

3. Opération d’importation des paramètres  L’opération d’importation transfère des paramètres dans un objet de stratégie de groupe existant en utilisant comme  source un objet de stratégie de groupe sauvegardé dans le système de fichiers. 

a. Pourquoi utiliser la fonctionnalité d’importation de la GPMC ?  Les  opérations  d’importation  peuvent  être  utilisées  pour  transférer  des  paramètres  d’un  objet  de  stratégie  de  groupe  à  un  autre  situé  dans  le  même  domaine,  dans  un  autre  domaine  de  la  même  forêt  ou  dans  un  domaine  d’une autre forêt.  L’opération  d’importation  place  toujours  les  paramètres  sauvegardés  dans  un  objet  de  stratégie  de  groupe  existant.  Faites  attention  au  fait  que  cette  opération  efface  tous  les  paramètres  préexistants  dans  l’objet  de  stratégie de groupe de destination. 

Si vous disposez de forêts de test et de production séparées, avec ou sans relation d’approbation,  il  est  conseillé  de  tester  les  objets  de  stratégie  de  groupe  dans  la  forêt  de  test  avant  de  les  importer  dans  la  forêt de production. 

L’importation ne requiert aucune relation d’approbation entre le domaine source et le domaine de destination.  Cette opération peut donc être utile pour transférer des paramètres entre des forêts et des domaines sans relation  d’approbation.  L’importation  de  paramètres  dans  un  objet  de  stratégie  de  groupe  n’affecte  ni  sa  liste  de  contrôle  d’accès  discrétionnaire  (DACL, Discretionary  Access  Control  List),  ni  les  liens  vers  cet  objet  de  stratégie  de  groupe  sur  les  sites, domaines ou unités d’organisation, ni le lien vers un filtre WMI. 

b. Utilisation d’une table de correspondances entres les objets de différents domaines ou forêts  Si vous utilisez l’opération d’importation pour transférer les paramètres d’un objet de stratégie de groupe vers un  objet de stratégie de groupe dans un autre domaine ou une autre forêt, vous pouvez utiliser une table de migration  conjointement à l’opération d’importation. Une table de migration vous permet de faciliter le transfert de références  à des groupes de sécurité, des utilisateurs, des ordinateurs et des chemins d’accès UNC dans l’objet de stratégie  de groupe source vers des nouvelles valeurs dans l’objet de stratégie de groupe de destination. 

© ENI Editions - All rigths reserved

- 3-

Vérification et résolution des problèmes liés aux stratégies de groupe  avec RsoP  Vous avez la possibilité de simuler le déploiement de stratégies de groupe pour les utilisateurs et les ordinateurs avant  de réellement les déployer dans l’environnement de production.  Cette  fonctionnalité  de  la  console  Gestion  de  stratégie  de  groupe  est  appelée  Jeu  de  stratégies  résultant  (RSoP,  Resultant Set of Policies) en mode de planification.  Elle requiert, au minimum, un contrôleur de domaine exécutant Windows Server 2003 ou Windows Server 2008  dans la forêt.  Pour vérifier les paramètres de stratégie de groupe à l’aide de l’Assistant Modélisation de stratégie de groupe, vous  devez  d’abord  créer  une  requête  de  modélisation  de  stratégie  de  groupe  et  afficher  cette  requête.  Pour  créer  une  nouvelle requête de modélisation de stratégie de groupe, procédez de la manière suivante :  ■

Ouvrez la console Gestion de stratégie de groupe, naviguez jusqu’à la forêt dans laquelle vous souhaitez créer une  requête de modélisation de stratégie de groupe, effectuez un clic droit de la souris sur Modélisation de stratégie de  groupe, puis sur Assistant Modélisation de stratégie de groupe. 

■

Sur  la  page  Assistant  Modélisation  de  stratégie  de  groupe,  cliquez  sur  Suivant,  entrez  les  informations  requises  dans les pages de l’Assistant, puis cliquez sur Terminer. 

Pour afficher la requête de modélisation de stratégie de groupe, procédez comme suit :  ■

Ouvrez la console Gestion de stratégie de groupe. 

■

Naviguez  jusqu’à  la  forêt  contenant  la  requête  de  modélisation  de  stratégie  de  groupe  à  afficher,  développez  Modélisation de stratégie de groupe, effectuez un clic droit sur la requête, puis cliquez sur Affichage avancé. 

Il ne reste plus qu’à vérifier que les résultats présentés sur le rapport généré en fin de simulation sont proches des  résultats attendus. 

© ENI Editions - All rigths reserved

- 1-

Délégation du contrôle administratif sur les stratégies de groupe  La  console  de  gestion  des  stratégies  de  groupe  permet  de  gérer  les  opérations  de  délégation  de  manière  très  conviviale. Ainsi, il sera très simple de réaliser les opérations suivantes :  ●

créer des objets de stratégie de groupe dans un domaine, 

●

définir des autorisations sur un objet de stratégie de groupe, 

●

définir les autorisations de stratégie sur un site, un domaine ou une unité d’organisation, 

●

lier des objets de stratégie de groupe à un site, un domaine ou une unité d’organisation donnés, 

●

lancer  des  analyses  de  modélisation  de  stratégies  de  groupe  sur  un  domaine  ou  une  unité  d’organisation  donnés, mais pas sur un site. 

●

lire  les  données  des  résultats  de  la  stratégie  de  groupe  pour  des  objets  d’un  domaine  ou  d’une  unité  d’organisation donnés, mais pas d’un site. 

●

créer des filtres WMI dans un domaine, 

●

définir des autorisations sur un filtre WMI. 

L’onglet Délégation est disponible sur tous les conteneurs affichés dans la console de gestion des stratégies de  groupe  La  console  de  gestion  des  stratégies  de  groupe  simplifie  beaucoup  la  délégation  en  gérant  les  diverses  entrées  de  contrôle  d’ac