Active Directory multi-sites, partages réseau et gestion des droits utilisateurs

Ce lab reprend un contrôleur de domaine fraîchement installé et le transforme en annuaire d’entreprise complet : trois sites, six départements, des partages réseau cloisonnés, des lecteurs montés automatiquement à l’ouverture de session et des profils qui suivent l’utilisateur de machine en machine.

L’installation du rôle AD DS est le prérequis, elle est couverte dans Installation d’un Windows Server avec le rôle AD DS. Nous repartons ici juste après le premier redémarrage du contrôleur de domaine SDE.LOCAL.

Le contexte : trois sites, un seul annuaire

L’entreprise possède 3 sites, chacun équipé d’un serveur Windows :

• SRV-CHA à Chassignieu, siège social, il porte le rôle AD DS et fait donc office de contrôleur de domaine.
• SRV-VIR à Virieu, serveur de fichiers.
• SRV-BLA à Blandin, serveur de fichiers.

Chaque site contient 2 départements, Administratif et Technique. Le siège en contient un troisième, la Direction.

Les 3 serveurs appartiennent au même domaine SDE.LOCAL : il n’y a qu’un seul annuaire, donc un seul endroit où créer les comptes et les groupes. Ce sont les données qui restent locales à chaque site, pas les identités.

Trois besoins découlent de cette organisation, et ce sont eux qui vont dicter toute la suite du lab :

1. Cloisonner : un technicien de Virieu ne doit pas voir les dossiers de la Direction, ni même savoir qu’ils existent.
2. Mutualiser : certains dossiers doivent rester accessibles à tous les sites, depuis un point unique.
3. Rendre l’utilisateur mobile : ses documents et son bureau doivent le suivre, quel que soit le poste sur lequel il ouvre sa session.

Le premier besoin est le plus délicat. Avant de cliquer dans la console, il faut donc fixer la règle qui décide qui accède à quoi.

La méthode : le modèle AGDLP

La tentation naturelle est de poser directement un utilisateur sur un dossier : clic droit, Sécurité, Ajouter, PDG, Contrôle total. Cela fonctionne le premier jour, et devient ingérable le deuxième. Chaque arrivée, chaque départ, chaque mutation oblige à rouvrir tous les dossiers concernés pour éditer leurs listes de contrôle d’accès, sans jamais pouvoir répondre simplement à la question « à quoi cet utilisateur a-t-il accès ? ».

Le modèle AGDLP résout ce problème en insérant deux niveaux de groupes entre le compte et le dossier :

La chaîne se lit de gauche à droite : le compte entre dans un groupe global, le groupe global entre dans un groupe local de domaine, et c’est ce dernier, et lui seul, qui apparaît dans l’onglet Sécurité du dossier.

PDG  →  GG-CHA-DIR  →  GL-SRV-CHA-DATA-DIRECTION-CF  →  Contrôle total sur \\SRV-CHA\DATA-CHA$\Direction
 A          G                       DL                                    P

L’intérêt apparaît dès qu’on change quelque chose :

• Un nouvel arrivant à la Direction ? Une seule action, l’ajouter à GG-CHA-DIR. Il hérite instantanément de tous les dossiers de la Direction.
• Un nouveau dossier à sécuriser ? Un seul groupe local à créer, puis à imbriquer dans les groupes globaux concernés. Aucun compte n’est touché.
• Un audit ? Les membres d’un groupe local répondent à « qui accède à ce dossier », les appartenances d’un groupe global répondent à « à quoi cette personne accède ».

Ce modèle a un coût : il multiplie les objets. Avec neuf dossiers à protéger et deux niveaux de droits possibles, on obtient rapidement une quinzaine de groupes locaux. Ils ne sont exploitables que si leurs noms se lisent sans documentation.

Une convention de nommage qui se lit toute seule

Chaque nom encode l’information nécessaire pour savoir, sans ouvrir la console, à quoi le groupe sert.

Pour les groupes globaux, deux segments suffisent, puisqu’ils décrivent uniquement des personnes :

Ce qui donne GG-CHA-DIR, GG-VIR-ADM, GG-BLA-TECH, et ainsi de suite.

Pour les groupes locaux de domaine, il faut en plus décrire la ressource et le niveau de droit :

Ce qui donne GL-SRV-CHA-DATA-ADM-COMMUN-L : le droit de lecture sur le dossier Adm-Commun du partage DATA hébergé par SRV-CHA.

Cette convention permet maintenant de lire le plan complet de l’annuaire d’un seul coup d’oeil.

Le plan à construire

Les unités d’organisation

