Rotation du mot de passe avec carte à puce Active Directory

Rotation du mot de passe avec carte à puce dans Active Directory

La rotation du mot de passe avec carte à puce dans Active Directory est importante, car ces comptes conservent un secret de mot de passe réseau. Sans renouvellement automatique du mot de passe, le secret aléatoire créé par Windows peut persister jusqu’à sa modification explicite. L’affirmation selon laquelle il « ne change jamais par défaut » exige une précision immédiate : Microsoft documente l’activation du renouvellement pour les nouveaux domaines, tandis que les domaines existants nécessitent une configuration. Il faut donc considérer ce risque dans les domaines où le renouvellement est absent ou désactivé, plutôt que comme une propriété universelle d’Active Directory moderne. La documentation Microsoft des fonctionnalités de Windows Server 2016 établit cette distinction.

L’option du compte et le paramètre de rotation du domaine répondent à des questions différentes. La première détermine si l’utilisateur doit employer une carte à puce pour l’ouverture de session interactive initiale, y compris via Bureau à distance. Le second régit l’entretien du secret fondé sur un mot de passe qui reste pertinent pour l’authentification réseau. Un examen limité à la case cochée du compte laisse la seconde question sans réponse. La documentation Microsoft des comptes décrit à la fois la restriction interactive et le hash NT qui subsiste.

Pour les administrateurs, l’objectif utile dépasse donc le simple fait de « mettre la case au vert ». Déterminez quelles identités doivent utiliser la carte, si leur domaine prend en charge et active le renouvellement, et comment démontrer une réinitialisation réussie sur un compte représentatif. Ce guide suit cette séquence : examiner le compte et le domaine, interpréter les constats, puis tester la remédiation sur un pilote. Les commandes ci-dessous sont des exemples fondés sur la documentation ; aucune n’a été exécutée sur un domaine pour cet article.

Le bit impose une exigence d’authentification

L’option correspond au flag cumulatif de userAccountControl nommé SMARTCARD_REQUIRED, de valeur hexadécimale 0x40000 et décimale 262144. D’autres flags peuvent coexister avec lui. Lire l’attribut entier comme s’il devait être égal à 0x40000 ferait manquer les comptes portant des options supplémentaires. La référence Microsoft de UserAccountControl répertorie le flag et explique les valeurs cumulatives.

Windows rend aléatoire le secret du compte lorsque cette exigence est activée. Les recommandations administratives de Microsoft décrivent un mot de passe aléatoire initialement inconnu et précisent qu’une personne disposant des droits de réinitialisation peut ensuite définir une valeur connue et emprunter certains chemins d’accès réseau. Exiger la carte ne diminue pas l’importance de ces autorisations de réinitialisation. Les recommandations Microsoft sur le moindre privilège décrivent explicitement cette capacité administrative restante.

Fonctionnement du secret restant et du renouvellement

Aléatoire ne signifie pas remplacé régulièrement

La référence Microsoft des comptes indique que, sans le mécanisme supplémentaire de renouvellement, la valeur générée reste en place jusqu’à la définition d’un nouveau mot de passe ou à la désactivation puis réactivation de l’exigence de carte à puce. Une valeur initiale à forte entropie répond au risque de devinette ; conserver la même valeur après son vol pose un autre problème. C’est cette distinction qui motive l’examen, sans prétendre que tout compte avec carte à puce possède le mot de passe le plus ancien de son domaine. Le comportement documenté des comptes étaye cette persistance et le mécanisme de remplacement manuel.

L’authentification Windows doit aussi permettre l’accès ultérieur aux ressources réseau. La documentation Microsoft des processus d’identification décrit la conservation du hash NT correspondant dans son modèle d’identifiants après une ouverture de session par carte à puce. Cela explique l’importance du secret. Cela ne démontre pas qu’un attaquant puisse extraire un hash de tout terminal, quelles que soient ses protections ou la session effective. Distinguez dans l’enquête l’existence d’un identifiant, son exposition et son vol.

Le paramètre du domaine active l’expiration selon la politique

