Les Maitres d’Operations pour la Forêt :

• Maitre du Schéma Active Directory

• Maitre de nom de domaine

Les Maitres d’Opération pour un domaine :

• Maitre RID

• Maitre d’Infrastructure

• Maitre PDC

Tous les maitres d’opération jouent un rôle important dans le bon fonctionnement d’Active Directory. Ils doivent être constamment joignables par tous les autres domaine contrôleurs de la forêt ou du domaine. Lors d’une maintenance planifiée, ou d’un incident  sur un DC qui agit comme maitre d’opération, il est nécessaire de transférer le ou les rôles à un autre DC pour assurer la bonne continuité du système.

Dans Active Directory, il existe deux modes pour transférer un rôle sur un autre contrôleur de domaine : le transfert simple, lorsque les deux domaines contrôleurs sont joignables, et la prise de contrôle du rôle (seize). Cependant, lorsque l’on transfert proprement un rôle, celui-ci peut retourner à son origine sans aucune contrainte, ce qui n’est pas le cas avec la prise de contrôle.

Criticité et retour à la normale

Voici l’ordre de priorité et de criticité des maitres d’Operations :

• Maitre PDC : Le PDC est l’Operation Master qui a le plus d’impact sur les utilisateurs s’il devient hors ligne. Heureusement, le rôle peut être transféré ou être pris sous contrôle facilement. Le retour au DC d’origine ne pose pas de soucis.

• Maitre Infrastructure : Un incident sur le maitre d’infrastructure ne sera vu que par les administrateurs et en aucun cas par les utilisateurs. De même que pour le PDC, un retour au DC d’origine ne pose aucun problème.

• Maitre RID : Une absence de maitre RID peut empêcher un DC de créer des nouveaux utilisateurs, groupes… Le problème ne se pose que si le pool de SID du DC arrive à sa fin. Il est préférable d’attendre que l’incident sur le serveur soit réparé plutôt que de faire une prise de contrôle du rôle. Cependant, si vous en faites une, l’ancien DC original ne peut pas être remis en ligne.

• Maitre du Schéma & Maitre de nom de domaine : De même que pour le Maitre RID, il est préférable d’attendre la réparation plutôt que de prendre le contrôle du rôle.

Transfert en interface graphique

Afin de transférer proprement un rôle, il y a deux solutions avec Windows Server 2008 : la méthode interface graphique et la méthode en ligne de commande avec ntdsutil.

Pour tout ce qui est interface graphique, vous devez vous connectez au serveur qui obtiendra le rôle une fois la manipulation effectuée. Faites bien attention à la connexion sur laquelle se fait la console MMC.

PDC, Infrastructure et RID

Active Directory Users And Computer est la console qui nous permet le transfert des rôles Primary Domain Contrôleur, du maitre d’infrastructure et du maitre RID.

Pour accéder à l’option, faites un clic droit sur votre domaine et sélectionnez « Operations Masters ».

Choisissez le rôle que vous voulez transférer et cliquez sur « Change »

Maitre de nom de domaine

Active Directory Domain And Trusts est la console qui nous permet le transfert du rôle Maitre de nom de domaine. Veuillez à bien faire attention au serveur sur lequel la console se connecte.

Maitre du Schéma

Active Directory Schema est la console qui nous permet le transfert du rôle Maitre du Schéma. Veuillez à bien faire attention au serveur sur lequel la console se connecte.

Rappel : Pour obtenir la console Active Directory Schema dans la MMC, il faut enregistrer une DLL avec la commande :

regsvr32 schmmgmt.dll

Une fois la console activée, utilisez la MMC pour ajouter le composant Active Directory Schema.

Toujours un clic droit sur la racine Active Directory Schema pour obtenir l’option de Transfert.

Transfert en ligne de commande

Le transfert d’un rôle en ligne de commande se fait par l’outil ntdsutil.

Pour cela, une fois l’outil lancé, vous devez vous connecter à un serveur puis lui transférer le rôle.

Par exemple, pour transférer le rôle de PDC sur le serveur 2.

Ntdsutil

Roles

Connections

Connect to server server-2.laboit.net

Quit

Transfer PDC

Voici une liste des actions possibles dans la partie rôles de l’outil ntdsutil:

Prise de contrôle (seize)

La prise de contrôle (seize) d’un rôle étant une action significative son utilisation ne peut être faite que par ligne de commande avec l’outil ntdsutil.

Je vous rappelle que lorsque vous prenez le contrôle des rôles RID, Schema Master, et Domain Naming Master, les anciens propriétaires du rôle ne doivent pas revenir en ligne. Vous devez forcer la désinstallation du DC en mode hors ligne avant de remettre le serveur en production.