Les unités d’organisation (OU) sont des conteneurs qui reproduisent l’organigramme dans l’annuaire. Ici, un niveau par site, puis un niveau par département.

Chaque OU de département contient son groupe global et les comptes qui en sont membres. Les groupes locaux, eux, sont regroupés dans leur propre sous-OU (ici GL-Direction) pour ne pas se mélanger aux objets qui décrivent des personnes.

Les partages et leurs groupes locaux

Côté données, chaque serveur expose un partage DATA découpé en sous-dossiers, plus deux partages techniques que nous verrons plus loin : DBASE pour les dossiers personnels et PROFILS pour les profils itinérants.

Le découpage suit deux logiques complémentaires. Les dossiers suffixés Commun vivent tous sur SRV-CHA et sont accessibles depuis les trois sites : c’est le point de mutualisation. Les dossiers suffixés par un nom de ville vivent sur le serveur de leur site : c’est le partitionnement, qui garde les données locales près de leurs utilisateurs.

Le tableau ci-dessous récapitule la cible à construire, un groupe local par couple (dossier, niveau de droit) :

Créer les objets de l’annuaire

La cible est posée. Nous allons maintenant la construire dans l’ordre exact de la chaîne AGDLP : d’abord les conteneurs, puis les groupes globaux (G), puis les comptes (A), et enfin les groupes locaux de domaine (DL). Ces quatre étapes se déroulent toutes dans la même console, Utilisateurs et ordinateurs Active Directory.

Étape 1 : créer les unités d’organisation

Les OU sont les premiers objets à construire, parce que tout le reste, groupes comme comptes, doit être créé à l’intérieur de l’une d’elles.

1. Ouvrir la console Utilisateurs et ordinateurs Active Directory

   Sur le contrôleur de domaine SRV-CHA, ouvrez le menu Outils du Gestionnaire de serveur et lancez Utilisateurs et ordinateurs Active Directory. C’est la console dans laquelle se déroule la quasi-totalité des étapes 1 à 4.

   

2. Créer l'OU de premier niveau

   Dans l’arborescence de la console, faites un clic droit sur le domaine SDE.LOCAL, puis choisissez Nouveau puis Unité d’organisation. Un clic droit sur une OU existante crée au contraire une sous-OU : c’est ainsi que l’on obtient la hiérarchie site puis département.

   

3. Nommer l'OU et désactiver la protection

   Donnez à l’OU un nom correspondant au site ou au département, puis validez avec OK.

   

   Astuce

   Décocher Protéger le conteneur contre la suppression accidentelle n’a de sens qu’en lab, où l’on reconstruit souvent l’arborescence. En production, laissez cette case cochée : elle empêche une suppression involontaire qui emporterait tous les objets contenus dans l’OU.

4. Répéter pour toute l'arborescence

   Reproduisez l’opération jusqu’à obtenir les 3 OU de site, leurs 7 sous-OU de département, et la sous-OU GL-Direction destinée aux groupes locaux.

Les conteneurs existent, ils sont vides. On y place d’abord les groupes globaux, car ce sont eux qui accueilleront les comptes créés juste après.

Étape 2 : créer les groupes globaux (le G)

Un groupe global représente un département sur un site. Il ne porte aucun droit : il ne fait que rassembler des personnes qui, par définition, ont les mêmes besoins d’accès.

1. Créer le groupe dans l'OU du département

   Dans l’OU du département, faites un clic droit et choisissez Nouveau puis Groupe. Créer le groupe depuis l’OU cible évite d’avoir à le déplacer ensuite.

   

2. Nommer le groupe et choisir l'étendue Globale

   Saisissez le nom du groupe selon la convention GG-<site>-<département>, définissez l’étendue sur Globale avec un type Sécurité, puis cliquez sur OK.

   

   ImportantSécurité et non Distribution

   Le type Distribution ne sert qu’aux listes de diffusion de messagerie : un tel groupe ne peut pas recevoir de droits. Seul un groupe de type Sécurité possède un SID exploitable dans une liste de contrôle d’accès. Choisir le mauvais type ici produit une chaîne AGDLP qui semble correcte mais n’accorde jamais rien.

3. Répéter pour les 7 départements

   À la fin de cette étape, vous disposez de GG-CHA-DIR, GG-CHA-ADM, GG-CHA-TECH, GG-VIR-ADM, GG-VIR-TECH, GG-BLA-ADM et GG-BLA-TECH.

Ces groupes sont pour l’instant vides. Il faut donc créer les comptes qui vont les peupler.

Étape 3 : créer les comptes utilisateurs (le A)

