Organiser l'annuaire : unités, groupes et stratégies

Où on va

Deux ordinateurs du même service n'ont pas la même configuration ni les mêmes logiciels. Un collaborateur change de fonction et il faut modifier ses accès sur plusieurs serveurs. Un annuaire seul ne règle rien de tout cela : il faut l'organiser. Ce chapitre installe les trois outils qui font la différence entre un annuaire et une administration : les unités d'organisation, les groupes et les stratégies de groupe. Et il commence par lever la confusion la plus tenace du domaine.

Unité d'organisation ou groupe

Définitions

Une unité d'organisation (OU) est un conteneur logique qui range les objets de l'annuaire. Un objet se trouve dans une OU et une seule.

Un groupe de sécurité est un objet qui rassemble des comptes pour leur attribuer des droits d'un seul geste. Un compte peut appartenir à autant de groupes qu'on veut.

La règle qui lève la confusion

On range dans une unité d'organisation, on donne des droits par un groupe.
Autrement dit : une OU sert à appliquer une stratégie et à déléguer l'administration. Un groupe sert à ouvrir un accès. Attribuer des droits sur un dossier à une OU n'est pas possible, et c'est logique : ce n'est pas ce à quoi elle sert.

L'erreur qui structure mal tout un annuaire

Créer une OU « Comptabilité » et croire qu'elle donnera accès au dossier comptable. Il faut les deux : l'OU Comptabilite pour appliquer aux postes du service la stratégie qui leur convient, et le groupe GG_Comptabilite pour ouvrir l'accès au partage.
Un annuaire construit sur cette confusion oblige à reprendre l'arborescence entière quand un utilisateur doit accéder à deux services.

Construire l'arborescence

Trois critères de découpage se rencontrent, et le bon choix dépend de ce qu'on veut piloter.

Critère	Quand il convient	Sa limite
Par service	Les stratégies diffèrent selon le métier	Une réorganisation oblige à déplacer des objets
Par site géographique	Les sites ont des contraintes propres	Ne dit rien du métier
Par type d'objet	Séparer utilisateurs, postes et serveurs	Insuffisant seul

En pratique, on combine : d'abord le type, puis le service. Cela donne une arborescence lisible et stable.

neolink.local
├── Utilisateurs
│   ├── Comptabilite
│   ├── Production
│   └── Direction
├── Ordinateurs
│   ├── Postes-Comptabilite
│   ├── Postes-Production
│   └── Portables
├── Serveurs
│   ├── Fichiers
│   └── Applicatifs
└── Groupes

Une stratégie ne s'applique jamais à un groupe

Une stratégie de groupe se lie à un site, à un domaine ou à une unité d'organisation. Jamais à un groupe, malgré le nom.
Le nom « stratégie de groupe » désigne un groupe de paramètres, pas un groupe d'utilisateurs. C'est un faux ami, et il coûte cher dès qu'on cherche pourquoi un paramètre ne s'applique pas.
Pour restreindre une stratégie à certains comptes, on emploie le filtrage de sécurité, décrit plus bas.

Les portées de groupe et la chaîne AGDLP

Un groupe a une portée, qui détermine ce qu'il peut contenir et où il peut recevoir des droits.

Portée	Peut contenir	Peut recevoir des droits
Globale	des comptes du même domaine	dans toute la forêt
Domaine local	des comptes et groupes globaux de la forêt	dans son domaine seulement
Universelle	des comptes et groupes de toute la forêt	dans toute la forêt

AGDLP

La convention d'usage tient en cinq lettres, dans cet ordre :

Account dans un groupe Global, ce groupe global dans un groupe Domain Local, et c'est au groupe domaine local qu'on accorde la Permission.

Ouvrir l'accès en lecture au partage comptable

Le compte de Marie entre dans le groupe global GG_Comptabilite, qui décrit qui elle est.
Le groupe global entre dans le groupe domaine local DL_Compta_Lecture, qui décrit ce qu'on peut faire.
La permission de lecture sur le dossier est accordée à DL_Compta_Lecture.

Marie change de service ? On la retire d'un groupe global, on l'ajoute à un autre. Aucune permission n'est touchée, sur aucun serveur.

Pourquoi ce détour vaut la peine

Sans AGDLP, chaque changement de poste oblige à parcourir les serveurs pour ajuster des droits, et c'est exactement la situation décrite chez NeoLink : « lorsqu'un collaborateur change de fonction, les modifications doivent être réalisées sur plusieurs équipements ».
Avec AGDLP, l'appartenance décrit l'identité, la permission décrit la ressource, et les deux ne se rencontrent qu'en un seul point. Un mouvement de personnel devient une opération, pas une campagne.

Les stratégies de groupe

Définition

Une stratégie de groupe (GPO) est un ensemble de paramètres appliqués automatiquement aux utilisateurs ou aux ordinateurs des conteneurs auxquels elle est liée.

