Connexion de domaine en cache : vérifier REG_SZ hors ligne

Qu'est-ce que la vérification des connexions de domaine en cache ?

La vérification des connexions de domaine en cache rapproche trois éléments de preuve sur un même poste pilote : la stratégie ordinateur appliquée, la valeur et le type dans le registre local, et une connexion hors ligne observée. Un résultat au niveau de la stratégie déclenche cette investigation. Il n'identifie pas un compte privilégié dans le cache et ne prouve pas que le poste a été compromis.

Microsoft documente CachedLogonsCount sous HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon comme étant de type REG_SZ. Sa référence sur les connexions de domaine en cache indique que zéro désactive la mise en cache et que les modifications directes de cette clé de registre nécessitent un redémarrage. Les indications distinctes sur le redémarrage pour la Security Option sont traitées dans la section Remédiation. Ces détails comptent lorsqu'un collecteur d'audit attend un autre type de registre ou ne voit pas le canal de distribution de la stratégie.

Le livrable pratique est une trace de décision : quel appareil a été examiné, ce qu'il devrait autoriser, ce qui a réellement été observé et qui a accepté une éventuelle exception persistante. La procédure ci-dessous est une proposition de démarche de vérification, pas un compte rendu de tests réalisés sur un domaine en production. Les sources et le comportement du détecteur ont été vérifiés le 6 octobre 2026 ; aucune connexion Windows ni commande de remédiation n'a été exécutée pour cet article.

Fonctionnement : distinguer stratégie, type et disponibilité

Utilisez trois niveaux de preuve, avec des conclusions distinctes :

Les deux premiers sont des observations de configuration. Le troisième est une observation de comportement pour une identité, une machine et un instant précis. Conservez ces précisions dans la conclusion finale. Un test réussi sur un portable ne couvre pas tous les portables de son OU, et un test échoué nécessite une explication avant de pouvoir appuyer une décision de modification.

Notre guide de durcissement RDP distingue les décisions relatives à NLA, à la couche de sécurité et à la délégation des identifiants. Il traite déjà des paramètres de connexion en cache aux côtés de ces contrôles. Cette démarche ajoute les preuves nécessaires lorsque le résultat sur les connexions en cache contredit la configuration du poste ; elle ne reprend pas le guide général de configuration RDP.

Gardez aussi séparés les travaux sur l'isolation des identifiants. Le guide Credential Guard après une mise à niveau vérifie les exceptions héritées et le service en cours d'exécution. Utilisez cette investigation pour sa propre question sur l'état de protection. Ni une lecture du registre des connexions en cache ni le détecteur décrit ci-dessous ne mesure le fonctionnement de Credential Guard.

Définir d'abord le pilote et le comportement requis

Avant de recueillir les preuves, désignez le responsable du pilote et le processus utilisateur qui exige un accès hors ligne. Décrivez le résultat attendu en termes opérationnels : par exemple, si un utilisateur de test non privilégié désigné doit pouvoir accéder au bureau local lors d'une perte planifiée de connectivité au domaine. C'est un critère d'acceptation propre à l'organisation, pas un quota de cache universel fixé par Microsoft ou l'ANSSI.

Consignez l'autorité de changement, la fenêtre de maintenance, le contact de récupération et la date de réexamen. En l'absence d'exigence hors ligne convenue, ne laissez pas le message du détecteur devenir implicitement cette exigence. Demandez au responsable de choisir le comportement voulu avant de proposer une valeur.

Vérification : rapprocher la GPO appliquée et le REG_SZ local

Étape 1 : capturer le rapport de stratégie résultante de l'ordinateur

Sur le pilote, utilisez la syntaxe et les options de sortie documentées de gpresult. Ces commandes locales adaptent cette syntaxe au périmètre ordinateur ; exécutez chacune séparément dans une invite de commandes Windows autorisée :

gpresult /scope computer /r

gpresult /scope computer /h cached-logon-computer-policy.html

La première renvoie des données de synthèse ; la seconde enregistre un rapport HTML. Sur Windows ARM64, Microsoft précise que l'option /h nécessite l'exécutable gpresult situé dans SysWow64. Le nom de fichier relatif est un exemple : choisissez le répertoire de preuves approuvé pour l'examen réel. Conservez l'identité de l'ordinateur et l'heure de collecte du rapport, puis examinez les preuves propres au paramètre disponibles dans ce rapport. Une liste des noms de GPO appliquées est un contexte utile, mais n'identifie pas à elle seule la valeur qui l'a emporté pour cette Security Option.

