Dans beaucoup de SI, la stratégie de mot de passe est restée coincée au niveau du domaine, avec une GPO uniforme qui traite de la même façon un stagiaire en front-office et un compte d’administration de production. Tant que personne ne force le sujet, tout le monde vit avec ce compromis bancal. Puis un audit, une alerte sécurité ou un projet de segmentation arrive, et la question se pose enfin : comment appliquer une stratégie de mot de passe plus exigeante pour certains comptes, sans tout casser pour le reste du parc Active Directory ? C’est exactement le rôle du Password Setting Object (PSO).
Dans Active Directory, les PSO permettent une gestion mot de passe plus fine que les GPO classiques, en ciblant directement des utilisateurs ou des groupes AD. Concrètement, on peut imposer 14 caractères et une expiration courte pour les administrateurs, conserver 10 caractères pour les équipes IT, et laisser 8 caractères à un back-office peu exposé, le tout dans le même domaine. L’enjeu n’est pas théorique : les exigences de conformité (NIS2, ISO 27001) et la pression des attaques sur les comptes à privilèges imposent de durcir les politiques de sécurité là où cela a vraiment un impact. Reste à comprendre comment fonctionnent les attributs PSO, comment les prioriser, les auditer, et surtout éviter les effets de bord.
En bref
- Les Password Setting Object (PSO) permettent d’appliquer des stratégies de mot de passe différentes à des utilisateurs ou groupes précis dans Active Directory, au-delà de la GPO de domaine.
- Chaque PSO définit la complexité mot de passe, la longueur minimale, la durée de vie mot de passe et la politique de verrouillage, avec une priorité gérée par l’attribut Precedence.
- La configuration se fait via le Centre d’administration Active Directory ou PowerShell, les deux étant complémentaires pour industrialiser et contrôler les changements.
- Une bonne architecture PSO repose sur quelques règles simples : limiter le nombre de PSO, travailler par groupes de rôles, documenter les priorités et tester avec des comptes pilotes.
- Pour des environnements exposés (IoT, OT, accès distants), les PSO ne suffisent pas : ils complètent une stratégie plus large incluant MFA, durcissement des postes et outils de gestion des mots de passe.
Password Setting Object dans Active Directory : rôle et limites par rapport aux GPO
Pour planter le décor, prenons une PME industrielle fictive, MetalNord, avec un domaine Active Directory unique. Pendant des années, tout le monde a partagé la même politique issue de la Default Domain Policy : 8 caractères, expiration à 90 jours, complexité activée. Le jour où un audit pointe les comptes « Admins du domaine » avec les mêmes contraintes que le standard, la DSI réalise qu’elle a besoin d’outils plus précis que la simple GPO.
Par défaut, la stratégie de mot de passe est définie au niveau du domaine via la GPO associée, souvent la Default Domain Policy. Ce mécanisme reste utile pour poser la base minimale commune et s’assurer que chaque compte est au moins protégé par des règles cohérentes. Le problème, c’est que cette approche « tout le monde au même régime » ne tient plus dès que l’on veut ajuster la sécurité au niveau de risque des comptes. Impossible, par exemple, de durcir uniquement les mots de passe des comptes de production ou de R&D via les GPO classiques, sans jouer avec des OU compliquées.
C’est là que les PSO entrent en jeu. Un Password Setting Object est un objet AD stocké dans le conteneur « Password Settings Container » du nœud System. Il encapsule une stratégie de mot de passe complète (longueur, historique, durée de vie mot de passe, verrouillage, complexité), mais au lieu de s’appliquer à une OU via GPO, il cible directement des utilisateurs ou des groupes AD. Autrement dit, il apporte la granularité qui manque à la GPO de domaine. Ignorer les PSO en 2026, surtout avec la montée des comptes à privilèges et des accès distants, revient à se priver d’un levier de sécurité assez simple à déployer.
Paramètres PSO vs GPO de domaine : même logique, portée différente
Sur le fond, les PSO reprennent quasiment les mêmes réglages que la section « Password Policy » de la GPO : longueur minimale, historique, exigences de complexité mot de passe, âge minimal et maximal, verrouillage de compte. Ce qui change, c’est la façon de les appliquer et la possibilité de jouer sur plusieurs niveaux de durcissement dans le même domaine sans bricoler les OU.
MetalNord a ainsi gardé une GPO de domaine à 8 caractères, puis créé trois PSO : un pour « Admins du domaine » (14 caractères, historique 24, expiration à 30 jours), un pour « Grp_Users_IT » (12 caractères, expiration 60 jours) et un pour un groupe applicatif finance (12 caractères, verrouillage plus strict). Résultat : les équipes sensibles durcissent leur hygiène sans imposer le même niveau de contrainte à tout le monde, ce qui limite la résistance au changement. Les GPO continuent de cadrer le socle, les PSO gèrent les cas critiques.
Attributs PSO : comprendre les réglages qui comptent vraiment
Avant de créer des objets à la chaîne, il vaut mieux comprendre ce que signifient les principaux attributs PSO. Beaucoup d’admins se contentent de recopier la GPO de domaine en durcissant au hasard deux ou trois valeurs, et se retrouvent avec une matrice illisible au bout d’un an. Une bonne approche consiste à lister noir sur blanc ce qu’on veut contrôler, puis à s’appuyer sur ces attributs comme sur une fiche de réglage.
Les champs d’un PSO couvrent trois blocs : la politique de mot de passe (longueur, complexité, historique, âge), le verrouillage de compte et la priorité (Precedence). C’est la combinaison de ces paramètres qui va déterminer le comportement effectif pour chaque utilisateur. L’enjeu n’est pas seulement de durcir, mais de rester compréhensible et maintenable : un PSO incompris finit souvent désactivé au prochain incident d’authentification.
Détail des paramètres de mot de passe et de verrouillage
Dans le Centre d’administration Active Directory, le formulaire d’un Password Setting Object reprend les champs habituels de gestion mot de passe. Chaque paramètre a un impact très concret :
- Enforce minimum password length : nombre minimal de caractères. Pour les comptes admins, rester à 8 n’a plus de sens, viser 12 à 14 est plus cohérent.
- Enforce password history : quantité de mots de passe mémorisés, qui ne peuvent pas être réutilisés. Plus cette valeur est élevée, plus on limite les cycles « ABCD1234!, ABCD1234!! ».
- Password must meet complexity requirements : impose au moins 3 types de caractères sur plusieurs familles (majuscule, minuscule, chiffre, caractère spécial, Unicode), et interdit les mots de passe trop proches du nom du compte.
- Enforce minimum password age et Enforce maximum password age : gèrent la durée de vie mot de passe, autrement dit le délai minimal avant de pouvoir le changer et le délai maximal avant expiration.
- Enforce account lockout policy : configure le nombre d’échecs, la durée de verrouillage et la fenêtre d’observation des tentatives ratées.
Pour MetalNord, l’équipe a par exemple fixé 1 jour d’âge minimal sur les PSO sensibles, pour éviter les enchaînements de changements rapides destinés à contourner l’historique. Les comptes standards, eux, conservent un âge minimal plus souple, afin de ne pas transformer chaque renouvellement en blocage. Cette granularité n’est intéressante que si elle est pensée en fonction des usages, pas pour cocher une case.
Precedence, Directly applies to et protection : les champs qui font la différence
Les champs plus spécifiques aux PSO méritent un arrêt. Precedence définit la priorité du PSO lorsqu’un utilisateur est ciblé par plusieurs objets. Plus la valeur est faible, plus la politique est prioritaire. Si deux PSO ont la même Precedence, c’est le GUID le plus petit qui gagne, ce qui n’est pas franchement parlant pour un humain. Autrement dit, créer plusieurs PSO avec la même Precedence est une mauvaise idée.
Dans la pratique, MetalNord a adopté une convention simple : 1 pour les comptes admin, 10 pour les groupes IT, 50 pour la finance, 99 pour les utilisateurs génériques. Cette échelle lisible évite de se battre avec des Precedence 3, 4, 5 perdus dans l’AD. Le champ Directly applies to permet ensuite d’associer le PSO à des groupes AD ou à des comptes individuels. Dernier détail utile, le flag de protection contre la suppression accidentelle (Protect from accidental deletion) qui évite de faire disparaître un PSO clé lors d’un ménage un peu trop énergique.
| Attribut PSO | Rôle principal | Recommandation courante |
|---|---|---|
| MinPasswordLength | Longueur minimale du mot de passe | 12+ pour comptes sensibles, 10 pour utilisateurs standards |
| PasswordHistoryCount | Nombre d’anciens mots de passe mémorisés | Entre 12 et 24 pour limiter la rotation en boucle |
| MaxPasswordAge | Durée de vie maximale avant expiration | 30 à 60 jours pour admins, 90 à 180 jours pour le reste |
| LockoutThreshold | Nombre d’échecs avant verrouillage | 3 à 5 tentatives, selon la sensibilité du compte |
| Precedence | Priorité en cas de PSO multiples | Échelle lisible (1, 10, 50, 99) documentée dans l’urbanisation AD |
Créer un PSO dans Active Directory : Centre d’administration vs PowerShell
Une fois la cible définie, il faut passer à la configuration. Pour un premier déploiement, l’interface graphique reste utile pour visualiser l’effet de chaque champ. Le Centre d’administration Active Directory (ADAC) propose un chemin assez direct : System, puis « Password Settings Container », puis création d’un nouvel objet de paramètres de mot de passe. Le formulaire demande un nom, une priorité (Precedence), les règles de mot de passe et de verrouillage, puis les groupes ou utilisateurs à qui la politique s’applique.
Pour MetalNord, le premier PSO a été créé de façon très pragmatique : copier les réglages de la GPO de domaine, durcir la longueur à 12, renforcer l’historique à 12, resserrer l’expiration à 60 jours et cibler le groupe « Grp_Users_IT » avec une Precedence de 10. Un compte de test ajouté à ce groupe a permis de vérifier immédiatement que la création d’un mot de passe de 10 caractères échouait, tandis qu’un mot de passe de 12 caractères passait sans problème. Ce genre de test simple donne rapidement confiance dans la mécanique.
Exemple PowerShell pour industrialiser les Password Setting Object
Dès que l’on multiplie les environnements (préproduction, production, filiales), PowerShell devient vite plus rassurant que le clic-clic manuel. La cmdlet clé est New-ADFineGrainedPasswordPolicy, disponible avec le module Active Directory. Elle permet de décrire de manière déclarative un PSO, scriptable et versionnable dans un dépôt Git, ce qui convient bien aux équipes qui aiment tracer les changements.
Pour MetalNord, le PSO des administrateurs de domaine a été créé avec un script ressemblant à ceci :
Exemple PowerShell
New-ADFineGrainedPasswordPolicy « AdminsDuDomaine » `
-ComplexityEnabled $true `
-LockoutDuration « 00:45:00 » `
-LockoutObservationWindow « 00:45:00 » `
-LockoutThreshold 3 `
-MaxPasswordAge « 30.00:00:00 » `
-MinPasswordAge « 1.00:00:00 » `
-MinPasswordLength 14 `
-PasswordHistoryCount 24 `
-Precedence 1 `
-ReversibleEncryptionEnabled $false `
-ProtectedFromAccidentalDeletion $true
Une fois la politique créée, il suffit de la lier à un groupe ou à un compte utilisateur avec Add-ADFineGrainedPasswordPolicySubject :
Add-ADFineGrainedPasswordPolicySubject « AdminsDuDomaine » -Subjects « Admins du domaine »
Ce couplage GUI/PowerShell est sain : l’interface pour comprendre, le script pour déployer et rejouer en cas de reconstruction ou de nouveau domaine. Ce n’est pas très différent de ce qu’on ferait pour protéger les mots de passe administrateur Windows sur un parc de serveurs distants.
Identifier quel PSO s’applique réellement à un compte utilisateur
Créer des PSO, c’est une chose. Savoir lequel s’applique à un utilisateur bien précis, surtout quand il appartient à plusieurs groupes, en est une autre. C’est souvent à ce moment-là que les équipes découvrent des priorités mal pensées ou des associations oubliées. L’ADAC fournit heureusement une vue « résultante » très pratique pour lever les doutes.
Sur un utilisateur donné, un clic droit permet d’afficher les « paramètres de mot de passe résultants ». La console énumère alors la politique effectivement appliquée, en tenant compte des PSO directs et de ceux hérités via les groupes AD. MetalNord a ainsi découvert un vieux PSO de test qui traînait sur un groupe technique, avec une Precedence plus forte que prévu, ce qui expliquait des messages d’erreur difficiles à reproduire chez certains techniciens.
Contrôler les stratégies au niveau des groupes et scripts d’audit
Le même travail peut être fait côté groupes : dans les propriétés d’un groupe, la section « Paramètres de mot de passe directement associés » liste les PSO liés. C’est un bon point de contrôle pour s’assurer qu’un groupe critique (comme un rôle applicatif d’ERP) ne traîne pas avec un PSO trop laxiste ou, au contraire, inutilement dur pour les utilisateurs concernés.
Pour aller plus loin, MetalNord a mis en place un script PowerShell hebdomadaire qui exporte la liste des PSO, leurs attributs PSO, les cibles associées et la Precedence, vers un rapport CSV. Ce rapport est ensuite versé dans un tableau de bord maison, au même titre que d’autres indicateurs de bonnes pratiques de sécurité. L’objectif n’est pas d’ajouter une couche de bureaucratie, mais d’éviter que des changements hâtifs en période de crise ne restent invisibles pendant des années.
Bonnes pratiques pour organiser ses PSO dans un domaine Active Directory
La tentation, une fois l’outil découvert, est de créer un PSO par cas particulier : un pour la compta, un pour chaque projet, un pour chaque chef de service… On se retrouve alors avec une grille illisible que plus personne n’ose toucher. Pour garder le contrôle, mieux vaut poser une règle d’or : limiter le nombre de PSO et les aligner sur des « rôles de sécurité », pas sur des individus ou des organigrammes mouvants.
Pour MetalNord, trois grandes familles de PSO ont suffi : comptes à privilèges (admin domaine, admin applicatif), comptes d’exploitation (équipes IT, supervision, exploitation industrielle) et comptes utilisateurs métiers sensibles (finance, RH). Chaque famille a ses paramètres de complexité mot de passe, de longueur et de durée de vie mot de passe adaptés, décrits dans un document d’architecture qui vit en même temps que le reste du référentiel AD.
Checklist pratique avant de déployer ou modifier un Password Setting Object
Pour rester pragmatique, une vérification rapide évite beaucoup de surprises. Une équipe qui manipule des PSO sans garde-fous finit toujours par provoquer un incident d’authentification dans un moment critique. Voici une grille simple qui fonctionne plutôt bien sur le terrain :
- Vérifier que le PSO cible bien un groupe de rôle, pas un individu (sauf exception très justifiée).
- Confirmer que la Precedence respecte la convention interne (par exemple 1 pour les admins, 10 pour l’IT, etc.).
- Tester la création et la modification de mots de passe avec un compte pilote rattaché au groupe, en forçant un mot de passe invalide puis valide.
- Documenter en une phrase la raison d’être du PSO (qui, quoi, pourquoi) dans le champ Description.
- Planifier un contrôle périodique des PSO, au même titre que les revues d’habilitation ou les audits de comptes à privilèges.
Cette discipline paraît un peu lourde au départ, mais elle paye dès le premier incident évité. Et elle s’intègre assez bien dans une approche plus large où l’AD n’est qu’une brique : ailleurs dans le SI, on retrouve la même logique de rôles pour les passerelles, les accès VPN ou les systèmes d’authentification fédérée.
À quoi sert concrètement un Password Setting Object dans Active Directory ?
Un Password Setting Object (PSO) permet de définir une stratégie de mot de passe plus fine que la GPO de domaine, en ciblant directement des utilisateurs ou des groupes AD. On peut ainsi appliquer des règles plus strictes aux comptes à privilèges (longueur minimale plus élevée, historique renforcé, expiration plus rapide, verrouillage plus strict) sans imposer ces contraintes à tous les utilisateurs du domaine. Les PSO complètent la GPO de base, ils ne la remplacent pas.
Comment fonctionne la priorité entre plusieurs PSO qui ciblent le même utilisateur ?
La priorité est gérée par l’attribut Precedence des PSO. Plus la valeur de Precedence est faible, plus le PSO est prioritaire. Si un utilisateur est visé par plusieurs PSO (directement ou via plusieurs groupes), c’est la stratégie avec la plus petite Precedence qui s’applique. En cas d’égalité, le PSO avec le GUID le plus petit l’emporte, ce qui reste peu lisible, d’où l’intérêt de garder des valeurs de Precedence uniques et documentées.
Comment vérifier quelle stratégie de mot de passe s’applique à un utilisateur donné ?
Dans le Centre d’administration Active Directory (ADAC), un clic droit sur l’utilisateur permet d’afficher les paramètres de mot de passe résultants. Cette vue montre la stratégie effectivement appliquée, en tenant compte de la GPO de domaine et des PSO associés aux groupes. On peut aussi interroger les PSO avec PowerShell et reconstruire la règle résultante, utile pour des audits ou des rapports automatisés.
Peut-on gérer tous les PSO uniquement avec PowerShell ?
Oui, l’ensemble du cycle de vie des PSO peut être géré en PowerShell via les cmdlets New-ADFineGrainedPasswordPolicy, Set-ADFineGrainedPasswordPolicy, Remove-ADFineGrainedPasswordPolicy et Add-ADFineGrainedPasswordPolicySubject. C’est même recommandé dès que l’on veut versionner les changements, reproduire une configuration entre plusieurs environnements ou générer des rapports réguliers. L’interface graphique reste utile pour l’exploration et la compréhension initiale.
Les PSO suffisent-ils pour sécuriser les mots de passe dans un environnement moderne ?
Les PSO améliorent clairement la granularité des politiques de mots de passe dans Active Directory, surtout pour les comptes à privilèges. Mais ils ne suffisent pas à eux seuls dans un contexte où les attaques passent souvent par le phishing et la réutilisation de mots de passe. Ils doivent être combinés avec du MFA, des coffres-forts de mots de passe pour les comptes techniques, une surveillance des connexions anormales et une hygiène globale du poste client, y compris sur les accès distants et les systèmes IoT exposés.