Dans cet article nous allons découvrir une première approche sur l'utilisation des stratégies d'authentification. Comme nous l'avons vu dans les articles précédents, les comptes d'administration sont sensibles. Par exemple, l'utilisation des comptes membre du groupe « Admins du domaine » devrait être limitée à certaines opérations et surtout pas sur les postes de travail. Vous pouvez consulter les articles précédents sur NTLM, Kerberos et la sécurité. A partir de Windows 2012, il est possible de restreindre l'utilisation du protocole NTLM sur ces comptes sensibles en les ajoutant dans le groupe « protected users ».

Notre objectif est de limiter l'ouverture de session des comptes à forts privilèges à certains postes. Dans notre exemple, nous parlerons de deux comptes d'administration « Admin1 » qui ne sera pas limité et « Admin2 » qui sera limité aux contrôleurs de domaines (il est possible de les limiter à d'autres postes).

Nous allons d'abord créer un groupe de sécurité contenant les comptes d'ordinateurs sur lequel « admin2 » pourra se connecter :

Dans l'article concernant Kerberos (voir lien ci-dessus), nous avons parlé des différents échanges dont la première la demande « AS-REQ ». Cet échange est sans doute la partie la plus vulnérable de Kerberos. Il est possible de la renforcer avec le blindage Kerberos. Le blindage Kerberos (Kerberos Armoring) sécurise la transaction avec les informations du compte d'ordinateur. La demande d'authentification de l'utilisateur inclus donc des informations sur l'ordinateur à partir duquel l'utilisateur s'authentifie et c'est cette information que nous allons utiliser pour limiter l'accès.

Nous allons activer la prise en charge des revendications et du blindage Kerberos par les contrôleurs de domaine avec le paramètre suivant à l'aide d'une GPO :

Nous activons également la prise en charge des revendications de l'authentification composée et du blindage Kerberos sur les postes client par GPO.

Depuis le centre d'administration Active Directory, dans la partie « Authentication Policy », nous allons créer une stratégie d'authentification.

Nous appelons notre stratégie « Zone-Rouge-AD » et nous sélectionnons le mode « Appliquer les restrictions de stratégie »

 

Dans la partie « Comptes », nous ajoutons le compte utilisateur concerné :

 

 

Dans la partie « Authentification de l'utilisateur » nous allons modifier les conditions d'authentification.

 

 

Nous ajoutons une condition pour l'authentification Kerberos.

 

 

Dans la condition, le terme « utilsateur » ne désigne pas la personne mais le compte de l'ordinateur qui va être utilisé pour sécuriser les échanges avec le blindage Kerberos. Ce compte doit être membre du groupe contenant les machines ou le compte « Admin2 » peut se connecter.

 

Une fois ajouter, vous devriez retrouver la requête suivante dans les conditions :

Membre de chaque({SG-Adminstration-AD (HTRAB\SG-Adminstration-AD)})

Si l'utilisateur Admin2 essaie d'ouvrir une session sur le serveur de fichier « File-2 », qui ne fait pas partie du groupe « SG-Adminstration-AD », l'authentification sera refusée.

 

Si au préalable vous avez activé le journal « AuthenticationPolicyFailures-DomainController » dans « journal des applications et des services \Microsoft\Windows\authentification » sur l'ensemble de vos DCs comme dans l'image ci-dessous :

 

Vous devriez retrouver sur un de vos DCs l'évènement ci-dessous indiquant que l'utilisateur n'a pas pu ouvrir de session sur notre serveur de fichier .

 

Le paramètre « nom de périphérique » indique que l'utilisateur « admin2 » n'a pas pu ouvrir de session sur le serveur « File-1 » à cause de la stratégie « ZoneRouge-AD »

Le compte « Admin1 » qui n’est pas limité par la stratégie n’a pas de problème pour ouvrir la session sur « file-1 » :