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/2010/04/18/les-operations-masters-d%e2%80%99active-directory/?utm_source=rss&utm_medium=rss&utm_campaign=les-operations-masters-d%25e2%2580%2599active-directory http://www.laboit.net/2010/04/18/les-operations-masters-d%e2%80%99active-directory/#comments Sat, 17 Apr 2010 22:16:28 +0000 Alexandre VIOT http://www.laboit.net/?p=489

Dans une infrastructure Active Directory (AD) tous les contrôleurs de domaine sont équivalents. Cela signifie que chaque modification apportée à votre base de données AD est automatiquement répliquée sur tous les autres contrôleurs de domaine (DC), c’est le mode dit de multi maitre. Tous les contrôleurs sont synchronisés et chacun peut apporter une modification. Il n’y a plus de notion maitre esclave.

Cependant, une architecture où tous les acteurs sont capables de décider et d’échanger les informations entre eux pose un problème : Comment être sûr de l’intégrité de certaines données nécessaire au bon fonctionnement du système ? Certains paramètres doivent être uniques dans votre infrastructure et un seul DC doit avoir le contrôle dessus.

Prenons l’exemple de l’heure, si le décalage entre le client et le contrôleur de domaine est supérieur à cinq (5) minutes, Kerberos refusera l’authentification du client. Or si deux DC ont des heures systèmes différentes, qui prendra le dessus sur l’autre, lequel fera office de Network Time Protocol (NTP) ? Un DC doit donc être désigné pour assurer seul ce rôle.

C’est pour résoudre ces différents problèmes que Microsoft a mis en place les rôles maitres d’Active Directory. Vous les avez peut-être déjà rencontrés avec des noms différents : Operations Master, Single Master Roles, Operations Tokens ou encore Flexible Single Master Operations (FSMO).

Nous verrons dans un premier temps les cinq différents rôles qui existent pour le service d’annuaire Active Directory, puis dans un second temps, comment les identifier.

La notion d’Operation Master

Un DC qui assume un rôle dit d’Operation Master est donc le seul responsable dans la forêt ou le domaine à effectuer des actions sur des données sensibles.

Active Directory Domaine Services possède 5 maitres d’opérations que l’on peut séparer en deux catégories : ceux qui agissent sur la Forêt et ceux qui agissent sur le Domaine. Deux rôles agissent sur la forêt tandis que 3 autres rôles agissent sur le domaine. Dans chacun de vos domaines se trouvent les trois rôles. Si vous avez dans votre architecture deux domaine, alors il existe huit operations master au total (2 pour la forêt, 3 pour le domaine A et 3 pour le domaine B).

Bien sûr, il n’est pas nécessaire d’avoir autant de DC que de rôles, un contrôleur de domaine peut très bien gérer plusieurs rôles simultanément.

Les Operations Masters de la Forêt

Il existe deux rôles maitres pour la forêt : Schema master et Domain Naming Master. Ils doivent être uniques dans votre forêt. Chaque rôle est assuré par un seul domaine contrôleur.

• Schema Master : Le contrôleur de domaine qui détient le rôle de maitre de schéma est responsable de tous les changements qui peuvent se produire sur le schéma de la forêt. Tous les autres domaines contrôleurs sont des réplicas en mode lecture seule (Read only). Les applications qui peuvent changer les propriétés d’un objet dans le schéma, comme Microsoft Exchange, envoient leurs requêtes au maitre d’opération Schéma de la forêt. Lorsque ce serveur est indisponible, il est alors impossible de modifier le schéma.

• Domain Naming Master : le contrôleur qui gère le rôle de maitre de nom de domaine est responsable de l’ajout et la suppression d’un domaine. Il vérifie également si un autre domaine ne porte pas le même nom. Si celui-ci est indisponible pendant la création d’un nouveau domaine,  il sera alors impossible de joindre le nouveau domaine à la forêt.

Les Operations Master du domaine

Chaque domaine contient trois masters rôles. Le rôle d’infrastructure, le PDC Emulator et enfin le RID. Comme les rôles de la forêt, un rôle doit être unique dans le domaine.

• RID Master (Relative Identifier) : Lorsque vous ajouter un utilisateur, un ordinateur, un groupe, etc… à votre base Active Directory, celui-ci est identifié par un SID. Le SID doit être unique dans le domaine. Pour assurer les ACL par exemple. Si chaque domaine contrôleur décide du SID qu’il va créer, alors comment être certain qu’un autre DC n’a pas déjà donné ou va donner le même. Il est donc nécessaire de mettre un place un mécanisme pour assurer l’unicité du SID. C’est là qu’intervient le rôle RID Master. Le DC qui en est responsable va générer un pool d’unique SID pour chaque DC du domaine. Ainsi, chaque DC pourra être certain de son SID. Le RID Master est comme un DHCP pour SID.

• Infrastructure Master : Dans un environnement multi domaine, on peut faire appel à des objets situés dans un autre domaine. Prenons l’exemple d’un groupe, un groupe peut inclure des utilisateurs du domaine, mais aussi des utilisateurs d’autre domaine. Mais lorsque le domaine distant ne vous appartient pas, comment être sur que l’utilisateur distant n’a pas été déplacé ou supprimé. Cela aura pour effet d’avoir des objets fantômes dans votre groupe. Le rôle d’infrastructure maintient donc à jour les relations extérieures au domaine. Il identifie les changements et fait les modifications pour garder à jour nos membres du groupe.

• PDC Emulator : Le Primary Domain Controller exécute plusieurs fonctions importantes ou  cruciales pour le domaine. Il regroupe 4 opérations.

Dans un premier temps, pour garder la compatibilité avec Windows NT 4 et ses différents outils / Applications , il émule un Primary Domain Controleur. Sous NT4 seuls les PDC pouvaient faire des changements sur la base de données.

