Active Directory : utilisez le groupe Protected Users pour les admins !
Sommaire
I. Présentation
L'Active Directory s'enrichit au fil des versions de mécanismes de protection pour protéger les comptes disposant de privilèges élevés sur l'infrastructure. Depuis Windows Server 2012 R2, Microsoft a intégré un nouveau groupe baptisé "Protected Users" : mais qu'est-ce qu'il apporte vraiment ?
Pour sécuriser les comptes d'administration, l'Active Directory va modifier certains comportements sur les comptes ajoutés au groupe Protected Users. L'idée est notamment d'éviter que les identifiants soient dérobés sur une machine où le compte est utilisé.
II. Protected Users : quels impacts (et bénéfices) ?
Lorsqu'un compte utilisateur est ajouté au groupe Protected Users, s'appliquent notamment les règles suivantes :
- Les identifiants ne sont pas mis en cache sur les machines. Sur une machine déconnectée du réseau, il ne sera pas possible de se connecter, même si la session a déjà était ouverte sur le poste en question. Le contrôleur de domaine doit être joignable impérativement.
- Le ticket Kerberos (TGT) est délivré à la connexion de l'utilisateur et il ne sera pas renouvelé automatiquement lorsqu'il devient invalide (4 heures, par défaut sur ces comptes).
- Impossible d'utiliser DES ou RC4 pour la pré-authentification Kerberos, d'utiliser NTLM pour s'authentifier, ni CredSSP.
Exemple n°1 : si vous utilisez un compte admin du domaine pour vous authentifier en VPN au travers de l'authentification basée sur l'AD, ça ne fonctionnera plus pour ce compte si il est ajouté au groupe Protected Users.
Exemple n°2 : pour vous connecter en RDP sur un serveur, il sera nécessaire d'utiliser le nom FQDN du serveur, avec l'adresse IP l'accès ne sera pas possible.
Tout cela pour dire qu'il ne faut pas ajouter des utilisateurs à ce groupe sans réfléchir, il convient de réaliser des tests sur votre infrastructure pour bien identifier les éventuelles problématiques.
Attention, ce groupe n'est pas fait pour contenir des objets ordinateurs ou des comptes de service.
Note : les fonctionnalités du groupe Protected Users sont supportées sur Windows Server 2012 R2 et Windows 8.1, et les versions ultérieures donc Windows 10, Windows 11 ainsi que Windows Server 2016, Windows Server 2019 et Windows Server 2022.
III. Gérer les membres du groupe
Pour lister les membres du groupe Protected Users et ajouter un nouveau membre, nous avons plusieurs méthodes : tout simplement via le Centre Active Directory, la console Utilisateurs et ordinateurs Active Directory, mais aussi avec PowerShell bien sûr. Ce groupe se situe dans l'OU built-in Users.
Voici la commande :
Get-ADGroupMember -Identity "Protected Users"
Pour ajouter un nouvel utilisateur à ce groupe, c'est également possible en mode graphique et en PowerShell. Par exemple pour ajouter le compte "fb.itconnect" :
Get-ADGroup -Identity "Protected Users" | Add-ADGroupMember –Members "CN=fb.itconnect,CN=Users,DC=IT-CONNECT,DC=LOCAL"
Pour surveiller le troubleshooting, vous pouvez vous référer aux journaux situés dans l'Observateur d'événements à cet endroit (et qu'il faut activer) :
Journaux des applications et des services\Microsoft\Windows\Authentication
IV. Démo avec mimikatz
Mimikatz est une application gratuite qui est très réputée et répandue lorsqu'il s'agit de s'attaquer à un environnement Windows, et plus particulièrement lorsqu'il s'agit de postes intégrés à un domaine Active Directory.
Sur Windows, le processus lsass.exe (Local Security Authority SubSystem) gère les informations d'identifications, et ils sont notamment stockés en mémoire. Avec Mimikatz, ils peuvent être extrait, notamment dans le but de récupérer le hash NTLM des comptes actifs sur la machine. Imaginez s'il s'agit des informations correspondantes à un compte "Administrateur" sur le domaine : cela peut-être dramatique.
Nous allons voir le comportement dans deux cas : avec un compte administrateur qui n'est pas dans le groupe "Protected Users" et ensuite nous mettrons ce compte dans le groupe pour voir la différence.
L'outil Mimikatz est disponible sur Github. Pour ma part, je vais l'utiliser sur une machine Windows 10 et l'exécuter en tant qu'administrateur (pour gagner du temps...). Attention : de nombreux antivirus bloquent l'exécution de Mimikatz, il faudra donc désactiver Windows Defender pour pouvoir mener à bien cette attaque.
Commençons par réaliser une élévations de privilèges avec Mimikatz sur la machine locale :
privilege::debug token::elevate
Ensuite, il y a plusieurs commandes disponibles pour afficher des informations... Pour ma part, j'ai utilisé la commande ci-dessous qui affiche notamment des informations sur les utilisateurs connectés :
sekurlsa::logonPasswords
Dans la liste des informations et comptes qui s'affichent, on retrouve assez rapidement le compte "fb.itconnect". Qu'est-ce que je vois comme information : NTLM, soit le hash NTLM du mot de passe de ce compte. Ça sent pas bon pour mon administrateur car avec ce hash en main, des portes s'ouvrent...!
Maintenant, on reprend tout à zéro : imaginons que ce compte est membre du groupe "Protected Users". Si je réalise de nouveau la même opération avec Mimikatz, voici ce que j'obtiens :
Sur la copie d'écran ci-dessus, on peut voir que le hash NTLM n'apparaît plus. Voilà l'un des bénéfices du groupe "Protected Users" où l'on est obligé d'utiliser Kerberos.
Comme je le disais précédemment, un compte membre du groupe "Protected Users" ne sera pas mis en cache sur une machine. Pour pouvoir ouvrir la session, le poste doit être en mesure de joindre le contrôleur de domaine. Avec un compte classique, les identifiants sont mis en cache (pour 10 utilisateurs par défaut), ce qui permettra d'ouvrir la session en mode hors ligne : ce qui est dangereux pour les comptes sensibles.
Les informations des identifiants en cache sont stockées dans le registre au sein de la clé : HKEY_LOCAL_MACHINE\Security\Cache
De façon plus radicale, la mise en cache peut être désactivée sur les postes par l'intermédiaire d'une GPO. Il faudra modifier le paramètre de GPO suivant : "Ouverture de session interactive : nombre de demandes d’ouverture de session à mettre en cache (au cas où le contrôleur de domaine ne serait pas disponible)" qui se trouve sous : Configuration Ordinateur\Paramètres Windows\Paramètres de sécurité\Options de sécurité
Tout cela pour dire qu'il est vivement recommandé d'utiliser le groupe "Protected Users" pour sécuriser les comptes sensibles de l'Active Directory. Bien que ce ne soit pas la seule action à mener, c'est une couche de sécurité intéressante que Microsoft a implémentée depuis Windows Server 2012 R2. A exploiter autant que possible ?
Bonjour,
Article très intéressant !
Pour info, il y a une petite faute ici ==> même si la session a déjà était (été) ouverte sur le poste en question
En attente de la suite des actions à mener !
intéressant
Mais moi j’ai un souci lorsque je fait cela si le compte est rattaché à Exchange il se déconnecte d’outlook .
Bonjour Nono,
Le but est de protéger les comptes Admins du domaine, donc en aucun cas, un compte admin du domaine doit être utilisé sur Outlook.
Les mauvaises habitudes ont la vie dure. Le groupe admins du domaine ne doit contenir que des comptes ayant pour but l’administration du domaine, pas des utilisateurs parce que c’est plus simple pour leur donner accès à tout (ça inclut le directeur !). Donc, pas de messagerie sur ces comptes, pas de VPN non plus, et un usage à restreindre dans la mesure du possible aux seuls DC.
Petit test sur nos comptes d’administration. Effet de bord le compte ne peut plus servir dans le cadre de connexion à nos firewall, analyseur de log …
A creuser, surement une connexion ntlm qui traine.
Bonjour,
Question de novice.
Est-il pertinent de mettre le compte « administrateur » dans el groupe « Utilisateurs protégés » ?
Bonjour,
Oui tu peux mais il faut surtout bien tester pour voir s’il n’y a pas d’effets de bords pour chaque compte qui sera ajouté dans ce groupe. Ce qu’il ne faut pas faire, c’est ajouter des comptes de service dans ce groupe.
Bonne journée
Florian
Bonjour,
Merci pour cet article très pertinent.
J’ai voulu le tester mais ca ne semble pas fonctionner pour moi.
J’ai crée un compte admin pour le test et ajouter dans le groupe Protected Users, j’ai pu me connecter sur un serveur avec l’ip et mon ticket kerberos a une durée de 10h et non de 4h.
J’ai du louper quelque chose ……
Bonjour,
J’ai le même problème et je suis preneur de la solution si vous en avez une ?
Bonjour,
pouvons-nous savoir pourquoi une fois ajouté au groupe un utilisateur ne peut plus s’authentifier en VPN par AD ? Dans un cas où l’authentification se fait en LDAP nous essayons de comprendre tous les tenants et aboutissants de ce groupe particulier merci.
Bonjour,
Compte tenu des restrictions appliquées sur les membres du groupe Protected Users, cela ne m’étonne pas. Il faut obligatoirement utiliser Kerberos, et non NTLM, et dans le cas où l’authentification est déléguée cela peut poser problème aussi. L’idéal étant de ne pas se connecter sur le VPN avec un compte à privilèges élevés.
Bonjour,
J’ai un compte domain admin qui est dans ce groupe (protected users).
Mais quand je fais un RDP depuis un serveur de rebond qui est dans le même domaine pen utilisant le compte, ça fonctionne parfaitement j’ai pas de soucis
Mais si je fais le RDP depuis un autre domaine ça ne marche pas. J’ai un message : « A user account restriction is preventing you from loggin on ».
Et pourtant ce domaine est bien trusté par l’autre domaine !
Merci
Merci pour cet article par contre lorsque je rentre un compte dans ce groupe, plus possible de se connecter sur les DC et j’ai dans les logs le message DES and RC4 preauthenticated failed. Je ne sais pas quoi modifier pour que ça fonctionne.
Bonjour,
De notre coté différents effet de bord on était constater et quasiment tous contourner. Ne pas ajouter un compte qui sers au sauvegarde VEEAM pour la partie applicative.
Impossible d’ouvrir des sessions sur des serveur 2003 s’il vous reste des vieux serveurs.
Le point qui me gêne le plus aujourd’hui et qui est la raison de mon commentaire. Je ne peux pas explorer mon root domain \\domain.local et de ce fait je ne pas gérer mes espaces nom DFS ce qui peux poser problème. Je n’ai pas encore trouvé de paramètre permettant l’exploration de mon root domain.
Je pense que c’est une bonne mesure ce groupe mais comme indiquer dans l’article ça mérite une petite « étude » et ça peux créer des régression qu’on se rend pas compte sur le coup.