Contexte et objectifs

Introduction

Le but de cette infrastructure est d’implémenter une authentification 802.1X au sein d’une PKI dans un environnement AD DS et AD CS respectant la distinction entre 3 tiers.

Phase 1 - Active Directory DS

clic yes

Entrer le mot de passe une première fois puis appuyer sur TAB pour accéder à la deuxième ligne

Vous arrivez sur cette fenêtre là

Disposition du clavier

Pour entrer dans la console Powershell, taper 15, puis entrer cette commande pour mettre en français la disposition du clavier :

Set-WinUserLanguageList -LanguageList "fr-FR"
#ou
Set-WinUserLanguageList -LanguageList fr-FR -Force

Paramètres réseau

Tapez 8 pour rentrer dans l’administration du réseau. Vérifiez que vous obteniez bien une adresse IP. Il faut désormais rentrer sa propre IP en tant que serveur DNS.

Renommer la machine

Activer le RDP

Taper 7 puis E pour activer le RDP :

A partir de maintenant, on va pouvoir administrer le Windows Server qui est un AD DS en devenir depuis la machine d’administration. On passe à l’installation de la VM d’administration

Installation du rôle AD DS

Lancer un PowerShell (Taper 15) et Install-WindowsFeature AD-Domain-Services –IncludeManagementTools -Verbose pour installer le rôle Windows

Pour vérifier c’est bien installé :

Get-WindowsFeature -Name *AD*

Paramétrage du domaine

Installation de la forêt

Lors de l’installation de la forêt, l’ordinateur devient désormais Contrôleur de domaine.

Install-ADDSForest -DomainName auteqia.local

Phase 2 - VM d’administration

Installatin d’un Windows Server avec un environnement graphique.

Pourquoi Windows Server ? Car c’est une VM de rebond sur laquelle il y aura parfois plusieurs connexions simultanées. Windows Server gère multiples connexions RDP en simultané tandis que Windows standard non.

Après avoir activé le RDP, changé le nom d’hôte, vérifié les paramètres réseaux et redémarré la machine, on va pouvoir rejoindre le domaine. Veiller à bien mettre le serveur de nom de domaine correspondant à l’AD dans les paramètres réseaux.

Ajoutons la machine dans le domaine:

Une fois l’ordinateur joint au domaine, redémarrer.

On va pouvoir ajouter le serveur à administrer depuis notre machine d’administration.

Ajouter les RSAT

Get-WindowsFeature | Where{ $_.Name -like "RSAT-*" }

Ce qui donne :

Pour installer les features nécessaires :

Install-WindowsFeature -Name "RSAT-AD-Tools" -IncludeAllSubFeature -IncludeManagementTools

Ajout du DC dans les serveurs distants

[!NOTE] Attention Il faudra se connecter avec un utilisateur administrateur du domaine sur la machine

Sur le gestionnaire de serveur, aller sur Dashboard et “Add other servers to manage”

Cliquer sur Add Other servers to manage

Ici on va ajouter le DC en double cliquant dessus

On peut désormais voir les rôles que l’on peut administrer à distance ici

Administration du DC01

Ajout dans la MMC

Lancer la MMC, puis ajouter un composant (snap-in)

Ajouter “Computer Management”

Désormais, on peut administrer nos utilisateurs et ordinateurs du domaine à partir de notre machine d’administration, en ayant notre Contrôleur de Domaine en Windows Core.

Ajout des Tiers dans l’Active Directory

Voici les documentations de l’ANSSI en matière d’Active Directory :

• Points de contrôles de l’Active Directory
• Recommandations pour l’administration sécurisée des systèmes d’information reposant sur la solution Active Directory

Ce modèle d’administration découpe en trois tiers (niveau en français) l’administration allant du tier 2, le moins privilégié au tier 0 servant à l’administration d’un contrôleur de domaine.

On y voit notamment dans le deuxième document une référence au tiering

Notre machine DC01 vient se placer dans le tier 0 tandis que notre machine d’administration vient se placer dans le tier 1. Ces tiers peuvent prendre la forme d’Unité d’Organisation (OU, Organisational Unit en anglais) sur lesquelles des GPO peuvent s’appliquer de manière à gérer les permissions.

• le Tier 1 correspond aux serveurs sensibles , qui requièrent une administration sécurisée .
• Administrer un serveur Windows AD ne doit PAS être fait depuis Tier 2 (postes utilisateurs).

Créations des Organisational Units par tiers

Pour se faire, nous allons séparer par des OU les différents tiers pour arriver à cette organisation là :