Le compte est le seul objet que l’utilisateur manipule vraiment : c’est avec lui qu’il ouvre sa session. Tout le reste de la chaîne lui est invisible.

1. Créer le compte dans l'OU du département

   Faites un clic droit sur la même OU de département, puis choisissez Nouveau puis Utilisateur.

   

2. Renseigner l'identité et le nom d'ouverture de session

   Renseignez le nom complet et le nom d’ouverture de session, puis cliquez sur Suivant. Le nom d’ouverture de session est l’identifiant technique du compte : il doit être unique dans tout le domaine et rester stable dans le temps, contrairement au nom complet qui peut évoluer.

   

3. Définir le mot de passe

   Confirmez le mot de passe et, pour ce lab, cochez Le mot de passe n’expire jamais avant de continuer.

   

   Avertissement

   Le mot de passe n'expire jamais fait gagner du temps en lab, mais ne se transpose pas en production. L’option cohérente y est plutôt L'utilisateur doit changer le mot de passe à la prochaine ouverture de session, qui garantit que l’administrateur ne connaît pas le secret final.

4. Valider la création

   Vérifiez le récapitulatif du compte et cliquez sur Terminer pour créer l’utilisateur.

   

Comptes et groupes globaux sont en place : la moitié gauche de la chaîne AGDLP (A et G) est prête. Il manque sa moitié droite, celle qui décrit les ressources.

Étape 4 : créer les groupes locaux de domaine (le DL)

Un groupe local de domaine est l’inverse d’un groupe global : il ne décrit pas des personnes, il décrit un droit sur une ressource précise. C’est le seul objet qui apparaîtra plus tard dans l’onglet Sécurité d’un dossier.

CF signifie Contrôle total, L signifie Lecture. Ces suffixes ne sont qu’une convention de nommage : ils n’appliquent rien par eux-mêmes, le droit réel sera posé à l’étape 7.

Le partage DATA-CHA contient un sous-dossier par périmètre (commun ou par site, administratif ou technique), et chacun devra être sécurisé par son ou ses propres groupes locaux.

1. Créer le groupe dans l'OU dédiée

   Dans l’OU GL-Direction, faites un clic droit et choisissez Nouveau puis Groupe.

   

2. Nommer le groupe et choisir l'étendue Domaine local

   Nommez le groupe selon la convention GL-SRV-<site>-DATA-... qui encode le dossier cible et le niveau de droit, définissez l’étendue sur Domaine local, puis cliquez sur OK.

   

   ExplicationPourquoi Domaine local et pas Global

   Un groupe global ne peut pas contenir d’autres groupes globaux venus d’un domaine différent, ce qui bloquerait toute évolution vers une forêt multi-domaines. Le groupe local de domaine, lui, accepte des groupes globaux de n’importe quel domaine approuvé. Choisir cette étendue ici, c’est garder ouverte la possibilité d’ouvrir un jour ce dossier à une filiale sans retoucher une seule ACL.

3. Vérifier la création

   Le nouveau groupe local de domaine apparaît désormais dans l’OU GL-Direction.

   

4. Répéter pour chaque ligne du tableau

   Reprenez le tableau de la section précédente et créez un groupe par cellule remplie, soit 13 groupes locaux au total.

Publier et sécuriser les partages

Les quatre maillons de la chaîne existent maintenant en tant qu’objets, mais aucun n’est relié aux autres, et surtout aucun dossier n’est encore accessible par le réseau. Les trois étapes qui suivent se déroulent donc côté serveur de fichiers : publier les dossiers, imbriquer les groupes, puis poser les autorisations.

Étape 5 : publier le partage DATA

Une permission NTFS ne sert à rien tant que le dossier n’est pas atteignable depuis un poste client. Il faut donc d’abord le publier en partage SMB. Cette étape est aussi l’occasion de comprendre pourquoi Windows superpose deux systèmes d’autorisations.

L’accès effectif d’un utilisateur est l’intersection des deux couches : c’est toujours la plus restrictive qui l’emporte. Ouvrir complètement la couche partage n’affaiblit donc rien, et concentre toute la logique de droits au même endroit, dans NTFS. C’est ce qui rend la configuration lisible et auditable : un seul onglet à consulter pour savoir qui accède à quoi.

1. Ouvrir les propriétés du dossier

   Sur le disque local, faites un clic droit sur le dossier DATA-CHA et ouvrez ses Propriétés.

   

2. Passer par le partage avancé

   Dans l’onglet Partage, cliquez sur Partage avancé. Le bouton Partager, juste au-dessus, est un assistant simplifié qui ne permet ni de masquer le partage ni de contrôler finement ses autorisations.

   