Le DC qui possède le rôle de PDC participe activement dans la mise à jour des mots de passes utilisateurs : Quand un mot de passe utilisateur est changé ou réinitialisé par l’administrateur, alors le DC qui a effectué la modification réplique immédiatement le changement vers le PDC du domaine. Cela assure la bonne connaissance des mots de passe entre tous les contrôleurs du domaine même si la réplication n’a pas encore eu lieu.  Si un utilisateur essaye d’ouvrir une session sur le domaine juste après le changement de son mot de passe et que la réplication n’a pas été effectué alors le contrôleur du site distant ne verra pas la correspondance entre les mots de passe. Pour avoir un second avis avant de refuser l’authentification, le contrôleur du site va demander au PDC de vérifier le mot de passe. Comme le PDC connait le nouveau mot de passe, il acceptera la demande d’ouverture. Attention, cela signifie qu’à chaque fois qu’un utilisateur se trompe de mot de passe, l’authentification est transmise au PDC. Il doit donc avoir une haute disponibilité ainsi qu’une bonne connexion.

Le PDC gère également les mises à jour des GPO. Si la gestion des GPO n’était pas centralisée sur un serveur unique,  il pourrait y avoir conflit lorsque deux administrateurs modifient la GPO simultanément au moment de la réplication. Par défaut, lorsque vous faites une modification sur l’objet, vous faites la modification sur le SYSVOL du PDC et la réplication s’occupe du reste.

Une fonction primordiale d’Active Directory est également gérée par le PDC : la gestion du temps horaire du réseau. En effet, Active Directory, Kerberos et la réplication des fichiers se basent sur l’heure pour fonctionner.  Les DC du domaine synchronisent tous leur heure sur le PDC. Tous les autres membres du domaine, comme les ordinateurs et serveurs se synchronisent sur leur DC respectif.

Le PDC est le rôle qui aura le plus d’impact s’il devient indisponible.

Identification des serveurs

Il est très utile de savoir quel serveur occupe les rôles vu ci-dessus dans votre infrastructure. Pour améliorer les performances ou prévoir un plan de secours en cas de défaillance.

Pour identifier l’actuel operation master de chaque rôle, utilisez les outils suivants :

• PDC, RID et Infrastructure : Active Directory Users and Computers.

• Domain Naming : Active Directory Domains And Trusts.

• Schema Master : Active Directory Schema.

Vous pouvez également lister les rôles avec ntdsutils, dcdiag ou netdom.

Pour ntdsutils :

Roles

Connections

Connect to server <Your DCFQDN>

Quit

Select operation target

List roles for connected server

Pour dcdiag:

Dcdiag /test:knowsofroleholders /v

Pour netdom:

Netdom query fsmo

Conclusion

Nous venons de voir que même si Active Directory est multi maitre, il n’empêche en rien que certains contrôleurs de domaine soient plus importants que d’autre dans le bon fonctionnement du système. Veillez à toujours avoir un plan d’action au cas où les maitres d’opérations seraient indisponibles pour maintenance ou pour défaillance. D’autre part, il est vivement conseillé d’avoir au moins deux DC par site.

Lorsque l’on utilise Microsoft Exchange 2007 comme serveur de messagerie, deux questions se posent forcément à un moment ou un autre : comment être sûr de fournir un service accessible 24/24 à vos utilisateurs ? Comment augmenter le taux de disponibilité malgré les pannes physiques du serveur?

Exchange 2007 intègre plusieurs fonctionnalités de réplication qui nous permettent d’assurer un fonctionnement maximal du service. En effet, la réplication permet de faire de la haute disponibilité sur votre architecture de messagerie. Elle permet d’assurer une récupération rapide et une disponibilité élevée  au niveau des serveurs Mailbox.

Les solutions intégrées dans Exchange 2007 sont la réplication locale en continu (LCR), la réplication continue en cluster (CCR) et  les clusters à copie unique (SCC).

Nous allons nous intéresser à la définition et aux caractéristiques de chacun des modes. Leur mise en place fera l’objet d’autres articles.

Réplication locale en continu (Local Continuous Replication)

La réplication continue en local est la plus simple et la moins chère à mettre en place. Elle ne nécessite qu’un seul serveur Exchange autonome.

La LCR utilise une technologie d’envoi des journaux de log pour créer et conserver une copie d’un groupe de stockage (base de données) sur un deuxième disque dur qui est connecté au même serveur en production.

Lors d’une défaillance de votre disque dur qui contient le groupe de stockage active, il suffit de basculer sur le groupe de stockage passif. La LCR évite ainsi  le temps de restauration des sauvegardes et la perte possible d’emails de la journée (selon la période de vos sauvegardes). La différence entre la LCR et le RAID est que le LCR vérifie l’intégrité du fichier, si le fichier est corrompu elle lancera une alerte pour résoudre ce problème.

© Microsoft

Ce mode de réplication permet une récupération rapide du service à la suite d’une défaillance du disque active. Cependant, elle est inefficace contre une défaillance du serveur en lui-même. C’est donc une excellente option pour les entreprises qui ont besoin d’une solution de récupération rapide et qui peuvent tolérer des interruptions de service occasionnelles.

La mise en cluster

Les modes de réplications qui suivent utilisent la mise en cluster de deux ou plusieurs serveurs Exchange 2007.  Elles sont plus coûteuse mais plus rapides dans la restauration du service.

Cluster à copie unique (Single Copy Cluster)

La réplication de cluster à copie unique utilise un système de stockage des données partagé de type SAN et la mise en cluster de plusieurs serveur Exchange.

Avec la version 2007, le cluster peut comporter jusqu’à huit nœuds maximum. Désormais, seule la configuration Actif/ Passif est supportée. Ce qui signifie que l’on peut définir plusieurs serveurs actifs mais il faudra également définir des serveurs passifs. Mais attention, si tous les nœuds actifs peuvent accéder aux données, ils ne peuvent pas le faire simultanément.

