Quel type de mécanisme DNS choisir (stub, secondaire ou redirecteurs conditionnels) ?

Sommaire

 

 

Introduction

Lorsqu’il est nécessaire que deux forêts distinctes puissent résoudre mutuellement leurs noms de machine et plus particulièrement lors de la création d’une relation d’approbation, vous serez dans l’obligation de mettre en place un mécanisme de résolution DNS entre ces deux forêts.

Pour cela, il existe trois solutions spécifiques qui sont la zone DNS secondaire, la zone de stub et les redirecteurs conditionnels. Chacune de ces solutions offre son lot d’avantages et d’inconvénients que nous allons voir au sein de cet article.

Remarque : Microsoft propose déjà un très bon article permettant de comprendre la différence entre une zone stub et les redirecteurs conditionnels: Différence entre les zones de stub et les redirecteurs conditionnels.

 


La zone secondaire

Une zone secondaire est une copie complète d’une zone primaire accessible uniquement en lecture seule. Sa mise en place permet d’accélérer le temps de réponse des requêtes des clients DNS car le serveur disposant de la zone secondaire traitent directement les demandes de résolution DNS.

Afin de mieux comprendre le fonctionnement, prenons l’exemple détaillé ci-dessous de deux forêts Active Directory « corpnet.net » et « fabrikam.com ». Pour permettre la résolution de nom du domaine « corpnet.net » depuis le domaine « fabrikam.com », nous avons créé un zone secondaire  « corpnet.net » sur les serveurs DNS « NS01.fabrikam.com » et « NS02.fabrikam.com ». Seul le serveur « NS03.fabrikam.com » n’est pas à même de résoudre la zone « corpnet.net » car il ne dispose pas d’une copie de la zone « corpnet.net ».

 

Un premier client sur « fabrikam.com » tente de résoudre un nom d’hôte « x.corpnet.net » à partir de « NS02.fabrikam.com »:

1-     Le client envoie sa demande de résolution au serveur « NS02.fabrikam.com ».

2-     Le serveur lui renvoie le résultat de la requête.

 

Un deuxième client sur « fabrikam.com » tente de résoudre un nom d’hôte « x.corpnet.net » à partir de « NS03.fabrikam.com »:

3-     Le client envoie une demande de résolution au serveur « NS03.fabrikam.com ».

4-     Le serveur DNS renvoie une erreur.

 


La zone de DNS secondaire est de moins en moins utilisée car elle représente généralement deux principaux points faibles. Premièrement, la zone secondaire est gérée indépendamment sur chaque serveur DNS (pas de stockage possible depuis la base Active Directory) et il peut devenir complexe de la mettre à disposition à l’ensemble de l’infrastructure. Ensuite, la zone secondaire peut générer de lourdes réplications car elle doit récupérer la totalité de la zone DNS primaire. Il faut qu’elle soit utilisé soit de manière intensive, soit que la zone DNS primaire ne contienne que peu d’enregistrements pour qu’elle puisse représenter un réel intérêt.

 

 

La zone de stub

A la manière d’une zone DNS secondaire, la zone de stub est une copie en lecture seule d’une zone DNS. Toutefois, elle ne dispose que des enregistrements nécessaires pour identifier les serveurs DNS autoritaires pour la zone concernée (enregistrement SOA, enregistrement A et NS). De ce fait, la réplication des mises à jour ne concerne qu’un nombre limité d’enregistrements (A noter que le rafraichissement de la zone s’appuie sur la valeur du paramètre d’actualisation spécifié dans l’enregistrement de ressources SOA).

La zone de stub a également la possibilité de pouvoir être stockée directement sur Active Directory et donc de profiter de la réplication multi-maître d’Active Directory.

Afin de mieux comprendre le fonctionnement, prenons l’exemple détaillé ci-dessous de deux forêts Active Directory « corpnet.net » et « fabrikam.com ». Afin de permettre la résolution de nom du domaine « corpnet.net » depuis le domaine « fabrikam.com », nous avons créé une zone de stub pour la zone « corpnet.net » sur le domaine « fabrikam.com ». Nous avons décidé de la stocker sur Active Directory et de la rendre disponible sur l’ensemble des serveurs DNS du domaine.

Lorsqu’un client sur « fabrikam.com » tente de résoudre un nom d’hôte « x.corpnet.net » :

1-     Le client envoie une demande de résolution sur un des serveurs DNS.

2-     Le serveur DNS contacté sur « fabrikam.com » sélectionne un serveur autoritaire depuis la zone de stub et lui transfert la demande de résolution.

3-     Le serveur DNS contacté sur « corpnet.net » renvoie le résultat de la requête DNS.

4-     Le serveur DNS contacté initialement par le client  lui fournit le résultat de la requête DNS.

 

La zone de stub représente un réel avantage en termes d’administration. Par contre, la mise en place d’une zone de stub ne permet de pas contrôler les flux entre la zone de stub et la zone primaire. Si nous reprenons l’exemple ci-dessus, un serveur DNS du domaine « fabrikam.com » contactera aléatoirement n’importe quel serveur DNS autoritaire sur le domaine « corpnet.net » ce qui peut poser des problèmes si un filtrage de sécurité est mis en place entre les deux forêts.

 

 

 

