Organiser l'annuaire : unités, groupes et stratégies
Ce que ce chapitre apporte
- Distinguer une unité d'organisation d'un groupe, et savoir à quoi sert chacun.
- Choisir un critère d'arborescence et en justifier le choix.
- Connaître les portées de groupe et appliquer la chaîne AGDLP.
- Expliquer ce qu'est une stratégie de groupe et où elle se lie.
- Dérouler l'ordre d'application LSDOU et résoudre un conflit de paramètres.
- Utiliser le blocage d'héritage, l'application forcée et le filtrage de sécurité, à bon escient.
- Mettre en place un audit qui produise une trace exploitable.
Unité d'organisation ou groupe
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.
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.
Facturation pour appliquer aux postes du service la stratégie qui leur convient, et le groupe GG_Facturation 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.
ardexia.lanle domaineUtilisateursles comptes des salariésFacturationPlateauDirectionOrdinateursles postes de travailPostes-FacturationPostes-PlateauPortablesServeursséparés des postes, leurs stratégies n'ont rien à voirFichiersApplicatifsGroupesdes groupes de sécurité, et rien d'autreDeux choses se lisent sur cette arborescence. Le premier niveau ne parle que de types d'objets : comptes, postes, serveurs, groupes. Le second, et lui seul, parle de services. Une réorganisation des services ne touche donc jamais qu'une profondeur de l'arbre.
Et l'unité Groupes est à part : elle range des objets qui ne sont ni des utilisateurs ni des ordinateurs. On y reviendra, car c'est ce qui explique qu'une stratégie liée à cet endroit ne produise rien.
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 |
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.
- Le compte de Marie entre dans le groupe global
GG_Facturation, qui décrit qui elle est. - Le groupe global entre dans le groupe domaine local
DL_Facturation_Lecture, qui décrit ce qu'on peut faire. - La permission de lecture sur le dossier est accordée à
DL_Facturation_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.
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
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.
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, il faut toujours vérifier 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.
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.
Les deux premiers niveaux se confondent facilement, parce qu'ils ne vivent pas au même endroit que les deux autres. La stratégie locale est stockée sur le disque du poste lui-même et s'applique même hors du réseau : c'est le socle sur lequel tout le reste vient écrire. La stratégie de site est liée à un ensemble de sous-réseaux, donc à l'emplacement physique de la machine, et sert typiquement à imposer un serveur mandataire ou une imprimante de proximité. Viennent ensuite les deux niveaux proprement logiques, le domaine et les unités d'organisation, qui ne dépendent plus de l'endroit où la machine est branchée mais de sa place dans l'annuaire.
Savoir cela permet de répondre à la première question de tout dépannage de stratégie : ce paramètre vient-il du poste, de son emplacement réseau, ou de l'annuaire ?
Un groupe de portée domaine local est un groupe qui ne peut recevoir des droits que dans son propre domaine. « Local » y qualifie une étendue, celle d'un domaine entier, qui peut compter des milliers de machines.
Une stratégie locale est celle qui est stockée sur le disque d'un poste et ne vaut que pour lui. « Local » y qualifie une seule machine.
Les deux notions ne se rencontrent jamais : un groupe domaine local ne s'applique pas plus à la stratégie locale que l'inverse. C'est le deuxième faux ami du chapitre, après le « groupe » des stratégies de groupe.
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.
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é.
Chacun de ces trois mécanismes se comprend seul. C'est leur combinaison qui résiste, parce qu'elle ne se lit dans aucun ordre linéaire : le blocage retire des stratégies, la forcée en rétablit une et prend le dessus, le filtrage en écarte une autre pour une raison qui n'a rien à voir avec la hiérarchie. La figure suivante déroule les cinq niveaux et affiche, pour chaque paramètre, toutes les écritures successives, la retenue en clair et les autres barrées.
- Proxy_Beauvais ne s'applique pas : bloquée par l'héritage coupé sur Facturation.
- Bureau ne s'applique pas : bloquée par l'héritage coupé sur Facturation.
- usb vaut non par application forcée, alors qu'une stratégie appliquée plus tard le contredisait. C'est la précédence inversée : forcer ne fait pas que traverser un blocage, cela l'emporte sur tout ce qui suit.
Quatre observations, dans l'ordre où elles se lisent sur la figure.
Le blocage posé sur Facturation coupe Proxy_Beauvais et Bureau, qui viennent de plus haut. Le proxy disparaît donc du résultat, ce que personne n'avait voulu : c'est l'effet de bord annoncé plus haut.
La stratégie locale survit au blocage. Elle n'est héritée d'aucun conteneur de l'annuaire, puisqu'elle vit sur le disque du poste, et rien ne la coupe. Elle est seulement écrasée par ce qui s'applique ensuite, et son fond=defaut l'emporte ici faute de concurrent, Bureau ayant été bloquée.
La stratégie forcée traverse le blocage, et surtout elle impose son usb=non alors que Compta, appliquée après elle et plus proche de la cible, dit l'inverse. C'est la précédence inversée, et c'est le point que la règle LSDOU seule ne permet pas de prévoir.
Le filtrage n'intervient pas ici, faute de stratégie filtrée. Ajouter | filtre=GG_Direction à Compta l'écarterait, bien qu'elle soit la plus proche de la cible et qu'aucun blocage ne la concerne.
La stratégie est-elle filtrée sur un groupe dont la cible ne fait pas partie ? Le filtrage passe avant tout le reste, et il ne se voit pas dans la hiérarchie.
Est-elle bloquée par un héritage coupé sur un conteneur situé plus bas qu'elle ?
Est-elle écrasée par une stratégie appliquée après elle, ou par une stratégie forcée appliquée avant ?
L'audit
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 Ardexia, 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.
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
Facturationvers l'OUDirection, pour que les stratégies de sa nouvelle fonction s'appliquent. - La retirer du groupe global
GG_Facturationet 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 Ardexia 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.
Le mot « tournent » recouvre un mécanisme précis. Le journal de sécurité a une taille maximale fixée à l'avance ; une fois pleine, chaque nouvel événement écrase le plus ancien. Or c'est justement une attaque qui produit le plus d'événements : quelques milliers de tentatives de connexion en échec suffisent à remplir un journal dimensionné pour l'activité ordinaire. La tentative initiale, celle qu'on voudrait retrouver, se trouve donc effacée par les tentatives suivantes, et l'attaque efface ses propres traces sans que personne ait eu à s'en occuper.
C'est ce mécanisme, et non un principe abstrait, qui impose d'exporter les journaux vers un serveur dédié au fil de l'eau.
Vérification
1.À quoi une stratégie de groupe se lie-t-elle ?
2.Le domaine bloque les ports USB, l'unité d'organisation de la comptabilité les réautorise. Que constate un poste de ce service ?
3.Que fait le blocage d'héritage sur une unité d'organisation ?
4.Dans la chaîne AGDLP, à quoi la permission est-elle accordée ?
La méthode
- Ranger dans une OU, donner des droits par un groupe. Cette phrase règle la moitié des questions du sujet.
- Découper l'arborescence par type d'objet, puis par service. Stable, lisible, délégable.
- Appliquer AGDLP systématiquement, même en domaine unique : le coût est nul, le bénéfice arrive au premier mouvement de personnel.
- Vérifier la moitié de la GPO (ordinateur ou utilisateur) avant de chercher pourquoi elle ne s'applique pas.
- Dérouler LSDOU pour tout conflit de paramètre, en gardant en tête que le dernier appliqué gagne.
- Réserver l'application forcée à ce qui doit être vrai sans exception, et traquer les blocages d'héritage oubliés.
- Décider ce qu'on veut pouvoir prouver avant d'activer un audit, et fixer une durée de conservation.
Synthèse
- 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.
Mettre en pratique
L'ordre LSDOU, la chaîne AGDLP, et ce qu'une portée de groupe autorise.
Tous les exercices sur annuaire et stratégies