La mise en place de cette solution oblige d’avoir un troisième serveur qui gère le basculement des nœuds du cluster.

SCC  fournit une haute disponibilité pour le service mais pas pour les données lorsque votre système de stockage tombe en panne. De plus, il est impossible de sauvegarder les données sur le nœud passif, ce qui a pour effet d’augmenter la charge du serveur actif lors de la sauvegarde.

© Microsoft

Réplication Continue en Cluster (Cluster Continuous Replication)

La réplication continue en cluster est la combinaison de la LCR et de la SCC.  Elle se base sur la mise en cluster de deux ou plusieurs nœuds et sur l’envoi des journaux asynchrones pour maintenir une copie de groupe de stockage sur un second serveur.

Chacun des serveurs Exchange intégré dans le mode CCR possède ses propres disques physiques et faire partie d’un cluster. Un serveur est défini comme Actif, tandis qu’un autre comme Passif. Il n’y a aucun disque partagé entre les deux serveurs. Le serveur actif envoie en continu les journaux au serveur passif qui les stocke sur ses propres volumes.

Comme pour la SCC, un serveur supplémentaire est nécessaire pour la gestion du basculement des nœuds lors d’une défaillance de l’Actif.

Avec la CCR, il est possible de sauvegarder la base de données sur le serveur passif. On peut également faire de la réplication de données sur des sites distants, ce qui permet une haute disponibilité même en cas d’incident majeur sur le site.

© Microsoft

Conclusion

Exchange 2007 propose différents modes de réplication pour avoir de la haute disponibilité sur votre architecture :

La plus simple à mettre en place et la moins chère : La LCR qui permet une réplication sur le même serveur. Utile pour les entreprises qui peuvent tolérer des interruptions de service.

La SCC qui se base sur un stockage partagé entre tous les serveurs actifs du cluster. Plus difficile à mettre en place, elle permet une haute disponibilité sur le service.

Enfin, la combinaison des deux : la CCR. Basée sur une architecture en cluster, elle permet de sauvegarder la base de données sur les disques d’autres serveurs Exchange, distant géographiquement ou non. Elle permet une haute disponibilité sur le service et les données.

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.

Cependant, une deuxième solution s’offre à nous : les outils en ligne de commande. Ces utilitaires souvent passés sous silence sont plus puissants que la console graphique.

Ces outils en ligne de commande sont généralement plus rapides et modulables quand ils nous sont familiers. Il est également possible de les utiliser en script, ce qui facilite l’administration.

Les outils disponibles

Active Directory contient de nombreuses commandes. Nous allons nous intéresser à trois d’entre elles qui permettent de gérer des objets Active Directory :

Dsadd

Dsmod

Dsrm

Le distinguished name

Ces outils utilisent le distinguished name. Il faut donc bien comprendre à quoi il correspond.

Chaque objet, que cela soit un utilisateur, une OU, un ordinateur ou un groupe, est identifié par un unique chemin dans le schéma. Il s’agit du distinguished name (dn).  Il contient le nom de domaine, toutes les OU et le commun name (cn) de l’objet.

Pour un utilisateur Alexandre VIOT situé dans l’unité d’organisation Administrateurs, son dn sera alors :

«CN=Alexandre VIOT, OU=Administrateurs, OU=Microsoft, DC=laboit, DC=lan »

Dsadd

La commande dsadd permet d’ajouter un objet dans la base de données Active Directory. Il faut lui préciser son type ainsi que son dn.

Les différents types disponibles :

Computer

Contact

Group

Ou

User

Par exemple, pour créer l’OU Formation dans laboit.lan, nous utiliserons :

dsadd ou « OU=Formation, DC=laboit, DC=lan »

Pour créer un utilisateur:

dsadd user  «CN= Alexandre VIOT,  OU=Microsoft, DC=laboit, DC=lan » -samid alexv –fn Alexandre -ln VIOT  –pwd myPassw0rd 

Dsmod

Dsmod permet quant à lui de modifier un objet déjà existant dans l’AD.

Pour ajouter un utilisateur au groupe LaboIT_Admins:

dsmod group « cn=LaboIT_Admins, OU=Microsoft, DC=laboit, DC=lan »  -addmr  «CN= Alexandre VIOT,  OU=Microsoft, DC=laboit, DC=lan »

Voici l’option qui permet de désactiver un compte. Cela peut vous être utile lorsque vous voulez en désactiver par script.

dsmod user «CN= Alexandre VIOT,  OU=Microsoft, DC=laboit, DC=lan »   -disabled yes

Dsrm

Dsrm a pour effet de supprimer l’objet de la base Active Directory.

Il prend juste en argument le dn de l’objet.

dsrm  «CN= Alexandre VIOT,  OU=Microsoft, DC=laboit, DC=lan » 

Pour aller plus loin

Vous trouverez sur la page ci-dessous tous les options disponibles lors de la création / modification d’objets.

http://technet.microsoft.com/fr-fr/library/cc731279(WS.10).aspx

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.

Pour cela, vous avez créé plusieurs stratégies de groupe et vous les avez liés aux unités d’organisation de votre domaine.  Cependant, cette solution donne toujours le même résultat : seule la stratégie de mot de passe spécifiée au niveau du domaine s’applique, la Default Domain Policy.

Sous Windows Server 2003, il est  impossible de définir plusieurs stratégies de mot de passe pour le domaine.

Heureusement,  Windows Server 2008 autorise désormais la création de plusieurs stratégies de mot de passe, dites granulaires. Néanmoins, elles ne pourront s’appliquer que sur des comptes utilisateurs ou de groupes de sécurité et non sur des unités d’organisation.

Pourquoi

On peut se poser la question de pourquoi a-t-on besoin d’avoir des mots de passe différents pour le domaine.