Pour l’instant, nous créons simplement les OU et nous les peuplons, l’application des GPO viendra après la mise en place de la PKI. Actuellement, notre machine SERVERADMIN se situe dans Computers, je vais le glisser dans Ordinateurs\Tier 1

De manière à ce que ça nous donne ceci :

Phase 3 - Autorités de certification

Nous allons pouvoir déployer nos deux Windows Server core 2022 qui seront respectivement l’Autorité de certification racine et l’autorité de certification intermédiaire.

Notre schéma est simple :

• La CA (certification authority) racine est la source de confiance principale, elle agit sur tout le domaine par l’intermédiaire de la CA intermédiaire
• La CA intermédiaire est autorisée à déployer des certificats sous la confiance de l’autorité racine
• Les postes et utilisateurs auront donc un certificat issu par la CA intermédiaire, qui elle même voit son certificat issu par la CA racine

Nous pouvons imaginer ce schema :

Notre autorité de certification racine n’est pas dans l’Active Directory et doit être éteint 99% du temps. En effet, elle intervient pour renouveler le certificat de l’autorité intermédiaire à chaque fin de validité de certificat (5 ans dans notre cas). Au contraire, l’autorité de certification intermédiaire doit se situer dans l’Active Directory, dans le Tier 0.

Autorité de certification racine

Après avoir installé le serveur Windows Core 2022, changé le nom d’hôte, vérifié les paramètres réseaux, nous pouvons installer le rôle. N’oubliez pas d’activer le RDP, ça nous sera utile par la suite.

Notre machine s’appelle donc ROOTCA

Installation du rôle

Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools

Configuration du rôle

Install-AdcsCertificationAuthority -CAType StandaloneRootCA -CACommonName "CAROOT" -KeyLength 4096 -HashAlgorithm SHA256 -ValidityPeriod Years -ValidityPeriodUnits 10 -Force

Notre Autorité de certification s’appellera CAROOT (à ne pas confondre avec ROOTCA qui est le nom d’hôte) et portera son certificat valide pendant 10 ans.

On peut désormais voir le certificat de la CAROOT dans C:\CAConfig

Troubleshooting

Il se peut que vous ayez des problèmes à cette étape, voici quelques commandes utiles :

Lister les certificats sur la machine : certutil -viewstore root

Lister les autorités de certifications stockées : certutil -store CA

Confirmer que la CA est bien installée : certutil -cainfo

Vérifier l’état du service : Get-Service -Name CertSvc

Autorité de certification intermédiaire

Après avoir installé notre CAROOT, nous devons install un serveur Windows Core 2022, changer le nom d’hôte, vérifier les paramètres réseaux et nous pouvons l’ajouter du domaine. Attention, la machine doit posséder le DC01 en tant que serveur DNS. N’oubliez pas d’activer le RDP, ça nous sera utile pour la suite. Notre machine s’appelle donc CASUB01.

Ajout du domaine

Taper 1 pour rentrer dans la configuration du domaine

Une fois ajoutée au domaine, la machine doit être déplacée dans l’OU Ordinateurs\Tier 0

Installation du rôle

Tout comme la CAROOT :

Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools

Une fois le rôle installé, il faut le paramétrer.

Ajout de la SUBCA01 dans le Server Manager

Une fois ajoutée dans la gestion des serveurs, on peut configurer l’ADCS depuis notre machine d’administration :

Paramétrage du rôle en GUI

Transférer la requête par Partage SMB

Sur la SUBCA01

cd C:\
mkdir share
mv "C:\.\CASUB01.auteqia.local_auteqia-CASUB01-CA.req" "C:\share"
New-SmbShare -Name "share" -Path "C:\share" -FullAccess "Domain Admins"

Maintenant sur la ROOTCA :

Copy-Item -Path "\\CASUB01\share\CASUB01.auteqia.local_auteqia-CASUB01-CA.req" -Destination "C:\" #possible de faire par IP plutôt que nom d'hôte

Sur la ROOTCA :

Signer la requête

Sur la CAROOT, il faut désormais signer la requête de certificat de la SUBCA01 :

certreq -submit C:\CASUB01.auteqia.local_auteqia-CASUB01-CA.req C:\CASUB01-Cert.crt

Une pop-up va apparaître, cliquer sur OK.

La requête est désormais en attente

Vous recevez un message disant que “Le certificat est en attente” (status: pending ). La RequestID est de 4.

Ce message signifie que la requête CSR de la Sub CA a bien été soumise, mais doit être approuvée manuellement par un administrateur sur la Root CA.

On peut donc désormais signer notre certificat qui est en attente :

certutil -resubmit 4

