Les silos d’Authentification Active Directory
Introduction
L’un des problèmes principaux dans la sécurisation d’un domaine Active Directory est la dissémination des secrets d’authentification.
Un utilisateur disposant de privilèges d’administration sur une machine est en mesure, par exemple, de récupérer les secrets d’authentification (condensat NTLM, tickets Kerberos) qui sont stockés dans le processus LSASS.
Il est également possible d’usurper l’identité d’un utilisateur authentifié via l’injection dans un processus ou la création d’une tâche planifiée.
De fait, si un utilisateur disposant de privilèges importants sur le domaine Active Directory est connecté, ou a été connecté depuis le dernier redémarrage, sur un serveur compromis, un attaquant pourrait être en mesure de récupérer ses secrets d’authentification et donc compromettre le domaine.
Prenons l’exemple suivant au sein du domaine lab.local :
L’utilisateur LAB\t0_user, membre du groupe Administrateur du Domaine est connecté sur la machine W10-WKS01;
L’utilisateur LAB\user est Administrateur local de cette machine.
Via l’utilisation de l’outil lsassy, l’utilisateur LAB\user peut récupérer le condensat NT ou le TGT de l’utilisateur LAB\t0_user et donc usurper son identité et ses privilèges au niveau du domaine.
Dump du processus lsass
Pour limiter ce problème, des modèles d’administration doivent être mis en place, en particulier le modèle en Tiers.
Le modèle en Tiers
Avant de rentrer dans le vif du sujet des Silos d’Authentification, un petit rappel sur le modèle en Tiers s’impose.
Une architecture en Tiers est largement recommandée dans les Systèmes d’Information afin de segmenter au mieux les différents niveaux de criticités des actifs.
Microsoft a également recommandé cette architecture pour les domaines Active Directory, afin de répondre à certaines problématiques liées au fonctionnement intrinsèque de l’authentification Windows (enregistrement des secrets, Pass-The-Hash, etc…).
En effet, si un tiers est compromis aucun secret d’authentification d’administrateurs des autres tiers ne peut s’y retrouver empêchant ainsi le déplacement vertical et l’élévation de privilèges dans le domaine.
3 tiers sont recommandés habituellement :
Le Tiers 0 (T0) qui contient l’ensemble des serveurs critiques : Contrôleurs de Domaine, PKI, etc…
Le Tiers 1 (T1) qui contient les autres serveurs du SI. Ce tiers peut être découpé en plusieurs niveaux en fonction des besoins
Le Tiers 2 (T2) qui contient les autres ressources du SI, en particulier les postes de travail
Segmentation du modèle en Tiers recommandé par Microsoft
Ce modèle passe par deux éléments afin de cloisonner les tiers :
- Des restrictions de connexions afin d’interdire aux administrateurs d’un tiers de se connecter sur les actifs d’un tiers différent. Cet article détaille une méthode pour les mettre en place.
Restrictions de connexions recommandées
De la délégation sur les objets du domaine afin de limiter les permissions des administrateurs de chaque tiers et empêcher des chemins d’attaque.
Modèle de délégation à appliquer
Afin de mettre en place les restrictions d’accès, deux méthodes principales existent :
Utilisation des GPO pour restreindre les privilèges d’authentification sur les machines du domaine ;
Utilisation des silos d’authentification (Authentication Policy et des Authentication Policy Silos) pour contrôler les demandes d’accès sur les machines du domaine.
Dans un premier temps, nous allons identifier les avantages et inconvénients des deux méthodes
Puis nous allons rentrer spécifiquement dans les composants des silos d’authentification avant de voir leurs mises en œuvre.
GPO vs Authentication Policy
GPO
Les restrictions de connexions par GPO utilisent les… GPO afin de mettre en place les restrictions sur les comptes machine.
Ces restrictions sont basées sur 5 types d’accès et privilèges distincts :
Connexion interactive : SeInteractiveLogonRight et SeDenyInteractiveLogonRight
Connexion en tant que compte de service : SeServiceLogonRight et SeDenyServiceLogonRight
Connexion en tant que tâches planifiées : SeBatchLogonRight et SeDenyBatchLogonRight
Connexion via RDS : SeRemoteInteractiveLogonRight et SeDenyRemoteInteractiveLogonRight
Accès à la machine via le réseau : SeNetworkLogonRight et SeDenyNetworkLogonRight
Une configuration correcte par GPO permet de grandement limiter les authentifications, mais comporte plusieurs écueils :
Le fonctionnement intrinsèque des GPO avec la possibilité de les surcharger, d’écraser les paramètres et de bloquer l’héritage peuvent rendre complexe l’implémentation et l’administration ;
Dans certains cas, un administrateur d’un Tiers peut modifier les GPO et ainsi supprimer les restrictions ;
L’administrateur d’une machine peut modifier les privilèges, sans passer par les GPO, même temporairement, pour diminuer le niveau de sécurité de la machine ;
De plus, dans le cadre d’une authentification NTLM, la vérification des privilèges se fait après l’authentification. Un attaquant peut ainsi être en mesure de récupérer des secrets d’authentification (défi/réponse, mot de passe…) si un administrateur tente de se connecter à la machine via ce protocole.
Lors de l’utilisation du protocole Kerberos, même si l’autorisation est réalisée après l’authentification, les secrets ne seront pas stocké en mémoire sur la machine. C’est pourquoi l’utilisation du groupe Protected Users est fortement recommandée afin d’empêcher l’utilisation du protocole NTLM pour l’authentification des comptes à privilège.
Silos d’Authentification
Les Silos d’Authentification, quant à eux, reposent uniquement sur des fonctionnalités du protocole Kerberos (et des objets LDAP) afin de définir si un utilisateur peut s’authentifier sur une machine ou accéder à un service. En particulier, les implémentations suivantes sont utilisées :
Le Kerberos Armoring ;
Les revendications (Claims) ;
L’authentification Composée.
Le fonctionnement de ces implémentations sera détaillé dans les sections suivantes.
Cette méthode permet de s’affranchir de l’administration et des failles liées aux GPO.
De plus, ces composants étant limités au protocole Kerberos, le protocole NTLM ne peut (et ne doit) pas être utilisé pour les authentifications des Administrateurs.
La mise en place des Silos d’Authentification demande néanmoins de prendre en compte certaines contraintes.
En particulier, il peut être assez complexe de les mettre en œuvre en fonction du système d’information. Une bonne maitrise de l’Active Directory est donc un prérequis essentiel. Il est important d’identifier précisément les cas d’usage (support, administration des serveurs) afin de vérifier s’ils sont compatibles avec les silos d’authentification.
En cas de mauvaise prise en compte des besoins, des connexions légitimes peuvent être bloquées, ce qui peut avoir un impact sur la production.
Par exemple, si un prestataire externe utilise une machine hors du domaine et un VPN pour réaliser l’administration des serveurs d’un silo, la connexion ne sera plus possible. Il faudra ainsi trouver une solution de contournement (machine physique, bastion…).
De plus, cela rajoute une couche dans l’administration d’un domaine et il est nécessaire de documenter précisément l’exploitation (ajout d’objets dans le silo, revue des événements) afin d’assurer un niveau de sécurité adéquat.
Les silos, à eux seuls, ne sont pas suffisant et ils doivent être combiné notamment avec des machines d’administration sécurisées (PAW), LAPS ainsi que de la segmentation et du filtrage réseau.
Un modèle en Tiers, configuré avec les GPO et les Silos d’Authentification, peut également être utilisé afin de garantir une défense en profondeur.
Composants principaux des Silos d’Authentification
Comme indiqué précédemment, différents composants sont utilisés afin de faire fonctionner les silos d’authentification. Les sections suivantes permettent d’expliquer le fonctionnement et le rôle de chacun d’entre eux dans l’implémentation des silos.
Rappels sur Kerberos
Le protocole Kerberos (voir cet article sur le blog hackndo pour une explication détaillée) est au coeur des silos d’Authentification et il s’agit d’un des principaux protocole d’authentification dans un domaine Active Directory.
Néanmoins, afin de comprendre certains composants, un rappel rapide est nécessaire.
Le protocole Kerberos est l’un des principaux protocoles d’authentification dans un domaine Active Directory. Il permet notamment la mise en place du Single Sign-On, afin que les utilisateurs n’aient pas besoin de renseigner leurs identifiants pour accéder à chaque ressource.
3 entités sont requises :
Le client - l’entité (utilisateur, ordinateur, service) qui souhaite accéder à un service (ordinateur ou fichier par exemple)
Le KDC (Key Distribution Center) - L’entité qui va gérer l’authentification (vérification des identifiants)
Un service - l’entité à laquelle le client souhaite accéder
Pour éviter que les mots de passe transitent sur le réseau, ce protocole se base sur l’échange de Ticket. On retrouve deux tickets différents :
Le TGT (Ticket Granting ticket) - Ce ticket est fourni au client lors de la première phase d’authentification auprès du KDC. Il est par la suite utilisé pour demander l’accès aux services via un Service Ticket (ST)
Le Service Ticket - Ce ticket est fourni au client par le KDC lorsque ce dernier veut accéder à un service. Il est par la suite transmis au service afin de prouver l’authentification et l’identité de l’utilisateur
Les échanges suivants prennent place lorsqu’un client s’authentifie et demande à accéder à un service :
Échanges lors d’une authentification Kerberos
AS_REQ : Le client s’authentifie sur une machine et demande un TGT au KDC
AS_REP : Si les données d’authentification sont correctes, le KDC retourne un TGT à l’utilisateur
TGS_REQ : Le client veut accéder à un service, il demande donc au KDC un ticket de service en utilisant comme preuve d’authentification son TGT.
TGS_REP : Le KDC retourne un Ticket de Service pour l’utilisateur
AP_REQ : Le client présente son Ticket de Service au service cible afin de prouver son authentification
AP_REP : Le service valide ou non l’accès de l’utilisateur
Prérequis
Avant de rentrer plus en avant dans le détail, il est nécessaire d’évoquer les différents prérequis pour pouvoir utiliser les Silos d’Authentification.
Il faut que le Niveau Fonctionnel du domaine soit d’au moins 2012R2.
Il est également important de prendre en compte les points suivants :
Les Silos ne fonctionnent pas pour les machines Linux intégrées au domaine ;
Les Silos ne fonctionnent pas pour les utilisateurs d'une autre forêt ;
Le kerberos armoring, les revendications et l’authentification composée ne fonctionne que sur les postes de travail à partir de Windows 8 et sur les serveurs à partir de 2012.
Authentication Policy
Les Authentication Policies sont des objets permettant de définir les propriétés des tickets Kerberos et les contrôles d'accès appliqués sur les objets d'un silo.
Il est notamment possible de définir :
La durée de vie du TGT ;
Les critères d’authentification pour les comptes, les comptes de services et les comptes machine.
Trois types d'objets peuvent être couverts par une Authentication Policy :
Objets User :
- Il est possible de définir depuis et vers quelles machines l’utilisateur peut s’authentifier
Objets "Compte de service" :
Comprend les MSA, gMSA, dMSA
Il est possible de définir auprès de quelle(s) machine(s) les comptes de service peuvent être utilisés
Objets Computer :
- Il est possible de définir quels sont les utilisateurs qui peuvent accéder à un service qui est lancé sous le contexte du compte machine.
Avec ces différents attributs, les administrateurs peuvent contrôler et limiter précisément l’authentification des utilisateurs dans un silo. Ce qui permet donc de réduire grandement la dissémination des secrets d’authentification.
Authentication Policy Silos
Ce type d’objet est tout simplement un conteneur permettant de faire le lien entre une Authentication Policy et les utilisateurs, comptes de services et machines d’un silo.
Kerberos Armoring
Lors de certains échanges Kerberos, certains “blocs” sont chiffrés uniquement avec le secret du compte qui s’authentifie.
C’est par exemple le cas du bloc pA-ENC-TIMESTAMP qui est directement chiffré avec le secret du compte.
Bloc pA-ENC-TIMESTAMP d’un échange AS-REP
En cas de récupération de cette échange (ou si la préauthentification est désactivée pour le compte) il est donc possible de réaliser une attaque par force brute sur ces blocs et potentiellement récupérer le mot de passe du l’utilisateur. C’est par exemple le cas de l’attaque AS-REP Roasting.
Le Kerberos Armoring permet de répondre à cette problématique en ajoutant une couche de chiffrement supplémentaire, utilisant en plus du secret du compte qui s’authentifie, celui de la machine vers lequel le compte s’authentifie.
Dans un échange AS_REQ utilisant du Kerberos Armoring, le bloc pA-ENC-TIMESTAMP est remplacé par un champ pA-PX-FAST contenant 3 champs :
armor: Indiquant le type de blindage et contenant généralement le TGT de la machine d’où provient l’authentification
req-checksum : Un checksum pour vérifier l’intégrité de la requête
enc-fast-req : Contient les données d’authentification
Bloc pA-FX-FAST
L’objectif est donc double :
Ajouter de la sécurité empêchant des attaques hors-ligne sur les échanges Kerberos ;
Permettre au KDC de savoir depuis quelle machine l’utilisateur s’authentifie.
Revendication Kerberos
Les revendications (Claims) sont des chaines de caractères et elles sont ajoutées lors des échanges Kerberos TGS-REP lors de l’authentification d’un objet. Elles peuvent être utilisées afin de définir des règles de contrôles d’accès.
On peut, par exemple, retrouver la valeur dans le champ Client Claims Info :
Revendication de l’utilisateur
On remarque une revendication Kerberos avec la valeur “T0”, indiquant que notre utilisateur fait partie du silo T0.
On retrouve différents types de revendications possibles au niveau d’un domaine Active Directory :
AD : La revendication est générée à partir d'un attribut LDAP (par exemple l’attribut description)
Certificat : La revendication est basée sur un attribut d'un certificat X.509
TransformPolicy : La revendication est basée sur une Claims Transform Rules pour traduire une revendication venant d'une autre forêt
Constructed : La revendication est générée automatiquement. Actuellement il n’existe que les revendications Construted de type AuthenticationSilo. Ces dernières sont utilisées par les Authentication Policy pour autoriser ou non l’accès à un compte.
L’authentification composée
Lors de l’authentification Kerberos, les données d’autorisation de l’utilisateur sont inclues dans le PAC. Cette structure contient, entre autres, le SID de l’utilisateur ainsi que le SID des groupes auxquels il appartient.
Les contrôles d’accès se basent sur ces informations.
L’authentification composée reprend l’ensemble des composants principaux détaillées précédemment pour inclure les données d’autorisation de la machine sur laquelle l’utilisateur est connecté en plus de ses propres données.
Cela permet donc de mettre en place des ACE basées sur ces nouvelles données et rendre la gestion des accès encore plus granulaire.
Par exemple, il est possible de définir que les comptes avec la revendication “T0” peuvent s’authentifier sur et depuis les machines ayant également une revendication “T0”.
Mise en place
Comme expliqué précédemment, il est possible de créer des politiques d’accès différentes en fonction des types d’objets.
Pour les objets utilisateur :
Auprès de quelles machines les utilisateurs peuvent s’authentifier
Quels objets peuvent accéder à un service qui est exécuté sous le contexte du compte utilisateur
Pour les comptes de service :
Auprès de quelles machines les comptes de service peuvent s’authentifier
Quels objets peuvent accéder à un service qui est exécuté sous le contexte du compte de service
Pour les comptes machine :
- Quels objets peuvent accéder à un service qui est exécuté sous le contexte du compte machine
Les sections ci-dessous détaillent la mise en place d’un silo d’authentification pour la connexion des utilisateurs sur les machines d’un tiers spécifique, le tiers 0 dans cet article. Les autres configurations reposant sur le même principe, elles ne seront pas détaillées.
Configuration des prérequis
Activation au niveau des Contrôleurs de Domaine (DC)
En premier lieu, il est nécessaire d’activer le support des revendications, de l’authentification composée et du Kerberos Armoring au niveau des contrôleurs de domaine.
Cela se fait via la GPO suivante :
Computer Configuration | Administrative Templates | System | KDC | Key Distribution Center (KDC) support for claims, compound authentication and Kerberos armoring
Différentes options sont possibles :
Not supported
Supported
Always provide claims
Fail unarmored authentication requests
Afin d’utiliser les silos d’authentification, il est nécessaire d’appliquer l’option « Always provide claims ».
Activation du support des revendications, de l’authentification composée et du Kerberos Armoring au niveau des DC
Un redémarrage n’est pas nécessaire, il faut néanmoins mettre à jour les GPO sur les Contrôleurs de Domaine.
Activation au niveau des clients
Dans un second temps, il est nécessaire d’activer le support du Kerberos Armoring, des revendications et de l’authentification composée pour les clients Kerberos. C’est-à-dire sur l’ensemble des machines faisant parties des silos à minima.
Cela se fait également via GPO :
Computer Configuration | Administrative Templates | System | Kerberos | Kerberos client support for claims, compound authentication and Kerberos armoring
Activation du support des revendications, de l’authentification composée et du Kerberos Armoring au niveau des clients Kerberos
Là aussi, pas besoin de redémarrer mais il faut attendre le déploiement de la GPO ou le forcer (gpupdate /force sur la machine) et faire une purge des tickets Kerberos (klist purge).
Configuration de l’Authentication Policy
Pour rappel, le but premier est de limiter la propagation des secrets d’authentification des objets d’un tiers vers les autres. De fait, les objets membres du tiers 0 (T0), et les serveurs critiques, ne doivent pouvoir s’authentifier que sur les objets du tiers 0.
La configuration ci-dessous va donc présenter une méthode pour autoriser les objets du T0 à s’authentifier auprès des machines du T0 uniquement.
Il est en premier lieu nécessaire de créer une Authentication Policy avant de créer un Authentication Policy Silo.
La configuration se fait soit via l’Active Directory Administrative center, soit via PowerShell.
La méthode via l’Administrative Center est expliquée ci-dessous.
Dans l’Active Directory Administrative Center, se rendre dans Authentication puis Authentication Policies :
Accès à l’Authentication Policy dans Active Directory Administrative Center
Il faut ensuite créer une nouvelle politique d’authentification.
Configuration de l’Authentication Policy - Partie 1
La première section (1) permet de définir un nom, une description et si la politique est en mode audit ou en mode appliquée. Le mode audit est nécessaire lors de la première phase de déploiement afin d’auditer les connexions en échec et y remédier.
La deuxième section (2) permet de définir les objets couverts par cette politique. Les paramètres du mode d’application et des comptes couverts sont écrasés par la configuration du Silo d’Authentification (voir la section suivante), ils n’ont donc aucun impact.
La troisième section (3) comporte le ou les Silos utilisant cette politique. Il s’agit d’un backlink et il n’est pas possible de le configurer ici.
Les paramètres détaillés dans les parties suivantes permettent de mettre en place les politiques effectives.
User Sign On
Cette section permet de définir les conditions d’authentification pour les utilisateurs du silo.
Configuration de l’Authentication Policy - Partie 2
Il est possible de configurer plusieurs paramètres :
Require rolling NTLM secret for NTLM authentication (1): Le mot de passe des utilisateurs avec l’attribut “Smart card is required for interactive logon” est renouvelé
Ticket-Granting-Ticket Lifetime (2): Permet de spécifier la durée de vie du TGT pour les comptes utilisateurs
Allow NTLM network authentication when user is restricted to selected device (3): Autorise l’utilisation du protocole… NTLM pour s’authentifier sur les machines du silo. Évidemment, ce paramètre ne doit pas être activé.
Conditions (4) :
Ce dernier paramètre permet de définir les conditions d’accès à proprement parler.
Actuellement, il est possible d’utiliser deux conditions distinctes :
L’appartenance (ou non) d’un utilisateur à un ou plusieurs groupes
L’appartenance (ou non) d’un utilisateur à un silo
L’exemple suivant montre la configuration via l’appartenance à un groupe spécifique.
Conditions pour l’Authentication Policy - Exemple 1
Afin de simplifier la configuration, il est possible de définir que les utilisateurs membres d’un silo pourront s’authentifier sur les machines de ce même silo avec la condition suivante :
Condition pour l’Authentication Policy - Exemple 2
Une fois cette configuration effectuée, il faut créer une Authentication Policy Silo.
Authentication Policy Silos
Comme expliqué préalablement, l’Authentication Policy Silo permet de faire le lien entre les objets du silo et l’Authentication Policy.
La configuration se fait soit via l’Active Directory Administrative center, soit via PowerShell. La méthode via GUI est expliquée ci-dessous.
Dans Active Directory Administrative Center, se rendre dans Authentication puis Authentication Policies Silos :
Accès à l’Authentication Policy Silos dans Active Directory Administrative Center
Différents paramètres sont à configurer :
Configuration Authentication Policy Silos
On retrouve donc le nom, la description et le mode d’application (audit ou appliquée) (1). Les objets du silo (Utilisateurs et machines) sont également à définir ici (2).
La section Authentication Policy (3) permet de définir une Authentication Policy en fonction du type de compte (User account, MSA account, Computer account). Il est également possible de définir que l’ensemble des objets sont couverts par une seule et unique Authentication Policy. Dans notre cas, cela est suffisant.
Finalement, pour assigner un silo à un objet, il faut se rendre dans l’Active Directory Administrative Center au niveau de l’objet et dans l'onglet Silos, lui attribuer celui-ci :
Assignation d’un silo à un utilisateur
Mode Audit
Afin de mener correctement le projet de mise en place des Silos d’Authentification, il est fortement recommandé d’activer le mode d’audit dans un premier temps.
Pour rappel, ce mode peut se configurer au niveau de :
L’authentication Policy
L’authentication Policy Silo
La configuration effectuée au niveau de l’Authentication Policy Silo aura la priorité.
Activation du mode Audit
Cela va permettre de générer des événements en cas d’erreur d’authentification liée aux silos et donc de corriger la configuration pour éviter les problèmes lors de la mise en production.
Les événements sont stockés sur les DC dans :
Application and Services logs/Microsoft/Windows/Authentication
Par défaut, les événements sont désactivés :
Évenements désactivés
Pour les activer, il faut faire un clic droit sur le journal puis cliquer sur Enable Logs :
Il est possible de retrouver les événements suivants :
Évenements générés avec les Authentication Policy Silos
Conclusion
Le modèle en Tiers et son implémentation sont des sujets importants lorsqu’un domaine Active Directory est présent au sein du système d’information (SI).
Ce modèle, bien que n’empêchant pas d’exclure tout risque à lui seul, permet de correctement isoler les zones de criticité afin de restreindre les attaquants.
Il est néanmoins nécessaire de corriger les vulnérabilités identifiées sur le SI avant de mettre en oeuvre ce modèle, au risque d’avoir un faux sentiment de sécurité. En effet, la dissémination des secrets d’authentification n’est pas le problème principal si tout le monde peut passer Administrateur du Domaine à cause d’une vulnérabilité l’autorité de certification ADCS.
Les silos d’authentifications permettent d’apporter une granularité dans l’administration et une sécurité qu’il n’était pas possible d’obtenir avec les GPO uniquement. La mise en place de cette solution sur les actifs du Tiers 0, dans un premier temps, peut donc apporter un vrai plus.
Les comptes d’administration sensibles sont donc encadrés et limités au maximum afin d’éviter toute utilisation abusive.
Il est tout de même essentiel de correctement cadrer ce projet afin d’identifier l’ensemble des cas d’usage potentiels et ainsi limiter les problèmes de production. Des tests approfondis en mode audit doivent être menés avant le déploiement et à chaque modification.
Cette solution nécessite une connaissance approfondie du SI.
De plus, les silos d’authentification ajoutent une charge non négligeable à l’administration.
Bien utilisés, les silos d’authentification sont une brique de sécurité importante qui complète le modèle en Tiers et les autres mécanismes de sécurité de l’Active Directory.
