Nous utilisons des cookies et d’autres technologies sur notre site web pour vous proposer l’ensemble de nos fonctionnalités. Ils peuvent également être mis en place à des fins d’analyse. En continuant à utiliser notre site web, vous acceptez l’utilisation de cookies. Pour plus d’informations, notamment sur la manière de les désactiver, veuillez consulter notre politique de confidentialité.
Sécuriser les jetons d’authentification en empêchant la délégation des comptes d’administrateur
Les capacités sous-jacentes fournies par l’authentification Kerberos dans Active Directory signifient que les jetons d’accès peuvent être délégués aux utilisateurs et aux ordinateurs à des fins diverses. Les cyber-attaquants peuvent tirer parti des capacites intégrées d’Active Directory en matière d’usurpation d’identité et de délégation et ainsi compromettre des ressources sensibles. Cet article détaille les paramètres que nous vous recommandons d’activer dans Active Directory afin de minimiser les risques associés à la délégation de comptes sur des ordinateurs non sécurisés et des comptes administrateurs.
Jetons d’accès et niveaux d’usurpation d’identité
Dans un environnement client-serveur, un jeton spécial appelé jeton d’imitation (usurpation) permet à un thread de s’exécuter dans le contexte sécurisé d’un utilisateur ou d’un ordinateur.
Certains services réseau exécutés dans l’environnement déterminent les autorisations et les niveaux d’accès attribués en fonction de l’imitation. Par exemple, lorsque certains services de serveur s’exécutent, ils utilisent brièvement le jeton d’imitation pour déterminer les privilèges attribués et les ressources auxquelles un utilisateur peut accéder.
Lorsque l’imitation est invoquée, cela signifie que le client a autorisé le serveur à agir comme un client en son nom. Il existe différents niveaux d’imitation que Microsoft appelle les niveaux d’usurpation d’identité. Chaque niveau détermine la latitude accordée au serveur pour agir au nom du client.
Il existe quatre niveaux d’imitation :
- Anonyme – Le client est anonyme pour le serveur. Bien que le serveur puisse usurper l’identité du client, le jeton d’usurpation ne contient aucune information sur le client.
- Identifier – Le niveau par défaut du système est configuré pour identifier. À ce niveau, le serveur peut usurper l’identité du client pour effectuer des vérifications de la liste de contrôle d’accès (ACL).
- Usurper – Le serveur peut se faire passer pour le client et son contexte de sécurité avec le niveau Usurper. Le serveur peut acceder aux ressources locales en tant qu’identité du client. Dans le cas d’un accès à distance, il ne peut accéder qu’aux ressources qui se trouvent sur le même ordinateur que le serveur.
- Délégué – Le délégué est le plus puissant et le plus dangereux des niveaux d’imitation. S’il est sélectionné, le serveur peut utiliser les informations d’identification du client, localement comme à distance. Ces informations peuvent être transmises à tous les ordinateurs.
Vous pouvez en savoir plus sur les niveaux d’usurpation d’identité auprès de Microsoft par ici : Niveaux d’usurpation d’identité (COM) – applications Win32 | Microsoft Learn.
L’utilisation du niveau d’usurpation d’identité du délégué comporte des exigences supplémentaires. Parmi lesquelles :
- Le client doit définir le niveau d’impersonnalisation sur RPC_C_IMP_LEVEL_DELEGATE.
- Le compte serveur doit être marqué avec l’attribut « Trusted for delegation » dans le service Active Directory.
- Tous les serveurs et clients en question doivent être en cours d’exécutions dans le domaine.
Implications en matière de sécurité des admins délégables
Grâce à des outils disponibles gratuitement, les attaquants peuvent facilement compromettre un client et accéder à un compte standard. Une fois qu’ils ont ouvert une brèche, ils peuvent utiliser des outils comme Meterpreter pour répertorier les jetons de délégation disponibles. Les comptes privilégiés disposant de jetons de délégation peuvent permettre à l’attaquant de voler un jeton d’utilisateur privilégié, comme le compte d’administrateur de domaine par exemple. Une fois que l’attaquant dispose d’un compte de niveau administrateur de domaine, ses possibilités de nuisance sont infinies.
Une fois qu’ils disposent de comptes privilégiés de haut niveau, les cyber-attaquant se concentrent souvent sur les fichiers de sauvegarde susceptibles de contenir des données précieuses, comme les sauvegardes de la base de données NTDS.DIT d’Active Directory. S’ils trouvent ces sauvegardes, ils peuvent copier la base de données hors site et exécuter un outil hors ligne pour compromettre encore davantage les comptes de l’organisation.
Le paramètre « Le compte est sensible et ne peut être délégué ».
Microsoft fournit un paramètre dans les services de domaine Active Directory qui peut aider à atténuer le problème. En outre, il est recommandé d’activer un paramètre Active Directory pour les comptes privilégiés du domaine. Le paramètre est « le compte est sensible et ne peut être délégué » dans les propriétés du compte.
Lorsqu’il est configuré, ce paramètre retire le jeton de niveau délégué de l’utilisateur, supprimant ainsi les informations d’identification de l’utilisateur. Une fois qu’il est coché, la connexion est une connexion ANONYME sans autorisation de ressources.
Ce compte est un paramètre sensible et ne peut être délégué dans Active Directory.

Lorsque les ordinateurs autorisés à déléguer sont compromis, les attaquants peuvent les utiliser pour accéder aux données stockées sur d’autres serveurs en utilisant les informations d’identification déléguées. C’est pourquoi Microsoft recommande d’utiliser le paramètre « le compte est sensible et ne peut pas être délégué » sur tout ordinateur non sécurisé qui ne dispose que de peu ou pas de sécurité physique ou de comptes d’administrateur, comme les administrateurs de domaine par exemple.
Les comptes administrateurs de domaine disposent d’énormes privilèges et d’un accès illimité aux ressources et aux données des serveurs dans l’organisation. En outre, si un ordinateur est autorisé à déléguer, vous pouvez utiliser la délégation restreinte et d’autres techniques pour atténuer les risques lorsque la délégation est utilisée.
Rapport Specops Delegable Admins
Dans le but de renforcer et d’améliorer la politique de cybersécurité de votre organisation, il est crucial d’avoir une visibilité des comptes administrateurs qui n’ont pas configuré le paramètre « Le compte est sensible et ne peut être délégué ». Bien que vous puissiez créer des scripts PowerShell pour interroger les différents attributs des utilisateurs et des ordinateurs du domaine, il existe un moyen beaucoup plus simple. Specops Password Auditor (gratuit) fournit un rapport intégré appelé « Admins délégables ».
Avec le rapport Delegable Admins, Specops Auditor offre une visibilité rapide sur tous les comptes de niveau administrateur. Les organisations intéressées par la sécurisation des jetons d’authentification trouveront ce rapport utile pour les aider à auditer les comptes qui devraient être marqués comme « sensibles et ne pouvant être délégués » au sein de leur environnement.

De plus le rapport « Delegable Admins », il fournit de nombreuses autres fonctionnalités et rapports utiles pour renforcer la sécurité des comptes Active Directory, avec notamment la détection des comptes dont les mots de passe sont compromis.
FAQ sur la délégation et l’usurpation d’identité
Pourquoi la délégation peut-elle être dangereuse ? Bien qu’elle puisse être utilisée dans certains cas, la délégation d’ordinateurs non sécurisés ou de comptes privilégiés, tels que les comptes d’administrateur de domaine, peut constituer une cible de choix pour les attaquants souhaitant mener une elevation de privilege.
Existe-t-il des moyens d’atténuer le risque d’usurpation de compte ? Oui, Microsoft fournit un paramètre dans Active Directory appelé « Le compte est sensible et ne peut être délégué ». Si vous définissez cette option pour un compte, celui-ci sera considéré comme sensible et le jeton de niveau délégué sera supprimé, ce qui forcera une connexion ANONYME. En outre, si la délégation est utilisée, elle doit être configurée de façon restreinte afin de limiter le domaine de la délégation. Enfin, les administrateurs doivent garder un œil sur tous les comptes administrateurs qui ne sont pas marqués comme sensibles.
Comment détecter les comptes admin dont le compte n’est pas marqué comme sensible ? En utilisant PowerShell, vous pouvez interroger les attributs configurés et trouver les comptes admin qui ne sont pas marqués comme sensibles. Cependant, Specops Password Auditor offre un moyen plus facile avec le rapport « Delegable Admins ». Il permet de créer des rapports exécutifs détaillant les admins délégables et d’autres informations d’audit de mot de passe.
(Dernière mise à jour le 23/03/2023)