La méthode est la même que pour transférer un rôle, à l’exception de la commande Transfer qui devient Seize.

Active Directory tentera toujours de transférer le rôle proprement plutôt que de faire une prise de contrôle lorsque cela est possible.

Par exemple, pour prendre le contrôle (seize) du rôle Maitre du Schéma sur le serveur 2.

Ntdsutil

Roles

Connections

Connect to server server-2.laboit.net

Quit

Seize schema master

Conclusion

Nous venons de voir comment changer les maitres d’Operations d’Active Directory. Deux méthodes, le transfert et la prise de contrôle. Cependant soyez très vigilant avec la prise de contrôle qui est une action significative.

]]> http://www.laboit.net/2010/06/13/transfert-des-operations-master/feed/ 0 http://www.laboit.net/2009/08/18/tour-de-france-windows-7/?utm_source=rss&utm_medium=rss&utm_campaign=tour-de-france-windows-7 http://www.laboit.net/2009/08/18/tour-de-france-windows-7/#comments Tue, 18 Aug 2009 09:00:30 +0000 Alexandre VIOT http://www.laboit.net/?p=431

Afin de faire découvrir son nouveau système d’exploitation, Microsoft et SUPINFO s’associent une nouvelle fois et organisent le tour de France Windows 7.

A cette occasion, j’animerai les conférences pour la ville de Troyes le mercredi 9 Septembre 2009.

Des ordinateurs exécutant  Windows 7 seront mis en démonstration :

• Laptop
• Netbook
• Tactile

 L’inscription se passe ici :

Vous utilisez la suite Microsoft Office et vous trouvez qu’il manque une fonctionnalité ou bien un bug, alors le site makeofficebetter.com est fait pour vous.

Issu d’une initiative de deux employés de Microsoft, il vous permettra d’ajouter vos idées et de voter pour celles qui vous plaisent.

Il ne s’agit pas d’un site officiel, mais nul doute que Microsoft surveillera cette expérience de très près.

http://www.makeofficebetter.com

Sous Exchange 2003, seul deux options étaient disponibles pour un serveur : Dorsal et Frontal. La version 2007 contient pas moins de cinq rôles possibles.

Dans un premier temps, nous allons revoir ce que proposait Exchange 2003. Puis nous  découvrirons les nouveaux rôles et la topologie qu’ils impliquent.

Auparavant

Sous la version 2003,  on distingue deux types de serveur : les Dorsaux et Frontaux.

Un serveur dorsal est la base de notre architecture. Sa fonction est de stocker les boites mail des utilisateurs ainsi que les dossiers publiques. Les clients qui utilisent Outlook en mode Exchange sont directement connectés à ces serveurs avec le protocole MAPI.

Un serveur frontal quant à lui se contente de gérer les clients en HTTP, POP3, IMAP. Lorsqu’un utilisateur se connecte à Outlook Web Access, le serveur frontal va interroger Active Directory pour être rediriger vers le serveur dorsal où se trouve la boite mail.

Ce type d’architecture est appelé frontal/dorsal. Il sépare le stockage de l’accès aux données. Il permet également une plus grande sécurité puisque seul le serveur frontal est connu sur internet.

Maintenant

La version d’Exchange 2007 possède désormais cinq rôles. Certains doivent être obligatoirement implémentés pour obtenir un service de messagerie.

Parmi ces rôles, quatre peuvent être installé sur le même serveur physique. Cependant, pour des raisons d’optimisation des performances et de maintenance, il est conseillé de les séparer.

Voici la liste et les explications des différents rôles :

• Mail box Server : ce rôle est équivalent au serveur dorsal dans Exchange 2003. Il permet de gérer et stocker les boites mail des utilisateurs et les dossiers publics. Il est possible de faire de la haute disponibilité en utilisant la réplication local en continue (LCR) ou bien en les mettant en cluster (CCR). C’est le seul rôle qui peut être mis en cluster. Contrairement à Exchange 2003, ce n’est plus lui qui s’occupe du routage des messages mais le HUB.  Il gère également l’accès des clients MAPI.
• Client Access Server (CAS) : il est équivalent au serveur frontal dans une architecture 2003. Il s’occupe de gérer les accès client non-MAPI, c’est-à-dire Outlook Web Access (OWA), ActiveSync, POP3, IMAP4. Ce changement de nom apporte également des nouveautés : ce serveur fournit maintenant des services supplémentaires tels que l’AutoDiscover (découverte automatique des options de configuration en spécifiant juste l’email.), une meilleure gestion des périphériques mobiles ainsi qu’une optimisation de la fonction Calendrier. Pour des raisons légales, CAS traite, filtre et journalise les messages.
• HUB Transport : ce nouveau rôle se consacre au routage des messages pour son site. Lorsqu’un utilisateur envoi un email vers l’extérieur, HUB le redirige vers un serveur EDGE ou bien vers une passerelle SMTP. Il peut également être configuré pour agir comme passerelle. Il est fortement recommandé d’installer un antivirus puisque c’est par lui que transitent les messages.

