L’Active Directory et la mise en cache des identifiants
Sommaire
I. Présentation
Quand un utilisateur d'un domaine Active Directory s'authentifie sur un ordinateur Windows (ou un serveur) membre du domaine, ses identifiants sont mis en cache en local, de manière automatique. On parle de Cached credentials. Ainsi, l'utilisateur peut se connecter à sa session, sur le même ordinateur, lorsque le contrôleur de domaine est injoignable, que l'ordinateur n'est pas connecté au réseau, ou lorsque l'ordinateur est connecté sur un réseau différent et qu'il ne peut pas contacter le contrôleur de domaine (télétravail, hôtel, train, etc.).
La mise en cache des identifiants s'avère très pratique pour les ordinateurs portables, car ils sont susceptibles d'être utilisés dans des conditions diverses et variées lors desquelles l'utilisateur aura besoin d'accéder à sa session et ses données.
Dans cet article, nous allons voir comment fonctionne la mise en cache des identifiants, comment elle se configure et quels sont les risques associés à cette fonctionnalité, autant d'un point de vue de la sécurité que de l'utilisation : la mise en cache à ses limites, comme nous le verrons, mais il existe des solutions.
II. Fonctionnement de la mise en cache des identifiants
Une entrée est ajoutée dans le cache des identifiants lorsqu'un utilisateur se connecte sur un ordinateur Windows ou un serveur Windows Server. C'est vraiment l'action de connexion qui alimente le cache. Si un utilisateur se connecte avec un nouveau mot de passe, l'entrée dans le cache sera également actualisée. Le cache entre en jeu lorsque l'utilisateur veut se connecter à sa session sans que Windows soit en mesure de contacter l'Active Directory. Ces informations sont stockées dans le Registre, sans limites de temps.
De ce fait, si le domaine Active Directory n'est pas joignable au moment où un utilisateur tente de se connecter, Windows vérifie si le nom d'utilisateur et le mot de passe saisi sur la page de connexion du système correspondent à des identifiants disponibles dans le cache local. Si c'est le cas, il accède à sa session.
Puisque le cache permet de s'authentifier en étant déconnecté de l'Active Directory, on peut imaginer le cas suivant. Si un utilisateur se connecte sur un ordinateur intégré au domaine Active Directory, qu'il éteint cet ordinateur, le déconnecte du réseau, et qu'il change son mot de passe depuis un deuxième ordinateur, il pourra toujours s'authentifier sur le premier ordinateur avec son ancien mot de passe (à condition d'utiliser l'ordinateur en mode hors connexion).
A. Où est stocké le cache des identifiants Windows ?
Par défaut, quand on ouvre une session d'un utilisateur Active Directory sur Windows, le système d'exploitation met en cache les identifiants : le nom d'utilisateur et un hash du mot de passe. Ce cache est stocké directement dans le Registre Windows au sein de la clé suivante :
HKEY_LOCAL_MACHINE\Security\Cache
Même avec les droits administrateurs vous ne pourrez pas voir la clé "Cache" dans le Registre Windows. C'est compréhensible. Néanmoins, il est assez facile d'accéder à ces informations en utilisant PsExec qui va nous permettre d'ouvrir le Registre Windows avec les droits Système.
A titre d'information, voici la commande à exécuter :
.\PsExec.exe -s -i -d regedit.exe
Sur mon ordinateur, que ce soit un Windows 10, un Windows 11 ou une autre version de Windows, il me sera possible de visualiser le cache. Chaque valeur "NL$X" correspond à une entrée du cache et le hash de chaque entrée utilise le nom d'utilisateur comme donnée de salage. En supprimant les entrées de cette liste, on purge le cache.
B. Cache des identifiants Windows : la limite d'identifiants
Windows ne va pas stocker dans son cache un nombre illimité d'identifiants. Dans sa configuration par défaut, Windows va stocker dans son cache les identifiants de 10 utilisateurs. C'est en tout cas le comportement depuis Windows 10 et Windows Server 2016, et c'est vrai aujourd'hui avec Windows 11 et Windows Server 2022. On peut même affirmer que Windows stocke dans son cache les identifiants des 10 derniers utilisateurs qui ont ouvert une session sur la machine en question.
Ce seuil de 10 est déterminé dans une valeur du Registre nommée "CachedLogonsCount" et qui se situe à cet emplacement :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Sur l'image ci-dessous, issue d'une machine Windows 10 dans sa configuration par défaut, on voit bien que la limite est définie sur 10.
Même en modifiant cette valeur, vous devez savoir aussi que Windows ne peut pas stocker plus de 50 entrées dans son cache d'identifiants. Ainsi, il faut considérer que la valeur maximale pour cette option est de 50 identifiants, mais personnellement je vous recommande plutôt de revoir cette valeur à la baisse (moins de 10). Je reviendrai sur ce point dans la suite de cet article.
C. Configuration du cache des identifiants par GPO
Que ce soit à partir d'une stratégie de groupe Active Directory ou de la stratégie de groupe locale (gpedit.msc), il y a un paramètre qui permet aux administrateurs de configurer le cache des identifiants sans devoir modifier directement le Registre. Si l'on prend l'exemple de la GPO Active Directory, il faut accéder à cet emplacement :
Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Options de sécurité
Ici, il sera nécessaire de configurer le paramètre "Ouvertures de sessions interactives : nombre d'ouvertures de sessions précédentes réalisées en utilisant le cache (lorsqu'aucun contrôleur de domaine n'est disponible)" en cochant l'option "Définir ce paramètre de stratégie" puis en définissant un seuil.
III. Les risques liés au cache des identifiants Windows
A. Le télétravail et le risque d'être bloqué
Lorsqu'un utilisateur est en télétravail et qu'il se connecte à sa session, il exploite le cache des identifiants et accède à son environnement. Ensuite, dans une majorité de cas, il va chercher à monter une connexion VPN pour se connecter aux ressources de l'entreprise : applications, fichiers, etc... Lorsque l'authentification du VPN est basée sur l'Active Directory, on peut se retrouver bloqué malgré la présence du cache des identifiants. Pourquoi ?
En fait, le cache des identifiants n'empêche pas le compte utilisateur de vivre dans l'Active Directory. Ainsi, il va arriver un jour où l'utilisateur devra changer son mot de passe conformément à la stratégie de mots de passe de l'entreprise. Sauf que le client VPN de l'entreprise ne sera pas en mesure de lui proposer le changement, et l'utilisateur ne pourra pas se connecter.
J'ai pris l'exemple du VPN, mais cela s'applique aussi s'il doit s'authentifier à une application Web basée sur l'authentification Active Directory. Ces tentatives répétées seront considérées comme en échec auprès de l'annuaire Active Directory et cela pourrait déclencher un verrouillage du compte utilisateur. Disons que ce comportement dépend de la stratégie de mot de passe et de verrouillage de comptes, mais dans le cas d'une infrastructure sécurisée, ce sera normalement le cas.
Face à cette problématique, quelle solution pour les utilisateurs et le service informatique ? Tout d'abord, nous pouvons faire en sorte d'avertir les utilisateurs par e-mail quelques jours avant l'expiration du mot de passe afin qu'ils anticipent et procèdent au changement du mot de passe. Cela éliminera sûrement une partie des cas problématiques.
En complément, il est pertinent de s'orienter vers une solution de réinitialisation du mot de passe en libre-service pour l'Active Directory, ce qui permet à l'utilisateur d'être autonome pour changer son mot de passe, de manière sécurisée. Cette solution va permettre au service informatique de ne plus avoir (ou quasiment plus, soyons honnêtes) ces demandes et ces problèmes à gérer.
B. La compromission du cache d'identifiants Windows
Le cache des identifiants représente un risque en matière de sécurité. Un attaquant qui obtient un accès sur un ordinateur avec des identifiants en cache pourra tenter différentes attaques, notamment une attaque de type brute force sur le hash du mot de passe. Ainsi, il devient possible de réaliser une attaque brute force sans être détecté par l'Active Directory en lui-même (ce qui ne déclenchera pas le verrouillage du compte Active Directory), car on cible le cache local, et non ne s'authentifie pas directement auprès de l'annuaire Active Directory.
Si un utilisateur se connecte sur l'ordinateur portable qui lui est affecté, ses identifiants seront mis dans le cache. Ensuite, si un administrateur du domaine se connecte sur la machine (normalement, on ne doit pas se connecter directement avec un compte administrateur du domaine, mais c'est très fréquent), ses identifiants seront aussi inclus dans le cache. De ce fait, un attaquant qui obtient un accès physique sur cet ordinateur peut réaliser un brute force sur le cache des identifiants afin d'espérer récupérer le mot de passe Administrateur du domaine ! La tâche sera plus ou moins compliquée selon la robustesse du mot de passe.
Pour réduire les risques, il convient de limiter le cache des identifiants à "1". Ainsi, si un administrateur se connecte, ses identifiants seront mis en cache, et quand l'utilisateur va récupérer son ordinateur et se reconnecter, cela va écraser l'entrée correspondante aux identifiants de l'administrateur. On peut appliquer cette politique sur les ordinateurs portables et aller plus loin sur les ordinateurs de bureau en désactivant le cache (valeur à "0") : ce sont des machines qui sont utilisées uniquement au bureau, en mode "en ligne" on peut dire. Attention tout de même, cela signifie qu'en cas d'indisponibilité du contrôleur de domaine ou du réseau, l'utilisateur ne pourra pas ouvrir sa session pour travailler.
Néanmoins, il existe une méthode qui ne nécessite pas de réaliser une attaque brute force sur le cache, mais qui consiste à démarrer l'ordinateur en mode récupération du système Windows et à venir écraser une entrée du cache par un nouveau mot de passe, à l'aide de Mimikatz (voir cet article). Ainsi, on change le mot de passe du cache et on peut s'authentifier sur la machine avec le nom d'utilisateur et le mot de passe falsifié.
Pour protéger les comptes avec des privilèges élevés, il convient d'ajouter les comptes au groupe "Protected Users" de l'Active Directory pour activer certaines protections, dont la désactivation de la mise en cache des identifiants pour les membres de ce groupe. Vous pouvez lire ce tutoriel à ce sujet : Active Directory et Protected Users.
IV. Conclusion
Suite à la lecture de cet article, vous en savez plus sur le fonctionnement du cache des identifiants sous Windows, et vous connaissez également les problématiques associées, que ce soit au niveau de la sécurité ou fonctionnellement parlant.
Merci pour ce brillant article, en complément de ce qui été dit, il est recommandé d’utiliser d’utiliser 2 pour les postes. 1 pour le compte administrateur et le second pour l’utilisateur. Ça permettra à l’administrateur d’intervenir sur le poste en cas de souci (par exemple lors d’une assistance sur le poste en mode hors connexion).
C’est vrai que cette recommandation s’applique dans une situation plus restreinte car le compte support peut pas être le même que le dernier à s’être connecté. Mais c’est déjà ça.
Non, 1 seul compte en cache c’est très bien.
Il vaut mieux intervenir avec un compte administrateur local pour éviter la latéralisation en cas de compromission.
Et pour aller plus loin installer LAPS sur le contrôleur de domaine.
dommage qu’on ne puisse pas désactiver le cache pour un type d’utilisateur (admin par exemple). Le mode protected est problématique quand on est sur un serveur rds d’administration, la session expire après 4H.
bonjour
après avoir activé le cache via gpo sur nos serveurs nous avons constaté un effet de bord non désiré, à savoir que toutes les tâches planifiées ne fonctionnent plus avec les comptes qui étaient en cache.
Donc bien être prudent avec cette fonctionnalité et voir si des comptes gSMA peuvent résoudre le soucis (pas encore testé).