Le partage SYSVOL et la réplication

Comme point final de ce cours d’introduction au service d’annuaire Active Directory, on va s’intéresser au répertoire « SYSVOL », ainsi qu’aux différentes réplications qui ont lieu au sein d’un environnement Active Directory, notamment au niveau des contrôleurs de domaine.

I. Le partage SYSVOL

Lorsqu’un contrôleur de domaine est installé, de nombreux éléments sont installés et créés sur le serveur, le partage SYSVOL en fait parti.

A. Introduction à SYSVOL

Stocké à l’emplacement « C:\Windows\SYSVOL », « SYSVOL » signifie « System Volume », et il sert à stocker des données spécifiques qui doivent être répliquées entre les contrôleurs de domaine ou accessibles par les ordinateurs clients.

Plus précisément, voici les éléments principaux que l’on trouvera dans le partage SYSVOL :

Pour rappel, les scripts de connexion s’exécutent à l’ouverture de session de l’utilisateur, ils sont généralement écrits en BATCH et comporte des commandes qui permettent de créer des lecteurs réseau sur les machines clientes (commande « net use »). Quant aux stratégies de groupe, elles sont récupérées par les clients puis appliquées, dans le but d’appliquer une stratégie de personnalisation de l’espace de travail de l’utilisateur.

De ce fait, si le partage SYSVOL est en erreur, vous aurez de gros problèmes ! Plus de réplication des GPOs et scripts de connexion entre les contrôleurs de domaine, plus possible pour les clients de récupérer les dernières mises à jour de GPO et les scripts… Bref, vous imaginez la galère… D’où l’intérêt de prendre connaissance de l’existence du partage SYSVOL.

Attention, certaines personnes utilisent ce partage pour stocker toutes sortes de données, ce n’est pas du tout recommandé ! Non seulement, car le partage SYSVOL n’est pas fait pour ça, mais aussi, car les processus de réplication seront plus longs (plus de données à répliquer).

B. Réplication de SYSVOL

Le dossier SYSVOL est répliqué entre les différents contrôleurs de domaine, pour que le contenu soit identique, et que les clients bénéficient tous des mêmes données (à jour). Sur les anciennes versions de Windows Server, notamment Windows Server 2000 et Windows Server 2003, le mécanisme FRS (File Replication Service) était utilisé pour la réplication. Depuis Windows Server 2008, FRS est mis de côté pour laisser la place à DFSR (Distributed File System Replication), qui est plus fiable et plus performant.

C. La structure de SYSVOL

Le répertoire « C:\Windows\SYSVOL\ » est composé de plusieurs sous-dossiers :

- domain : ce répertoire contient toutes les données à jour (GPO et scripts), réparties en deux sous dossiers : « Policies » et « scripts ».

- Policies : ce répertoire est stocké sous « domain » et stocke toutes les GPOs du domaine, que l’on crée au sein de la console « Gestion des stratégies de groupe ». Un sous-dossier par GPO est créé où le nom du dossier correspond au GUID de l’objet GPO.

- scripts : ce répertoire est stocké sous « domain » et contient les différents scripts, notamment les scripts de connexion.

- staging : ce répertoire est utilisé pour créer une file d’attente (queue) des données en attente de réplication à destination des autres contrôleurs de domaine.

II. Réplication : Quoi ? Quand ? Comment ?

Qui dit redondance, dit nécessité de répliquer les données afin que les données soient identiques sur les différents membres. C’est le même principe pour les contrôleurs de domaine, puisqu’ils doivent se répliquer pour mettre à jour différentes choses :

- Base annuaire Active Directory

Si un utilisateur est créé, modifié ou supprimé, il faut synchroniser les changements auprès des autres contrôleurs de domaine. De la même manière, si l’on intègre un nouvel ordinateur dans le domaine, cela créera un objet « ordinateur » dans l’annuaire, il est donc nécessaire de synchroniser ce changement.

Le protocole RPC over IP (Remote Procedures Call over Internet Protocol) est utilisé pour répliquer la base d’annuaire.

- Les stratégies de groupes et les scripts

Une nouvelle stratégie de groupe créée, un paramètre modifié dans une GPO existante, ou encore la suppression d’une GPO, sont autant d’opérations qui impliquent un changement et donc la nécessité de répliquer des données.

- DNS

Comme nous l’avons vu dans un module précédent, le DNS joue un rôle important dans une architecture Active Directory. Pour assurer la continuité de service, on utilise au moins deux serveurs DNS. Ceci implique que les enregistrements des zones soient répliqués entre les serveurs DNS, pour que les informations retournées soient identiques.

Imaginez si un serveur DNS n’est pas à jour et qu’il retourne une mauvaise adresse IP à une requête client, cela générera des problèmes de communication au sein de l’infrastructure.

Maintenant, vous savez ce qui doit être répliqué et pourquoi ça doit être répliqué, mais alors quand est-ce la réplication se déclenche ?

- Délai de réplication