L’attribut booléen du domaine msDS-ExpirePasswordsOnSmartCardOnlyAccounts contrôle l’expiration des mots de passe des comptes réservés à la carte à puce selon la politique de mot de passe. Ce n’est pas le bit de carte à puce de l’utilisateur. La définition de l’attribut dans MS-ADA2 précise sa fonction.

La fonctionnalité nécessite un niveau fonctionnel du domaine Windows Server 2016 ou supérieur. La seule version du système d’exploitation d’un contrôleur de domaine ne démontre pas ce prérequis ; l’exigence porte ici sur le niveau du domaine, pas sur un prérequis inventé au niveau de la forêt. La page des fonctionnalités de Microsoft documente aussi l’option du Centre d’administration Active Directory pour les domaines existants. La description de la fonctionnalité de renouvellement est la référence pour ces conditions de déploiement.

La réinitialisation intervient lors d’une ouverture de session éligible

Pendant le traitement de la requête AS-REQ PKINIT, le KDC demande la réinitialisation du mot de passe du compte réservé à la carte à puce dans les conditions définies par la procédure de réinitialisation MS-PKCA. Si elle aboutit, le traitement de la requête initiale reprend depuis le début.

Le service répondant applique les règles d’expiration et de validation de la spécification normative de réinitialisation MS-SAMS. Un mot de passe non expiré renvoie un succès sans remplacement. Ici, l’expiration désigne la condition calculée par le protocole, qui tient aussi compte des règles de durée de vie des tickets ; elle ne correspond pas simplement au seuil d’âge du domaine utilisé par le collecteur. Pour un mot de passe expiré, la validation inclut l’activation de l’attribut du domaine, un niveau fonctionnel du domaine suffisant, le bit de carte à puce et l’absence de DONT_EXPIRE_PASSWD. Une réinitialisation réussie génère de nouveaux secrets et met pwdLastSet à l’heure actuelle.

Il s’agit d’un traitement de connexion soumis aux conditions de la politique et du protocole. Ce n’est ni un minuteur en arrière-plan, ni un remplacement garanti à chaque connexion, ni un calendrier universel à nombre de jours fixe. Par inférence opérationnelle, un compte qui effectue rarement une ouverture de session éligible peut conserver une date ancienne même si le renouvellement est activé. Examinez sa politique et son utilisation réelle avant d’attribuer une cause à cette date.

Mesurer séparément le compte et le domaine

Utilisez un contrôleur de domaine nommé pour obtenir des lectures comparables et remplacez corp.example, dc01.corp.example, le nom distinctif du domaine et admin-pilot par les valeurs réelles. Conservez l’identité, l’heure de collecte et les résultats bruts dans le dossier de changement. Ces exemples sont construits à partir de paramètres de cmdlets documentés ; ils ne sont présentés ni comme des commandes exactes copiées mot pour mot depuis Learn, ni comme des résultats d’un audit client.

Étape 1 — Inventorier les comptes portant l’exigence

Get-ADUser documente -Filter, -Properties et -Server. Le modèle objet Active Directory documente SmartcardLogonRequired et la propriété PasswordLastSet dérivée de pwdLastSet.

Get-ADUser -Filter {SmartcardLogonRequired -eq $true} -Properties pwdLastSet,PasswordLastSet,PasswordNeverExpires,Enabled,adminCount -Server dc01.corp.example

Lisez l’état d’activation et l’exception d’expiration avec les dates. Conservez les comptes désactivés dans l’inventaire si cela est utile, mais distinguez-les de la population activée évaluée par le détecteur de rotation. Une date renseigne sur l’entretien du mot de passe ; elle ne date pas, à elle seule, l’activation du bit de carte à puce.

Pour chaque compte, consignez son propriétaire, le parcours de connexion attendu, la politique applicable et les exceptions d’expiration. Recueillez séparément les détails du parcours et de la propriété ; Get-ADUser ne les établit pas.

Étape 2 — Identifier le domaine et son niveau fonctionnel

Get-ADDomain accepte une identité de domaine et un serveur, et renvoie les informations du domaine, notamment DomainMode et DistinguishedName.

Get-ADDomain -Identity corp.example -Server dc01.corp.example

