Dans Active Directory, la stratégie de mot de passe définie pour le domaine ne répond pas toujours aux besoins de chaque compte. Les Password Settings Objects, ou PSO, permettent d’appliquer des règles différentes à des utilisateurs ou à des groupes précis, sans multiplier les stratégies de groupe. Comptes d’administration, comptes de service et collaborateurs peuvent ainsi relever de paramètres distincts de longueur, d’historique ou de verrouillage.
La souplesse a toutefois ses pièges. Une PSO mal ciblée, deux priorités identiques ou un groupe dont l’étendue ne convient pas peuvent produire un résultat différent de celui attendu. Ce guide explique le fonctionnement des objets de paramètres de mot de passe, leur création dans le Centre d’administration Active Directory ou avec PowerShell, puis les méthodes à utiliser pour vérifier leur application et organiser leur maintenance.
En bref
- Une PSO complète la stratégie du domaine et s’applique à des utilisateurs ou à des groupes de sécurité.
- La valeur de précédence la plus faible l’emporte lorsque plusieurs stratégies peuvent s’appliquer.
- Des priorités distinctes évitent de laisser le choix de la stratégie effective à un arbitrage secondaire.
- PowerShell permet de créer, attribuer et auditer les PSO de façon reproductible.
- La réplication des stratégies entre contrôleurs de domaine doit être prise en compte après chaque modification.
Objet de paramètres de mot de passe : rôle et fonctionnement dans Active Directory
Un Objet de paramètres de mot de passe, ou Password Settings Object (PSO), est un objet Active Directory qui contient des règles relatives aux mots de passe et au verrouillage des comptes. Il permet de définir une Stratégie de mot de passe affinée pour certains comptes, plutôt que d’imposer les mêmes paramètres à tous les utilisateurs du domaine.
La stratégie de mot de passe par défaut du domaine reste le comportement de référence. Une PSO ne la remplace pas pour tout l’annuaire : elle s’applique aux utilisateurs ou aux groupes qu’elle cible. Si aucun objet correspondant ne s’applique à un compte, celui-ci reste soumis à la politique de domaine habituelle.
Cette différence compte au moment de choisir l’outil. Une GPO liée à une unité d’organisation ne permet pas de créer plusieurs politiques de mots de passe distinctes pour les utilisateurs de cette unité. Les règles de mot de passe du domaine sont définies dans la stratégie du domaine, tandis que les PSO servent à affiner ces règles pour des groupes ou des comptes précis.
Quels paramètres peut-on définir dans une PSO ?
Une PSO peut notamment définir la longueur minimale du mot de passe, l’historique des mots de passe, les exigences de complexité, l’âge minimal et maximal du mot de passe, ainsi que les paramètres de verrouillage. Ce dernier ensemble comprend le seuil d’échecs, la durée du verrouillage et la période d’observation des tentatives infructueuses.
Par exemple, une entreprise fictive appelée Atelier Nord peut appliquer une stratégie de 16 caractères minimum aux comptes d’administration, une politique différente à ses comptes de service et une troisième règle à ses employés. Le principe n’est pas de créer une PSO par personne, mais de traduire des besoins opérationnels en catégories faciles à administrer.
Un compte de service ne se gère pas comme un compte utilisé chaque matin par une personne. Avant de fixer une règle, il faut donc vérifier les méthodes d’authentification et les dépendances applicatives. Un changement de mot de passe ou une expiration mal anticipée peut interrompre une tâche planifiée ou un service, même si la PSO est techniquement valide.
Conditions et portée d’application
Les stratégies de mots de passe affinées sont prises en charge lorsque le niveau fonctionnel du domaine est au moins Windows Server 2008. La gestion s’effectue notamment avec le Centre d’administration Active Directory et le module PowerShell Active Directory.
Une PSO peut viser directement un utilisateur, mais le ciblage par groupes de sécurité est généralement plus facile à maintenir. Dans la configuration courante, le groupe cible doit être un groupe de sécurité global. Il faut éviter de supposer qu’un groupe de portée différente fonctionnera simplement parce qu’une commande permet de l’inscrire dans l’attribut de ciblage.
À retenir : une PSO est une règle attachée à des objets précis, pas une GPO liée à une unité d’organisation. Cette distinction explique à la fois sa souplesse et ses limites.
Priorité des stratégies : choisir la PSO réellement appliquée
Un utilisateur peut être concerné par plusieurs PSO, par exemple parce qu’il appartient à différents groupes de ciblage. Active Directory doit alors déterminer quelle règle est effective. La valeur de précédence, souvent appelée priorité, sert à départager les objets : la valeur numérique la plus faible est prioritaire. Les valeurs possibles vont de 1 à 1 024.
Si un compte appartient à un groupe « Administrateurs » associé à une priorité de 10 et à un groupe « Employés » associé à une priorité de 40, la PSO de priorité 10 l’emporte. Il est donc utile de réserver les valeurs basses aux règles les plus strictes ou aux catégories qui doivent être traitées en premier.
Quand plusieurs PSO ont la même valeur, Active Directory applique un mécanisme de départage fondé sur le GUID des objets. Ce comportement est déterministe, mais il ne constitue pas une méthode d’organisation. Une administration qui dépend de GUID générés automatiquement devient difficile à lire et à auditer. Mieux vaut donner une précédence distincte à chaque PSO utile.
Établir une hiérarchie facile à relire
Un plan de priorité doit être compréhensible par la personne qui reprendra l’annuaire dans six mois. Des écarts entre les valeurs laissent une marge pour ajouter une catégorie sans devoir renuméroter toutes les stratégies. À titre d’exemple, une organisation peut réserver les valeurs 1 à 9 aux comptes très sensibles, puis utiliser des intervalles de dix pour les autres profils.
| Catégorie de comptes | Exemple de priorité | Longueur minimale indicative |
|---|---|---|
| Comptes de service | 1 | À définir selon les applications et le type de compte |
| Administrateurs | 10 | 16 caractères ou davantage selon la politique retenue |
| Équipe technique | 20 | 14 caractères |
| Comptes externes | 30 | 12 caractères |
| Employés | 40 | Selon les exigences de l’organisation |
Ces valeurs sont un exemple de classement, pas une configuration universelle. Le minimum pertinent dépend de la politique de sécurité, des mécanismes d’authentification complémentaires et des usages. Il faut aussi garder en tête que les règles de longueur et de complexité sont évaluées au changement de mot de passe : augmenter le minimum ne transforme pas rétroactivement les mots de passe déjà définis.
Certains paramètres ont un effet immédiat sur le compte, notamment les règles de verrouillage applicables. D’autres, comme les exigences de longueur, interviennent lorsqu’un nouveau mot de passe est choisi. Cette différence rend l’audit moins direct : Active Directory permet de connaître la stratégie résultante, mais pas de lire les mots de passe ni d’en déduire leur longueur actuelle.
Les cas de ciblage qui surprennent
Un même groupe peut être associé à plusieurs PSO. Dans ce cas, la valeur de précédence départage les objets. Il est également possible qu’un utilisateur soit membre de plusieurs groupes ciblés ; l’appartenance imbriquée peut donc produire une stratégie effective moins évidente à identifier à partir de la seule liste des groupes directs.
Un utilisateur peut aussi recevoir une PSO directement. L’affectation directe et les affectations par groupe doivent être vérifiées avec les outils de résultat effectif, plutôt que déduites manuellement de l’organisation des unités d’organisation. Une lecture rapide de l’arborescence ne suffit pas à répondre à la question « quelle règle s’applique à ce compte ? ».
Position pratique : ne laisse pas des priorités identiques en production sous prétexte que le résultat actuel semble correct. Un changement d’appartenance ou l’ajout d’une PSO peut révéler un arbitrage que personne n’avait prévu.
Création d’objet PSO avec le Centre d’administration ou PowerShell
La Création d’objet peut se faire dans le Centre d’administration Active Directory ou par PowerShell. L’interface graphique est pratique pour une opération ponctuelle et pour relire les champs disponibles. PowerShell est plus adapté aux environnements où les réglages doivent être documentés, répétés ou contrôlés dans un script.
Créer la stratégie dans le Centre d’administration Active Directory
Dans le Centre d’administration Active Directory, ouvre le domaine, puis le conteneur System et Password Settings Container. L’action de création d’un objet de paramètres de mot de passe affiche les champs de configuration et la liste des utilisateurs ou des groupes à cibler.
Donne un nom explicite à la PSO, choisis une précédence unique, puis renseigne les paramètres de mot de passe et de verrouillage en fonction du profil concerné. Ajoute de préférence un groupe de sécurité prévu à cet effet plutôt qu’une longue série d’utilisateurs. Cette approche réduit les oublis lorsqu’une personne change d’équipe ou qu’un compte est créé.
Avant de valider, vérifie notamment la longueur minimale, l’historique, la complexité, les durées et le seuil de verrouillage. L’option de chiffrement réversible ne doit pas être activée sans besoin applicatif clairement documenté : elle augmente l’exposition des secrets et ne doit pas servir de raccourci pour contourner un problème d’authentification.
Créer et affecter une PSO avec PowerShell
Le module Active Directory expose les commandes New-ADFineGrainedPasswordPolicy, Add-ADFineGrainedPasswordPolicySubject, Set-ADFineGrainedPasswordPolicy et Get-ADFineGrainedPasswordPolicy. Une création simplifiée peut ressembler à ceci :
New-ADFineGrainedPasswordPolicy -Name « PSO-Administrateurs » -Precedence 10 -MinPasswordLength 16 -PasswordHistoryCount 24 -ComplexityEnabled $true -ReversibleEncryptionEnabled $false -ProtectedFromAccidentalDeletion $true
Les paramètres de durée PowerShell suivent un format de type jours.heures:minutes:secondes. Il faut donc vérifier la valeur exacte avant de lancer une commande en production, surtout pour les fenêtres d’observation et les durées de verrouillage. Une valeur exprimée dans le mauvais format peut créer une politique différente de celle prévue ou provoquer une erreur.
Une fois l’objet créé, associe-le au groupe voulu, par exemple avec Add-ADFineGrainedPasswordPolicySubject -Identity « PSO-Administrateurs » -Subjects « Groupe-Administrateurs ». Le nom du groupe doit correspondre à un groupe de sécurité approprié. Pour modifier ensuite les paramètres, utilise Set-ADFineGrainedPasswordPolicy, puis relis la configuration avec Get-ADFineGrainedPasswordPolicy.
Dans un script destiné à plusieurs environnements, évite de coder en dur des noms de domaine ou des identifiants supposés universels. Prévois des paramètres, teste d’abord dans un domaine de préproduction et conserve le résultat de la configuration. Une commande réussie confirme la création de l’objet ; elle ne prouve pas que le bon utilisateur reçoit effectivement cette stratégie.
Le contrôle à ne pas sauter : après la création, vérifie l’affectation au groupe, la précédence et le résultat sur un compte représentatif. La configuration affichée et la politique appliquée sont deux choses différentes.
Gestion des mots de passe : auditer la PSO effective et sa réplication
La Gestion des mots de passe ne s’arrête pas à la création des objets. Une politique doit être contrôlée dans son contexte réel : quels comptes la reçoivent, quelle PSO l’emporte et si les changements ont été répliqués aux contrôleurs de domaine concernés. Sans cet audit, une erreur de ciblage peut rester invisible jusqu’à un changement de mot de passe ou à un verrouillage.
Identifier la stratégie effective d’un utilisateur
Pour examiner un compte précis, la commande Get-ADUserResultantPasswordPolicy donne la stratégie résultante :
Get-ADUserResultantPasswordPolicy -Identity « jdupont »
Si la commande ne retourne pas de PSO, l’utilisateur relève de la stratégie de mot de passe du domaine. Pour un contrôle par attribut, la propriété msDS-ResultantPSO indique le nom distinctif de l’objet résultant lorsqu’une PSO s’applique.
Pour lire l’expiration calculée, interroge l’attribut msDS-UserPasswordExpiryTimeComputed. Sa valeur est un FileTime Windows, qu’il faut convertir en date avec PowerShell. Une valeur vide peut signaler que le mot de passe n’expire pas ; elle doit être interprétée avec les paramètres effectifs du compte et non isolément.
Repérer les comptes concernés et les chevauchements
Un inventaire global aide à repérer les comptes sans PSO dédiée et les stratégies qui ne ciblent personne. L’attribut résultant peut être regroupé pour obtenir une répartition, tandis que les appartenances de groupe servent à repérer les utilisateurs exposés à plusieurs politiques. L’objectif n’est pas de supprimer automatiquement les chevauchements : certains sont attendus, à condition que les précédences soient cohérentes.
Pour chaque PSO, documente son objectif, son groupe cible, sa valeur de précédence, son propriétaire technique et la date de sa dernière revue. Cette documentation est particulièrement utile pour les comptes de service, car leurs dépendances sont parfois connues d’une seule équipe. Une PSO oubliée dans le conteneur peut continuer à influencer des comptes longtemps après le changement d’application.
La Réplication des stratégies suit le mécanisme de réplication Active Directory. Après une modification, tous les contrôleurs de domaine ne présentent pas nécessairement la nouvelle valeur au même instant. En cas de comportement divergent, vérifie le contrôleur interrogé et l’état de réplication avant de conclure que la PSO ne fonctionne pas.
Pour une équipe informatique, un audit utile peut s’appuyer sur une courte liste de vérification :
- Confirmer le groupe cible et son étendue de sécurité.
- Vérifier la précédence et rechercher les valeurs dupliquées.
- Interroger la stratégie résultante pour plusieurs comptes de test.
- Comparer la configuration sur les contrôleurs de domaine concernés.
- Contrôler les paramètres de verrouillage et leurs effets sur les applications.
Évite de confondre audit de politique et audit du secret lui-même. Les attributs Active Directory permettent de contrôler les paramètres et certaines dates, mais ils ne révèlent pas la longueur ou le contenu des mots de passe existants. Pour aller plus loin, il faut une démarche de sécurité distincte, encadrée et compatible avec les règles de l’organisation.
Une PSO bien gérée se reconnaît moins à la quantité de règles qu’à la facilité avec laquelle l’équipe peut expliquer leur portée. Quand un administrateur peut retrouver rapidement le groupe, la précédence et le résultat effectif, l’annuaire reste compréhensible même après plusieurs évolutions.
FAQ sur les Password Setting Objects dans Active Directory
Une PSO remplace-t-elle la stratégie de mot de passe du domaine ?
Non. Une PSO ne s’applique qu’aux comptes ou groupes qu’elle cible. En l’absence de stratégie affinée applicable, le compte utilise la politique de mot de passe du domaine.
Comment savoir quelle PSO s’applique à un utilisateur ?
Utilise Get-ADUserResultantPasswordPolicy avec l’identité du compte. L’attribut msDS-ResultantPSO permet également d’identifier la stratégie résultante lorsqu’une PSO s’applique.
Que se passe-t-il si deux PSO ont la même priorité ?
Active Directory départage les objets à l’aide du GUID. Ce mécanisme ne doit pas servir de méthode de gestion : attribue une valeur de précédence distincte à chaque PSO pour garder un ordre explicite.
Peut-on appliquer une PSO à une unité d’organisation ?
Non. Une PSO cible directement un utilisateur ou un groupe de sécurité, elle ne se lie pas à une unité d’organisation comme une GPO. Le ciblage par groupe est généralement plus facile à maintenir.
Pourquoi un changement de longueur minimale ne modifie-t-il pas les mots de passe existants ?
La longueur minimale est vérifiée lorsque l’utilisateur définit un nouveau mot de passe. La modification de la PSO n’allonge pas et ne remplace pas les mots de passe déjà enregistrés.
