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 bien sûr et WS 2016 / 2019.

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"

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 😉