Revue de l'expiration des comptes AD : décider avant prolongation

Revue de l'expiration des comptes AD : décider avant l'échéance

Une revue de l'expiration des comptes AD transforme les prochaines dates de fin d'accès en décisions attribuées à un responsable. Un compte arrivant à expiration peut appartenir à un prestataire dont la mission se termine, à un salarié disposant d'un accès temporaire ou à une identité utilisateur employée par une application. La première question est de savoir si la date de fin prévue reste correcte. Prolonger tous les comptes figurant dans un rapport annule l'intérêt d'une date de fin.

La revue doit réunir l'instant d'expiration, le responsable désigné, le besoin métier persistant et les dépendances à retirer ou à transférer. Elle doit couvrir toutes les populations d'utilisateurs concernées. L'appartenance à des groupes privilégiés influe sur l'urgence et les droits à retirer, mais elle n'est pas une condition préalable à la revue d'une échéance proche.

Un compte proche de l'expiration ne constitue pas une preuve de compromission. L'expiration du compte est également distincte de celle du mot de passe : ce sont des propriétés différentes du compte et des problèmes opérationnels différents. Ce guide propose une procédure de revue ; il ne présente pas de résultats issus d'un domaine réel et ne prescrit aucune politique universelle de renouvellement.

Comment accountExpires représente une date de fin

L'attribut AD accountExpires stocke un Windows FILETIME : des intervalles de 100 nanosecondes comptés depuis le 1er janvier 1601 UTC. Microsoft définit deux valeurs pour un compte qui n'expire jamais : 0 et 9223372036854775807, également écrite 0x7FFFFFFFFFFFFFFF. Aucune de ces valeurs n'est une échéance future à inscrire dans un calendrier d'expiration. Microsoft Learn : attribut Account-Expires

Distinguez l'instant stocké d'une instruction métier telle que « l'accès se termine vendredi ». Demandez si le responsable vise le début de cette journée, la fin d'une plage de travail ou un instant UTC précis. Consignez le fuseau horaire convenu et l'heure exacte avant toute modification. Sans ce contexte, une date peut interrompre l'accès plus tôt que prévu par le responsable.

Ce sujet recoupe notre article sur les comptes désactivés, expirés et verrouillés restant dans des groupes privilégiés. Cet article traite des comptes déjà dans un état invalide dont l'appartenance privilégiée persiste. La présente revue intervient avant l'expiration, pour toutes les populations d'utilisateurs, afin d'attribuer la décision et de coordonner les changements d'accès. Si le compte a déjà expiré, intégrez-le à la procédure existante de départ et de revue des appartenances plutôt que de le traiter comme une échéance à venir.

Le guide sur la durée de vie des tickets Kerberos et le confinement des connexions explique pourquoi l'état du compte, les tickets émis et les connexions authentifiées nécessitent des preuves distinctes. Utilisez cette distinction pour planifier une date de fin d'accès. Une revue ordinaire d'expiration n'est pas un constat d'incident et ne justifie pas de supposer un vol de tickets.

Détection : établir un inventaire des expirations

1. Définir le périmètre et un horizon explicite

Commencez par le domaine, le serveur d'annuaire, la base de recherche et l'instant de référence. Consignez l'horizon de revue comme un choix opérationnel local. Les exemples ci-dessous nécessitent le module PowerShell ActiveDirectory et un contexte d'annuaire autorisé. Il s'agit de commandes illustratives adaptées de la documentation, pas de commandes exécutées dans un environnement AD. Remplacez chaque serveur, DN et identité d'exemple par des valeurs vérifiées.

Microsoft documente Search-ADAccount -AccountExpiring avec -TimeSpan pour une période à partir de l'instant courant ou -DateTime pour une échéance. -UsersOnly restreint la population d'objets aux utilisateurs. L'exemple suivant choisit un horizon de rapport de trente jours ; ce choix n'est pas une exigence Microsoft. Microsoft Learn : Search-ADAccount

$server = 'dc01.example.com'
$searchBase = 'OU=People,DC=example,DC=com'
Search-ADAccount -AccountExpiring -UsersOnly -TimeSpan '30.00:00:00' -Server $server -SearchBase $searchBase |
    Select-Object DistinguishedName, Name, Enabled, AccountExpirationDate

Pour une revue planifiée, une échéance absolue peut être plus facile à reproduire. Cet exemple distinct construit un DateTime UTC au lieu de dépendre d'une chaîne de date liée à la locale :

$deadlineUtc = [datetime]::new(2026, 11, 3, 18, 0, 0, [DateTimeKind]::Utc)
Search-ADAccount -AccountExpiring -UsersOnly -DateTime $deadlineUtc -Server $server -SearchBase $searchBase |
    Select-Object DistinguishedName, Name, Enabled, AccountExpirationDate