La réponse est simple : vous avez dans votre entreprise différents types d’utilisateurs et tous n’ont pas la même importance.

Pour des questions de sécurité, vous aimeriez que vos administrateurs changent leur mot de passe tous les 30 jours, que la longueur soit d’au moins 12 caractères…

Cependant, il est très difficile d’imposer à un utilisateur lambda la même complexité, ceux-ci seraient alors tentés d’inscrire le mot de passe sur leur bureau.

Configuration

L’ajout de stratégies granulaire s’effectue en 3 étapes :

1. Vérification des prés requis.
2. Création de la stratégie.
3. Attribution à un groupe

Pré Requis

La stratégie de mots de passes granulaire est une chose qui n’existait pas sous Windows Server 2003, il faudra donc élever le niveau fonctionnel de votre domaine sous Server 2008. Si vous souhaitez utiliser ces stratégies, il faudra migrer tous vos contrôleurs de domaine sous Windows Server 2008.

Pour augmenter le niveau fonctionnel d’un domaine,  rendez-vous dans Active Directory Domains and Trusts. Il suffit ensuite de cliquer avec le bouton droit sur votre nom de domaine et de sélectionner Augmenter le niveau fonctionnel de domaine.

Dans la liste, sélectionnez Windows Server 2008 et cliquez sur Augmenter.

Création

Afin de créer et d’appliquer nos stratégies granulaires, nous allons utiliser ADSI Edit car il n’y a pas réellement d’outil dédié pour cela.

Une fois que vous avez connecté la console ADSI à votre serveur, vous obtenez un arbre qui décrit les caractéristiques du domaine.

Pour Windows Server 2008, les stratégies de mots de passe granulaires (Fine-grained Password en anglais) ne sont pas considérées comme des GPO mais comme des objets particuliers.

Ces objets sont appelés : Password Settings Objects (PSO) et ont différents attributs qui  détermineront les mots de passe.

Les PSO se situent dans l’emplacement System -> Password Settings Container. Ou si vous préférez le chemin LDAP: « CN=Password Settings Container,CN=System,DC=votre_domaine »

Avant de créer votre premier Password Setting Object, il est important de se souvenir que ce type d’objet ne peut s’appliquer qu’à des comptes utilisateurs ou à des groupes globaux.

Pour ajouter une stratégie, cliquez droit sur le conteneur CN=Password Settings Container et de sélectionner New et Object

L’assistant ne vous propose qu’un seul type d’objet possible : le msDS-PasswordSettings.

Cliquez sur Next et renseignez les informations demandées pour tous les attributs de l’objet.

Voici les explications des attributs du PSO :

cn: Common Name. Le nom de votre objet PSO. Exemple: Password Admin Labo IT

msDS-PasswordSettingsPrecedence: Un PSO peut-être lié à plusieurs utilisateurs ou groupes globaux, et un utilisateur ou un groupe peut se voir appliqué plusieurs PSOs. Pour déterminer quels sont les paramètres à utiliser, chaque PSO possède une précédence. Celle-ci permet de définir des priorités entre les PSO. C’est un nombre commence à 1. Plus la valeur est petite, plus elle est prioritaire.

msDS-PasswordReversibleEncryptionEnabled: Activer le chiffrement réversible des mots de passe. C’est une valeur booléenne (TRUE ou FALSE). Cette fonction est fortement déconseillée.

msDS-PasswordHistoryLength: Taille de l’historique des mots de passe. Nombre entier.

msDS-PasswordComplexityEnabled: Paramètre permettant d’activer la complexité des mots de passe. Un mot de passe est considéré comme complexe lorsqu’il combine 3 des 4 critères suivant: lettres minuscules, lettres majuscules, chiffres et caractères spéciaux. La valeur attendue est un booléen.

msDS-MinimumPasswordLength: Taille minimale du mot de passe. La valeur attendue doit un nombre entier supérieur ou égal à 0.

msDS-MinimumPasswordAge: Durée de vie minimum d’un mot de passe. La valeur attendue est une durée exprimée sous le format j:hh:mm:ss. Exemple pour 1 jour et 8 heures, 1:08:00:00.

msDS-MaximumPasswordAge: Durée de vie maximale du mot de passe. Force l’utilisateur a changé de mot de passe une fois la durée de vie maximale atteinte. La valeur attendue est une durée au format j:hh:mm:ss. msDS-LockoutTreshold: Seuil de verrouillage pour la stratégie de verrouillage des comptes. Cela permet de définir le nombre de tentatives possibles. La valeur attendue est un nombre entier supérieur ou égal à 0.

msDS-LockoutObservationWindow: Durée pendant laquelle un utilisateur ne peut plus tenter d’ouvrir sa session. La valeur attendue est une durée au format j:hh:mm:ss comprise entre 00:00:00:01 et la valeur du paramètre msDS-LockoutDuration.

msDS-LockoutDuration: Durée pendant laquelle un compte utilisateur reste verrouillé s’il n’y a pas eu l’intervention d’un administrateur. La valeur attendue est une durée au format j:hh:mm:ss.

Une fois la configuration terminée, l’objet PSO doit apparaitre dans la liste de droite.

Attribution

La dernière étape consiste à attribuer notre PSO à un compte utilisateur ou un groupe global.

Pour avoir une meilleure gestion des stratégies, je vous conseille d’appliquer les PSO aux groupes et non à un compte utilisateur.

Pour appliquer une stratégie, cliquez droit dessus puis Propriétés. Cherchez ensuite l’attribut msDS-PSOAppliedTo, sélectionnez-le puis cliquez sur le bouton Modifier.

Dans la fenêtre qui apparaît cliquez sur Ajouter un Compte Windows et sélectionnez le groupe voulu.

Notre objet de mot de passe est désormais créé et appliqué sur un groupe.