Quand un message doit être transmis, il répond à trois règles :

1. 1. Si le destinataire est dans le même site Active Directory, alors le serveur transfert le message au Mail Box serveur interne.
   2. Le destinataire fait parti de l’entreprise mais sur un site différent : alors le message est transmis au prochain HUB en utilisant le principe de la réplication.
   3. Le destinataire ne fait pas parti de l’entreprise : alors le message sera envoyé vers un serveur EDGE ou une passerelle SMTP.

• EDGE Transport : Il s’agit d’un nouveau rôle qui est différent des autres dans son fonctionnement. En effet, pour des questions de sécurité,  il ne doit pas faire parti du domaine et être positionné dans une DMZ. De se fait, il doit obligatoirement être installé sur un serveur distinct. Son but est de faire office de passerelle SMTP pour gérer les messages entrant avant le HUB. Un antivirus et anti spam doivent également être installés dessus. EDGE a une instance ADAM qui lui permet de stocker les utilisateurs afin de gérer le spam. Ne faisant pas parti du domaine, la liste des utilisateurs est poussée par le serveur HUB.
• Unified Messaging : joue le rôle d’intermédiaire entre le téléphone de l’entreprise et l’organisation Exchange. La messagerie unifiée Exchange Server 2007 réunit les fonctions de messagerie vocale, de télécopie et électronique en une seule boîte de réception accessible depuis le téléphone et l’ordinateur.

Architecture

Pour créer une architecture Exchange 2007 sécurisée, performante avec redondance des données, je vous conseille de suivre ces points :

• Pour assurer une tolérance des pannes, deux contrôleurs de domaine ainsi qu’un cluster possédant  au minimum deux nœuds pour les serveurs de boite aux lettres sont nécessaires sur chaque site où est déployé Exchange. Le cluster permet la réplication en continue des données.
• Un serveur HUB doit  est installé sur chaque site. Sans celui-ci, il est impossible de transférer les messages entre les différents sites.
• Lorsque le site est suffisamment grand pour accueillir un serveur EDGE, il doit être placé dans une zone DMZ.
• Un serveur CAS doit être présent sur chaque site, sans celui-ci les clients ne pourront pas utiliser OWA, ni les protocoles non-MAPI.
• Installation d’un antivirus et activation de l’anti spam sur chaque HUB et EDGE.

Conclusion

Tout au long de cet article, nous avons vu les différents rôles qu’apporte Exchange 2007 et la topologie qu’il nécessite.

J’espère qu’il vous a permis de mieux les comprendre et d’y voir plus clair. N’hésitez pas à réutiliser l’architecture pour éviter les soucis matériels.

Après un rappel sur le fonctionnement de DNS, les points abordés seront l’installation et l’administration du service. J’expliquerai les différents types de zones, les redirecteurs et la délégation de zone.

Introduction à DNS

Avant de commencer toute partie pratique, nous allons revoir le fonctionnement DNS afin de bien comprendre ce que nous allons mettre en place par la suite.

Pourquoi ?

Les ordinateurs en réseau  ne peuvent communiquer entre eux que par des adresses IP. Une adresse IP est seulement composée de chiffre. De ce fait, il est techniquement impossible, de base, de s’échanger des données en utilisant un nom. Hors il est bien plus facile de retenir un nom plutôt qu’une suite de chiffre.

Au début d’internet, on utilisait un fichier texte sur la machine qui permettait de faire la relation entre un nom et une adresse IP. Il était rempli manuellement sur chaque ordinateur.

Ce fichier existe toujours sur nos nouveaux systèmes d’exploitation. Sous Windows, il se trouve dans %SystemRoot%\Windows\System32\drivers\etc\hosts et sous Linux  /etc/hosts.

Cependant, avec l’explosion d’internet et la multiplication des noms de domaine il est devenu indispensable d’avoir un système qui permette de gérer dynamiquement la résolution. Ce fut l’apparition du DNS pour Domain Name System.

Un model hiérarchique

De par sa création, le système DNS est basé sur une structure arborescente. Cela signifie que vous pouvez décomposer un nom de domaine en plusieurs parties. Chaque partie est délimitée par un « . ». Par exemple, on peut séparer www.laboit.net en 3 parties.

