Bien que Microsoft ait implémenté dans ses systèmes un certain nombre de règles pour éviter les conflits de réplication dans Active Directory, certaines mises à jour sont trop importantes pour être résolues avec ces règles, comme par exemple la modification du schéma Active Directory. C’est pourquoi Microsoft a créé depuis Windows 2000 Server les Flexible Single Master Operation (FSMO). Ce sont en fait des rôles attribués à différent serveurs de manière à ce que seuls certains serveurs permettent de modifier des aspects internes à Active Directory.

Il existe donc depuis Windows 2000 cinq rôles FSMO. Ces 5 rôles sont nécessaires au bon fonctionnement des différents domaines et forêts de l’infrastructure. Chacun de ces rôles ne peut être hébergé que par des contrôleurs de domaine et non par des serveurs membres. Ils ont également des étendues différentes et des domaines de réplication différents.

On distingue parmi les 5 rôles:

• Maître d’attribution de noms de domaines
• Contrôleur de schéma
• Maitre RID
• Maitre d’infrastructure
• Emulateur PDC

Le Maitre d’attribution de noms de domaines et le contrôleur de schéma ont une portée au niveau de la forêt, pour laquelle ils sont uniques.

Le maitre RID, le maitre d’infrastructure et l’émulateur PDC ont une portée au niveau du domaine, pour lequel ils sont uniques.

Nous allons présenter plus en détail les différents rôles ainsi que l’impact de leur indisponibilité.

Maître d’attribution de noms de domaines

Présentation

