Revue AD logonCount par DC : qualifier les totaux avant le retrait du compte

Ce qu’établit une revue AD logonCount par DC

Une revue AD logonCount par DC examine l’origine d’un compteur de l’annuaire avant de l’utiliser pour retirer un compte administratif. Une faible valeur sur un contrôleur de domaine peut déclencher une revue. Elle n’établit ni l’activité du compte à l’échelle du domaine, ni ses autorisations actuelles, ni si son propriétaire en a encore besoin.

Le résultat utile est un dossier de revue : l’identité du compte, chaque DC du périmètre, chaque valeur retournée, les lectures non résolues, les accès actuels et la décision du propriétaire. Conservez ces observations ensemble pour qu’un administrateur puisse expliquer pourquoi un compte a été conservé, a fait l’objet d’investigations supplémentaires ou a intégré une procédure de retrait approuvée.

Ce guide propose une procédure de collecte en lecture seule et de décision. Les exemples PowerShell adaptent des paramètres documentés dans Microsoft Learn à des identités et serveurs illustratifs ; ils n’ont pas été exécutés dans le domaine d’un client. Remplacez les valeurs fictives par des valeurs vérifiées et utilisez le module ActiveDirectory avec une identité autorisée à lire l’annuaire.

Fonctionnement du compteur

La référence de l’attribut Logon-Count de Microsoft décrit un compteur de connexions réussies maintenu indépendamment sur chaque DC, sans réplication. Elle recommande d’interroger tous les DC et d’additionner leurs valeurs. Zéro signifie inconnu. Les DC retirés peuvent laisser des lacunes dans l’historique, et le plafond documenté de 65535 rend un compteur saturé impropre au suivi de l’activité sur ce DC.

Traitez l’attribut comme un décompte cumulé dont la couverture et l’historique sont limités, plutôt que comme un horodatage. Un décompte de 1–4 ne contient aucune date permettant de calculer une inactivité récente. Même un ensemble complet de lectures actuelles ne peut pas reconstituer les contributions des contrôleurs retirés. Consignez ces limites à côté de tout sous-total au lieu de le présenter comme l’historique complet du compte depuis sa création.

Ne remplacez pas logonCount par badPwdCount lorsque le premier est indisponible. La procédure connexe de triage badPwdCount qualifie les compteurs d’échecs avant un verdict d’attaque. Sa discipline de conservation du serveur, de l’heure et de la qualité de collecte s’applique ici, mais un compteur d’échecs ne répond pas à la question des connexions réussies.

Détection : construire une matrice de preuves compte/DC

Étape 1 — Fixer l’identité et le périmètre

Partez du constat initial et conservez son identifiant de compte, le point de connexion du collecteur, l’heure de collecte, la révision du collecteur et les erreurs. Confirmez le domaine du compte et l’inventaire des DC avec l’équipe d’exploitation de l’annuaire. Les deux noms d’hôte ci-dessous illustrent des lectures séparées ; ils ne constituent pas la liste complète des DC d’un domaine réel.

Choisissez un identifiant de compte stable et vérifiez sa concordance avec le constat avant de répéter la lecture. Conservez le DN ou le GUID avec le nom affiché dans le dossier de revue. Si le compte ne peut pas être résolu sur un serveur, conservez l’erreur de recherche et examinez l’identité, le périmètre ou la disponibilité de l’annuaire. Ne créez pas d’entrée numérique pour un objet qui n’a pas été retourné.

Microsoft documente la sélection de l’identité, la sélection explicite du serveur et les attributs supplémentaires dans Get-ADUser. Ces adaptations demandent explicitement logonCount à un DC nommé, au lieu de s’appuyer sur la sélection de serveur par défaut :

Get-ADUser -Identity 'CN=ReviewAdmin,OU=Staff,DC=corp,DC=example' -Server 'dc01.corp.example' -Properties logonCount,adminCount -ErrorAction Stop

Get-ADUser -Identity 'CN=ReviewAdmin,OU=Staff,DC=corp,DC=example' -Server 'dc02.corp.example' -Properties logonCount,adminCount -ErrorAction Stop

Exécutez séparément la même lecture documentée sur chaque DC vérifié du périmètre. Enregistrez l’objet retourné et toute erreur avec le point de connexion choisi et l’heure de lecture. Une connexion réussie ne suffit pas à établir que l’attribut demandé a été retourné. Examinez la propriété plutôt que de laisser une conversion numérique ultérieure transformer une valeur vide en zéro.

Étape 2 — Préserver les observations brutes

Utilisez une ligne par compte et par DC. La matrice ci-dessous est une structure de preuves recommandée, pas un exemple de sortie provenant d’un environnement client ni des champs fournis automatiquement par le détecteur.

Pour un zéro retourné, conservez le zéro littéral et marquez la valeur d’activité comme inconnue. Pour un attribut absent, conservez l’absence. Pour une valeur invalide, gardez sa représentation d’origine et classez l’interprétation comme non résolue. Pour une lecture échouée, conservez l’erreur et laissez le décompte non renseigné. Ces états peuvent nécessiter des suites différentes, même si aucun ne fournit de décompte d’activité connu.

Si un serveur est indisponible, gardez sa ligne dans le périmètre déclaré. Attribuez la nouvelle tentative ou l’investigation à un responsable. Une nouvelle tentative réussie devient une observation supplémentaire avec sa propre heure ; elle ne doit pas effacer l’échec de collecte initial. De même, si la collecte est répétée, préservez les observations différentes au lieu de choisir la valeur qui donne à la revue une apparence de complétude.

Étape 3 — Synthétiser sans effacer l’incertitude

Additionnez les valeurs positives connues tout en conservant la matrice complète. Présentez le résultat comme un sous-total connu dès qu’un DC possède une valeur inconnue ou n’a pas été lu avec succès. Indiquez à côté les DC qui ont contribué, ceux qui n’ont pas contribué, l’intervalle de collecte, ainsi que tout compteur saturé ou toute contribution historique manquante.

N’excluez pas silencieusement les serveurs indisponibles du périmètre et ne remplissez pas leurs cellules avec zéro. Une feuille de calcul contenant une valeur numérique sur chaque ligne peut encore contenir des preuves non résolues. La synthèse doit le rendre visible à la personne qui décide si une collecte supplémentaire est nécessaire.

Appliquez la même règle lorsque vous comparez des revues. Maintenez la cohérence de l’identité du compte et de la couverture des DC, décrivez les changements d’inventaire et préservez la matrice précédente. Un sous-total différent peut refléter une couverture différente ; il ne fournit pas automatiquement un intervalle d’activité récente. Si la décision exige une chronologie, obtenez des preuves d’activité qualifiées séparément pour une période définie et documentez leur couverture.

Remédiation : examiner les accès et le propriétaire avant le retrait (Remediation)

Étape 4 — Clarifier le marqueur administratif

Le détecteur utilise adminCount=1 pour sélectionner les candidats. Avant de qualifier le compte d’administrateur, établissez ses accès actuels. La procédure de nettoyage des valeurs adminCount obsolètes explique pourquoi le marqueur peut persister après la fin d’une appartenance privilégiée. Suivez sa revue des appartenances et des autorisations au lieu de supposer que l’indicateur est un inventaire des droits actuels.

Pour décider du retrait, demandez une revue des groupes directs et imbriqués, du groupe principal, des autorisations déléguées pertinentes et des ressources que le compte peut administrer. Conservez dans le dossier l’examinateur, le périmètre et les chemins non résolus. Une liste de groupes directs d’apparence ordinaire ne clôt pas la question plus large des accès.

Cette revue peut produire des résultats distincts : un compte dont les accès actuels sont justifiés ; un ancien compte privilégié présentant un état résiduel ; des autorisations injustifiées nécessitant une modification ciblée ; ou des accès qui restent non vérifiés. Consignez les preuves réelles de cette classification. N’effacez pas adminCount simplement pour supprimer ce constat, et n’assimilez pas le nettoyage du marqueur au retrait du compte.

Étape 5 — Obtenir la décision du propriétaire

Identifiez le propriétaire responsable et demandez quelles procédures dépendent du compte. Confrontez l’usage déclaré aux preuves opérationnelles et aux dépendances disponibles. Incluez les usages planifiés, peu fréquents, de récupération et d’urgence lorsqu’ils s’appliquent au compte ; leur pertinence doit venir du propriétaire et de l’environnement, pas d’une explication supposée d’un faible compteur.

La procédure proposée sépare la revue du compteur de l’autorisation de modifier les accès. Si le retrait est approuvé, utilisez la procédure de cycle de vie des comptes de l’organisation pour l’identité vérifiée. Choisissez la modification et la méthode de récupération selon ce plan approuvé. Ce guide ne prescrit aucune désactivation ou suppression en masse fondée sur le seuil du détecteur.

Étape 6 — Valider le résultat consigné

Après une modification approuvée, relisez le même compte sur les serveurs documentés et préservez séparément les nouveaux résultats. Les paramètres d’identité, de serveur et de propriétés de Get-ADUser documentés ci-dessus permettent aussi cette lecture reproductible :

Get-ADUser -Identity 'CN=ReviewAdmin,OU=Staff,DC=corp,DC=example' -Server 'dc01.corp.example' -Properties logonCount,adminCount -ErrorAction Stop

Répétez la revue des accès pertinente pour la modification et faites confirmer les procédures affectées par le propriétaire. Consignez l’état réel du compte, les autorisations, les dépendances restantes, les erreurs et le suivi. La seule disparition du constat n’établit pas que les autorisations ou les dépendances métier ont été traitées correctement.

Comment EtcSec détecte ce cas

Le contrôle etc-collector examiné est ADMIN_LOGON_COUNT_LOW, dans Accounts, avec une sévérité Info. À la révision du collecteur afca1b9f7bba6f076d6a6493371486071001452b, admin-logon-count-low.go:36 sélectionne les utilisateurs activés avec AdminCount=true, exclut LogonCount=0 et retient un décompte non nul inférieur à 5. Il n’applique aucune période d’inactivité. Le seuil est un prédicat du produit, pas une règle de retrait des comptes.

Count est le nombre d’utilisateurs correspondants, pas une somme de connexions. Le détecteur retourne le constat même lorsque ce nombre est nul ; les détails des utilisateurs affectés sont joints lorsqu’ils sont demandés et que des correspondances existent. Une correspondance est une piste d’investigation issue de la vue collectée.

Le fournisseur LDAP limite cette vue. client.go:460 récupère les utilisateurs via la connexion sélectionnée sans agréger les compteurs des DC. parser.go:41 demande logonCount ; le parseur utilisateur le lit via getIntAttr, dont le traitement des valeurs absentes et des entiers invalides peut produire zéro. Le détecteur ne peut donc pas distinguer tous les états de collecte que préserve la matrice indépendante. Exclure zéro empêche un décompte inconnu de devenir un constat positif, mais ne vérifie pas l’utilisation à l’échelle du domaine.

Le contrôle ne calcule aucun total de domaine et n’établit ni droits effectifs, ni propriétaire, ni dépendances, ni chronologie d’activité récente. adminCount est son marqueur de sélection, pas une preuve de privilèges actuels. Utilisez ADMIN_LOGON_COUNT_LOW pour ouvrir la revue, puis qualifiez chaque observation de DC et les accès du compte avant de décider de son avenir.