Dans cet article, nous allons aborder l’implémentation des Silos d’authentification dans Active Directory.
Introduction
Dans le cadre de la sécurisation d’un environnement active Directory, l’une des bonnes pratiques consiste à implémenter le Tier Model dans le but de limiter les authentifications des comptes à privilèges uniquement aux machines privilégiées.
Par exemple, les comptes administrateurs du domaine (comptes T0) doivent se connecter uniquement aux machines impliquées dans l’authentification active Directory, telles que les contrôleurs de domaine, les serveurs ADCS, etc… Cela vise à limiter le risque d’escalade des privilèges verticale avec par exemple une attaque de type « pass to hash » qui consiste à utiliser un hash de mot de passe d’un compte privilégié stocké dans le cache d’une machine d’un niveau inférieur, comme illustré dans le schéma ci-dessous.
Il existe deux méthodes pour restreindre les connexions des comptes à certaines machines :
- La segmentation des Tiers de confiance via des GPO d’attribution de droits utilisateurs qui nécessitent une politique de GPO bien maîtrisée.
- La segmentation des Tier de confiance via les silos d’authentification. Ils permettent d’appliquer un silo à des comptes utilisateurs, qui pourront s’authentifier uniquement sur les machines de leur propre silo.
Ces deux approches facilitent la segmentation des Tiers lors de la mise en œuvre du tier model, comme illustré dans le schéma ci-dessous :
Prérequis
L’implémentation des silos d’authentification nécessite l’application des prérequis suivants :
- Niveau fonctionnel de domaine au moins en 2012R2.
- L’activation de la prise en charge du contrôle d’accès dynamique et du blindage Kerberos sur les contrôleurs de domaine
- L’activation de la prise en charge de revendications sur les postes clients, ce qui nécessite d’avoir des serveurs membres minimums en 2012 et des postes clients minimums en Windows 8.
Attention : si vous avez des systèmes d’exploitation non supportés dans le silo, les utilisateurs du silo ne pourront pas se connecter sur ces machines, quand bien même elles feraient partie du silo.
Si vous avez encore des serveurs membres ne respectant pas ces prérequis, il est fortement conseillé d’appliquer un silo d’authentification uniquement sur vos ressources T0. La segmentation des autres Tiers peut être assurée par la méthode 2.
Il est à noter également qu’un compte ordinateur ou utilisateur ne peut faire partie que d’un seul silo. À vous de bien structurer vos silos d’authentification.
Si vous souhaitez administrer des machines en RDP membres d’un Silo, deux conditions sont nécessaires :
- Disposer d’un compte d’administration membre du silo.
- Disposer d’une machine d’administration membre du silo (PAW).
Notez que Microsoft recommande de placer les comptes utilisateurs faisant partie d’un silo Authentification dans le groupe « Protected Users » afin de forcer une authentification Kerberos avec ces comptes utilisateurs. Les silos d’authentification s’appuyant sur les révocations Kerberos. Pour plus d’informations sur le groupe « Protected Users », nous vous invitons à consulter la documentation Microsoft.
Mise en place
Application des paramètres de GPO sur les contrôleurs de domaine et sur les clients
Sur les contrôleurs de domaine, activez le paramètre « Prise en charge du contrôleur de domaine Kerberos pour les revendications, l’authentification composée et le blindage Kerberos » situé dans Configuration Ordinateur/Système/KDC.
L’option « toujours fournir les revendications » est préconisée par Microsoft pour les domaines en 2012R2, car elle permet une vérification des revendications, quand des hôtes ne prenant pas en charge les revendications sont utilisés pour connecter les services prenant en charge les revendications. Mais l’option « prise en charge » fonctionne également pour le cas des silos d’authentification.
Il est à noter que l’option « Rejeter les demandes d’authentifications non blindées » doit être utilisée avec parcimonie. Avec cette dernière, les systèmes d’exploitation non compatibles avec le blindage ne sont plus en mesure de s’authentifier sur un contrôleur de domaine ayant ce paramètre activé.
Sur les clients Kerberos il est nécessaire d’activer le paramètre de GPO « Prise en charge du client Kerberos pour les revendications, l’authentification composée et le blindage Kerberos » situé dans Configuration ordinateur/Système/Kerberos.
Création d’une « Authentification Policy »
Une stratégie d’authentification « Authentification Policy », permet de définir des paramètres d’authentification pour les comptes. Il y a divers paramètres comme la durée du TGT, limitation du protocole NTLM à certains devices, conditions d’authentifications, etc..
Vous trouvez ci-dessous un tableau correspondant aux différents paramètres issus de la documentation officielle Microsoft :
La création d’une stratégie d’authentification peut se faire de deux manières, par l’utilisation de la console active Directory Admin Center ou en PowerShell. Autant être transparent, nous allons vous montrer les deux méthodes. La partie graphique est intéressante pour comprendre son fonctionnement, cependant vous allez vite vous rendre compte que dans un contexte de production avec de nombreuses machines et de nombreux utilisateurs, l’utilisation des silos d’authentification est difficilement gérable sans PowerShell.
Dans le centre d’administration active directory, les stratégies d’authentification et les stratégies de silo se trouvent dans le nœud « Authentification ».
Si le nœud « Authentification » n’est pas présent, c’est que le domaine n’est pas au moins au niveau fonctionnel 2012R2.
Dans notre exemple, nous allons créer une stratégie pour les comptes d’administration de Tiers 2 « Administrateur des postes utilisateurs ».
Nous avons nommé la stratégie ADM_T2, elle est définie en mode Application. (Nous pourrions très bien la mettre en mode audit, si nous souhaitions tester uniquement les effets de son application.) Nous définirions également la durée du TGT que nous avons choisi de limiter à 240 minutes contre 10 heures par défaut sur un domaine.
Une fois ce paramètre défini, nous validons les modifications pour procéder à la création de la stratégie d’authentification. Une fois la stratégie de silo créée, il faudra revenir sur cette stratégie pour définir une condition d’application du Silo.
La création peut se faire également avec la commande PowerShell ci-dessous.
New-ADAuthenticationPolicy -Enforce:$true -Name:"ADM_T2_" -ProtectedFromAccidentalDeletion:$true -RollingNTLMSecret:"Disabled" -UserTGTLifetimeMins:240 Création d’une « Authentification Policy Silo » et application sur comptes.
Une fois la stratégie d’authentification créée, il est nécessaire de créer la stratégie de silo, c’est cette stratégie qui va définir le silo, j’ai nommé cette stratégie ADM_T2 et défini le paramètre appliqué les stratégies du silo, ce qui indique que je veux que le silo soit effectif et pas seulement en mode audit. Dans la partie comptes autorisés j’ai mis le compte utilisateur et compte ordinateur devant faire partie du silo.
Il est à noter que les cases attribuées ne sont pas cochées, car pour que la stratégie soit en mode attribué, il est nécessaire d’attribuer cette stratégie de silo directement dans les propriétés du compte utilisateur et ordinateur.
Il est également nécessaire d’indiquer la stratégie d’authentification devant s’appliquer aux comptes du silo, dans notre cas, la stratégie d’authentification ADM_T2. Vous remarquerez qu’il y a deux possibilités, soit d’appliquer une même stratégie pour tous les types de compte du silo (ordinateur, service managé, utilisateur) ou d’en appliquer une par type de compte.
Une fois ces paramètres définis, nous pouvons les valider pour créer la stratégie de silo.
Les commandes PowerShell suivantes permettent de réaliser cette même action en ligne de commande.
New-ADAuthenticationPolicySilo -Name:"ADM_T2" -OtherAttributes:@{"msDS-AuthNPolicySiloEnforced"=$true;" msDS-ComputerAuthNPolicy"= » CN =ADM_T2, CN=AuthN Policies, CN=AuthN Policy Configuration, CN=Services, CN=Configuration, DC=lab, DC=local";» msDS-ServiceAuthNPolicy"=" CN =ADM_T2, CN=AuthN Policies, CN=AuthN Policy Configuration, CN=Services, CN=Configuration, DC=lab, DC=local";» msDS-UserAuthNPolicy"=" CN =ADM_T2, CN=AuthN Policies, CN=AuthN Policy Configuration, CN=Services, CN=Configuration, DC=lab, DC=local »} -ProtectedFromAccidentalDeletion:$true
Set-ADObject -Add:@{'msDS-AuthNPolicySiloMembers'=" CN=Client02, OU=Computers, OU=MyOrganisation, DC=lab, DC=local », « CN=adm-ldupont, OU=ADM, OU=MyOrganisation, DC=lab, DC=local »} -Identity:" CN =ADM_T2, CN=AuthN Silos, CN=AuthN Policy Configuration, CN=Services, CN=Configuration, DC=lab, DC=local »Pour appliquer la stratégie du silo sur les comptes utilisateurs et ordinateurs, il est nécessaire d’aller dans la partie silo des propriétés des comptes utilisateurs et ordinateurs, et de cocher la case « affecter un silo de stratégie d’authentification » puis de sélectionner la stratégie de silo créée au préalable « Adm_T2 » et de valider.
La commande PowerShell suivante permet de réaliser cette même action en ligne de commande.
Set-ADAccountAuthenticationPolicySilo -AuthenticationPolicySilo:" CN =ADM_T2, CN=AuthN Silos, CN=AuthN Policy Configuration, CN=Services, CN=Configuration, DC=lab, DC=local » -Identity:" CN=adm-ldupont, OU=ADM, OU=MyOrganisation, DC=lab, DC=local Pour la partie ordinateur, la manipulation est identique.
La commande PowerShell suivante permet de réaliser cette même action en ligne de commande.
Set-ADAccountAuthenticationPolicySilo -AuthenticationPolicySilo:" CN =ADM_T2, CN=AuthN Silos, CN=AuthN Policy Configuration, CN=Services, CN=Configuration, DC=lab, DC=local » -Identity:" CN=Client02, OU=Computers, OU=MyOrganisation, DC=lab, DC=local Une fois ces opérations effectuées, si vous affichez à nouveau la stratégie de silo, vous devriez avoir des cases vertes cochées sur la colonne attribuée de ces comptes.
Liaison du silo authentification à la stratégie d’authentification
Une fois la stratégie de silo créée, il est nécessaire d’appliquer une condition d’application du silo dans la stratégie d’authentification créée au préalable.
En éditant la stratégie d’authentification, vous devez voir qu’un silo a été affecté à la stratégie d’authentification pour la partie utilisateur, ordinateur et compte de service managé.
Pour affecter la condition de ressource au compte utilisateur, il est nécessaire de se rendre dans la partie « authentification de l’utilisateur », d’éditer les conditions de contrôle d’accès de ressource.
Une fois dans la condition de contrôle d’accès, il est nécessaire de créer une condition, utilisateur > AuthentificationSilo > Est égal à Valeur > Nom de la stratégie de silo (ADM_T2 dans notre exemple) et de valider.
La commande PowerShell suivante permet de réaliser cette même action en ligne de commande.
Set-ADAuthenticationPolicy adm_T2 -UserAllowedToAuthenticateFrom « O:SYG:SYD:(XA;OICI;CR;;;WD;(@USER.ad://ext/AuthenticationSilo == "ADM_T2")) » Activation Journal de Débogage sur le(s) contrôleur(s) de domaine
Avant de faire un test de connexion, il peut être intéressant d’activer le journal de débogage avancé des stratégies d’authentification, ce journal peut avoir un intérêt dans le cadre de débogage des silos.
Pour ce faire, il faut se rendre dans l’observateur d’événements du/des contrôleurs de domaine puis suivre le chemin suivant :
Journal des applications et services > Microsoft > Windows > Authentification > AuthentificationPolicyFailures-DomainController et activer le journal via le menu contextuel.
Ces évènements vous permettront d’auditer facilement les refus de connexions liés aux silos.
Tests de Fonctionnement
Maintenant que les silos sont créés, nous allons pouvoir faire un test d’authentification.
Dans notre lab, nous avons deux postes clients, Client01 et Client02, notre compte devrait pouvoir se connecter sur Client02 puisqu’il fait partie du silo en revanche la connexion au client01 ne devrait pas fonctionner.
Connexion sur Client02 :
En revanche sur Client01 qui est en dehors du silo, la connexion avec le compte adm-ldupont n’est pas possible. Le silo est fonctionnel.
Lorsque l’on va dans le journal des événements « AuthentificationPolicyFailures » on a un événement Kerberos-Key-Distribution-Center ID405 qui notifie que le ticket a été refusé, car il n’est pas conforme avec le contrôle d’accès. Dans les détails de l’événement, on a le poste client concerné ainsi que la stratégie d’authentification et de Silo qui motive le rejet du ticket.
Cet échec engendre un échec d’audit de sécurité « Kerberos Authentification Service » id 4820. Ce que l’on peut constater est qu’en dehors de débogage qui nécessite d’identifier rapidement les événements en lien avec les silos, les événements AuthentificationPolicyFailures ont peu d’intérêt si l’on a activé les audits avancés sur les contrôleurs de domaine. Toutes les informations étant présentes dans le journal de sécurité d’audit.
Conclusion
Relativement peu connue des administrateurs systèmes, l’implémentation des stratégies de silo est un bon moyen de sécuriser ses comptes à privilèges. Il me semble que cette fonctionnalité est une bonne entrée en matière pour aborder le tiering model dans un environnement Active Directory. Même si vous avez encore des systèmes antérieurs à Windows 2012/8 dans votre environnement, utiliser des Silos d’authentification pour les comptes hautement privilégiés (Admins du Domaine), peut se révéler judicieux.
Si ce n’est pas déjà en place dans vos domaines de production sous votre responsabilité, je vous invite à maquetter cette fonctionnalité.
Vous trouverez ci-dessous un comparatif des avantages et inconvénients des silos d’authentification Versus GPO « User Right Assignement ».
Disclaimer : Avant de l’appliquer à vos comptes Admins_du_Domaine, ces comptes étant critiques, je vous recommande deux précautions :
- Passer la stratégie en mode audit, avant de la passer en mode activé, ce qui permettra de valider dans le journal de AuthentificationPolicyFailures que les silos s’appliquent correctement comme vous le souhaitez.
- Le compte Administrateur de builtin est un compte de type « Bris de glace » ne devant en principe, jamais être utilisé sauf cas de situation d’urgence. De par la particularité de ce compte, je suis partisan de ne pas le placer dans un silo, et de vérifier que toute tentative authentification avec ce compte génère une alerte critique dans votre environnement (alerte mail, alerte siem etc…).
Écrit par Christophe ROVAI