3. Nommer le partage et le masquer

   Cochez Partager ce dossier, saisissez le nom du partage DATA-CHA$ pour que le $ le garde masqué, puis ouvrez Autorisations.

   

   NoteCe que fait vraiment le dollar

   Un partage dont le nom se termine par $ n’apparaît pas dans la liste renvoyée par l’exploration réseau. Il reste parfaitement accessible à qui connaît son chemin \\SRV-CHA\DATA-CHA$. C’est une mesure de confort et de discrétion, pas une mesure de sécurité : la sécurité, ce sont les permissions NTFS de l’étape 7.

4. Ouvrir la couche partage

   Accordez le Contrôle total à Tout le monde au niveau du partage, puisque les autorisations NTFS assureront le filtrage réel, puis cliquez sur OK.

   

5. Relever le chemin réseau

   De retour dans l’onglet Partage, le dossier est maintenant partagé sur \\Srv-cha\data-cha$ ; fermez la boîte de dialogue. Notez ce chemin, il servira tel quel dans les scripts d’ouverture de session.

   

6. Retrouver les sous-dossiers à sécuriser

   En rouvrant le partage, on retrouve les sous-dossiers qui recevront chacun leur groupe local de domaine.

   

Répétez l’opération sur SRV-VIR et SRV-BLA pour publier DATA-VIR$ et DATA-BLA$.

Masquer ce qui n’est pas accessible

Sans réglage supplémentaire, un utilisateur qui ouvre \\SRV-CHA\DATA-CHA$ verra la liste complète des sous-dossiers, y compris Direction, et récoltera un refus d’accès en cliquant dessus. Le cloisonnement fonctionne, mais il révèle l’organigramme. L’énumération basée sur l’accès (ABE) corrige exactement ce point en filtrant la liste elle-même.

1. Ouvrir Services de fichiers et de stockage

   Dans le Gestionnaire de serveur, ouvrez Services de fichiers et de stockage.

   

2. Ouvrir les propriétés du partage

   Sous Partages, faites un clic droit sur le partage DATA-CHA$ et ouvrez ses Propriétés.

   

3. Activer l'énumération

   Dans la section Paramètres, cochez l’option d’énumération et validez.

   

   Astuce

   L’ABE se règle par partage, pas par dossier. Activez-la aussi sur DATA-VIR$ et DATA-BLA$, sinon le partitionnement de site restera visible depuis les autres sites.

Les dossiers sont publiés et prêts à filtrer. Il reste à relier les maillons de la chaîne entre eux.

Étape 6 : câbler la chaîne AGDLP

Deux imbrications suffisent, et l’ordre importe peu tant que les deux sont faites : sans la première, l’utilisateur n’est rattaché à rien ; sans la seconde, son groupe ne mène à aucune ressource.

Du compte vers le groupe global (A vers G)

1. Ouvrir les propriétés du groupe global

   Faites un clic droit sur le groupe global (ici GG-CHA-DIR) et ouvrez ses Propriétés.

   

2. Ajouter l'utilisateur comme membre

   Dans l’onglet Membres, cliquez sur Ajouter, saisissez le nom de l’utilisateur, résolvez-le avec Vérifier les noms, puis cliquez sur OK.

   

   Astuce

   Vérifier les noms n’est pas une simple politesse d’interface : tant que le texte saisi n’est pas souligné, l’objet n’a pas été résolu dans l’annuaire, et la validation échouera. C’est aussi le moyen le plus rapide de détecter une faute de frappe dans un nom de groupe.

3. Confirmer l'appartenance

   L’utilisateur figure désormais dans la liste des membres du groupe ; cliquez sur OK pour enregistrer.

   

Du groupe global vers le groupe local (G vers DL)

1. Rouvrir les propriétés du groupe global

   Ouvrez de nouveau les propriétés du même groupe global.

   

2. Basculer sur l'onglet Membre de

   Basculez sur l’onglet Membre de et cliquez sur Ajouter. L’onglet Membres liste ce que le groupe contient, l’onglet Membre de liste ce dans quoi il est contenu : c’est bien le second qu’il faut ici, puisque le groupe global entre dans le groupe local.

   

3. Désigner le groupe local de domaine

   Saisissez le nom du groupe local de domaine, résolvez-le avec Vérifier les noms, puis cliquez sur OK.

   

4. Confirmer l'imbrication

   Le groupe global est maintenant membre du groupe local de domaine ; cliquez sur OK.

   

La chaîne est câblée de bout en bout, mais elle ne débouche encore sur rien : aucun groupe local n’apparaît dans la liste de contrôle d’accès d’un dossier. C’est le dernier maillon, le P.