La décomposition commence par la droite, et plus on va vers la gauche, plus on se rapproche de la machine cible.

Pour chaque partie du nom de domaine, il existe un serveur qui est capable de nous donner l’adresse IP de la machine, ou bien de nous rediriger vers un autre serveur DNS.

De plus, tous les noms de domaine dérivent d’une racine  Root symbolisé par le « . ». Ainsi, le véritable nom de Labo IT serait « www.laboit.net. »

La composition

On distingue deux types de noms avec le système DNS :

le nom d’hôte qui représente le nom d’une machine, généralement un serveur.

le FQDN (Fully Qualified Domain Name) ou nom de domaine pleinement qualifié

Le FQDN est composé de deux parties : le nom d’hôte et le suffixe DNS. Le suffixe DNS défini la relation entre le domaine auquel appartiennent la machine et le domaine racine. Pour un FQDN du type  www.microsoft.laboit.net, le nom d’hôte serait  www et le suffixe serait microsoft.laboit.net.

Voici un schéma pour vous montrer le model hiérarchique :

A chaque niveau de la hiérarchie, il existe un serveur DNS pour chaque membre.

Le processus

Pour obtenir une réponse à ses demandes, un client doit au moins avoir un serveur DNS primaire de renseigné. Pour les particuliers, il s’agit généralement de celui du fournisseur d’accès.

Voici le processus lorsqu’un client demande une résolution de nom :

1. Dans un premier temps, le client envoie une requête à son serveur DNS primaire pour savoir l’adresse IP du FQDN www.laboit.net
2. Si le serveur DNS a déjà le site dans son cache, il lui renvoie directement l’adresse IP. Sinon il va aller interroger d’autres serveurs.
3. Le serveur A demande au serveur racine (B) qui s’occupe de la partie .net. Ce dernier lui répond qu’il faut demander au serveur C.
4. Le serveur A réitère sa demande au serveur C mais cette fois, il demande l’adresse du serveur qui a autorité pour laboit.net. Le serveur C le redirige vers le serveur D.
5. Le serveur A demande au serveur  D de lui donner l’adresse IP de la machine qui a le nom d’hôte www.
6. Une fois l’adresse IP obtenue, le serveur A la renvoie au client.

Mise en place du service

Nous allons mettre en place un serveur DNS local.

Pré requis

Pour le bon fonctionnement de la résolution, les clients doivent savoir où envoyer leurs requêtes. L’information est généralement délivrée par le serveur DHPC, ou bien en dur pour les clients qui ont une IP fixe.

C’est pour cela que notre serveur DNS doit avoir une IP statique dans notre réseau.

Installation

Sous Windows Server 2008, le service DNS est un rôle. On utilisera Server Manager pour l’installer.

Une fois le service DNS installé, vous pouvez le configurer grâce à une console dédiée accessible dans les outils d’administration ou bien en tapant la commande dnsmgmt.msc

Configuration

Les serveurs racines

Lorsque vous avez installé le service sur votre machine, vous devez vérifier la présence des informations sur les serveurs DNS racine. En effet, si elles sont absentes, vous ne pourrez pas résoudre les noms de domaines extérieurs à votre réseau.

Quand notre serveur reçoit une requête dont il ne connait pas la réponse, il va contacter les serveurs DNS racine pour l’obtenir.

Pour accéder aux Serveur Racines, clic droit sur le serveur dans la console, puis Propriété.

Les redirecteurs

On a vu ci dessus que lorsque notre serveur DNS ne peut pas résoudre un nom de domaine, celui-ci va en contacter un autre. Par défaut, il s’agit des serveurs racines.

Un redirecteur permet de modifier ce comportement : en effet, notre serveur ne va plus demander aux  racines mais à un serveur qu’on aura précisé.

Cette fonction peut vous être utile lorsque vous avez plusieurs sites ou plusieurs serveurs DNS dans votre entreprise.

Utilisation des zones

Introduction

Le service est basé sur le principe de zone. Une zone contient les informations pour un et un seul nom de domaine. Pour simplifier, on peut comparer une zone DNS à un dossier. Vous pouvez avoir plusieurs zones par serveur.

Un client peut effectuer deux types de requête, une directe et une indirecte.

La requête directe est une demande de résolution simple, vous voulez connaitre l’adresse IP en fonction du nom.

La requête indirecte est le contraire, vous souhaitez connaitre le nom de la machine en fonction de son adresse IP.