Utilisez une seule forme d'horizon par requête. Conservez l'heure de la requête ainsi que son échéance : une requête relative exécutée plus tard porte sur une autre fenêtre. Ces recherches par cmdlet alimentent l'investigation ; elles ne prétendent pas reproduire les comparaisons strictes des bornes d'EtcSec. Examinez les dates retournées et l'état d'activation avant d'attribuer une action.

2. Lire l'attribut brut et normaliser les dates

Récupérez explicitement accountExpires avec Get-ADUser -Properties. Microsoft documente l'accès aux attributs LDAP supplémentaires par ce paramètre, ainsi que -SearchBase et -Server pour choisir le contexte d'annuaire. Microsoft Learn : Get-ADUser

Cet inventaire illustratif conserve la valeur brute et indique l'état de conversion. Il distingue volontairement une valeur indisponible ou invalide d'une sentinelle documentée indiquant l'absence d'expiration :

Get-ADUser -Filter * -Server $server -SearchBase $searchBase -Properties accountExpires,manager,description |
    ForEach-Object {
        $raw = $_.accountExpires
        $expiryUtc = $null
        $state = 'Missing or invalid'
        if ($null -ne $raw -and [string]$raw -ne '') {
            try {
                $value = [long]$raw
                if ($value -eq 0 -or $value -eq [long]::MaxValue) {
                    $state = 'Never expires'
                } else {
                    $expiryUtc = [datetime]::FromFileTimeUtc($value)
                    $state = 'Dated'
                }
            } catch {
                $state = 'Missing or invalid'
            }
        }
        [pscustomobject]@{
            DistinguishedName = $_.DistinguishedName
            Enabled = $_.Enabled
            RawAccountExpires = $raw
            ExpirationUtc = $expiryUtc
            DateState = $state
            Manager = $_.Manager
            Description = $_.Description
        }
    }

FromFileTimeUtc convertit un temps de fichier en DateTime UTC et rejette les entrées hors plage. Les deux sentinelles d'absence d'expiration sont traitées avant la conversion. Les libellés d'erreur de cet exemple sont des libellés proposés pour la revue, pas des sorties du parseur du collecteur. Microsoft Learn : DateTime.FromFileTimeUtc

Les champs manager et description de l'annuaire sont des pistes pour trouver un responsable, pas une preuve que la personne nommée a autorisé l'accès. Confirmez le responsable désigné à partir du contrat actuel, de la demande d'accès ou de la fiche de service. Laissez visible toute responsabilité non résolue au lieu de considérer un champ vide comme une autorisation de renouveler.

3. Transformer les dates en registre d'actions

Pour chaque identité du périmètre, conservez son identifiant stable, l'attribut brut, l'expiration normalisée, l'état d'activation, l'horodatage de la revue et la source d'annuaire. Ajoutez la date de fin métier, le responsable, les dépendances, la décision et la référence du changement. Distinguez les comptes déjà expirés, ceux qui n'expirent jamais et les dates illisibles de la file des échéances à venir.

Une dépendance applicative doit devenir une tâche confiée au propriétaire du service. Elle ne doit pas transformer silencieusement une identité limitée dans le temps en identité permanente. Décidez comment le travail se poursuivra, qui sera responsable du remplacement ou de la transition et quelle preuve clôturera cette tâche.

Remédiation : confirmer la date de fin ou autoriser une prolongation bornée (Remediation)

1. Décider avant de modifier le compte

Confirmez d'abord la date de référence et la population, puis transmettez chaque échéance à son responsable. Demandez si la date de fin initiale reste valide et si l'utilisateur a toujours besoin du même accès. Consignez la réponse avec la source d'approbation. Une absence de réponse laisse la revue non résolue ; elle n'autorise pas une prolongation.

Lorsque l'accès doit se terminer comme prévu, coordonnez le retrait des droits, la revue des appartenances et le transfert applicatif avec les équipes responsables. Si le travail se poursuit, exigez une nouvelle date de fin bornée et un motif autorisé. Séparez ces deux issues dans le registre pour qu'un renouvellement en masse ne soit pas confondu avec une remédiation achevée.

2. Appliquer uniquement la date approuvée

Microsoft documente Set-ADAccountExpiration pour définir une heure d'expiration exacte. Son paramètre -DateTime suppose l'heure locale sauf indication contraire ; omettre l'heure signifie minuit en heure locale. Utilisez l'instant exact approuvé et consignez-le explicitement. Microsoft Learn : Set-ADAccountExpiration

La prolongation ciblée illustrative suivante utilise une identité fictive et une échéance UTC. Exécutez d'abord l'aperçu dans un environnement autorisé. N'appliquez l'écriture distincte qu'après avoir vérifié que l'identité et la date correspondent à l'approbation consignée. Ces commandes n'ont pas été exécutées ici.