Conclusion

Après cet article, les stratégies de mot de passes granulaires ne devraient plus avoir de secret pour vous. J’espère qu’il vous aidera à les mettre en place et à comprendre leur fonctionnement.

In this article, we study how to activate the DHCP relay on the router to forward requests from clients located on a different network.

To better understand the problem, we will quickly  review the functioning of DHCP protocol.

Understanding the problem.

Take a basic network composed of a DCHP server and multiple clients.

Obtaining a client IP configuration is done in 4 steps:

DHCP DISCOVER: As a first step, the client sending a  configuration request in broadcast.

DHCP Offer: If a DHCP server is present, then it receives the request and responds to client by offering a free IP configuration.

DHCP Request: The client requests to the first DHCP server which responds it to give the proposed configuration ,always broadcast

DHCP Ack: Finally, the server validates the configuration.

Indeed, the request of the client cannot cross a router because it is a 3 layer equipment and that it separates the areas of broadcast.

In the diagram below, clients cannot obtain an IP configuration because the DHCP server is placed behind the router:

To resolve this problem, we must activate DHCP relay on the router. Therefore, it forwards all client’s requests from newtwork A to the DHCP server in the network B.

This is also valid for the following protocols:

• TFTP
• DNS
• Time
• NetBIOS Name Server
• NetBIOS Datagram Service
• BOOTP Server
• TACACS

Configuring the router

The router configuration is very simple by itself

We must specify to the router which IP address transfer requests arriving on the interface.

Handling is therefore in interface configuration mode.

In our example, the configuration will be on the F0/0 interface

LaboIT(config)#interface FastEthernet0/0

LaboIT(config-if)#ip helper-address 192.168.2.2

The last step is to configure the server to offer leases on the DHCP network address A. We see this in future articles. Windows Server 2008 and a Linux server.

Before to begin any technical part, I will try to explain the operation of Port Forwarding and why implement it.

To understand this concept, I refresh your memories on the communication of computer:

To exchange informations, computers need an IP address and a port number. The port number is important because it’s thanks to it that the communication exists. Client and server have to communicate on the same port number.

Now, we decrypt the Port Forwarding. The Port Forwarding consist of redirect informations sent on a port number of a computer to a different port number on another computer.

A picture to better understand this redirection:

In this example, the number port 6000 of client will be encapsulated on port 22. When the request arrives on the server on the port 22, it will be decapsulated et sent on 80.

To simplify, the Port Forwarding swap the port number of communication.

Why implement it

We can ask the question of why implement it. Port forwarding with SSH is used when you want secure an communication between two computers.

Maybe you have a firewall in your company which allows only the port number 22 and you want to access the internal FTP server. Or a filter on your HTTP requests (Websense, SurfControl) and you want bypass it. Bu avoid this control remains under your responsibility.

How informations communicate , with and without Port Forwarding?

Explication:

The Blue path (1) is the communication in a normal situation. When you request a web page, your request is filtered by the firewall and redirected to Internet. If the website is in the blacklist, then access will be denied.

The Red path (2) is the communication with Port Forwarding.Your internet request is encapsulated in a secure tunnel and sent to your remote server.

When you encrypt your transaction between your PC and the server, it means that the firewall can’t inspect your request.

Once the remote server has received your request, it will go for you on internet and download the web page. Everything in a secure connection.

Result: Secure exchange between two hosts, unable to inspect the content.

How implement it

I used for this article a Debian distribution, but this solution works also on Mandriva.

We need :

- A Linux server

- A client on Microsoft Windows

-  Putty

The server configuration is divided into 4 steps.

1. OpenSSH Installation.
2. Certificates for SSH.
3. Configuration of file SSH.
4. User creation.

And for client configuration into 2 steps.

1. Configuration of Putty.
2. Configuration of your browser.

Server Configuration

OpenSSH Installation

Port Forwarding is based on the SSH protocol. So the first step is to install OpenSSH.

apt-get install openssh-server

Note: Don’t forget to update your sources with:

apt-get update

Generating certificates for SSH

Once you have installed the service SSH, you must have certificates to validate the connection.

A certificate contains a private key and public key which allow you to encrypt your communications.

During the installation, it is possible that generation of certificates were done automatically. For more security, we are going to recreate them.

To create certificates:

ssh-keygen -t dsa -b 1024

ssh-keygen -t rsa -b 1024

The system asks you to specify the path et name for your certificates. I advise you to put them in /etc/ssh

Configuration of file SSH

The next step is the modification of  configuration file of SSH to accepts tunnels and modify certificate’s paths.

You linux server can also connect to another remote server in SSH. It will be client.

This is why there are two configurations for SSH files: a file named ssh_config for the client connection and a sshd_config file which allows us to configure our SSH server.

We modify the file sshd_config

vi /etc/ssh/sshd_config

In first time, we specify new certificate’s path.

To do this, modify lines which contain HostKey:

# HostKeys for protocol version 2
HostKey /etc/ssh/certifLaboIT
HostKey /etc/ssh/certifLaboITdsa

To allow SSH tunneling,  add this command at the end of the file:

#Permit Tunnel
PermitTunnel yes

It is possible to change the listening port of the server. In case of the port number 22 is blocked by your firewall.

#What ports, IPs and protocols we listen
Port 22

Quit Vim editor and don’t forget to save your modifications.

SSH configuration is now complete.

We need to restart the service with command:

/etc/init.d/ssh restart

User creation

To avoid login with root account, we create a new user:

useradd LaboIT

passwd LaboIT

Server configuration is now complete.

Client Configuration

It is important to understand what we are going to do.

All client requests will be encapsulated in a tunnel by Putty dynamically to use the red path (2).

Configuration of Putty

You can download Putty at this address: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

The configuration of the PuTTY executable will be in 2 steps:

1. Information of the server’s IP address and its listening port.
2. Creation on the client of a new dynamic port.

For the first step, we will fill in the connection information:

Specify the IP address or FQDN of the server in the red box. And then in the yellow box specify the port is in your configuration sshd_config file

Second step, creation of new port:

To create a dynamic, port verify that the dynamic option is selected and then in the field source port enter 9999. Once this done, click Add to add to the ports forwarded.

To open the connection to the remote server, click Open.

Configuration of your browser.

You must specify your favorite browser where it should exit. Indeed, it should not use the blue path (1) but the Red (2).

For the connection host address specify 127.0.0.1, which is your PC. And in port, you must specify 9999, that was informed earlier.

You just have to accept the changes and go to your favorite pages.

Remember that if your company has set up a filter is for a good reason. So do not overuse. You are solely responsible for your actions.

Dans cet article, nous allons étudier comment transformer le routeur en relais DHCP afin de transmettre les requêtes des clients qui se trouvent sur un réseau différent.

Pour mieux comprendre le problème, nous allons revoir rapidement le fonctionnement du protocole DHCP.

Prenons un réseau basic, composé d’un serveur DCHP et de plusieurs clients.

L’obtention d’une configuration IP d’un client se fait en 4 étapes :

DHCP DISCOVER: Dans un premier temps, le client envoi en broadcast une demande de configuration.

DHCP Offer: Si un serveur DHCP est présent, alors celui-ci reçoit la requête et répond au client en lui proposant une configuration libre.

DHCP Request: Le client demande au premier serveur DHCP qui lui a répondu de lui attribuer la configuration proposée, toujours en broadcast.

DHCP Ack: Enfin, le serveur valide l’attribution au client.

Ci-contre un schéma représentant les différentes étapes:

Il ne faut pas oublier que la demande du client est envoyée en broadcast, le probleme se situe à cet endroit la.

En effet, la demande du client ne pourra pas  traverser un routeur puisque c’est un équipement de couche 3, et qu’il sépare les domaines de broadcast.

Dans le schéma ci-dessous, les clients ne pourront pas obtenir une configuration IP car le serveur DHCP est placé derrière le routeur:

La solution à ce problème est de mettre le routeur en mode DHCP Relais afin qu’il transmette toutes les demandes en broadcast du réseau A vers le serveur DHCP du réseau B.

Cette fonction est également valable pour les protocoles suivants :

• TFTP
• DNS
• Time
• NetBIOS Name Server
• NetBIOS Datagram Service
• BOOTP Server
• TACACS

Configuration du routeur

La configuration du routeur est très simple par elle même.

Il faut indiquer au routeur vers quelle adresse IP transférer les demandes qui arrivent sur l’interface.

La manipulation se fait donc en mode de configuration d’interface.

Dans notre exemple, la configuration se fera sur l’interface F0/0

LaboIT(config)#interface FastEthernet0/0

LaboIT(config-if)#ip helper-address 192.168.2.2

La dernière étape consiste à  bien configurer le serveur pour qu’il offre des baux DHCP sur l’adresse réseau A. Nous verrons ceci dans de prochains articles. Aussi bien sous Windows Server 2008 que sous un serveur Linux.

Avant de commencer toute partie technique, je vais essayer de vous expliquer le fonctionnement du Port Forwarding et pourquoi le mettre en place.

Pour bien comprendre cette notion, un petit rappel sur le mode de communication entre les ordinateurs est peut être nécessaire:

Afin de s’échanger des informations, les ordinateurs ont besoin d’une adresse IP ainsi que d’un numéro de port.  Le numéro de port est très important car c’est grâce à lui que la communication va pouvoir se faire. Le client et le serveur doivent communiquer sur le même numéro de port pour s’entendre.

Prenons  un exemple de la vie quotidienne : si vous décidez de rendre visite à une personne dans un immeuble, vous avez son adresse postale (Adresse IP) et son numéro d’appartement (Port). Si vous vous trompez de numéro d’appartement, la communication ne pourra pas se faire.

Déchiffrons maintenant le terme de Port Forwarding ou Redirection de Port en français. Le Port Forwarding consiste à rediriger les informations envoyées sur un port  d’un ordinateur vers un port différent de l’ordinateur distant.

Une image pour mieux comprendre cette redirection :

Dans cet exemple, le port 6000 du client sera encapsulé sur le port 22. Lorsque la requête arrivera sur le serveur via le port 22, elle sera décapsulée et envoyées sur le port 80.

Pour simplifier, le port Forwarding consiste à échanger le port de communication via un autre port.

Pourquoi le mettre en place

On peut se poser la question de pourquoi le mettre en place. Le Port Forwading avec SSH est utile lorsque vous voulez une sécuriser communication entre deux ordinateurs.

Vous avez peut être dans votre entreprise un pare-feu qui n’autorise que le port 22 et vous devez accédez au serveur FTP interne de la société. Ou  tout simplement un filtrage de vos requêtes HTTP (Websense, SurfControl) et vous voulez le contourner, mais esquiver ce contrôle reste sous votre entière responsabilité.

Comment communiquent les informations, avec et sans Port Forwarding ?

Explication,

Le chemin bleu (1) est la communication en temps normal. Lorsque vous demandez une page, votre requête est filtrée par le pare-feu puis redirigé vers internet. Si le site est dans la blacklist, alors l’accès vous sera refusé.

Le chemin rouge (2) est la communication par la redirection de port. Votre demande internet est encapsulée dans un tunnel  complètement sécurisé puis est envoyée sur votre serveur distant.

Le fait de chiffrer la transaction entre votre pc et le serveur signifie que le firewall ne pourra pas filtrer votre demande.

Une fois que le serveur distant a reçu votre requête,  il va aller à votre place chercher sur internet la page web et vous la renvoyer en connexion sécurisée.