Utilisez l’identité du domaine renvoyée pour confirmer que les lectures suivantes visent le contexte de nommage voulu. Consignez le niveau fonctionnel séparément de l’inventaire des systèmes d’exploitation des contrôleurs de domaine. Si le résultat ne peut pas être obtenu ou désigne le mauvais domaine, résolvez ce problème de mesure avant de conclure à la disponibilité de la fonctionnalité.

Étape 3 — Lire l’attribut du domaine et la politique d’âge du mot de passe

Get-ADObject documente la lecture d’un objet par son identité avec des propriétés LDAP supplémentaires. Lisez l’objet racine du domaine, plutôt qu’une OU ou un utilisateur individuel :

Get-ADObject -Identity 'DC=corp,DC=example' -Properties msDS-ExpirePasswordsOnSmartCardOnlyAccounts,maxPwdAge -Server dc01.corp.example

Conservez la valeur brute de maxPwdAge avec le paramètre du domaine. La comparaison d’âge du collecteur décrite plus bas utilise une valeur en jours dérivée de cette politique. Ne lui substituez pas un objectif d’âge arbitraire pour le présenter ensuite comme une exigence Microsoft de renouvellement.

Traitez un attribut absent, une valeur false et une lecture échouée comme des situations d’enquête distinctes. Confirmez le contrôleur, l’identité du domaine, les autorisations et l’exhaustivité de la réponse. Une console vide ne suffit pas à prouver qu’une collecte réussie a renvoyé false.

Détection : déterminer à quelle question répond la preuve

Partez de deux populations : les comptes activés qui exigent la carte, et les identités administratives qui ne l’exigent pas. Dans la première, déterminez si le renouvellement est activé avant d’évaluer l’âge. Dans la seconde, confirmez les responsabilités administratives réelles avant de décider où appliquer l’exigence. Ce sont des étapes d’examen dérivées des critères des détecteurs, pas des preuves d’intrusion.

Le tableau résume smartcard-rotation.go:48 et admin-no-smartcard.go:24, examinés intégralement pour cet article. Leur implémentation est détaillée dans « Comment EtcSec détecte cette situation ».

Un dossier de preuves utile distingue l’observation de configuration, l’observation de l’âge du compte et la cause confirmée. Par exemple, une date ancienne avec renouvellement activé justifie une enquête ; cela ne prouve pas que l’attribut du domaine serait secrètement désactivé. Évitez de transformer le nom du détecteur en diagnostic de chacun des comptes qu’il renvoie.

Pourquoi la conséquence d’attaque reste conditionnelle

Si un secret NT encore valide est réellement volé, son utilisation dépend des protocoles d’authentification et des droits disponibles sur le chemin ciblé. Notre guide Pass-the-Hash explique cette réutilisation conditionnelle via NTLM. Il distingue aussi Overpass-the-Hash, qui obtient du matériel d’authentification Kerberos dans les conditions pertinentes, de Pass-the-Ticket, qui réutilise un ticket. Ne déduisez pas que la possession du hash NT d’un utilisateur donne accès à tous les tickets d’un domaine utilisant AES.

Gardez un objectif de durcissement précis : réduire la persistance d’un secret de mot de passe réutilisable. Ne présentez pas une réinitialisation réussie comme une révocation universelle des tickets déjà émis, des sessions réseau existantes ou des certificats. Ceux-ci exigent leurs propres décisions de réponse à incident.

Remédiation : activer le renouvellement avec un pilote contrôlé (Remediation)

Étape 1 — Établir les prérequis et les responsabilités

Avant de modifier le domaine, désignez l’administrateur responsable, choisissez un compte pilote représentatif et confirmez le niveau fonctionnel du domaine. Examinez la politique de mot de passe réelle du pilote et ses exceptions d’expiration. Organisez le test de son ouverture de session par carte à puce et des accès réseau nécessaires, avec une procédure de récupération convenue.

C’est un plan de changement recommandé, pas un résultat de laboratoire. Il vise à révéler les dépendances avant d’étendre le changement. Ne prenez pas la seule réussite d’une écriture comme critère d’acceptation. Décidez à l’avance quelles lectures et quels tests d’authentification le responsable du changement conservera comme preuves.