Et retrouver le certificat signé :

certreq -retrieve 4 C:\CASUB01-Cert.crt

Le certificat de la SUBCA01 signé est désormais disponible ici : C:\SUBCA01-Cert.crt

Transférer le certificat signé sur la SUBCA01

On peut faire le même cheminement que pour le premier transfert, sur la ROOTCA :

Copy-Item -Path "C:\CASUB01-Cert.crt" -Destination "\\CASUB01\share\"

Import du certificat de la ROOTCA sur la SUBCA01 par SMB

De la même manière, en passant par SMB, le fichier C:\CAConfig\CAROOT_CAROOT.crt. Pour le transférer :

Sur la CAROOT :

Copy-item -Path .\CAConfig\CAROOT_CAROOT.crt -Destination "\\SUBCA01\share\"

Une fois le fichier transféré sur la CASUB01, il faut l’ajouter au magasin “Trusted Root Certification Authorities” :

certutil -addstore -f "Root" "C:\share\CAROOT_CAROOT.crt"

Et publier le certificat de la CAROOT dans l’AD :

certutil -f -dspublish .\CAROOT_CAROOT.crt RootCA

De cette manière, la chaîne de confiance est déployée à tous les ordinateurs et utilisateurs du domaine.

On peut vérifier notre schéma de confiance :

Import du certificat signé dans la SUBCA01

Ensuite, on peut importer le certificat de la SUBCA01 signé :

certutil -installcert C:\share\CASUB01-Cert.crt

Cette erreur signifie que le serveur de révocation des certificats (CRL - Certificate Revocation List) n’est pas accessible lors de la vérification de la chaîne de certification. Cela empêche le système d’authentifier correctement le certificat , car il ne peut pas confirmer s’il a été révoqué ou non.

Sur la ROOTCA on peut vérifier qu’il existe bien une CRL

On va la copier depuis la ROOTCA vers la CASUB01 :

Copy-Item -Path "C:\Windows\System32\CertSrv\CertEnroll\CAROOT.crl" -Destination "\\CASUB01\share\"

certutil -dsPublish -f .\CAROOT.crl CAROOT 

certutil -addstore -f "Root" C:\share\CAROOT.crl

Il faut donc redémarrer le service :

Restart-Service CertSvc
#ou
Start-Service CertSvc

Vérification dans la VM d’administration

Pour pouvoir administrer le rôle d’autorité de certification, il faut installer les RSAT-ADCS :

Install-WindowsFeature RSAT-ADCS

le rôle Certification Authority est désormais accessible depuis la MMC du serveur d’administration

Nous pouvons donc administrer la CA intermédiaire depuis notre VM d’administration

Modèle de certificat

Pour pouvoir prétendre à une authentification 802.1x, qu’elle soit filaire ou sans fil, le serveur NPS (RADIUS) qui verra prochainement la lumière du jour doit pouvoir s’authentifier avec un modèle de certificat spécifique : RAS and IAS Server.

Duplication du modèle RAS et IAS

Pour pouvoir publier un modèle de certificat, il faut cloner le modèle existant. Pour y parvenir, il faut cliquer sur Certificate Template, puis Manage.

Dans les modèles, on y voit celui qui nous intéresse :

Clic droit, puis dupliquer le modèle. Une fois dedans, il faut aller dans Security, et permettre aux membres du groupes RAS and IAS Servers de demander automatiquement un certificat de ce type. A savoir, le serveur NPS sera directement ajouté en tant que membre de ce groupe.

Et lui donner un petit nom

Duplication du modèle Utilisateur

On peut en profiter pour dupliquer le modèle de certificat Utilisateur, qui sera utilisé pour s’authentifier. On procède de la même manière : Authenticated Users dispose du droit de lecture sur le modèle et Domain Users dispose du droit de lecture, d’enroll et d’autoenroll.

Publication des modèles

Une fois ça fait, il faudra publier les modèles :

Désormais, les deux modèles de certificats sont autorisés à être utilisés.

GPO d’autoenrollment

Pour que les utilisateurs du domaine ainsi que le serveur NPS (membre du groupe RAS et IAS) puisse demander automatiquement des certificats, il faut créer une GPO dans l’Active Directory qui le permet.

Installer les outils de gestion de GPO :

Install-WindowsFeature GPMC -IncludeManagementTools

Lancer la MMC, et sélectionner Group Policy Management. On voit ici que les deux composants de la MMC sont accessibles depuis la même interface

Création d’une GPO d’autoenrollment Utilisateurs

On va placer une GPO au niveau de l’OU Utilisateurs

