Utiliser des comptes Administrateur local Windows, Partie I
Utiliser des comptes Administrateur local Windows, Partie II
Utiliser des comptes Administrateur local Windows, Partie III
Une des choses que nous ne devons pas perdre de vue dans cette série, c’est que nous essayons de limiter les pouvoirs associés aux comptes Administrateur. En bref : il ne faut pas abuser de la Force. Dans le dernier billet, nous avons montré qu’il était possible de supprimer le compte Administrateur local et de le gérer de manière centralisée au moyen d’Objets de stratégie de groupe (GPO). Revenons sur quelques éléments sur lesquels j’ai fait l’impasse la dernière fois et examinons d’autres façons de protéger ces comptes.
Groupes restreints : à manipuler avec précaution
Dans mon environnement Acme, le GPO des Groupes restreints sert à pousser un groupe du domaine vers l’extérieur, dans le groupe Administrateurs locaux de chacune des Unités organisationnelles (OU) : une stratégie pour Masa et Pimiento, une autre pour Taco. C’est une super astuce, et dans le cas de domaines plus étendus, cela évite à l’équipe informatique de recourir à des scripts ou de perdre du temps à effectuer l’opération manuellement.
Pour vous rafraîchir la mémoire, voici à quoi ressemblait le GPO de mes Groupes restreints :
En utilisant la section « Member of this group » (Membre de ce groupe), j’oblige le Gestionnaire de stratégie de groupe à remplacer, et non ajouter, Acme-IT-1 à chaque groupe Administrateurs locaux de mon OU. Le problème est que vous écraserez peut-être des membres de groupe existants et que vous ne savez pas quels services ou applis dépendent de la présence de certains comptes locaux.
Vous voudrez peut-être tester cette idée dans un petit exemple. Ceci vous demandera peut-être un surcroit de travail (scripts locaux pour ajouter à nouveau ces comptes) ou de créer de nouveaux comptes dans le domaine pouvant être ajoutés dans la fenêtre ci-dessus.
Ou, si vous préférez, vous pouvez utiliser des Préférences de stratégie de groupe (GPP). Une option de mise à jour permet d’ajouter un nouveau groupe (ou utilisateur) sous un compte Administrateur local (ci-dessous). Nous savons qu’il ne faut pas utiliser les GPP pour réinitialiser les mots de passe des comptes Administrateur locaux, n’est-ce pas ?
Encore plus sûr
L’utilisation de Groupes restreints et de comptes Administrateur de domaine gérés de manière centralisée pose problème (*soupir*). Puisque par défaut tous les utilisateurs sont sous Domain Users (Utilisateurs de domaine), cela signifie qu’il est possible d’appliquer aux Administrateurs locaux des techniques Pass-the-Hash (PtH) (consistant à obtenir le hachage NTLM et à le transmettre à psexec) pour se connecter à n’importe quelle autre machine du réseau.
Il s’agit du problème que nous essayions de résoudre au départ ! Pour rappel, les Administrateurs locaux ont généralement des mots de passe simples (faciles à deviner ou à pirater) qui peuvent ensuite servir à se connecter à d’autres machines. Nous voulions éviter d’avoir un compte local de niveau Administrateur pouvant être utilisé de manière globale.
Comme je l’indiquais dans le second billet, il est possible de pallier à cette faille de sécurité en créant un GPO (dans Attribution des droits utilisateur) pour restreindre carrément l’accès au réseau. Cela pourrait s’avérer peu pratique dans certains cas pour les comptes Administrateur.
Il existe une autre possibilité : limiter les machines auxquelles les comptes Administrateur du domaine peuvent se connecter. Ici encore, l’Attribution des droits utilisateur est notre planche de salut, mais cette fois en utilisant la propriété « Allows log on locally » (Autorise la connexion en local), et en ajoutant le groupe Administrateurs Acme-IT-1 (ci-dessous). Il convient alors de répéter l’opération pour l’autre OU du domaine Acme mais en ajoutant le groupe Acme-IT-2.
Ce GPO empêche les comptes de se connecter à des machines n’appartenant pas au domaine précisé. Ainsi, même si un hacker particulièrement malin accède à l’entreprise Acme, il peut effectuer un PtH sur le compte Administrateur, mais uniquement dans l’OU.
C’est une solution raisonnable. Et j’ai conscience que de nombreuses entreprises utilisent probablement déjà cette propriété de GPO pour les comptes utilisateur ordinaires, uniquement pour les raisons indiquées plus haut.
Quelques réflexions
En écrivant cette courte série d’articles, j’en suis rapidement venu à la conclusion suivante, à laquelle des millions d’informaticiens sont déjà arrivés inconsciemment : on s’efforce toujours de trouver le juste équilibre entre sécurité et commodité. La solution parfaite n’existe pas, et il est probable que vous ayez tendance à privilégier l’aspect pratique (pour éviter de vous faire lyncher par les utilisateurs).
Évidemment, on fait ce qu’on peut avec ce qu’on a. Mais dans ce cas, vous devez compenser les failles de sécurité potentielles en mettant en place une surveillance renforcée ! Vous voyez ou je veux en venir.
Une dernière mise en garde avant de vous laisser, et je vous renvoie pour cela vers ma super série d’articles dans laquelle j’ai joué les testeurs d’intrusions. J’y ai expliqué comment le fait d’utiliser des groupes Administrateur délégués peut permettre à un hacker de se déplacer plus librement dans un domaine. Tout cela parce que les comptes figurent dans plusieurs groupes Active Directory. Retournez y jeter un œil !