Le détenteur du rôle FSMO Maître d’attribution de noms de domaine est le contrôleur de domaine chargé d’apporter des modifications à l’espace de noms des domaines de niveau forêt de l’annuaire (c’est-à-dire le contexte de nommage PartitionsConfiguration ou LDAP://CN=Partitions, CN=Configuration, DC=). Ce contrôleur de domaine est le seul à pouvoir ajouter ou supprimer un domaine de l’annuaire.

C’est un rôle qui n’est donc utilisé que très occasionnellement.

En cas d’indisponibilité

En cas d’indisponibilité du maitre d’attribution des noms de domaine, il n’est plus possible d’ajouter ou d’enlever des domaines à la forêt.

Contrôleur de schéma

Présentation

Le détenteur du rôle FSMO Contrôleur de schéma est le contrôleur de domaine chargé d’effectuer les mises à jour vers le schéma d’annuaire (c’est-à-dire, du contexte de nommage du schéma ou LDAP://cn=schema,cn=configuration,dc=). Ce contrôleur de domaine est le seul à pouvoir traiter les mises à jour vers le schéma de l’annuaire. Une fois la mise à jour du schéma terminée, elle est répliquée du contrôleur de schéma sur tous les autres contrôleurs de domaine de l’annuaire. Il existe un seul contrôleur de schéma par forêt

Un contrôleur de schéma rempli 4 fonctions au sein d’une forêt Active Directory :

• Il contrôle les mises à jour d’origines apportées au schéma.
• Il contient la liste des classes d’objets et des attributs utilisés pour la création d’objet dans Active Directory.
• Il réplique les mises à jour apportées au schéma sur les tous autres contrôleurs de domaine de la forêt via la partition de schéma.
• Il autorise uniquement les administrateurs du schéma à modifier le schéma.

En cas d’indisponibilité

Si le contrôleur de schéma n’est pas joignable, les modifications sur le schéma ne pourront pas être appliquées. Le schéma stockant les classes d’objets et les attributs, il ne sera par exemple pas possible d’installer une application devant modifier certains attributs, comme Microsoft Exchange par exemple.

La perte de ce contrôleur à de faibles conséquences car les modifications du schéma sont des opérations rares.

Maitre RID

Présentation

Le détenteur du rôle FSMO Maître RID est le seul contrôleur de domaine chargé du traitement des demandes de pools de RID (blocs d’identificateurs relatifs) émanant de tous les contrôleurs de domaine d’un domaine donné. Il est également chargé de supprimer un objet de son domaine et de le mettre dans un autre domaine au cours d’un déplacement d’objet.

Lorsqu’un contrôleur de domaine crée un objet entité de sécurité tel qu’un utilisateur ou un groupe, il joint à l’objet un ID de sécurité (SID) unique. Ce SID est constitué d’un SID de domaine (le même pour tous les SID créés dans un domaine) et d’un ID relatif (RID), unique pour chaque SID d’entité de sécurité créé dans un domaine.

Chaque contrôleur de domaine se voit allouer un pool de RID qu’il peut attribuer aux entités de sécurité qu’il crée. Lorsque le pool de RID d’un contrôleur de domaine tombe en deçà d’un certain seuil, le contrôleur de domaine demande des RID supplémentaires au maître RID du domaine. Le maître RID répond à la demande en récupérant des RID du pool de RID non alloués du domaine et les attribue au pool du contrôleur de domaine demandeur.

En cas d’indisponibilité

Si le maître RID ne peut être joint, la création d’un objet est impossible sur un contrôleur de domaine dont la réserve de RID est épuisée. Chaque contrôleur de domaine obtenant des blocs de 500 identificateurs à chaque demande, l’impact est plus ou moins important selon la taille de l’infrastructure Active Directory.

Maitre d’infrastructure

Présentation

Lorsqu’un objet d’un domaine est référencé par un autre objet dans un autre domaine, il représente la référence par le GUID, le SID (pour les références aux entités de sécurité) et le nom unique (DN) de l’objet qui est référencé. Le détenteur du rôle FSMO Infrastructure est le contrôleur de domaine chargé de mettre à jour le SID et le nom unique d’un objet dans une référence d’objet interdomaine.

Pour ce faire, Active Directory utilise des objets fantômes pour les références aux utilisateurs des différents domaines. Cet objet fantôme est un objet spécial qui ne peut être vu d’aucune façon par les outils d’exploration LDAP.

Ces enregistrements fantômes contiennent une quantité minimale d’informations qui permet à un contrôleur de domaine de se référer à l’emplacement dans lequel l’objet original existe.

Si un objet auquel un objet fantôme fait référence a été modifié ou supprimé, l’objet fantôme doit être modifié ou supprimé du domaine le contenant. Le maître d’infrastructure compare régulièrement les informations des objets fantômes présent dans sa base de donnée avec la dernière version du répliquas des objets sur un serveur de catalogue global. Si les SID ou les distinguished name  ne correspondent pas avec ceux des objets fantômes, alors le maître d’infrastructure met à jour les objets fantômes qu’il contient.

En cas d’indisponibilité

Si le détenteur du maître d’infrastructure est hors ligne, il ne sera plus possible d’utiliser des sécurités mettant en œuvre des groupes composés d’utilisateurs d’un autre domaine. Si le nom d’un utilisateur d’un autre domaine est modifié, ou bien lors d’une suppression, l’objet fantôme ne pourra pas être mis à jour ou supprimé du groupe sur tous les contrôleurs de domaine du domaine contenant cette référence.

L’impact de la perte de ce rôle dépend donc grandement de l’infrastructure Active Directory en place puisqu’il est nul pour une infrastructure mono forêt mono domaine.

Emulateur PDC

Présentation

Le rôle émulateur PDC (contrôleur de domaine principal) est particulièrement important au bon fonctionnement de chaque domaine de la forêt.

Il assure quatre fonctions au sein d’un domaine Active Directory :

• Permet la compatibilité avec des contrôleurs de domaine du type Windows NT et réplique les mises à jour à destination des contrôleurs secondaire de domaine NT
• Gère le verrouillage des comptes utilisateurs et du changement des mots de passe
• Gère les mécanismes de synchronisation horaire sur tous les contrôleurs de domaine du domaine (nécessaires aux horodatage insérés dans les paquets d’authentification Kerberos)
• Réalise les modifications des stratégies de groupe du domaine (GPO) afin d’interdire toute possibilité d’écrasement et de conflit.

L’émulateur PDC est donc un rôle fondamental puisque les modifications de mot de passe exécutées par d’autres contrôleurs de domaine du domaine sont répliquées de préférence sur l’émulateur PDC. De plus, les échecs d’authentification qui se produisent en raison d’un mot de passe inexact sur un contrôleur donné dans un domaine sont transférés à l’émulateur PDC avant que l’échec ne soit signalé à l’utilisateur dans un message.

En cas d’indisponibilité

La perte du contrôleur qui détient le rôle émulateur PDC est lourde de conséquences. En effet, la perte de ce contrôleur empêche tout nouveau changement de mot de passe et le verrouillage de compte utilisateur, peut entrainer une perte de synchronisation entre les DC ainsi que des problèmes d’authentification Kerberos et des problèmes lors de l’application des GPO.

Synthèse

Le principe est le suivant :

• Les utilisateurs sont affectés à un groupe global
• Les groupes globaux sont ajoutés aux groupes locaux
• Les groupes locaux se voient attribués des permissions au niveau des ressources partagées

Les groupes globaux regroupent donc des utilisateurs qui se voient accorder des droits via des groupes locaux sur des ressources partagées.

En plus de la méthode AGDLP, comme vu dans le schéma précédant, chaque ressource sera liée à trois groupes locaux, chacun disposant de droits spécifiques :

• Contrôle total (CT)
• Lecture / Ecrite (RW)
• Lecture (RO)

Cela permet ainsi d’affecter à des groupes d’utilisateurs des droits spécifiques pour une même ressource. Dans l’exemple du schéma AGDLP, les utilisateurs du service Etudes d’Orsay se voient affecter des droits en lecture/écriture sur le dossier « Projet MIR».

Nous pouvons imaginer que les collaborateurs du service Production d’Orsay aient besoin de visualiser le contenu du dossier « Projet MIR ». Avec cette méthode il suffira alors d’ajouter le groupe global « G_ORS_Production » contenant les utilisateurs du service Production d’Orsay au groupe local « L_ProjetMIR_RO » permettant l’accès au dossier « ProjetMIR » en lecture seule.

Dans le cas où des personnes n’appartenant pas au même service auraient besoin d’accéder à une ressource spécifique il faudra alors créer un groupe global spécifique. Par exemple si chaque chef de service doit pouvoir accéder en lecture au dossier relatif à la comptabilité il faudra alors créer le groupe global « G_ORS_Direction » associé au groupe local « L_Comptabilite_RO ».

Voici le fonctionnement général de l’acheminement d’un courriel d’un destinataire à un autre. Dans cet exemple, Jean-Bob souhaite envoyer un message à Billy.

Jean-Bob appartient au domaine de messagerie emc.fr et Billy au domaine yahoo.co.uk. Chacun dispose d’un serveur de messagerie (MTA et MDA) correspondant à leur domaine.

1. Jean-Bob rédige son message et l’envoie grâce à son MUA. Le message est acheminé au serveur SMTP de son domaine.
2. Le MTA du domaine emc.fr reçoit le message et constate que le destinataire n’est pas dans ses destinations. Il cherche alors grâce à DNS si un MTA existe pour le domaine yahoo.co.uk. Une fois qu’il la trouvé il envoie le message à ce MTA qui le dépose alors la boite aux lettres de Billy par l’intermédiaire du MDA.
3. Billy souhaite relever son courrier et envoie donc une requête à son serveur POP via son MUA.
4. Le serveur POP consulte la boite aux lettres de Billy et constate qu’il y a un message.

Itinéraire détaillé d’un message

Maintenant que nous avons l’idée générale, détaillons un peu plus ce processus, en s’appuyant sur le même exemple.

1. Jean-Bob rédige son message et l’envoie grâce à son MUA. Le message est acheminé au serveur SMTP de son domaine.
2. Le MTA du domaine emc.fr reçoit le message et constate que le destinataire n’est pas dans ses destinations. Il cherche alors grâce à DNS si un MTA existe pour le domaine yahoo.co.uk. Une fois qu’il la trouvé il envoie le message à ce MTA.
3. Le serveur SMTP de yahoo.co.uk reçoit le message et constate que le destinataire est bien dans ses destinations. Il dépose alors le message dans la boite aux lettres de Billy par l’intermédiaire du MDA.
4. Billy souhaite relever son courrier et envoie donc une requête à son serveur POP via son MUA.
5. Le serveur POP consulte la boite aux lettres de Billy et constate qu’il y a un message.
6. Il envoie alors le message au MUA de Billy.

Dans notre cas un routeur virtuel est créé à partir de deux routeurs physiques : un considéré alors comme actif et le second en standby. Si le routeur actif tombe en panne le second prends le relais jusqu’à réparation de la panne.

Plusieurs routeurs sont considérés logiquement comme un seul routeur en partageant la même adresse MAC et IP. Ces différents routeurs forment un groupe. Les membres de ce groupe sont capables de s’échanger des messages d’état et des informations.

Si le routeur actif a un problème, le routeur en standby prendra sa place automatiquement, les paquets continueront de transiter de façon transparente.

Un routeur primaire (actif) est élu par groupe au moyen d’une priorité, les autres routeurs sont alors considérés comme secondaires (standby). Le secondaire assumera donc la tâche de transmettre les paquets à la place du primaire en cas de défaillance.

Le processus d’élection se déroule pendant la mise en place des liens, une fois ce processus terminé, seul le routeur primaire (actif) va envoyer des messages multicast en UDP périodiques HSRP aux autres afin de minimiser le trafic réseau.

Si ces messages ne sont plus reçus par le routeur secondaire (synonyme de défaillance) il devient immédiatement actif.

Présentation

Le protocole MPLS (Multi Protocol Label Switching) permet de transporter des données grâce à la constitution de réseaux privés virtuels à l’intérieur de l’infrastructure d’un opérateur.

Il se base sur une étiquette pour commuter les paquets à travers deux équipements, les LER (Label Edge Routeurs) et les LSR (Label Switch Routers). Cette opération s’effectue entre la couche liaison de données et la couche réseau, c’est pourquoi MPLS est qualifié de protocole de couche « 2,5 ».

MPLS offre une étanchéité des flux et supporte les différents protocoles de niveau 1 à 3 du modèle OSI. Le but est d’associer la puissance de la commutation de la couche 2 avec la flexibilité du routage de la couche 3.

Principe

Les LER sont les routeurs de périphéries qui marquent le trafic à l’entrée du réseau MPLS. Ils encapsulent les datagrammes d’un protocole spécifiques (par exemple IP) dans les datagrammes MPLS. Cette encapsulation consiste à rajouter une étiquette (label) dépendant de la destination, de la nature et de la priorité du trafic.

Les LSR analysent les étiquettes des datagrammes MPLS et traitent chaque datagramme selon l’information contenue dans son étiquette. Ils changent également la valeur de l’étiquette qu’ils font suivre.  Le traitement que doit effectuer un LER ou LSR est décrit dans une structure de données propre à chaque routeur MPLS appelée LIB (Label Information Base)

Les paquets de données ainsi étiquetés par les LER suivent leur trajet spécifique aiguillé sur le bon chemin tout au long de leur trajet par les LSR. Ce système d’étiquetage des données permet au responsable du réseau au sein de l’entreprise de définir des ordres de priorité, donc de la QoS (Quality of Service).

Etiquette

Pour les réseaux Ethernet, un champ de 32 bits nommé « shim » a été introduit. Il contient les champs :

• Etiquette
• Fonctions expérimentales pour la CoS (Class of Service)
• Bit S : Pile de labels (indique le bas de la pile)
• TTL (Time To Live), identique à IP

L’étiquette a une signification locale entre 2 LSR adjacents et mappe le flux de trafic entre le LSR amont et la LSR aval.

< ——– 32 bits ——– >

< ———– 20 bits ———– > < — 3 bits — > <1bit>  <8bits>

Distribution des étiquettes MPLS

Les LSR commutent à partir des étiquettes entre deux équipements voisins. Les LER et LSR doivent préalablement se mettre d’accord sur les traitements associés à chaque étiquette, pour cela ils utilisent un protocole de signalisation (LDP : Label DistributionProtocol)

La distribution peut s’effectuée de deux manière :

• Non centralisée : chaque équipement établit et annonce les informations de commutation en écoutant les annonces de routage (Hop By Hop)
• Contrôlée : un équipement du réseau MPLS est responsable de la distribution des informations de commutation

Ces deux manières sont également respectivement appelés Routage Implicite et Explicite. La première approche à l’avantage de converger plus rapidement mais la seconde permet de faire du Traffic Engineering.

Topologie et terminologie

Le schéma ci-dessous montre l’emplacement des différents routeurs utilisés dans une architecture MPLS :

Une terminologie particulière est employée pour désigner ces routeurs en fonction de leur rôle :

Trois types de flux transitent :

• Les données que les clients échangent au sein du VPN
• Les informations de contrôle relatives aux VPN et échangées entre les PE
• Les informations de contrôle relatives aux chemins entre les PE (routage, étiquettes)

La sécurité des VPN MPLS se base donc sur la confiance dans le réseau de l’opérateur. Si des besoins forts de sécurité exigent le service de confidentialité, il est possible de combiner IPSec à MPLS.

QoS (Quality of Services)

Comme nous l’avons vu précédemment, MPLS gère également la qualité de service en définissant 5 classes de services :

La définition de classes disposant chacune d’un niveau de priorité permet de garantir une qualité de service adaptée à chacun des flux.

Ainsi MPLS permet de véhiculer de la VOIP ou même de mettre en place des applications de visioconférence dans d’excellentes conditions, même sur des VPN à forts taux d’utilisation.