Délégation Kerberos : trois mécanismes, trois façons de perdre le domaine
La délégation Kerberos permet à un service d'agir au nom d'un utilisateur. Chacune de ses trois variantes, mal configurée, offre à un attaquant un moyen d'usurper un administrateur. Les repérer est simple ; les corriger demande de la méthode.
Pourquoi la délégation existe
Un utilisateur se connecte à une application web, qui doit interroger une base de données en son nom. La délégation Kerberos permet ce « double saut » : le service frontal agit pour le compte de l'utilisateur auprès d'un second service. Utile, mais chaque mécanisme de délégation confie à un serveur une part du pouvoir des utilisateurs qui s'y connectent. Mal maîtrisé, il devient un chemin vers l'administration du domaine.
La délégation non contrainte
La plus ancienne et la plus dangereuse. Un serveur en délégation non contrainte reçoit une copie du TGT — le ticket maître — de chaque utilisateur qui s'y authentifie, et peut l'utiliser vers n'importe quel service. Si un administrateur du domaine s'y connecte, son ticket reste en mémoire. Pire : des techniques de coercition permettent de forcer un contrôleur de domaine à s'authentifier vers ce serveur, livrant le ticket du contrôleur lui-même.
Seuls les contrôleurs de domaine devraient porter ce paramètre. Tout autre serveur concerné est à traiter en priorité.
La délégation contrainte
Ici, le serveur ne peut déléguer que vers une liste de services définis (attribut msDS-AllowedToDelegateTo). C'est plus sûr, avec une nuance importante : si la transition de protocole est autorisée (« Utiliser n'importe quel protocole d'authentification »), le serveur peut obtenir un ticket au nom de n'importe quel utilisateur, sans que celui-ci se soit connecté. Qui compromet ce serveur peut alors se faire passer pour un administrateur auprès des services cibles — et le nom de service inscrit n'est pas toujours la limite qu'on imagine.
La délégation contrainte basée sur les ressources
Avec la RBCD, c'est la ressource cible qui déclare, dans l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity, quels comptes peuvent déléguer vers elle. Le risque vient des droits d'écriture : un attaquant qui peut modifier cet attribut sur un objet ordinateur peut y inscrire un compte qu'il contrôle, puis obtenir un accès administrateur à la machine. Et par défaut, tout utilisateur du domaine peut créer jusqu'à dix comptes ordinateurs (ms-DS-MachineAccountQuota) : il dispose ainsi du compte nécessaire.
Deux protections simples pour les comptes privilégiés : cocher « Le compte est sensible et ne peut pas être délégué », et les placer dans le groupe Protected Users. Leurs tickets ne seront alors délégués par aucun mécanisme.
Plan d'action
- Lister les comptes et ordinateurs en délégation non contrainte, hors contrôleurs de domaine, et les migrer vers une délégation contrainte.
- Revoir les délégations contraintes avec transition de protocole et en réduire le périmètre.
- Rechercher les attributs RBCD renseignés et les droits d'écriture excessifs sur les objets ordinateurs.
- Ramener
ms-DS-MachineAccountQuotaà zéro et confier la jonction au domaine à un compte dédié. - Protéger tous les comptes administrateurs contre la délégation.
Ces vérifications font partie de tout audit Active Directory sérieux : elles relient une configuration technique discrète à un chemin d'attaque très concret.