Utilisateur AD ne peut pas changer son mot de passe : audit

Utilisateur AD ne peut pas changer son mot de passe : quel est ce paramètre ?

Pour diagnostiquer le cas utilisateur AD ne peut pas changer son mot de passe, examinez la liste de contrôle d’accès discrétionnaire (DACL) de l’utilisateur avant de modifier la stratégie de mots de passe du domaine. Le droit étendu Change Password peut lui être refusé. Il s’agit d’une restriction de contrôle d’accès au changement de mot de passe en libre-service, distincte de la possibilité pour un administrateur de réinitialiser le mot de passe.

Commencez par le compte exact et l’opération qui a échoué. Consignez si la personne a tenté de changer son propre mot de passe ou demandé à un opérateur du support d’en définir un nouveau. Une réinitialisation administrative réussie ne démontre pas que le changement par l’utilisateur est autorisé. De même, un échec de ce changement n’identifie pas à lui seul une ACE Deny comme cause : il faut encore lire la DACL.

Ce guide examine une condition précise de permission, sans prescrire une nouvelle durée de validité ou longueur des mots de passe. Séparez la revue plus large de la stratégie : la sécurité des mots de passe Active Directory couvre les stratégies de domaine, l’expiration, les paramètres des comptes et le stockage des identifiants. Modifier ces contrôles ne remplace pas l’identification des ACE applicables au compte examiné.

Fonctionnement : permission de changement personnel et réinitialisation administrative

Microsoft identifie le droit étendu User-Change-Password par le nom d’affichage Change Password et le GUID ab721a53-1e2f-11d0-9819-00aa0040529b. Les preuves pertinentes se trouvent dans le descripteur de sécurité de l’objet utilisateur. Ne déduisez pas cet état d’un simple test de bit userAccountControl : la condition du collecteur examinée ici n’utilise pas cet attribut.

La procédure de modification LDAP de Microsoft décrit une configuration standard avec des ACE spécifiques à un objet pour deux mandataires : Everyone et SELF. Le refus de la permission utilise ADS_ACETYPE_ACCESS_DENIED_OBJECT ; son octroi utilise le type Allow spécifique à un objet correspondant.

Élément à consigner	Valeur pour cette revue	Pourquoi il compte
Type d’objet	`ab721a53-1e2f-11d0-9819-00aa0040529b`	Identifie Change Password plutôt qu’une autre permission d’objet
Mandataire Everyone	`S-1-1-0`	Un des mandataires acceptés par le prédicat du collecteur
Mandataire SELF	`S-1-5-10`	L’autre mandataire accepté par ce prédicat
Sens de l’ACE	Deny	Une entrée Allow ne satisfait pas le détecteur
Cible	Nom distinctif exact de l’utilisateur	Permet d’associer la preuve au bon compte

Préservez la distinction entre la configuration documentée et la condition du détecteur. L’exemple de lecture Microsoft reconnaît l’état standard de refus lorsque les ACE des deux mandataires sont Deny. Le collecteur utilise une condition OR : une entrée Deny correspondante pour l’un ou l’autre mandataire suffit à son prédicat. Consignez une seule ACE correspondante comme une condition portant sur un seul mandataire à examiner ; ne la décrivez pas comme la configuration complète à deux ACE de l’exemple Microsoft.

La réinitialisation administrative du mot de passe pose une question de permission distincte. L’article ResetNightmare traite d’un exploit d’opération de mot de passe Kerberos et de sa distinction avec les droits Reset Password délégués. Il aide à séparer les opérations, sans prouver que cette restriction de changement personnel cause cet exploit. Évaluez cette exposition distincte à partir des prérequis et des recommandations de remédiation de l’article lié.

Détection : lire la DACL indépendamment

Étape 1 : choisir un compte et préserver le contexte

Utilisez le nom distinctif du compte plutôt qu’un nom d’affichage supposé. Notez le propriétaire du compte, son état activé ou désactivé, son usage métier, le contrôleur de domaine interrogé et l’heure de l’inspection. Incluez les comptes désactivés dans l’inventaire si vous le rapprochez de ce prédicat du collecteur : Detect() n’a pas de filtre Disabled. L’état du compte peut influencer la priorité de remédiation, mais ne doit pas retirer silencieusement une entrée de la revue des permissions.

Pour une identité de service, identifiez le responsable des changements de mot de passe avant de qualifier la restriction d’indésirable. Il faut déterminer si la restriction est intentionnelle et soutenue par un processus avec un responsable identifié. La seule étiquette de compte de service ne justifie pas une exception.

Étape 2 : récupérer et filtrer les règles d’accès

La procédure de lecture LDAP de Microsoft lit ntSecurityDescriptor, récupère sa DACL, puis examine ObjectType, le mandataire et AceType. Elle avertit aussi que les noms des mandataires sont localisés. Comparez les SID bien connus au lieu de coder en dur des noms de comptes anglais.