Le redirecteur conditionnel

A la manière d’une règle de routage IP où l’on spécifie le routeur IP à utiliser pour contacter un réseau IP spécifique, le redirecteur conditionnel permet de préciser le ou les serveurs DNS à interroger pour résoudre un domaine DNS donné.

Un redirecteur conditionnel peut être stocké directement sur la base Active Directory et être répliqué sur l’ensemble des serveurs DNS de la forêt afin de permettre d’avoir des règles de redirection DNS à l’échelle de l’entreprise. Ce dernier point permet de simplifier grandement l’administration et le déploiement des redirecteurs conditionnels.

Afin de mieux comprendre le fonctionnement, prenons l’exemple détaillé ci-dessous de deux forêts Active Directory « corpnet.net » et « fabrikam.com ». Pour permettre la résolution de nom du domaine « corpnet.net » depuis le domaine « fabrikam.com », nous avons créé un redirecteur conditionnel « corpnet.net » sur le domaine « fabrikam.com » pointant vers le serveur « NS03.corpnet.net ». Le redirecteur conditionnel est stocké sur Active Directory et est disponible sur l’ensemble des serveurs DNS du domaine.

Lorsqu’un client sur « fabrikam.com » tente de résoudre un nom d’hôte « x.corpnet.net » :

1-     Le client envoie une demande de résolution sur un des serveurs DNS.

2-     Le serveur contacté  sur « fabrikam.com » contacte le serveur NS03.corpnet.net afin de réaliser la résolution de nom.

3-     « NS03.corpnet.net » renvoie le résultat de la requête DNS au serveur de « fabrikram.com ».

4-     Le serveur DNS contacté initialement par le client  lui fournit le résultat de la requête DNS.

 

Le redirecteur conditionnel est simple à mettre en place et permet de définir clairement le ou les serveurs DNS à utiliser pour une zone DNS donnée. Le contrôle de flux réseau est donc assuré.

D’un autre côté, les redirecteurs conditionnels nécessitent une maintenance accrue car la sélection des serveurs DNS doit être réalisé manuellement. Si un serveur DNS utilisé dans de la redirection conditionnelle disparait alors il faudra mettre impérativement à jour la règle de redirection en conséquence.

 

 

 

Tableau récapitulatif

 

Stockage

Avantages

Inconvénients

Zone DNS secondaire

  • Fichier à plat
  • Autonomie
  • Résolution DNS rapide
  • Maitrise des flux réseau
  • Volume de réplications
  • Configuration et maintenance sur chaque serveur

Zone de stub

  • Fichier à plat
  • Active Directory
  • Stockage depuis la base Active Directory
  • Utilisation des réplications Active Directory
  • Mise à jour dynamique des serveurs de noms
  • Maitrise des flux réseau

Redirecteur conditionnel

  • Configuration locale du serveur DNS
  • Active Directory
  • Stockage depuis la base Active Directory
  • Utilisation des réplications Active Directory
  • Maitrise des flux réseau
  • Mise à jour manuelle des serveurs maîtres

 


Mise à jour de votre contrôleur de domaine vers Windows Server 2012 (in-place upgrade)

Sommaire

 

 

Introduction

L’article présente les différentes étapes pour mener à bien la mise à jour de vos contrôleurs de domaine vers Windows Server 2012.

 


Prérequis et limitations