Il y a un temps de latence de 5 minutes (par défaut) entre le moment où vous effectuez la modification, et le moment où le contrôleur de domaine source va notifier un autre contrôleur de domaine qu’il a effectué une modification.

Ensuite, s’il y a un second contrôleur de domaine à notifier, il y aura un intervalle de 30 secondes entre chaque réplication, pour éviter de surcharger le contrôleur de domaine source.

Note : Ces deux valeurs peuvent être modifiées dans le registre, Replicator notify pause after modify (secs) pour le premier déclenchement de notification, et la valeur Replicator notify pause between DSAs (secs) pour les délais de notification suivants. Tout cela au niveau de la clé « HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters ».

Cependant, il existe des cas de « réplication urgente » où l’on n’observera aucune latence. C’est le cas par exemple lorsqu’on désactive un utilisateur, change un mot de passe … Et de toute action liée à la sécurité.

Imaginons maintenant qu’aucune modification ne soit effectuée pendant une heure, ce qui a des chances d’arriver, car on ne passe pas son temps à modifier les données de l’annuaire… Un processus de réplication est automatiquement déclenché pour contrôler que tout est bien à jour.

- Méthode de réplication

La réplication avec le protocole RPC over IP est sûre, mais le contenu n’est pas compressé, ce qui répond plus à un fonctionnement de réplication intrasite. En fait le contenu est chiffré et les connexions authentifiées grâce au protocole Kerberos.

Lorsque l’infrastructure est répartie sur plusieurs sites distants, le protocole utilisé pour la réplication dépendra de la vitesse de connexion, mais la plupart du temps il s’agira toujours du RPC. À la différence de la réplication intrasite, le trafic RPC généré lors d’une réplication intersites est compressé, ce qui permet d’économiser de la bande passante, mais nécessite des ressources CPU pour décompresser le contenu.

Dans certains cas, où la liaison intersites serait lente et avec un temps de latence fort, il est possible d’utiliser le protocole SMTP pour la réplication (Oui, oui, le SMTP, le protocole pour envoyer des mails). Cependant, il n’est pas en mesure de répliquer le répertoire « SYSVOL », il peut seulement répliquer des éléments précis : mises à jour du schéma, la configuration ou encore les données du catalogue global.

Vous l’aurez compris, le protocole RPC over IP est au cœur de la réplication entre les contrôleurs de domaine, aussi bien en intrasites qu’en intersites. Le SMTP joue un rôle secondaire pour des réplications spécifiques sur des liaisons lentes, comme une liaison satellite, et il ne peut être utilisé que pour des contrôleurs se trouvant dans des domaines différents.

- Déclarez vos sites

Les services Active Directory économisent la bande passante entre les sites, en réduisant au minimum la fréquence de réplication. De plus, on peut planifier la disponibilité des liens intersites pour la réplication.

Par défaut, la réplication intersites a lieu toutes les 3 heures sur chaque lien intersites.

Lorsque l’on dispose de nombreux sites, il y a des chances pour que les liaisons ne soient pas toutes de la même qualité. De ce fait, il pourra être nécessaire de répliquer moins souvent sur les liaisons lentes que sur les liaisons rapides.

Pour que l’Active Directory comprenne comment est organisée votre infrastructure de manière géographique. Il faut déclarer ses différents sites dans la console « Sites et services Active Directory », puis créer des liens entre les sites ainsi qu’indiquer les adresses réseau utilisées sur ces sites.

Ainsi, on ajoutera nos différents sites, et dans ces sites on ajoutera des serveurs. Cela permettra de dire : « Sur le site Paris, j’ai le contrôleur de domaine nommé SRV-AD02 » et « Sur le site Rennes, j’ai le contrôleur de domaine nommé SRV-AD03 ».

Note : Lors de la création d’un premier domaine, il y a toujours un site par défaut nommé « Default-First-Site-Name » qui est créé et qui contient le contrôleur de domaine venant d’être installé. Un lien par défaut est également créé et nommé « DEFAULTIPSITELINK »

De plus, une notion de coût est intégrée pour chaque lien intersites. Ajustez sa valeur selon la vitesse, l’efficacité et la fiabilité de la liaison. Ainsi, si plusieurs liens connectent les mêmes sites, alors pour la réplication le lien ayant le coût le plus faible sera choisi. Le second lien faisant office de backup pour le mécanisme de réplication (cela n’empêche pas que ce lien soit utilisé pour autre chose).

Enfin, il faut savoir que la réplication entre les contrôleurs de domaine est automatiquement générée par le vérificateur de cohérence des connaissances (KCC - Knowledge Consistency Checker). Le KCC fonctionne sur tous les contrôleurs de domaine et c’est lui qui génère la topologie de réplication de la forêt .

Ce cours sur l’Active Directory, de par son aspect théorique, vous permettra d’avoir une approche plus sereine quant à la mise en place d’un domaine et d’un annuaire Active Directory. Que ce soit pour une maquette, ou un cas concret en entreprise. Les notions acquises par ce cours représentent une base solide pour aborder la suite.