Les identités sélectionnées doivent aussi correspondre à l’usage prévu. La référence Microsoft des comptes indique que les comptes exigeant une carte à puce ne peuvent pas servir à démarrer des services ou à exécuter des tâches planifiées. Examinez ces dépendances avant de modifier l’exigence d’un compte. Les recommandations Microsoft sur les comptes définissent cette limite.

Étape 2 — Activer le renouvellement du domaine

Après avoir validé le niveau fonctionnel et planifié le pilote, adaptez l’exemple 6 de Set-ADDomain :

Set-ADDomain -Identity corp.example -PublicKeyRequiredPasswordRolling $true -Server dc01.corp.example

Le paramètre documenté définit msDS-ExpirePasswordsOnSmartCardOnlyAccounts à true. Il s’agit d’un changement du domaine, même si la validation commence par un seul compte. Inventoriez les identités concernées et leurs propriétaires avant de l’appliquer.

Répétez immédiatement la lecture précédente de l’objet domaine sur le contrôleur choisi. Organisez ensuite une ouverture de session éligible du pilote et répétez la lecture de l’utilisateur. Consignez ce qui s’est réellement produit plutôt que d’insérer les résultats attendus dans le dossier de changement. Si la date ne change pas, examinez l’éligibilité et la politique avant de répéter aveuglément les modifications. Cet exemple ne promet ni délai de réplication ni résultat de réinitialisation.

Étape 3 — Réserver le remplacement manuel à une procédure contrôlée

Lorsque le renouvellement automatique ne peut pas encore être utilisé, la référence Microsoft des comptes documente le remplacement par désactivation puis réactivation de l’exigence. Set-ADUser documente le paramètre booléen -SmartcardLogonRequired. Les actions suivantes sont deux opérations distinctes sur un compte pilote.

Désactivez d’abord l’exigence :

Set-ADUser -Identity admin-pilot -SmartcardLogonRequired $false -Server dc01.corp.example

Rétablissez-la ensuite :

Set-ADUser -Identity admin-pilot -SmartcardLogonRequired $true -Server dc01.corp.example

Relisez le compte, vérifiez que l’exigence est rétablie, testez le parcours de connexion et d’accès réseau prévu, puis confirmez l’état répliqué pertinent. N’affirmez pas que cette procédure manuelle met toujours pwdLastSet à jour de manière identique à la réinitialisation automatique normative. Mesurez le résultat.

Si un niveau fonctionnel inférieur empêche le renouvellement automatique, documentez la procédure manuelle, les responsabilités et le calendrier organisationnel. Choisissez ce calendrier selon votre processus de gestion du risque et d’exploitation ; ne présentez pas l’intervalle choisi comme une exigence Microsoft de cette fonctionnalité.

Étape 4 — Examiner le périmètre administratif réel

Utilisez la sélection du détecteur complémentaire comme liste de départ. La syntaxe ci-dessous emploie les paramètres documentés de Get-ADUser ; les critères de sélection proviennent de admin-no-smartcard.go:24.

Get-ADUser -Filter {Enabled -eq $true -and adminCount -eq 1 -and SmartcardLogonRequired -eq $false} -Properties adminCount,userAccountControl -Server dc01.corp.example

Rapprochez cette liste des appartenances actuelles aux groupes, de l’administration déléguée, des autorisations applicatives et des identités de récupération. Le détecteur lit un marqueur administratif ; il ne calcule pas toutes les formes de privilèges effectifs. Les recommandations Microsoft sur le moindre privilège abordent les privilèges dans les groupes de l’annuaire, les systèmes membres et les applications : l’examen doit donc dépasser la population de la requête. Examinez les privilèges administratifs et les droits de réinitialisation de mot de passe avant d’appliquer des restrictions aux comptes.

Valider le changement sans exagérer le résultat