Pour la GPO concernée, conservez son nom, son GUID, sa version et le paramètre exact de connexion en cache issu des preuves administratives. Comparez-les aux informations de stratégie résultante du pilote. Lorsque le rapport n'établit pas l'origine du paramètre, consignez cette provenance comme non résolue et obtenez des preuves propres au paramètre avant de décider quelle stratégie modifier.

Examinez le fichier Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf de la GPO concernée et son entrée [Registry Values] lorsqu'elle est présente. Conservez uniquement l'extrait propre au paramètre et l'identité de stratégie nécessaires à cet examen. Ce contrôle est motivé par l'angle mort documenté du collecteur sur le canal standard, détaillé plus loin. Une déclaration SYSVOL doit encore être rapprochée du pilote ; ne remplacez pas les preuves de stratégie appliquée par la déclaration d'une GPO sans rapport.

Étape 2 : lire la valeur locale sans masquer son type

Utilisez la référence de reg query avec le chemin Winlogon et le nom de valeur documentés :

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v CachedLogonsCount

Il s'agit d'une adaptation de syntaxe en lecture seule, pas d'une commande copiée d'un exemple détaillé de Microsoft. Examinez le nom de valeur, le type et les données renvoyés. Pour la configuration documentée, attendez-vous au libellé de type REG_SZ et au texte numérique configuré. Ne filtrez pas la requête sur DWORD : cela masquerait précisément la divergence de type examinée.

Conservez la sortie réelle avec le rapport de stratégie. Si la valeur manque, si le type diffère, si l'accès échoue ou si la sortie provient d'un autre hôte, qualifiez explicitement cette observation. Aucun de ces résultats n'autorise à fabriquer une valeur locale de dix à partir d'un message d'audit.

Construisez une ligne de rapprochement pour le pilote, contenant l'origine de stratégie rapportée, les preuves GptTmpl.inf, le type et les données locaux, l'heure de collecte et le contexte de redémarrage. Attribuez un responsable et une prochaine action aux divergences. Par exemple, un zéro REG_SZ documenté avec un résultat d'audit persistant oriente vers la limitation du collecteur ; ce n'est pas une raison de réécrire la valeur du poste en DWORD pour faire disparaître l'audit.

Détection : conserver LsaSrv 45058 et tester la connexion hors ligne

L'article de dépannage LsaSrv 45058 de Microsoft décrit un événement informatif du journal System, qui consigne l'éviction de l'entrée utilisateur en cache la plus ancienne lorsque le quota est atteint. L'événement identifie l'utilisateur supprimé et l'horodatage de son entrée. Il fournit un contexte utile pour un échec de connexion hors ligne ; il n'établit pas un vol d'identifiants.

Si l'événement existe dans la période pertinente, conservez son heure, l'ordinateur, la source, l'identifiant d'événement, l'identité de test supprimée et l'horodatage de l'entrée. Corrélez-le avec la chronologie des connexions du pilote. Si la collecte ou la conservation est incomplète, consignez cette lacune. Traitez l'absence d'événement observé comme une limite des preuves, pas comme un inventaire complet des identités en cache.

Étape 3 : utiliser une identité non privilégiée et consigner les conditions

Choisissez une identité de test de domaine dédiée et non privilégiée, dont le responsable autorise l'exercice. Consignez comment son absence d'accès privilégié a été vérifiée par le processus de revue des comptes de l'organisation. N'utilisez pas un administrateur privilégié simplement parce que le titre du détecteur mentionne des comptes privilégiés.

Planifiez un test de connexion à la console locale avec une voie de récupération approuvée. Consignez l'état de référence en ligne, la condition réseau contrôlée, la manière dont l'accessibilité des contrôleurs de domaine a été exclue, la méthode de connexion et le résultat exact observé. Rétablissez la connectivité après l'exercice. Si la condition réseau du test ne peut pas être établie, signalez le résultat comme non concluant.

L'énoncé du résultat doit rester précis : l'identité de test nommée a ou n'a pas atteint le bureau sur le pilote nommé dans les conditions indiquées. Microsoft précise séparément que l'accès au bureau hors ligne ne donne pas accès aux ressources nécessitant une validation par le domaine. Ne présentez pas une réussite d'accès au bureau comme une réussite d'accès aux services du domaine.