$identity = 'CN=Example User,OU=People,DC=example,DC=com'
$approvedExpiryUtc = [datetime]::new(2026, 12, 1, 18, 0, 0, [DateTimeKind]::Utc)
Set-ADAccountExpiration -Identity $identity -DateTime $approvedExpiryUtc -Server $server -WhatIf

Set-ADAccountExpiration -Identity $identity -DateTime $approvedExpiryUtc -Server $server

N'envoyez pas tout le rapport d'expiration à cette écriture. Un résultat de requête établit une condition de date ; il ne fournit aucune approbation pour poursuivre l'accès. De même, supprimer l'expiration relève d'une décision de politique distincte, pas d'une correction courante d'un constat d'expiration prochaine.

3. Relire et conserver la décision

Après le changement, relisez le même compte depuis le serveur choisi. Conservez les anciennes et nouvelles valeurs brutes, les dates normalisées, le serveur, l'horodatage, l'approbation et la référence du changement :

Get-ADUser -Identity $identity -Server $server -Properties accountExpires,AccountExpirationDate |
    Select-Object DistinguishedName, Enabled, accountExpires, AccountExpirationDate

Normalisez la valeur brute avec la méthode d'inventaire et comparez-la à l'instant UTC approuvé. Cette relecture vérifie la valeur du serveur sélectionné ; lorsque la procédure dépend d'autres contrôleurs de domaine, organisez leur vérification selon le processus de l'équipe annuaire. Une approbation sauvegardée sans relecture ne démontre pas que l'attribut a changé comme prévu.

Pour les départs planifiés, conservez la preuve de l'achèvement des tâches attribuées de retrait des droits et de transition des services. Pour les prolongations, programmez la prochaine revue autour de la nouvelle échéance. Dans les deux cas, distinguez l'attribut du compte des tickets, des connexions et des accès applicatifs. Le registre doit préciser ce qui a été vérifié et ce qui reste à la charge d'un autre responsable.

Comment EtcSec détecte cette situation

L'etc-collector d'EtcSec implémente ACCOUNT_EXPIRE_SOON dans public/internal/audit/detectors/ad/accounts/status/account-expire-soon.go. L'inspection statique de Detect() montre la logique suivante ; aucun audit client n'a été exécuté pour cet article :

1. Prendre l'instant de référence dans data.Now.
2. Calculer la borne supérieure avec now.AddDate(0, 0, 30).
3. Ignorer tout utilisateur dont l'indicateur Disabled vaut true.
4. Ignorer tout utilisateur dont la valeur parsée AccountExpires est le temps zéro.
5. Sélectionner uniquement les dates strictement postérieures à l'instant de référence et strictement antérieures à la borne supérieure.

Les bornes inférieure et supérieure sont toutes deux exclues. Les comptes déjà expirés sont exclus, tout comme une expiration exactement égale à l'instant de référence de l'audit. Count est le nombre d'utilisateurs sélectionnés, pas le nombre de domaines, d'approbations ou de tâches de départ manquantes. Le détecteur renvoie un constat de niveau Medium avec ce nombre ; il joint les détails des utilisateurs concernés uniquement lorsque IncludeDetails est activé et que le nombre est positif.

Ce contrôle ne comporte aucune condition liée aux groupes privilégiés, aux comptes de service ou aux secrets. Il couvre tous les utilisateurs collectés qui satisfont les conditions de date et d'état d'activation. La fenêtre de trente jours est un choix produit déclaré, pas une exigence Microsoft, ANSSI ou CIS. L'implémentation utilise une addition de dates calendaires ; conservez la référence de l'audit et les bornes pour expliquer un résultat précis.

Le parseur LDAP renseigne AccountExpires via parseFileTime dans public/internal/providers/ldap/parser.go. Une entrée vide, 0, la sentinelle maximale signée sur 64 bits et les erreurs de conversion en entier deviennent le temps zéro sans diagnostic par valeur dans cette fonction auxiliaire. Les valeurs antérieures à la borne de conversion de l'époque Unix deviennent également zéro. Une date parsée à zéro peut donc représenter soit des données sans expiration, soit une entrée indisponible ou inutilisable. Le détecteur ignore les deux.

Utilisez ACCOUNT_EXPIRE_SOON pour lancer la revue des responsables et des échéances. Un nombre positif ne démontre ni une attaque, ni l'expiration d'un mot de passe, ni une prolongation non autorisée, ni un besoin de renouvellement. Clôturez la revue avec une décision documentée sur la date de fin, un état d'attribut vérifié et des tâches de retrait d'accès ou de gestion des dépendances attribuées séparément.