L’adaptation PowerShell en lecture seule suivante utilise ADSI via .NET sur un poste d’administration Windows. Remplacez le contrôleur de domaine et le DN d’exemple par des valeurs vérifiées. Elle lit directement le descripteur de sécurité de l’annuaire, hors de l’analyseur d’ACL du collecteur. Ces commandes n’ont pas été exécutées sur un domaine pour cet article.

Add-Type -AssemblyName System.DirectoryServices
$dc = 'dc01.example.test'
$dn = 'CN=Example User,OU=Users,DC=example,DC=test'
$entry = New-Object -TypeName System.DirectoryServices.DirectoryEntry -ArgumentList "LDAP://$dc/$dn"
$entry.psbase.Options.SecurityMasks = [System.DirectoryServices.SecurityMasks]::Dacl
$descriptor = $entry.psbase.ObjectSecurity
$rules = @($descriptor.GetAccessRules(
    $true, $true, [System.Security.Principal.SecurityIdentifier]
))
$changePassword = [guid]'ab721a53-1e2f-11d0-9819-00aa0040529b'
$matchingDenies = @($rules | Where-Object {
    $_.ObjectType -eq $changePassword -and
    $_.AccessControlType -eq [System.Security.AccessControl.AccessControlType]::Deny -and
    $_.IdentityReference.Value -in @('S-1-1-0', 'S-1-5-10')
})
$matchingDenies | Select-Object IdentityReference, ObjectType,
    AccessControlType, ActiveDirectoryRights, IsInherited,
    InheritanceType, InheritanceFlags, PropagationFlags | Format-List
$entry.psbase.Dispose()

Les références d’API documentent ObjectSecurity, SecurityMasks et GetAccessRules. Les règles explicites et héritées sont toutes deux demandées, et les identités des mandataires sont renvoyées sous forme de SID. Gardez les règles non filtrées disponibles pour une revue plus large de la DACL ; le filtre sélectionne délibérément la seule condition de cet article.

Si la liaison ou la récupération du descripteur de sécurité échoue, conservez l’erreur et marquez le compte comme non inspecté. Une DACL illisible n’est pas une DACL vide. Ne remplacez pas un échec d’inspection par un résultat apparemment réussi et sans anomalie.

Étape 3 : interpréter la forme sans exagérer le résultat

Résultat observé	Ce qu’il faut consigner	Action suivante
Everyone et SELF ont tous deux des entrées Deny spécifiques à un objet correspondantes	Configuration possible de refus pour les deux mandataires	Confirmer le droit de contrôle d’accès et l’applicabilité des règles, puis examiner l’intention avant un changement ciblé
Un seul mandataire a une entrée Deny correspondante	Condition à un seul mandataire acceptée par le prédicat du détecteur	Inspecter la DACL complète ; ne pas l’écarter parce que l’autre entrée est absente
Aucune entrée Deny correspondante après une lecture réussie	Cette condition précise n’a pas été trouvée	Poursuivre le diagnostic ; ce n’est pas un verdict complet sur l’accès effectif ou la stratégie de mots de passe
La DACL n’a pas pu être récupérée	Preuves manquantes	Résoudre l’échec de lecture avant de conclure

La sortie comprend les droits et les informations d’héritage pour permettre d’examiner l’applicabilité. Le filtre ne teste ni le masque d’accès ni l’applicabilité de l’héritage. Avant de classer une paire comme la configuration standard Microsoft, comparez-la au masque ADS_RIGHT_DS_CONTROL_ACCESS et aux indicateurs d’ACE de la procédure de modification. Il s’agit d’un inventaire ciblé des ACE, pas d’une implémentation complète du contrôle d’accès Windows. Les permissions larges, les autres mandataires et les configurations d’ACL non standard nécessitent une évaluation supplémentaire. Ne comptez pas deux ACE correspondantes sur un même compte comme deux comptes affectés, ni plusieurs lectures du même DN comme des identités différentes.

Remédiation : rétablir le changement personnel uniquement pour les comptes approuvés (Remediation)

Étape 1 : documenter l’intention et l’état initial

Attribuez un responsable à chaque compte examiné et conservez les preuves de la DACL avant de la modifier. Consignez si le changement personnel doit être disponible, qui a approuvé la décision et quelle dépendance opérationnelle doit être vérifiée. Si une restriction est conservée, documentez sa justification métier, l’équipe responsable, la procédure de gestion des mots de passe et le point de réexamen. Évitez d’accorder ou de retirer des permissions sur toute une OU au seul motif qu’un utilisateur a signalé un échec.

Examinez les règles explicites et héritées avant de choisir la modification. Si la restriction provient d’une règle héritée, identifiez son origine et la population affectée. Soumettez cette décision de périmètre au responsable de l’annuaire au lieu de traiter une modification au niveau parent comme une correction individuelle.

Étape 2 : effectuer un changement ciblé