Le nom de la zone pour la directe est simplement le suffixe DNS tandis que pour la zone inversée il s’agit de l’adresse IP à « l’envers » suivi de « .in-addr.arpa ». Pour résoudre 192.168.1.10, il faudra créer la zone inverse  « 1.168.192.in-addr.arpa ».

Les types d’enregistrement

Voici une liste des principaux enregistrements DNS :

A qui fait correspondre un nom d’hôte à une adresse IPv4.

AAAA qui fait correspondre un nom d’hôte à une adresse IPv6

CNAME qui permet de faire un alias vers un enregistrement A.

MX qui définit les serveurs de messagerie.

PTR qui associe une adresse IP à un enregistrement de nom de domaine, aussi dit « reverse » puisque il fait exactement le contraire du A record.

NS qui définit les serveurs DNS de ce domaine.

SOA donne les informations générales de la zone.

SRV qui définit un service.

Configuration d’une zone Primaire

Zone directe

La création de zone directe est simple sous Windows Server 2008. Il suffit de cliquer droit sur le conteneur de « Zone de recherche directe » puis de sélectionner « Nouvelle Zone ».

Une fenêtre s’ouvre alors vous demandant le type de la zone. Sélectionnez pour le moment « Zone Primaire»

Le serveur n’étant pour le moment pas un contrôleur de domaine, nous ne pouvons pas choisir d’intégrer la zone à Active Directory.

Sur la fenêtre suivante,  spécifiez le nom de votre zone, dans notre exemple, cela sera laboit.lan

Par la suite, une fenêtre vous demandera si la zone doit accepter les mises à jour dynamiques sécurisées ou non sécurisées. Cette option est utile lorsque vous utilisez un plan d’adressage dynamique tel que DHCP. En effet, les machines changeront régulièrement d’IP et la résolution de nom statique n’a plus aucun intérêt. Les machines sous Windows mettront donc à jour les informations DNS les concernant.

Voici la signification des 3 choix possibles :

N’autoriser que les mises à jour dynamiques sécurisées : seuls les ordinateurs possédant un compte d’ordinateur dans Active Directory peuvent créer et mettre à jour automatiquement leurs enregistrements de ressources.

Autoriser à la fois les mises à jour dynamiques sécurisées et non sécurisées : tous les ordinateurs exécutant Windows 2000/XP/2003 peuvent créer et mettre à jour leurs enregistrements de ressources. Même une machine qui n’est pas membre du domaine.

Ne pas autoriser les mises à jour dynamiques : Dans ce cas, la seule façon de mettre à jour les enregistrements de ressources est d’utiliser la commande ipconfig /registerdns sur chaque machine cliente.

Cliquez sur Terminer pour créer la zone primaire.

Lorsque la zone primaire a été crée, vous pouvez ajouter autant d’informations que vous souhaitez. Dans l’exemple si dessous, j’ai crée 3 enregistrements : un de type A et deux autres alias.

Zone indirecte

Si vous voulez avoir la possibilité de résoudre une adresse IP en nom, vous devez créer une zone de recherche inverse, ou indirecte.

Le principe de création reste le même que pour la zone principale, sauf qu’on ne vous demandera pas un nom, mais une plage IP. La zone inverse contiendra des enregistrements PTR.

Voici le résultat après l’ajout d’un enregistrement de type A dans la zone directe :

Les zones secondaires

Lors de la création d’une zone, l’assistant vous demande son type. Il existe la zone secondaire.

Une zone secondaire est utile lorsque vous avez plusieurs serveurs DNS dans votre entreprise: vous pouvez répliquer les zones primaires  pour éviter la surcharge.

Pour des questions de sécurité, les zones secondaires sont seulement en lecture seule.

La délégation de zone

Voici un autre point important du service DNS, la délégation de zone.

Imaginons que vous ayez deux sous domaine dans votre architecture : microsoft.laboit.net et cisco.laboit.net. Pour une meilleure organisation et gestion de votre réseau, vous avez décidé d’installer un serveur DNS dans chaque zone. Le serveur DNS de laboit.lan doit donc être capable de rediriger les requêtes vers le serveur sous jacent qui a autorité sur la zone.

La délégation s’applique sur une zone, cliquez droit sur la zone dont vous voulez déléguer, puis sélectionnez Nouvelle Délégation.

L’assistant vous demande alors le nom du sous domaine puis l’adresse IP du serveur distant.

Votre délégation est désormais effective. Les domaines délégués sont grisés sur l’arborescence et contiennent l’adresse IP du serveur qui a authorité.

Conclusion

Tout au long de cet article nous avons vu le fonctionnement du service DNS.

J’espère  que cet article a pu vous être utile.