Étape 7 : poser les permissions NTFS (le P)

Ici, deux mécanismes se combinent et expliquent la longueur de la procédure.

Le premier est l’héritage : par défaut, un sous-dossier reçoit automatiquement les autorisations de son parent. Comme C:\DATA-CHA hérite lui-même de la racine du disque, le groupe intégré Utilisateurs s’y trouve, ce qui donnerait à tout compte du domaine un droit de lecture sur Direction. Il faut donc rompre cet héritage.

Le second est la conversion des autorisations héritées en autorisations explicites : au moment de désactiver l’héritage, Windows propose de recopier les entrées existantes sur le dossier. On choisit cette option, puis on supprime celles dont on ne veut pas. C’est plus sûr que la suppression pure, qui laisserait un dossier sans aucune ACL et donc inaccessible même aux administrateurs.

Répétez cette procédure pour chaque ligne du tableau de permissions. À la fin, chaque dossier expose une liste courte et lisible : SYSTEM, Administrateurs, et un ou deux groupes GL-.

Les données sont cloisonnées. Reste à les rendre atteignables sans effort pour l’utilisateur, qui ne doit avoir à mémoriser aucun chemin UNC.

Rendre les données atteignables depuis le poste

Trois mécanismes se complètent, tous réglés depuis le même onglet Profil du compte utilisateur, plus un script pour la partie dynamique.

Le dossier de base

Le dossier de base est un répertoire personnel hébergé sur le serveur, dans lequel l’utilisateur range ses documents. Le stocker à distance plutôt que sur le poste apporte deux garanties : il est inclus dans les sauvegardes du serveur, et il reste disponible si la machine tombe en panne.

Les lecteurs réseau

Le dossier de base est monté par Active Directory lui-même. Les partages DATA, eux, dépendent du site de l’utilisateur : c’est un script d’ouverture de session, stocké dans le partage NETLOGON du domaine, qui s’en charge.

net use Y: \\SRV-CHA\DATA-CHA$

net use Y: \\SRV-CHA\DATA-CHA$
net use Z: \\SRV-VIR\DATA-VIR$

net use Y: \\SRV-CHA\DATA-CHA$
net use Z: \\SRV-BLA\DATA-BLA$

Concrètement, pour un utilisateur rattaché à Blandin :

• X: pointe sur \\SRV-BLA\DBASE-BLA$\NOM_UTILISATEUR, son espace personnel.
• Y: pointe sur \\SRV-CHA\DATA-CHA$, le partage commun hébergé au siège. Grâce à l’ABE et aux permissions NTFS, il n’y verra que les dossiers auxquels il a au moins un droit de lecture.
• Z: pointe sur \\SRV-BLA\DATA-BLA$, le partage de son propre site, filtré de la même manière.

Les profils itinérants

Les données sont maintenant accessibles depuis n’importe quel poste, mais l’environnement de travail, lui, reste local : bureau, favoris, préférences applicatives. Le profil itinérant complète le dispositif en stockant ce profil sur le serveur et en le recopiant sur la machine à chaque ouverture de session.

La mécanique est identique à celle du dossier de base : on publie un partage, puis on y pointe le compte.

Tout est configuré côté serveur. La seule preuve qui vaille reste une ouverture de session réelle depuis un poste client.

Vérifier et récapituler

Le test du premier utilisateur

Joignez un poste client au domaine SDE.LOCAL, redémarrez-le, puis ouvrez une session avec un compte de domaine, par exemple ADM1B. Passez ensuite la liste suivante, qui rejoue la chaîne AGDLP dans l’ordre inverse et localise immédiatement le maillon défaillant.

Si un point échoue, le tableau ci-dessous couvre les causes les plus fréquentes.

La chaîne complète, de bout en bout

Pour un utilisateur du service Direction, tout ce qui vient d’être construit tient en une ligne :

PDG (compte, OU Direction)
  > membre de GG-CHA-DIR (groupe global, OU Direction)
      > membre de GL-SRV-CHA-DATA-DIRECTION-CF (groupe local, OU GL-Direction)
          > Contrôle total NTFS sur \\SRV-CHA\DATA-CHA$\Direction
              > visible dans Y: grâce à l'ABE et au script d'ouverture de session

Chaque maillon a une seule responsabilité, et chacun peut être modifié sans toucher aux autres : c’est exactement ce qui rend cette configuration tenable dans le temps.

L’infrastructure est fonctionnelle, mais rien n’empêche encore un utilisateur de remplir le partage à lui seul. C’est l’objet de l’article suivant de la série : Appliquer des quotas sur des répertoires partagés en réseau.