Une GPO comporte deux moitiés indépendantes : une partie ordinateur, appliquée au démarrage de la machine, et une partie utilisateur, appliquée à l'ouverture de session.

La moitié qui ne s'applique pas

Lier à l'OU Utilisateurs une stratégie dont tous les paramètres sont dans la partie ordinateur ne produit rien. Aucune erreur, aucun message : simplement aucun effet.
Avant de chercher plus loin, vérifie toujours que la moitié configurée correspond au type d'objets contenus dans l'OU liée.

L'ordre d'application : LSDOU

Quand plusieurs stratégies s'appliquent au même objet, elles sont traitées dans un ordre fixe, et la dernière appliquée l'emporte en cas de conflit.

LSDOU

Local, puis Site, puis Domaine, puis OU de la plus générale à la plus profonde.

Plus une stratégie est liée près de l'objet, plus elle est prioritaire.

main.py

Sortie

>_ Prêt à exécuter…

Ce que montre le calcul

Le domaine bloque les ports USB, et pourtant la comptabilité les a. Ce n'est pas un bug : l'OU est appliquée après le domaine, donc elle gagne.
C'est la raison pour laquelle un paramètre de sécurité posé au niveau du domaine ne garantit rien tant qu'on n'a pas vérifié qu'aucune OU ne le contredit. Pour garantir, il faut l'application forcée.

Blocage, application forcée, filtrage

Trois mécanismes modifient le jeu, et ils ne se valent pas.

Le blocage d'héritage se pose sur une OU et empêche les stratégies des niveaux supérieurs de s'y appliquer. Pratique, et dangereux : il coupe aussi les stratégies de sécurité du domaine.

L'application forcée se pose sur une liaison de stratégie. Elle inverse la règle : la stratégie forcée l'emporte sur tout ce qui est appliqué après, et traverse les blocages d'héritage.

Le filtrage de sécurité restreint une stratégie à certains comptes ou groupes. C'est le seul moyen propre de cibler des utilisateurs plutôt qu'un conteneur.

Deux réglages qui se retournent contre l'administrateur

Le blocage d'héritage est souvent posé pour régler un cas particulier, puis oublié. Six mois plus tard, la politique de mots de passe du domaine ne s'applique plus à cette OU, et personne ne sait pourquoi.
L'application forcée résout le problème mais rigidifie : trop de stratégies forcées et plus personne ne peut adapter quoi que ce soit localement. On la réserve à ce qui doit être vrai partout, sans exception : sécurité, conformité.

L'audit

Définitions

L'audit est le mécanisme de collecte et d'enregistrement des événements du système.

La traçabilité est la capacité qui en découle : retrouver l'origine d'une action ou d'une modification.

Chez NeoLink, la direction demande qui a accédé à quoi. Sans audit, la question n'a pas de réponse, même a posteriori : les traces n'existent pas.

Quatre familles d'événements méritent d'être auditées en priorité :

Les ouvertures de session, réussies et échouées.
Les modifications de comptes et de groupes : création, suppression, ajout à un groupe privilégié.
Les accès aux ressources sensibles, en lecture comme en écriture.
Les modifications de stratégies.

Auditer tout revient à n'auditer rien

Activer l'audit sur l'ensemble des accès de tous les partages produit des millions d'événements par jour, sature les journaux, et fait disparaître les traces utiles par rotation avant même qu'on les consulte.
Un audit se conçoit comme un seuil d'alerte : on décide ce qu'on veut pouvoir prouver, et on n'enregistre que cela. C'est exactement le raisonnement du chapitre de supervision.

Exercices type

Marie passe de la comptabilité à la direction. Quelles opérations ?

Avec une arborescence et des groupes bien construits, deux opérations :

Déplacer son compte de l'OU Comptabilite vers l'OU Direction, pour que les stratégies de sa nouvelle fonction s'appliquent.
La retirer du groupe global GG_Comptabilite et l'ajouter à GG_Direction, pour que ses accès suivent.

Aucune permission n'est modifiée sur aucun serveur. C'est tout l'intérêt d'AGDLP.

À ne pas oublier : le déplacement d'OU ne prend effet qu'à la prochaine ouverture de session, et la modification d'appartenance à un groupe qu'à l'obtention d'un nouveau ticket. Se déconnecter et se reconnecter fait partie de la procédure.

Une GPO liée au domaine bloque l'USB, mais un service l'a toujours. Pourquoi ?

Trois causes possibles, à vérifier dans cet ordre :

Une GPO liée plus bas, sur l'OU du service, réautorise l'USB. C'est LSDOU : l'OU s'applique après le domaine et l'emporte. C'est le cas le plus fréquent.
Un blocage d'héritage est posé sur l'OU : la stratégie du domaine ne l'atteint plus du tout.
Un filtrage de sécurité exclut ce groupe de la stratégie du domaine.

