Structurer Active Directory en PME, des OU aux droits de fichiers

Des droits illisibles coûtent du temps à chaque demande d'accès. Un départ devient une opération à risque quand personne ne sait exactement ce qu'un compte peut encore atteindre. Une structure saine se pose une fois, s'entretient presque sans effort et répond à la question « qui a accès à quoi » en quelques secondes. Ce guide s'adresse aux PME avec un Active Directory on-premise, qu'il soit hérité d'un prestataire précédent ou en cours de montage. Le fil conducteur va des unités organisationnelles (OU) jusqu'aux droits NTFS sur les partages de fichiers, en passant par les groupes et les conventions de nommage.

Une arborescence d'OU par type d'objet

La première erreur à éviter est de calquer les OU sur l'organigramme. La direction des Ventes devient une OU, la direction des Achats en devient une autre, et la prochaine réorganisation impose de tout déplacer. Les GPO deviennent impossibles à lire, les délégations se multiplient sans plan.

Une OU ne sert qu'à deux choses. Appliquer des stratégies de groupe (GPO) à un ensemble cohérent d'objets. Déléguer une tâche d'administration à une personne ou un groupe sans lui donner les clés du domaine entier.

Une arborescence lisible pour une PME mono-domaine ressemble à ceci.

contoso.local
├── _OU_Utilisateurs
├── _OU_Groupes
├── _OU_Postes
├── _OU_Serveurs
└── _OU_ComptesDeSvc

Selon la taille, subdiviser _OU_Utilisateurs en sous-OU si des GPO différentes s'appliquent à des populations distinctes, par exemple des VIP avec une politique de verrouillage d'écran différente. Subdiviser _OU_Postes si les postes portables reçoivent des GPO BitLocker absentes des postes fixes.

Les conteneurs par défaut (Computers, Users, Builtin) restent intacts. Ils n'acceptent pas les GPO et ne doivent pas servir de rangement opérationnel. Tout objet créé en production va directement dans une OU dédiée.

Le préfixe _OU_ devant chaque OU de premier niveau est optionnel mais pratique. Dans la console, il groupe visuellement les OU créées par l'équipe et les sépare des conteneurs système.

Le modèle AGDLP, des groupes qui travaillent pour vous

AGDLP signifie Account, Global, Domain Local, Permission. La formule désigne une chaîne d'indirection. Un compte utilisateur entre dans un groupe global. Le groupe global entre dans un groupe de domaine local. Le groupe de domaine local porte la permission sur la ressource.

En pratique, cela donne deux types de groupes avec des rôles bien séparés.

Le groupe de rôle (groupe global, préfixe GG_) reflète un métier ou un service. GG_Compta, GG_Direction, GG_Projets_Alpha. Il décrit qui sont les personnes, pas ce à quoi elles ont accès.

Le groupe de ressource (groupe de domaine local, préfixe DL_) est lié à un dossier et à un niveau de droit. DL_Compta_RW donne une écriture sur le dossier Compta, DL_Compta_RO donne une lecture. Il décrit ce qui est accessible, sans rien dire des personnes.

La connexion se fait en un sens. Le groupe de rôle entre dans le groupe de ressource. Le groupe de ressource entre dans l'ACL du dossier. On ne touche plus jamais aux ACL des dossiers, sauf pour ajouter un nouveau groupe de ressource. Le modèle décrit ici suppose un domaine unique, le cas de loin le plus courant en PME.

Les bénéfices concrets apparaissent dès quinze salariés. Une arrivée se règle par une adhésion à un ou deux groupes de rôle. Un changement de poste demande deux opérations, retirer de l'ancien groupe et ajouter au nouveau. La question « qui a accès au dossier Compta en écriture » trouve sa réponse dans les membres de DL_Compta_RW, sans parcourir les ACL dossier par dossier.

Un audit réseau ou un état des lieux révèle souvent des droits posés au fil de l'eau, directement sur des comptes nominatifs. Ces droits orphelins sont invisibles depuis les groupes et survivent aux départs.

Pour les structures de moins de dix personnes, une version simplifiée tient sans le groupe de domaine local intermédiaire. Le groupe de rôle porte directement le droit sur le dossier. Ce raccourci est acceptable à condition de ne jamais poser un droit sur une personne plutôt que sur un groupe.

Appliquer le modèle aux partages de fichiers

Les dossiers de tête donnent la structure générale du partage. Commun, Compta, Direction, Projets, RH. Chaque dossier de tête correspond à un périmètre de confidentialité cohérent. Sous ces dossiers de tête, les sous-dossiers héritent des droits sans qu'on y touche.

Les droits NTFS se posent une seule fois, sur le dossier de tête, via les groupes de ressource. On ne pose pas de droit sur un sous-dossier sauf raison documentée. Chaque exception à l'héritage est notée dans la description du groupe de ressource concerné, avec la date et la justification.

Droit de partage et droit NTFS jouent deux rôles différents. Le droit de partage SMB reste large, le niveau Modifier pour les utilisateurs authentifiés couvre la grande majorité des usages. C'est le droit NTFS qui fait le tri fin. Ce découpage simplifie le dépannage. Si un utilisateur ne peut pas accéder à un dossier, le problème vient des groupes NTFS, pas du partage.

Quelques règles fixes.