Résultat es échanges sécurisés entre les deux hôtes, impossible de lire le contenu.

Comment mettre en place

J’ai utilisé pour rédiger cet article une distribution Debian, mais cette solution a également été testée sous une distribution Mandriva.

Voici les équipements nécessaires :

- Un serveur Linux

- Un client sous Microsoft Windows

- L’utilitaire Putty

La configuration du serveur se décompose en 4 étapes :

1. Installation d’OpenSSH
2. Génération des certificats pour SSH
3. Configuration du fichier
4. Création d’un utilisateur

Et la configuration du client en 2 étapes.

1. Configuration de l’utilitaire Putty
2. Configuration du navigateur Internet

Configuration du serveur

Installation d’OpenSSH

La redirection de port étant basée sur le protocole SSH, la première chose à faire est d’installer l’utilitaire Openssh.

apt-get install openssh-server

Note : N’oubliez pas mettre à jour vos dépôts avec la commande :

apt-get update

Génération des certificats pour SSH

Une fois le service installé, il est nécessaire d’avoir des certificats pour la connexion soit valide.

Un certificat contient une clef privée et une clef publique qui vont vous permettre de chiffrer vos communications.

Lors de l’installation, il est possible que la génération des certificats se soient fait automatiquement. Mais pour plus de sécurité nous allons en recréer.

Nous allons générer deux types de certificats, un DSA et un RSA, qui sont deux algorithmes de chiffrement. Ils seront générés grâce à l’utilitaire ssh-keygen.

Pour créer les certificats :

ssh-keygen -t dsa -b 1024

ssh-keygen -t rsa -b 1024

Le système vous demande ensuite de préciser le chemin et le nom pour les certificats. Je vous conseille de les mettre dans /etc/ssh

Configuration du fichier SSH

Maintenant que le service est installé et que les certificats sont créés, il faut modifier le fichier de configuration de ssh pour accepter les tunnels et modifier le chemin des certificats.

Il ne faut pas oublier que notre serveur peut également se connecter sur une machine distante en SSH. Il sera donc client à son tour.

C’est pour cela qu’il existe deux fichiers de configurations pour SSH : un fichier nommé ssh_config pour la connexion cliente et un fichier sshd_config qui va nous permettre de configurer notre serveur SSH.

Nous modifions donc le fichier sshd_config

vi /etc/ssh/sshd_config

Dans un premier temps, nous allons spécifier les nouveaux certificats que nous venons de créer.

Pour cela modifier les lignes qui contiennent HostKey en précisant vos certificats.

# HostKeys for protocol version 2
HostKey /etc/ssh/certifLaboIT
HostKey /etc/ssh/certifLaboITdsa

Pour autoriser SSH à faire du Tunneling, rajouter cette commande à la fin du fichier :

#Permit Tunnel
PermitTunnel yes

Il est également possible de changer le port d’écoute du serveur. Au cas où le port 22 serait bloqué par un pare-feu.

Il faut pour cela modifier la ligne contenant le mot :

#What ports, IPs and protocols we listen
Port 22

Quittez l’éditeur Vim en n’oubliant pas de sauvegarder vos modifications.

La configuration de SSH est désormais terminée.

Il ne reste plus qu’à redémarrer le service avec  la commande:

/etc/init.d/ssh restart

Création d’un utilisateur

Pour éviter de se connecter avec le compte root sur le serveur, nous allons créer un autre utilisateur.

useradd LaboIT

passwd LaboIT

La configuration du serveur est désormais terminée. Nous pouvons maintenant passer à celle du client.

Configuration du Client

Il faut bien comprendre ce que nous allons faire par la suite.

Dans un premier temps, nous allons configurer Putty pour qu’il écoute sur un port non utilisé (par exemple le 9999) puis nous allons ouvrir une connexion SSH vers le serveur. Cela va créer le port Forwarding.

Dans un second temps, nous spécifierons à notre navigateur web d’envoyer toutes nos requêtes vers ce nouveau port.

Toutes les requêtes du client seront donc encapsulées dans un tunnel par Putty dynamiquement pour passer par le chemin rouge (2) vu plus haut.

Configuration de l’utilitaire Putty

Vous pouvez télécharger Putty à cette adresse : http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

La configuration de l’exécutable Putty se fera en 2 étapes :

1. Renseignement de l’adresse IP du serveur et de son port d’écoute.
2. Création sur le client d’un nouveau port dynamique.

Pour la première étape, nous allons renseigner les informations de connexion :

Spécifiez dans la case rouge l’adresse IP ou le FQDN du serveur. Puis dans la case jaune, indiquez le port qui se trouve dans votre fichier de configuration sshd_config

Deuxième étape, Création du nouveau port :

Pour créer un port dynamique, vérifiez que l’option Dynamic soit sélectionnée puis dans le champ Source port indiquez 9999. Une fois ceci fait, cliquez sur Add pour l’ajouter dans les Forwarded Ports.

Pour ouvrir la connexion au serveur distant,  cliquez sur le bouton Open.

Bien sur, vous devez spécifier un couple utilisateur/password valide lors de la connexion au serveur.

Configuration du navigateur Internet

Voici la dernière étape, qui de plus, est la plus facile.

Vous devez indiquer à votre navigateur web préféré par où il doit sortir. En effet, il ne doit plus utiliser  le chemin bleu (1) mais le rouge (2).

Il faut que l’on change l’adresse de Hote SOCKS. Cette information est généralement dans les paramètres de connexion.

Pour l’adresse de connexion hôte, spécifiez 127.0.0.1, c’est votre PC. Et en port, vous devez indiquez 9999, celui qu’on a renseigné plus haut.

Vous n’avez plus qu’à valider les changements et de vous rendre sur vos sites favoris.

N’oubliez pas que si votre entreprise a mis en place un filtrage, c’est pour une bonne raison. Donc n’en abusez pas. Vous êtes le seul responsable de vos actes

DHCP Service (Dynamic Host Configuration Protocol)  allows users to obtain IP configuration automatically.

The DHCP  service is often coupled with DNS service on a dedicated server. However, it is possible to activate it on a router for a small network.

An configuration has an IP address, its subnet mask and others options. Forty of them are configurable such as the default gateway, DNS servers, domain name and WINS server.

A client has a configuration during a specified time, we call it: the lease.

Note : DHCP uses broadcast to communicate,  which means that the client’s request can’t cross a router (except explicit command).

Configuration

This is the network for the test:

Configuring the DHPC service in 4 steps :

1. Creating a DHCP pool.
2. Indicating a network.
3. Settings options of pool.
4. IP Exclusions

Step 1 :Creating a DHCP pool

The first step is to create a DHPC pool on the router. One pool includes addresses which will be distribute and its options.

To activate a pool on the router, in configuration mode:

ip dhcp pool pool_name

Once this done, we are in dhcp configuration mode.

It is possible to create several pool on the same router.

Step 2 : Indicating a network.

In dhcp configuration mode, to specify the network we use the command:

network ip_address mask

In this example, the service assigns ip addresses between 192.168.20.1 and 192.168.20.254

Step 3 :Settings options of pool.

We will specify 4 options : the default gateway, DNS server, the domain name et the lease.

To specify the default gateway, we use the option:

default-router ip_gateway

To indicate DNS server:

dns-server ip_server_DNS

The domain name is specified with:

domain-name domain_name

To configure  time of the lease : 

lease day hour minute

The option lease infinite permits to define a infinite lease.

Step 4 : IP Exclusions

Once we have configured one or more pool DHCP on the server, we must define  ip addresses which will not use. To avoid conflicts with statics addresses.

How forbid the server to distribute router’s ip?

We use this command:

ip dhcp excluded-address ip_forbidden

3) DHCP Server Management

By default, the service DHCP is activated when we define a pool.

If we want to desactivate, we use the next command : no service dhcp. To reactivate : service dhcp

We can see distributed leases by the server with : show ip dhcp binding

Le protocole DHCP (Dynamic Host Configuration Protocol) permet aux utilisateurs d’obtenir une configuration IP  automatiquement.

Le service DHCP est souvent couplé au service DNS sur un serveur distinct. Cependant, il est possible de l’activer sur un routeur pour un réseau de petite taille.

Une configuration possède une adresse ip, son masque de sous-réseau  et différentes options. Une quarantaine d’entre elles sont configurables tel que la passerelle par défaut, les serveurs DNS,  le nom de domaine, le serveur WINS.

La configuration est attribuée pour une durée déterminée, on appelle ce temps: le bail.

Note : le protocole DHCP se diffuse par broadcast,  ce qui signifie que la demande du client ne peut pas traverser un routeur (sauf commande explicite).

Configuration

Voici le réseau de test :

La configuration du service DHCP se fait en 4 étapes :

1. Création d’un pool DHCP.
2. Indication du réseau à écouter.
3. Définition des options du pool.
4. Exclusion d’adresses IP

Étape 1 : Création du pool DHCP

La première étape consiste  à créer un pool DHCP sur le routeur. Un pool regroupe les adresses qui seront distribuées ainsi que ses options.

La commande est la suivante, en mode de configuration globale du routeur :

ip dhcp pool nom_du_pool

On rentre alors en mode de configuration DHCP.

Il est notamment possible de créer plusieurs pools sur un même routeur.

Étape 2 : Indication du réseau à écouter

Dans le mode de configuration DHCP, on spécifie  le réseau à écouter avec la commande :

network adresse_ip masque

Dans notre exemple, le service attribuera des adresses ip de 192.168.20.1 à 192.168.20.254

Étape 3 : Définition des options du pool

Nous allons spécifier 4 options : la passerelle par défaut, le serveur DNS, le nom de domaine et le bail.

Pour spécifier la passerelle par défaut, on utilise l’option

default-router ip_du_router

Pour indiquer le serveur DNS primaire :

dns-server ip_du_serveur_DNS

Le nom de domaine se spécifie avec:

domain-name nom_de_domaine

On fixe la durée du bail avec:

lease jour heure minute

La commande lease infinite permet de définir un bail infini.

Étape 4 : Exclusion d’adresses IP

Une fois qu’on a fini de configurer le ou les pools DHCP  il faut définir quelles adresses ne seront pas distribuées par le serveur, pour éviter les conflits.

On va  interdire au serveur de distribuer l’adresse ip du routeur.

On utilise pour cela la commande en mode de configuration globale.:

ip dhcp excluded-address ip_interdite

Gestion du serveur DHCP

Par défaut, le service DHCP est activé lorsqu’on définit un pool.

Si l’on souhaite le désactiver, on utilise la commande suivante : no service dhcp. Pour le réactiver : service dhcp

On peut voir les baux distribués par le serveur avec : show ip dhcp binding, en mode privilégié.

Je vous souhaite la bienvenue sur Labo  IT,  un  blog dédié aux nouvelles technologies de l’information.

Avant toute partie technique, une petite présentation s’impose. Étant étudiant en école d’ingénieur informatique, j’ai décidé de créer ce blog pour apporter ma petite contribution à internet  et ainsi, au fil des billets, j’essayerai de vous transmettre mes connaissances sur les systèmes informatiques.

Ce blog comportera des articles sur les différentes technologies mais aussi des projets plus complets qui mélangeront deux ou plusieurs technologies. J’ajouterai également des petites astuces qui peuvent vous simplifier la vie.

J’espère que vous serez nombreux à partager ma passion de l’informatique!

Pour ceux qui voudraient en savoir plus, http://www.alexandre-viot.fr

A  bientôt sur Labo IT.

Alexandre