Avec Windows Server 2012 R2, un nouveau groupe a été rajouté dans Active Directory : « Protected Users ».
Le groupe « Protected User » permet de réduire les risques liés aux comptes d'administration. L'ajout d'un compte dans ce groupe va modifier certains comportements. Dans cet exemple, nous verrons quelques éléments de protection liés à ce groupe.
Pour ce faire nous disposons d'un domaine AD avec des DCs en 2016(niveau fonctionel 2016). Dans ce domaine nous avons deux comptes d'administration « Admin1 » et « Admin2 » et un poste client en Windows 10.
Le compte « Admin1 » n'est pas membre du groupe « Protected Users ».
Le compte « Admin2 » est membre de ce groupe.
Il est possible d'ouvrir une session à distance avec le compte « Admin1 » sur le poste Windows 10 (RDP a été activé) avec le nom ou l'adresse IP de la machine. Par contre, l'ouverture de session avec l'adresse IP ne fonctionne pas avec le compte « Admin2 »(voir message d'erreur dans l'image à gauche). L'ouverture de session avec le nom de la machine fonctionne (voir la fenêtre RDS à droite de l'image).
Lorsqu'on utilise le protocole d'authentification Kerberos, plutôt que NTLM, il n'est nécessaire que le nom du destinataire soit enregistré dans le « SPN (ServicePrincipalName) de l'objet. C'est généralement le cas pour le nom de la machine mais pas son adresse IP. Si vous utilisez l'adresse IP, plutôt que le nom, l'authentification ne pourra se faire en Kerberos.
Exemple de SPNs pour le compte d'un ordinateur :
Une des premiers éléments de sécurité pour les comptes membres du groupe « Protected Users » et l'interdiction d'utiliser NTLM. Le protocole utilisé sera donc Kerberos, plus sécurisé et vous devrez contacter la machine en utilisant son nom ou un élément présent dans la liste des SPNs. L'utilisation exclusive de Kerberos plutôt que NTLM réduit les vulnérabilités des protocoles d'authentification.
Nous allons maintenant ouvrir la session sur le poste client Windows en utilisant un compte local de la machine. A l'aide de « PSExec -s -i regedit », nous ouvrons le registre en l'exécutant avec le compte système. En utilisant le compte système (machine), il est possible de parcourir certaines clés normalement interdites même à l'administrateur. Nous recherchons, la clé « HKLM\Security\Cache ». Vous retrouvez à droite dans l'image ci-dessous de valeurs « NL$x ». Ces valeurs correspondent à la mise en cache du login des 10 derniers utilisateurs connecté aux postes. La mise en cache permet à un utilisateur d'ouvrir la session même si le contrôleur de domaine n'est pas disponible.
Vous retrouverez dans le cadre ci-dessous encadré en orange des codes hexadécimales écrit à droite à gauche par bloc de deux chiffres et qui corresponde au SID de l'utilisateur du domaine (F401 correspond à 0x1F4).
Parmi ces codes, vous trouverez par exemple :
0x1F4 = 500, compte administrateur par défaut membre du groupe « admins du domaine »
0xa29 = 2601, le compte admin1 qui n'est pas membre de protected user
0x453 = 1107 => mon compte utilisateur « pbarth ».
Il est donc possible à l'aide d'outils et en utilisant le compte administrateur local de la machine, de retrouver la valeur de hachage du mot de passe, voir le mot de passe des comptes du domaine qui ont ouvert une session sur le poste. De plus, il est facile de réactiver et modifier le mot de passe du compte « administrateur » local à la machine lorsqu'on a un accès physique à celle-ci. L'utilisation de comptes « Admins du domaine » sur des postes de travail représente un risque important pour la sécurité. Il n'est pas recommandé de le faire même si le compte est membre du groupe « Protected Users ». Ce type de compte ne devrait utiliser que sur des contrôleurs de domaine ou des postes d'administrations.
Vous remarquerez dans l'image issu de regedit que le compte « Admin2 », avec le SID se terminant par « 2602 » n'est pas présent dans le cache du poste. Il s'agit d'une autre protection apportée par le groupe « Protected Users », les mots de passe de ces comptes ne sont pas mis en cache et il est donc nécessaire de joindre un contrôleur de domaine pour ouvrir la session.
Pour résumé, les comptes membre du groupe « Protected Users » sont soumis aux règles suivantes :
-les comptes ne peuvent utiliser NTLM, les mots de passe ne sont pas mis en cache
-Kerberos n'utilisera pas DES ou RC4, le domaine doit prendre en charge AES
-les comptes ne peuvent être délégué avec une délégation Kerberos (la page délégation n'apparaît pour des comptes utilisateurs, que si un SPN a été définit dans les propriétés du compte. Cela peut être le cas lorsque vous exécuter un service avec un compte utilisateur spécifique) :
- la durée des tickets Kerberos est de 4 heures par défaut et non 10
Avant d'utiliser ce groupe qui renforce la sécurité des flux, il est important d'avoir mis en place une politique structuré sur la gestion et l'utilisation des comptes. Si vous utilisez votre compte dans un script qui essaye de joindre un partage réseau avec l'IP et que vous ajouter ce compte dans le groupe « protected users », le script ne fonctionnera plus.
|
|
Les comptes d'ordinateurs et les comptes de services ne doivent pas être ajoutés à ce groupe. Il est important de connaitre son environnement afin de déterminer l'utilisation faites des protocoles d'authentification. Beaucoup d'applications peuvent ne pas supporter les restrictions apportées aux membres de ce groupe. L'administration d'Active Directory le supporte. |
Je vous conseille la lecture de l'article suivant:
