Vous pouvez atténuer le risque en cochant la case dans l'onglet du compte > options du compte pour "Le compte est sensible et ne peut pas être délégué" pour vos comptes administratifs privilégiés.
La délégation contrainte est une fonctionnalité quelque peu inhabituelle et mal comprise de l'Active Directory. Ce n'est pas nouveau ; cela existe depuis Windows 2003.
Avant la délégation "contrainte", la délégation de la capacité d'usurper un autre compte utilisateur pour effectuer des fonctions en leur nom avait des "contraintes" minimales. Cela signifie qu'avec une délégation non contrainte, si vous avez un jeton de niveau "délégation" pour un autre compte utilisateur, vous pouvez usurper ce compte et accéder à toutes les ressources sur n'importe quel serveur en tant que ce compte utilisateur. C'était, comme vous pouvez l'imaginer, indésirable dans des environnements à haute sécurité. Les jetons sont généralement disponibles lorsque l'utilisateur se connecte en entrant ses informations d'identification, ou en utilisant l'authentification Windows intégrée. Si vous utilisez l'authentification Windows, vous avez besoin de Kerberos pour obtenir un jeton de niveau "délégation", par opposition à un jeton d'usurpation ou d'identité. IIS expose les jetons utilisateur et facilite l'utilisation de cette fonctionnalité.
La délégation contrainte a traité les risques de la manière suivante :
- le service usurpant le compte ne peut accéder qu'aux ressources dans le domaine où se trouvent le compte usurpé et les services (généralement un domaine "ressource"). Il ne peut pas accéder aux ressources dans des domaines de confiance. (Bien qu'il puisse usurper n'importe quel compte de n'importe quel domaine de confiance).
- limiter les serveurs auxquels le service usurpant pourrait accéder ;
- limiter davantage la portée en spécifiant le type de service (CIFS, LDAP, SQL, etc).
Une autre subtilité cependant : avec la délégation contrainte, il est possible de créer un jeton pour usurper n'importe quel compte utilisateur dans n'importe quel domaine, et ce compte n'a pas besoin de saisir d'abord ses informations d'identification, comme avec la délégation non contrainte. Il est trivial d'écrire seulement quelques lignes de code .NET pour cela, en fournissant les autorisations appropriées et en configurant correctement le serveur où l'usurpation est effectuée.
Donc oui, c'est puissant, c'est pourquoi Microsoft fournit des avertissements effrayants dans la documentation sur les sujets de délégation. Mais avec cette case cochée, les comptes privilégiés ne peuvent pas être usurpés.
Notez que dans certains scénarios, l'exposition au risque est une question de perspective. Certains préféreraient la capacité de délégation et d'usurpation plutôt que de transmettre des mots de passe au-delà d'une frontière de sécurité. Dans un environnement où il n'y a pas de mots de passe (comme avec certaines cartes à puce), l'usurpation et la délégation peuvent être l'une des rares façons d'effectuer certaines fonctions de manière pratique.
Je n'ai pas utilisé cette fonctionnalité de Citrix, mais s'il est possible d'utiliser le Catalogue Global (GC:// versus LDAP://, port 3268/3269 au lieu de 389/636), cela pourrait atténuer davantage le risque, car le Catalogue Global est en lecture seule. Ils ne devraient pas avoir besoin de mettre à jour AD s'ils ne font que s'authentifier.