Si une éviction nécessite une investigation, utilisez un événement 45058 observé pour l'identité de test ou un exercice de laboratoire approuvé séparément. Ne faites pas défiler les comptes de production simplement pour forcer un événement. Consignez « éviction non observée » lorsque c'est la preuve disponible. Aucun vidage du cache, export de vérificateur, extraction de ruche du registre ni récupération de mot de passe n'est nécessaire pour ce protocole.

Étape 4 : consigner la décision avant de modifier le paramètre

Une trace de revue utile peut suivre ce modèle :

Posez trois questions explicites lors de la revue : Quel pilote et quelle contrainte hors ligne justifient une exception ? Quelles preuves GptTmpl.inf/REG_SZ et quelle GPO résultante faut-il conserver lorsque le résultat d'audit diverge de l'état local ? Quelle identité non privilégiée peut démontrer le comportement pertinent sans manipuler de secrets ? Nommez le responsable de la décision au lieu de laisser ces questions implicites.

Remédiation : appliquer la décision et répéter le contrôle pilote (Remediation)

Si la décision approuvée consiste à modifier la mise en cache, utilisez la Security Option identifiée dans l'article 45058 de Microsoft : Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options, puis Interactive logon: Number of previous logons to cache (in case domain controller is not available). Limitez le changement aux appareils visés.

Pour une décision de désactivation du cache, Microsoft documente zéro comme valeur de désactivation. Une exception conservant la mise en cache nécessite sa propre justification opérationnelle, un responsable et une date de réexamen. Ne transformez pas le maximum global du détecteur, son message sur la valeur par défaut de dix ou une éviction informative en quota universel acceptable.

La référence de Microsoft sur cette Security Option indique que les modifications de stratégie prennent effet sans redémarrage lorsqu'elles sont enregistrées localement ou distribuées par Group Policy. Son article de dépannage du registre exige séparément un redémarrage pour les modifications directes de la clé de registre. Consignez la voie de configuration utilisée et suivez les indications documentées de redémarrage pour cette voie. Une fois le changement effectif, répétez le même rapport de stratégie, la lecture du type et de la valeur locaux et le test pilote contrôlé. Comparez des éléments comparables : les mêmes niveaux de preuve et le même critère d'acceptation. Conservez les différences non résolues au lieu de clore la trace au seul motif que l'audit ne signale plus rien.

Pour un utilisateur affecté par une éviction, la récupération documentée par Microsoft consiste à rétablir la connectivité et la résolution de noms des contrôleurs de domaine, puis à effectuer une connexion authentifiée au domaine ; la remise en cache dépend de l'activation de la mise en cache. Distinguez la récupération d'une décision de stratégie visant à agrandir le quota. Une session utilisateur rétablie ne justifie pas à elle seule une modification de configuration de tout le parc.

Comment EtcSec détecte ce problème

Le contrôle BP039_PRIV_ACCOUNTS_CACHED d'etc-collector d'EtcSec, lu au commit bcd03c54, examine les paramètres de registre des GPO collectées. Tout CachedLogonsCount à zéro observé dans une GPO quelconque supprime le résultat d'audit. Sinon, il renvoie un seul résultat de sévérité Medium avec Count=1, y compris lorsqu'aucune valeur GPO n'a été collectée. Sa valeur worstSeen est le maximum parmi les GPO collectées, pas la stratégie résultante de chaque poste.

Le fournisseur renseigne ce champ depuis Registry.pol via getDWORDValue, qui accepte REG_DWORD. Microsoft documente le paramètre réel comme étant de type REG_SZ. L'analyseur GptTmpl.inf ne renseigne pas CachedLogonsCount depuis [Registry Values]. Le code du détecteur explique lui-même que le canal standard de la Security Option peut donc être invisible et produire un faux positif.

Deux conséquences doivent figurer dans la trace de revue. Un zéro fourni par le canal standard peut coexister avec un résultat d'audit ; inversement, un zéro observé dans une autre GPO peut supprimer ce résultat sans prouver que le pilote est couvert. La référence à la valeur Windows par défaut de dix dans le message d'absence de valeur est une inférence de ce message, pas un paramètre local mesuré.

Ce contrôle n'observe pas un compte précis en cache, ses privilèges effectifs, une compromission, les événements LsaSrv, le comportement de connexion hors ligne ni le fonctionnement de Credential Guard. Traitez-le comme une demande de vérification de la configuration par le canal approprié. Clôturez la revue pilote avec les preuves de stratégie, l'observation REG_SZ locale, le résultat de comportement et la décision autorisée ; gardez visible toute couverture du parc non mesurée.