La mise à jour de vos contrôleurs de domaine va dépendre d’un ensemble de limitations et de contraintes que nous vous listons ci-dessous.

  • Version des systèmes d’exploitation : seuls les systèmes d’exploitation en version Windows Server 2008 x64 ou 2008 R2 sont supportés. De manière générale, les versions 32-bit ne sont pas supportées (pas de migration possible avec une version Windows 2008 32-bit).
  • Edition des systèmes d’exploitation : le choix de l’édition va dépendre bien entendu de celle du système d’exploitation existant. Ci-dessous, vous avez le tableau listant les possibilités en fonction de votre système d’exploitation existant (source Microsoft http://technet.microsoft.com/fr-fr/library/jj574204.aspx):

Système d’exploitation existant

Edition(s) compatible(s)

Windows Server 2008 Standard with SP2 or Windows Server 2008 Enterprise with SP2

Windows Server 2012 Standard, Windows Server 2012 Datacenter

Windows Server 2008 Datacenter with SP2

Windows Server 2012 Datacenter

Windows Web Server 2008

Windows Server 2012 Standard

Windows Server 2008 R2 Standard with SP1 or Windows Server 2008 R2 Entreprise with SP1

Windows Server 2012 Standard, Windows Server 2012 Datacenter

Windows Server 2008 R2 Datacenter with SP1

Windows Server 2012 Datacenter

Windows Web Server 2008 R2

Windows Server 2012 Standard


  • Compatibilité des applications : nous partons également du principe que vos contrôleurs de domaine n’hébergent pas d’applications spécifiques et ne remplissent que le rôle de contrôleur de domaine. Si cela n’est pas le cas, il faudra s’assurer de la compatibilité des applications tierces hébergées sur vos contrôleurs de domaine auprès des différents éditeurs. Pour la compatibilité des applications Microsoft vous pouvez consulter le lien http://technet.microsoft.com/en-us/library/hh994618.aspx#BKMK_AppCompat.
  • Espace disque : vous devez disposer d’un espace disque libre sur la partition stockant le fichier NTDS.DIT d’au moins égale à 20% de la taille totale du fichier NTDS.DIT (il est possible de réduire la taille de la base en passant par une défragmentation hors-ligne).
  • Niveau fonctionnel de la forêt : L’intégration d’un contrôleur de domaine sous Windows Server 2012 nécessite un niveau fonctionnel de forêt Windows Server 2003 ou supérieur.
  • Mode Core : au moment où l’article est rédigé, la mise à niveau d’un Windows Server 2008 en mode Core n’est pas supportée suite à des problèmes connus de compatibilité. Il est toutefois possible que dans un futur proche le problème soit corrigé.
  • Langue :il est impératif que langue du support d’installation soit identique à la langue du système d’exploitation à mettre à jour.

 

 

Préparation du schéma Active Directory

Si vous vous apprêtez à faire l’intégration du premier contrôleur de domaine sous Windows Server 2012, il faudra au préalable mettre à jour le schéma de la forêt et du domaine Active Directory.

Pour cela, il est préférable de réaliser l’opération de mise à directement sur le contrôleur de domaine « maître de schéma ». Pour l’identifier vous pouvez utiliser la commande « netdom query /domain:[MONDOMAINE] fsmo ».

Remarque : La version 32-bit d’ADPREP (ADPREP32) n’existant plus, il faut impérativement que votre maitre de schéma soit hébergé sous une version 64-bit. Vous pouvez déplacer le maitre d’opération si nécessaire et de façon temporaire.

Une fois connecté sur le maître de schéma, insérez votre support d’installation de Windows Server  2012 et lancer la commande suivante : « X:\support\adprep\adprep .exe /forestprep » (X: étant la lettre de votre lecteur DVD).

{gallery}55_INPLACEUPGRADE2012/01{/gallery}

 

 

 

 

 

Il faut relancer ensuite la commande pour préparer, cette fois-ci, le schéma du domaine. La commande reste identique mais avec un commutateur différent : X:\support\adprep\adprep .exe /domainprep

{gallery}55_INPLACEUPGRADE2012/02{/gallery}

 

 

 

 


 

 

Mise à niveau

Les vérifications faites, les prérequis respectés et le schéma Active Directory mis à jour, il ne reste plus qu’à mettre à jour le contrôleur de domaine.

Pour démarrer le processus, vous devez lancer le « setup.exe » du support d’installation.

{gallery}55_INPLACEUPGRADE2012/03{/gallery}

 

 

 

 

 

 

 


Vous avez la possibilité de récupérer automatiquement les dernières mises à jour relatives à l’installation de Windows Server 2012. L’opération est recommandée.

{gallery}55_INPLACEUPGRADE2012/04{/gallery}

 

 

 

 

 

 


Une fois la clé de produit entrée, vous allez devoir sélectionner le mode d’installation. Plus précisément, vous aurez le choix entre le mode Core ou GUI. Sachant que vous ne pouvez pas mettre à jour une version Core, nous choisirons la version GUI.

{gallery}55_INPLACEUPGRADE2012/05{/gallery}

 

 

 

 

 

 


Dans le contexte actuel, nous allons choisir le type d’installation « Upgrade : Install Windows and keep files, settings, and applications ».

{gallery}55_INPLACEUPGRADE2012/06{/gallery}

 

 

 

 

 

 


L’assistant d’installation génére également une rapport de comptabilité disponible directement depuis votre bureau et listant les applications non compatibles avec Windows Server 2012.

{gallery}55_INPLACEUPGRADE2012/07{/gallery}

 

 

 

 

 

 


La mise à jour vers Windows Server 2012 débute…

{gallery}55_INPLACEUPGRADE2012/08{/gallery}

 

 

 

 

 

 


… Mais en cas de soucis le retour-arrière est automatique !

{gallery}55_INPLACEUPGRADE2012/09{/gallery}

 

 

 

 

 

Vérifications

La montée de version est terminée mais si vous le désirez, vous pouvez faire quelques vérifications.

A titre d’exemple, vous pouvez vérifier l’état de santé du contrôleur de domaine à l’aide de la commande « DCDIAG ».

{gallery}55_INPLACEUPGRADE2012/10{/gallery}

 

 

 

 

 

Vous pouvez également utiliser le « Best pratices analyzer » du rôle AD DS depuis la console « Server Manager ».

{gallery}55_INPLACEUPGRADE2012/11{/gallery}

 

 

 

 

 

 


Enfin, vous pouvez également vérifier l’état des réplications à l’aide de la commande « repadmin /showrepl ».

{gallery}55_INPLACEUPGRADE2012/12{/gallery}