On notera ici que le groupe sur lequel s’applique la GPO est “Domain Users” et non pas “Authenticated Users”.

Il faut modifier la GPO pour activer l’autoenrollement

Appliquer la GPO. Tous les utilisateurs du domaine dans l’OU Utilisateurs et celles en dessous pourront autoenroll à un certificat.

Création d’une GPO d’autoenrollment RAS et IAS

On va procéder de la même manière pour la GPO qui servira au serveur NPS. Ce dernier se trouve dans le Tier 1 (se référer aux guides de l’ANSSI sur le Tiering).

Il faut activer le même paramètre mais dans Computer Configuration cette fois ci :

Phase 4 - Serveur NPS (RADIUS)

Paramétrage de la machine

[!NOTE] Attention Le rôle NPS n’est pas disponible en Windows Server Core. Il faut donc installer un Windows Server avec une interface graphique

Après avoir vérifié l’adresse IP, changé le nom de la machine, ajouté l’AD en DNS et ajouté dans le domaine, nous pouvons installer le NPS.

Ajout de la machine dans les serveurs sur la VM d’administration

Ajout du rôle NPS

Dans la gestion des serveurs, on peut ajouter un rôle au serveur NPS fraîchement ajouté

Suivre les configurations par défaut

Il devrait apparaître le rôle NPAS dans le Server Manager :

[!WARNING] Le tiering Pensez à glisser le serveur NPS dans l’OU Computers\Tier 1

Pensez à installer les RSAT liés au NPS sur la machine d’administration:

Install-WindowsFeature -Name NetworkPolicyAndAccessServices -IncludeManagementTools

Configuration du rôle NPS

Dans la MMC, ouvrez Network Policy Server

Attention, il se peut que le pare-feu Windows pose un problème lors de la connexion à distance. En effet, le profil pare-feu de domaine peut poser problème quant à la connexion à distance.

Pour rappel :

New-NetFirewallRule -DisplayName "Allow SMB for NPS Remote Management (TCP)" -Direction Inbound -Protocol TCP -LocalPort 445 -Action Allow -Profile Domain

Une fois ça fait et le composant de la MMC attaché, clic droit et Register server in Active Directory. De cette manière, le serveur sera autorisé à requêter dans l’AD. Attention, il se peut que ce soit grisé, dans ce cas il faut passer en RDP sur le NPS et l’activer directement depuis l’hôte.

Ensuite, sélectionner RADIUS server for 802.1X Wireless or Wired Connections

Puis Configure 802.1X.

Ajout des clients

Un client au sens RADIUS est un appareil qui relayera l’authentification de l’utilisateur final. Dans notre cas, cela peut être un pare-feu (dans le cas d’un multi-site), un switch ou bien une borne wifi. Dans mon cas, j’opterai pour la dernière solution.

Considérons que notre infrastructure est composée d’un seul point d’accès, Auteqia-AP

Choix de la méthode d’authentification

qui est l’implémentation EAP-TLS de Microsoft

Ici nous sommes face à un choix de taille. Il faut choisir entre :

• Microsoft: Smart Card or other certificate : L’utilisateur s’identifie avec un certificat, nécessite une PKI, s’effectue avec TLS, le NPS valide le certificat auprès de la CA.
• Microsoft: Protected EAP (PEAP) : PEAP encapsule EAP-MSCHAPv2 ou EAP-TLS dans un tunnel TLS sécurisé, peut s’authentifier avec un mot de passe ou un certificat
• Microsoft: Secured password (EAP-MSCHAP v2) : MSCHAPv2 authentifie les utilisateurs en comparant des hashes de mot de passe, pas de certificat,

Dans notre cas, nous choisirons le premier Microsoft: Smart Card or other certificate car nous disposons d’une PKI et tout ce qu’il faut pour pouvoir se baser sur cette méthode d’authentification.

Cliquer sur Configure pour bien vérifier que le NPS reçoit un certificat (via la GPO d’autoenrollment)

Choisir pour quel groupe s’applique la stratégie réseau RADIUS, dans mon cas Domain Users

Les contraintes de la stratégie

Décocher toutes les méthodes d’authentification moins sécurisées.

Il est désormais le moment de passer à la partie Wifi/Contrôleur wifi.

Phase 5 - Hardening par GPO du domaine (optionnel)

Attention, dans un environnement avec beaucoup de postes, des serveurs “legacy”, des comptes de services et des applications connectées, ces GPO pourraient littéralement casser l’AD DS. Elles sont donc à appliquer avec précautions.

1. Empêcher le relay NTLM et forcer Kerberos