• Jamais de droit posé directement sur un compte utilisateur dans une ACL NTFS.
• Tout le monde n'apparaît sur aucun dossier sensible, même en lecture.
• CREATOR_OWNER avec contrôle total sur les sous-dossiers est à éviter sauf usage spécifique documenté.

Avec ces règles, la lecture des droits reste rapide. Ouvrir les propriétés de sécurité d'un dossier de tête affiche quatre à six entrées, toutes des groupes préfixés DL_, lisibles immédiatement.

Des comptes propres

Un Active Directory sain repose sur des comptes nominatifs sans exception. Pas de compte accueil, pas de compte scanner, pas de compte stagiaire partagé entre plusieurs personnes. Chaque personne physique a un compte à son nom, même pour trois semaines.

Les comptes d'administration sont séparés du compte bureautique. Un administrateur système dispose d'un compte standard pour le quotidien et d'un compte suffixé -adm pour les tâches d'administration. Le compte -adm n'a pas de boîte mail, n'ouvre pas de session interactive sur les postes utilisateurs, et ne sert qu'à administrer. Cette séparation limite la surface d'exposition en cas de compromission du poste.

Les comptes de service sont dédiés par application. Un compte pour la sauvegarde, un autre pour l'antivirus, un troisième pour l'ERP. Chacun est documenté dans la description AD avec le nom de l'application, la date de création et le responsable. Le mot de passe est long, aléatoire, et stocké dans un gestionnaire de mots de passe partagé. Un départ d'un salarié qui était le seul à connaître un mot de passe de service est un incident évitable.

Le MFA s'active en priorité sur les comptes d'administration et les accès distants, bien avant les comptes bureautiques.

Au départ d'un collaborateur, on désactive le compte le jour J, on le déplace dans une OU _OU_Desactives, et on le conserve le temps défini par la politique interne, souvent trente à quatre-vingt-dix jours, avant suppression. Les droits et l'historique restent lisibles pendant cette période. Supprimer immédiatement prive de la traçabilité et rend impossible la vérification qu'aucun dossier n'était dépendant du compte.

Conventions de nommage et hygiène

Des préfixes cohérents rendent la console AD lisible, même pour quelqu'un qui n'a pas construit l'annuaire.

Le suffixe _RW indique une lecture-écriture (droit NTFS Modifier), _RO une lecture seule. Ces deux niveaux couvrent la quasi-totalité des besoins en PME.

Le champ description de chaque groupe est rempli à la création. Nom du demandeur, raison du groupe, date de création. Trois lignes qui économisent une demi-heure d'investigation six mois plus tard.

La revue des membres des groupes sensibles se fait tous les six mois. Un tableur, les membres de chaque groupe DL_ et ADM_, un responsable métier qui confirme ou retire. En PME, cette revue prend moins d'une heure. Elle révèle régulièrement des comptes oubliés après un changement de poste.

Une page de documentation interne décrit le modèle. Pas un roman, une page. Le nom des OU, les préfixes utilisés, la règle sur les droits NTFS, le process d'arrivée et de départ. Cette page évite que le prochain administrateur reconstruise sa propre logique par-dessus l'existante.

Les erreurs qui se paient pendant des années

Elles sont communes, faciles à éviter dès le départ, et coûteuses à corriger une fois ancrées.

• Droits NTFS posés sur des personnes plutôt que sur des groupes. Le compte reste dans les ACL après un départ et nul ne le voit plus.
• Tout le monde en lecture sur un partage sensible, parce que c'était plus rapide à configurer.
• OU calquées sur l'organigramme, qui imposent un chantier à chaque réorganisation.
• Groupes imbriqués sans logique documentée, où personne ne sait plus quelle imbrication donne quel droit.
• Compte administrateur du domaine utilisé au quotidien pour lire les mails et naviguer sur le web.

Questions fréquentes

AGDLP n'est-il pas surdimensionné pour 20 personnes ?

La chaîne complète (compte, groupe global, groupe de domaine local, droit) vaut la peine dès que les ressources sont réparties sur plusieurs serveurs. Sous ce seuil, la version raccourcie convient. Un groupe de rôle GG_Compta porte directement le droit Modification sur le dossier Compta. L'essentiel reste de ne jamais poser un droit sur une personne. Même à vingt personnes, un compte nominatif dans une ACL crée un problème invisible à chaque départ.

Combien de groupes, c'est trop ?

L'arithmétique reste petite avec une approche dossier de tête. Cinq dossiers de tête donnent dix groupes de ressource (_RW et _RO). Quatre services donnent quatre groupes de rôle. En ajoutant une poignée de groupes d'administration, on reste sous la trentaine pour une PME standard. Cette liste tient dans une page de console. Un groupe par projet ou par sous-dossier, à l'inverse, génère des centaines d'entrées et rend l'ensemble illisible en six mois.

Et en hybride avec Entra ID ?

Les principes se transposent. Les groupes restent l'unité de gestion des droits, qu'ils soient synchronisés depuis l'AD on-premise via Entra Connect ou créés nativement dans le cloud. Entra ID ajoute la notion de groupes dynamiques basés sur des attributs utilisateur (disponibles à partir de la licence Entra ID P1), ce qui peut automatiser les adhésions pour des mouvements simples. Le modèle des groupes de rôle et de ressource reste le cadre de référence. La checklist d'audit informatique couvre les points de vérification utiles avant une migration hybride.