Le remède, si le blocage doit être garanti : passer la stratégie du domaine en application forcée. Elle traverse alors les blocages d'héritage et l'emporte sur les liaisons plus basses.

Peut-on lier une GPO à un groupe de sécurité ?

Non. Une GPO se lie à un site, un domaine ou une unité d'organisation. Le mot « groupe » dans son nom désigne un groupe de paramètres, pas un groupe d'utilisateurs.

Pour cibler des comptes précis, on lie la stratégie à l'OU qui les contient, puis on la restreint par filtrage de sécurité au groupe voulu.

Cette confusion est le contresens le plus courant du sujet, et elle explique beaucoup de stratégies qui « ne s'appliquent pas ».

Pourquoi ne pas donner directement les droits sur un dossier à un groupe global ?

Cela fonctionne, dans un domaine unique. Ce qui se dégrade est la capacité à faire évoluer.

Le groupe global décrit une identité, « les gens de la comptabilité ». La permission décrit une ressource, « lecture sur ce partage ». Les fusionner revient à créer autant de groupes que de combinaisons identité fois ressource.

Avec AGDLP, ouvrir un nouveau partage à trois services consiste à créer un groupe domaine local et à y placer trois groupes globaux existants. Sans, il faut aller poser trois entrées de permission sur le dossier, et se souvenir de les retirer un jour.

L'argument devient décisif en environnement multi-domaines, où un groupe global ne peut pas recevoir de droits dans un autre domaine, alors qu'un groupe domaine local peut contenir des globaux venus de toute la forêt.

Un blocage d'héritage a été posé sur une OU. Quel risque ?

Que les stratégies de sécurité du domaine ne s'y appliquent plus : politique de mots de passe, verrouillage de session, restrictions logicielles.

Le blocage est indiscriminé : il ne coupe pas seulement la stratégie qui gênait, il coupe tout ce qui vient d'au-dessus. Et rien ne le signale au quotidien, ce qui le rend durable.

Deux remèdes. Marquer les stratégies de sécurité du domaine en application forcée, ce qui leur permet de traverser les blocages. Et surtout, se demander pourquoi le blocage a été posé : c'est presque toujours le symptôme d'une arborescence mal découpée.

Quels événements auditer chez NeoLink en priorité ?

En partant des plaintes de la direction, deux besoins :

Pour « des personnes accèdent à des dossiers qui ne les concernent pas », auditer les accès en lecture et en écriture sur les partages sensibles, et eux seuls.

Pour « on ne sait pas si les accès d'un partant ont bien été retirés », auditer les modifications d'appartenance aux groupes et les désactivations de comptes.

Ce qu'il faut écrire en plus, et qui est souvent oublié : la durée de conservation et l'endroit où les journaux sont centralisés. Un audit dont les traces tournent au bout de trois jours ne prouve rien, et des journaux qui restent sur la machine auditée disparaissent avec elle.

La méthode

Range dans une OU, donne des droits par un groupe. Cette phrase règle la moitié des questions du sujet.
Découpe l'arborescence par type d'objet, puis par service. Stable, lisible, délégable.
Applique AGDLP systématiquement, même en domaine unique : le coût est nul, le bénéfice arrive au premier mouvement de personnel.
Vérifie la moitié de la GPO (ordinateur ou utilisateur) avant de chercher pourquoi elle ne s'applique pas.
Déroule LSDOU pour tout conflit de paramètre, et rappelle-toi que le dernier appliqué gagne.
Réserve l'application forcée à ce qui doit être vrai sans exception, et traque les blocages d'héritage oubliés.
Décide ce que tu veux pouvoir prouver avant d'activer un audit, et fixe une durée de conservation.

En résumé

OU : on y range, elle porte les stratégies et la délégation. Groupe : il porte les droits.
Arborescence par type puis service, pour qu'elle survive à une réorganisation.
Portées : globale (des comptes du domaine), domaine local (reçoit les droits), universelle (à travers la forêt).
AGDLP : compte dans un global, global dans un domaine local, permission sur le domaine local.
Une GPO a deux moitiés, ordinateur et utilisateur, indépendantes.
LSDOU : Local, Site, Domaine, OU. La dernière appliquée gagne.
Blocage d'héritage : coupe tout ce qui vient d'en haut, sécurité comprise. Application forcée : traverse les blocages. Filtrage de sécurité : le seul moyen de cibler des comptes.
Un audit se conçoit par ce qu'on veut prouver, avec une durée de conservation. Tout auditer revient à ne rien auditer.

Et ensuite ? Les comptes sont rangés et les groupes construits. Reste à s'en servir là où les incidents de NeoLink se produisent vraiment : sur les dossiers partagés et leurs permissions.