L’authentification NTLM est vulnérable aux attaques NTLM Relay et Pass-the-Hash . Il est recommandé de désactiver NTLM et de forcer Kerberos. La GPO s’applique à Domain Controllers et Domain Computers. J’appliquerai cette GPO à la racine du domaine.

Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options

• Network security: Restrict NTLM: Incoming NTLM traffic → Deny all
• Network security: LAN Manager authentication level → Send NTLMv2 response only, refuse LM & NTLM
• Network security: Restrict NTLM: Audit NTLM authentication in this domain → Enable Audit (before full enforcement)

2. Désactiver le stockage de hash de mot de passe en mémoire (Pass-the-Hash)

Empêcher LSASS de stocker des hash NTLM en mémoire

Le Pass-the-Hash (PtH) consiste à réutiliser des hashs NTLM volés pour s’authentifier. S’applique au Domain Computers.

Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options

• Network Security : Do not store LAN Manager hash value on next password change → Enabled
• Interactive logon: Number of previous logons to cache → Set to 0 (Prevents offline credential theft)

3. Sécuriser Kerberos pour éviter Pass-the-Ticket (PtT)

Empêcher le vol et la réutilisation de tickets Kerberos

S’applique aux Domain Computers et Domain Controler.

Computer Configuration → Windows Settings → Security Settings → Account Policies → Kerberos Policy

• Maximum lifetime for user ticket → 4 hours
• Maximum lifetime for service ticket → 10 minutes

4. Enable Credential Guard (Windows 10/11 & Server 2016+)

Prévient du Credential Dumping from LSASS (Mitigate PtH, PtT, Mimikatz). S’applique sur tous les ordinateurs du domaine.

Computer Configuration → Administrative Templates → System → Device Guard

• Turn On Virtualization Based Security -> Enable without lock

Si vous voulez pouvoir désactiver Credential Guard à distance, sélectionnez Enabled without lock.

5. Enable Advanced Auditing to Detect Attacks

S’applique aux Domain Controler et aux Domain Computers.

Computer Configuration → Windows Settings → **Security → Advanced Audit Policy Configuration → Audit Policies

• Logon / Logoff -> Audit Logon → Success & Failure
• Account Logon -> Audit Kerberos Authentication Service → Success & Failure

Phase 6 - Client Windows 802.1x

Selon votre matériel et si vous avez opté pour un 802.1x sans fil, vous pourrez paramétrer un SSID sur vos bornes ou contrôleur WiFi avec des paramètres 802.1X, plus particulièrement un serveur RADIUS vers lequel le SSID communique pour relayer l’authentification. C’est ici que se place le protocole EAP.

Une fois le SSID paramétré, on peut passer au test sur un client Windows. Pour y parvenir, j’ai créé un utilisateur auteqia et une OU Lambda dans laquelle se placeront les utilisateurs non-privilégiés du domaine. Si tout s’est bien passé, notre utilisateur a récupéré son certificat automatiquement et l’a mit dans son magasin de certificat personnel. Il n’y a plus qu’à lancer la connexion au WiFi !

Audit de l’infrastructure à clé publique

Dans le but de vérifier si je n’ai pas laissé de mauvaises configuration derrière moi, je vais lancer une succession d’outil fait pour le pentest d’environnement Active Directory (et donc AD CS).

Certify / Certipy

Lister les modèles de certificats disponibles

Certify.exe find /vulnerable

Demander un certificat à partir d’un template vulnérable

Certify.exe request /ca:<CA_SERVER> /template:<VULNERABLE_TEMPLATE>

Rubeus

Convertir un certificat en format utilisable pour Kerberos

Rubeus.exe asktgt /user:auteqia /certificate:<CERT_FILE> /password: /domain:<DOMAIN>

• Génère un TGT à partir d’un certificat valide.

Utiliser le TGT

Rubeus.exe ptt /ticket:<TGT_FILE>

Impacket

Lister les utilisateurs et groupes Active Directory

python3 GetADUsers.py -dc-ip <DC_IP> <DOMAIN>/<USER>:<PASSWORD>

Exploiter Kerberos avec PKINIT (si un certificat valide est obtenu)

python3 getTGT.py -cert-pfx <CERTIFICATE.pfx> <DOMAIN>/<USER>

Sharphound

SharpHound.exe -c All

• Cela collecte toutes les informations pertinentes sur AD, y compris celles liées aux autorités de certification et aux permissions des utilisateurs sur la PKI.

Axe d’amélioration

• Hardening des ordinateurs du domaine par GPO plus poussé
• Appliquer l’administration par tier (cas réel)
• Faire la procédure de renouvellement des certificats ROOT et SUB