Construisez le dossier de validation autour d’observations reproductibles par un relecteur : le domaine et le contrôleur interrogés, le niveau fonctionnel, l’attribut brut de renouvellement, l’exigence du compte, la politique examinée et le résultat d’authentification du pilote. Ajoutez les horodatages et conservez les erreurs. C’est un format de preuves recommandé, pas l’affirmation qu’une seule commande fournit chaque élément.

Distinguez « le paramètre est activé » de « la réinitialisation d’un compte éligible a abouti ». Si le pilote n’est pas encore arrivé à expiration, une date inchangée peut être cohérente avec le déroulement documenté. Si la réinitialisation réussit, comparez la nouvelle observation utilisateur à la capture précédente. Pour les comptes rarement utilisés, décidez comment organiser leur validation future plutôt que de supposer qu’un changement du domaine renouvelle immédiatement tous les secrets.

Enfin, relancez l’évaluation de configuration et examinez à nouveau les deux populations. Un constat restant mérite une enquête ; un décompte nul exige du contexte sur la collecte. Gardez le plan de récupération administrative disponible pendant l’extension du changement. La clôture doit préciser ce qui a été vérifié et ce qui dépend encore de futures connexions ou de contrôles distincts.

Comment EtcSec détecte cette situation

SMARTCARD_PASSWORD_ROTATION_DISABLED

L’implémentation dans ad/advanced/other/smartcard-rotation.go:48 traite d’abord l’absence d’informations sur le domaine en renvoyant un constat avec Count: 0. Elle sélectionne ensuite les utilisateurs activés dont userAccountControl contient 0x40000.

Elle comporte deux branches effectives :

• Paramètre du domaine false : chaque utilisateur de cette population activée exigeant une carte à puce est sélectionné, indépendamment de PasswordLastSet. Une modification récente du mot de passe ne supprime pas le constat de configuration.
• Paramètre du domaine true : l’âge n’est évalué que si MaxPasswordAge > 0. Le compte est sélectionné si PasswordLastSet est nul ou strictement antérieur à Now.AddDate(0, 0, -MaxPasswordAge). L’égalité n’est pas sélectionnée. Avec un âge maximal nul, cette branche ne déduit aucun constat d’âge.

Ces branches se trouvent dans smartcard-rotation.go:79–87 ; le seuil de politique se trouve dans 62–66. Le contrôle n’utilise pas de seuil à nombre de jours fixe et ne prouve pas qu’une réinitialisation ait eu lieu lors d’une connexion particulière.

ADMIN_NO_SMARTCARD

L’implémentation complémentaire dans ad/accounts/advanced/admin-no-smartcard.go:24 sélectionne les utilisateurs activés avec AdminCount=true et sans bit de carte à puce, selon les conditions de 29–41. Elle n’examine ni l’âge du mot de passe ni l’attribut de renouvellement du domaine.

Les deux contrôles évaluent des populations de comptes différentes. L’un examine l’entretien du secret derrière une carte à puce obligatoire ; l’autre identifie les comptes de sa sélection administrative qui n’imposent pas cette exigence. Aucun ne doit être présenté comme éliminant toutes les attaques fondées sur les mots de passe.

Ce que ces constats ne mesurent pas

Aucun des deux Detect() ne valide le niveau fonctionnel du domaine, ne calcule la politique de mot de passe affinée effective de chaque utilisateur, ne contrôle DONT_EXPIRE_PASSWD, ne prouve la réussite d’une connexion ou d’une réinitialisation, ni n’inventorie les administrateurs hors de adminCount. La collecte LDAP convertit un attribut de renouvellement true en booléen et convertit son absence ou false en false ; elle dérive l’âge maximal du mot de passe de maxPwdAge (providers/ldap/client.go:636,662–669). Cette limite de collecte compte pour l’interprétation de la première branche.

Un décompte nul peut donc signifier qu’aucun utilisateur n’est sélectionné, qu’une comparaison d’âge n’a pas de seuil positif ou que les informations du domaine sont indisponibles. Ce n’est pas une preuve autonome d’exhaustivité de la collecte ou de bon fonctionnement de la rotation. Utilisez les constats pour guider les mesures du compte et du domaine décrites plus haut, et conservez les preuves du pilote qui démontrent le comportement réellement vérifié.