Microsoft documente CannotChangePassword dans Set-ADAccountControl. Son exemple décrit la modification du descripteur de sécurité de l’utilisateur. L’adaptation suivante retire la restriction pour un seul compte approuvé ; prévisualisez-la d’abord avec -WhatIf.

Set-ADAccountControl -Identity 'CN=Example User,OU=Users,DC=example,DC=test' -Server 'dc01.example.test' -CannotChangePassword $false -WhatIf

Une fois la cible et le changement approuvés, exécutez l’opération sur ce compte individuel avec confirmation :

Set-ADAccountControl -Identity 'CN=Example User,OU=Users,DC=example,DC=test' -Server 'dc01.example.test' -CannotChangePassword $false -Confirm

Ce sont des adaptations de commandes documentées, pas des commandes exécutées durant cette revue. Une prévisualisation ne prouve pas que l’écriture ultérieure a réussi. Capturez le résultat de l’opération réelle et recherchez les erreurs avant de passer à la validation.

Pour une implémentation LDAP personnalisée, suivez la procédure de modification Microsoft : trouvez les entrées Change Password des deux mandataires, remplacez leur AceType spécifique à un objet par Allow, ajoutez les entrées manquantes avec le masque de contrôle d’accès et l’indicateur de type d’objet documentés, puis écrivez et validez le descripteur de sécurité. Suivez l’étape d’ordonnancement des ACL lors de la création d’entrées. Ne remplacez pas toute la DACL par une paire minimale de règles et ne supprimez pas les permissions sans rapport pour faire paraître le compte conforme.

Étape 3 : relire et vérifier l’opération prévue

Après l’écriture, récupérez à nouveau le descripteur de sécurité et répétez la procédure de lecture Microsoft. Comparez les deux mandataires, le GUID et l’AceType à l’état initial. Gardez visibles les restrictions héritées restantes. Une réponse de commande réussie est un artefact intermédiaire ; la DACL après modification constitue la preuve de permission.

Organisez ensuite une vérification contrôlée du changement personnel par le propriétaire du compte, avec le parcours habituel de changement de mot de passe. Conservez ce résultat séparément de celui de la DACL. Si l’opération échoue encore, examinez l’erreur réelle et les autres contrôles applicables au lieu de modifier l’ACL à répétition ou d’affaiblir la stratégie de domaine. Une réinitialisation par le support n’est pas l’étape de vérification du rétablissement du changement personnel.

Comment EtcSec détecte cette condition

L’identifiant de catalogue de cette condition est USER_CANNOT_CHANGE_PASSWORD. Dans l’implémentation cannot-change.go examinée, Detect() analyse les entrées d’ACL fournies et sélectionne celles présentant :

un ObjectType égal au GUID Change Password, comparé sans tenir compte de la casse ;
un AceType contenant DENIED après conversion en majuscules ;
un mandataire égal à Everyone S-1-1-0 ou SELF S-1-5-10.

Le détecteur convertit en minuscules les DN des objets sélectionnés dans une map, puis les rapproche des DN des utilisateurs. Cela déduplique les ACE correspondantes par DN de compte avant de construire la liste des utilisateurs affectés. Le Count du constat provient de cette liste, sans filtre Disabled. Une ACE Allow ne satisfait pas le prédicat, et l’implémentation ne lit pas de drapeau userAccountControl pour établir cette condition. Elle ne teste pas non plus le masque d’accès ni l’applicabilité de l’héritage : une correspondance du prédicat ne constitue donc pas à elle seule un verdict complet d’accès effectif.

La limite actuelle se situe à la frontière de collecte. Dans public/internal/providers/ldap/acl_parser.go, parseACE() n’accepte que les types d’ACE ACCESS_ALLOWED et ACCESS_ALLOWED_OBJECT. Les autres types renvoient nil, y compris les ACE Deny nécessaires ici. Un prédicat correct sur des entrées fournies n’établit pas que la détection fonctionne par le chemin de collecte LDAP. Cet article ne revendique aucun test du collecteur de bout en bout ni validation sur un domaine réel.

Que conserver dans le dossier de revue ?

Pour chaque compte, préservez le DN exact, le contrôleur interrogé, l’horodatage, les SID des mandataires correspondants, ObjectType, le sens Deny ou Allow, les droits et le contexte d’héritage. Conservez les erreurs d’inspection au lieu d’écarter les lectures échouées. Associez les états avant et après à la même identité, avec l’approbation du changement ou le responsable de l’exception.

La décision de clôture doit préciser ce qui a été établi : restriction conservée avec une raison documentée, permission modifiée et relue indépendamment, ou investigation complémentaire encore ouverte. Consignez un résultat fonctionnel de changement personnel uniquement si cette vérification a réellement été effectuée. Ne transformez pas cette revue de sources, un exemple de commande, une opération de réinitialisation ou un décompte nul du collecteur en preuve d’une rotation en libre-service réussie.