¶ Introduction
Notre nouvel objectif ici est de mettre en œuvre l’authentification des utilisateurs de pfSense depuis un contrôleur de domaine Windows Server, pour illustrer plus généralement le mécanisme d'authentification par LDAP sur un domaine Windows.
Plus précisément, il s’agit d’autoriser un accès (limité) sur pfSense pour une liste d’utilisateurs fournie via un fichier externe (tableur). Ces utilisateurs devront être importés dans l’AD via un script Powershell, dans un groupe de sécurité spécifique, et pfSense devra authentifier les accès depuis l’AD, via le protocole LDAP.
De plus, puisque depuis la version 2022 Windows Server n'accepte plus les accès LDAP standard, mais uniquement chiffrés LDAPS, nous serons aussi amenés à ajouter le rôle de PKI (Public Key Infrastructure) sur le Serveur Windows.
Ce TP doit être entrepris à la suite ce celui qui concerne : WinRM - administration distante de serveur Windows.
¶ Environnement
Nous repartons donc de ce schéma :
Rappel des modifications apportées lors du TP WinRM sur le mini-lab en mode Windows :
- la VM Windows Server Core est contrôleur du domaine pascal.lan (dans cet exemple)
- la VM Client Windows est membre du domaine
- Les outils RSAT d'administration ont été installé sur cette VM (Gestion AD, Gestion Serveur, Gestion DNS et Gestion GPO)
- Un lecteur partagé M: est disponible sur le domaine, créé par GPO.
Si possible, il est recommandé de configurer le client Windows avec 8Go de RAM et 4 CPU.
¶ Configuration de pfSense
Nous allons notamment indiquer à pfSense que le serveur DNS est désormais sur le contrôleur de domaine. Depuis l’interface webadmin de pfSense (sur le poste Windows client) :
apportez ces modifications :
- Depuis le menu system > general setup :
- hostname : pfsense
- domaine : votre_nom.lan
- DNS : 192.168.1.20 (Serveur ADDS)
- Depuis le menu services > DNS Resolver :
- Désactiver le service DNS Resolver
Automatiquement, le serveur DHCP de pfSense ajuste ses paramètres pour propager ces infos sur les clients DHCP (voir dans menu Services > DHCP Server) :
¶ Configuration de client Windows
Maintenant que pfSense est ajusté au domaine, nous pouvons rétablir les paramètres standard de l'interface réseau de Windows :
¶ installation de OnlyOffice Desktop
Afin de manipuler facilement les fichiers CSV, on télécharge et on installe le logiciel OnlyOffice sur notre client Windows.
L'installation se fait simplement, avec les options par défaut.
¶ Configuration du domaine
¶ Création des OU et groupes
Lancez Powershell ISE avec l’élévation administrateur, et connectez-vous à distance sur le Serveur (contrôleur AD) :
# adaptez le nom du serveur selon votre contexte
Enter-PSSession -ComputerName "SRV-PM01"
Créez une OU (Unité d’Organisation) « Sécurité » à la racine de l’AD, avec une commande Powershell :
# adaptez les Domain Components (DC) selon votre propre domaine
New-ADOrganizationalUnit -Path "DC=pascal,DC=lan" -Name "Sécurité" -PassThru
Réponse :
City :
Country :
DistinguishedName : OU=Sécurité,DC=pascal,DC=lan
LinkedGroupPolicyObjects : {}
ManagedBy :
Name : Sécurité
ObjectClass : organizationalUnit
ObjectGUID : 9af31a60-3b4c-4946-aad5-88611fda00a2
PostalCode :
State :
StreetAddress :
On vérifie la présence de l’OU Sécurité dans l’arborescence AD :
Créez un groupe de sécurité rattaché à l'OU Sécurité, nommé précisément Observateurs PfSense :
# adaptez les Domain Components (DC) selon votre propre domaine
New-ADGroup -Name 'Observateurs pfSense' -GroupCategory 'Security' -GroupScope 'DomainLocal' -Path 'OU=Sécurité,DC=pascal,DC=lan' -Description 'Groupe de surveillance pfSense' -PassThru
Réponse :
DistinguishedName : CN=Observateurs pfSense,OU=Sécurité,DC=pascal,DC=lan
GroupCategory : Security
GroupScope : DomainLocal
Name : Observateurs pfSense
ObjectClass : group
ObjectGUID : 6caf5437-830a-48f7-bc86-7a6ab4fffba9
SamAccountName : Observateurs pfSense
SID : S-1-5-21-2014020534-3525384246-3471752833-1106
On obtient maintenant dans la console de l'AD (utiliser le bouton d’actualisation si nécessaire) :
¶ Importation des utilisateurs dans l'AD
Récupérez et enregistrez dans le dossier partagé M: le fichier pfsense_users.xlsx qui contient la liste des utilisateurs à créer. Ce fichier peut être récupéré ici. Ouvrez-le avec OnlyOffice :
A l’aide d'OnlyOffice, personnalisez et enregistrez ce fichier au format CSV sur le dossier partagé. Par défaut, OnlyOffice utilise le format UTF-8 pour l’encodage de caractères, et la virgule comme séparateur (contrairement à MS Excel, qui utilise le point-virgule).
A partir de ce fichier, on va générer les utilisateurs correspondants dans le groupe Observateurs pfSense, grâce à un script Powershell. Les utilisateurs créés doivent correspondre à ce schéma :
- Given Name = Prénom
- Surname = Nom
- Name = Prénom Nom
- SamAccountName = initiale du prénom en minuscule . nom en minuscule (ex :
g.eiffel) - Password = celui indiqué dans le fichier. Le mot de passe n’expire jamais.
- UserPrincipalName = initiale du prénom en minuscule . nom en minuscule @votre_nom.lan
- L’utilisateur doit être ajouté au groupe Observateurs pfSense
- L’utilisateur doit être activé
Voici le script, à copier dans l'interface de PowerShell ISE :
$users = import-csv -path "\\SRV-PM01\Commun\pfsense_users.csv" -delimiter ","
foreach($user in $users) {
$gn=$user.Prénom
$sn=$user.Nom
$ou="OU=Sécurité,DC=pascal,DC=lan"
$SAM=$gn.Substring(0,1).ToLower() + "." + $sn.ToLower()
$Password=$user.Password
$secure_pwd = convertto-securestring $Password -asplaintext -force
$UPN = $SAM + "@pascal.lan"
$CN = $gn + " " + $sn
New-ADuser -displayName $CN -Surname $sn -Name $CN -givenname $gn -Path $ou -SamAccountName $SAM -AccountPassword $secure_pwd -PasswordNeverExpires $True -UserPrincipalName $UPN -Enabled $True
Add-ADGroupMember -Identity "Observateurs pfSense" -Members $SAM -PassThru
}
Vérifiez qu’il correspond bien aux critères et à vos informations, puis exécutez le script :
Attention ! il faut lancer le script en étant connecté sur le serveur (et non sur le client)
Le script est enregistré sur la machine cliente, le fichier CSV est enregistré sur le serveur. Le script va être lancé sur le serveur, via la connexion winRM.
Vérification de la liste des utilisateurs :
Vérification des attributs d’un utilisateur créé :
¶ Ajout du rôle AD-CA
Comme évoqué au début de ce TP, depuis la version 2022, Windows Server n'accepte plus les accès LDAP standard, mais uniquement chiffrés LDAPS. Le plus simple pour ce cas (et bien d'autres en fait), est d'ajouter le rôle AD-CA dans le domaine. Nous allons l'installer sur notre Serveur Windows (une bonne pratique voudrait que l'on utilise un autre serveur dédié dans le domaine).
Depuis notre client Windows (connecté comme admin du domaine), on se connecte à distance (si ce n'est déjà fait) sur le serveur :
Enter-PSSession -ComputerName 'SRV-PM01'
On installe le rôle AD-CA :
Install-WindowsFeature -Name AD-Certificate, ADCS-Cert-Authority
Cette commande PowerShell installe deux fonctionnalités Windows Server liées aux services de certificats Active Directory (AD CS) :
AD-Certificate: Installe les composants de base nécessaires pour la gestion des certificats dans un environnement Active Directory.ADCS-Cert-Authority: Installe le rôle d'Autorité de Certification (CA), qui est le composant central permettant d'émettre, gérer et révoquer des certificats numériques dans votre infrastructure.
En exécutant cette commande, vous préparez votre serveur Windows à fonctionner comme une autorité de certification pour votre organisation. Cette configuration permet de :- Créer et gérer une infrastructure à clé publique (PKI)
- Émettre des certificats numériques pour les utilisateurs, ordinateurs et services
- Sécuriser les communications via SSL/TLS
- Prendre en charge l'authentification par certificat
- Permettre la signature et le chiffrement de documents
On configure notre PKI :
# adaptez "NomDeVotreCA" en fonction de votre contexte
Install-AdcsCertificationAuthority -CAType EnterpriseRootCA -CACommonName "NomDeVotreCA" -KeyLength 2048 -HashAlgorithm SHA256 -ValidityPeriod Years -ValidityPeriodUnits 5
Cette commande PowerShell configure et installe l'Autorité de Certification avec les paramètres suivants :
-CAType EnterpriseRootCA: Configure l'autorité de certification comme une CA racine d'entreprise, ce qui signifie qu'elle sera la première CA dans votre hiérarchie PKI et sera intégrée à votre Active Directory.-CACommonName "NomDeVotreCA": Définit le nom commun (CN) de votre autorité de certification, qui sera visible dans les certificats émis. Dans cet exemple, il faut remplacer "NomDeVotreCA" par le nom souhaité pour votre CA (je prendrai comme exemple pascal-root-CA)-KeyLength 2048: Spécifie la taille de la clé cryptographique (2048 bits), ce qui représente un bon équilibre entre sécurité et performances. La valeur 4096 est plus sécurisée, mais impacte les performances (complexité).-HashAlgorithm SHA256: Définit l'algorithme de hachage utilisé pour signer les certificats (SHA256 est considéré comme sécurisé et est recommandé).-ValidityPeriod Years: Indique que la période de validité sera exprimée en années.-ValidityPeriodUnits 5: Spécifie que le certificat racine sera valide pour une durée de 5 ans.
Cette commande termine essentiellement la configuration initiale de votre autorité de certification d'entreprise. Après son exécution, votre CA sera opérationnelle et prête à émettre des certificats pour votre organisation selon les paramètres spécifiés.
Activez ensuite le modèle de certificat LDAPS :
# Activer le modèle de certificat "Contrôleur de domaine"
certutil -setcatemplates +DomainController
Cette commande ajoute le modèle de certificat "DomainController" à la liste des modèles que votre autorité de certification (CA) est autorisée à émettre. Le signe "+" indique l'ajout d'un modèle à la liste existante.
Son utilité :
- Sécurisation des contrôleurs de domaine : Elle permet d'émettre des certificats spécifiquement conçus pour les contrôleurs de domaine, ce qui renforce la sécurité des communications dans votre domaine.
- Prérequis pour certaines fonctionnalités : Ces certificats sont nécessaires pour:
- L'authentification LDAPS (LDAP sécurisé par SSL/TLS)
- Certaines fonctionnalités d'authentification Kerberos avancées
- La communication sécurisée entre contrôleurs de domaine
- Automatisation : Une fois le modèle activé, les contrôleurs de domaine peuvent demander automatiquement ces certificats s'ils sont configurés pour le faire.
- Conformité : L'utilisation de LDAPS est souvent exigée par les normes de sécurité et de conformité (PCI-DSS, HIPAA, etc.).
Demander et installer automatiquement un certificat :
certutil -pulse
Cette commande force la publication immédiate de la liste de révocation de certificats (CRL) depuis l'autorité de certification. Elle déclenche le processus de publication sans attendre l'intervalle de publication régulier configuré sur la CA.
Pour configurer pfSense (pour qu'il accepte le domaine comme autorité de confiance racine), il nous faut exporter le certificat :
- Afficher les certificats racine et leur empreinte :
Get-ChildItem -Path Cert:\LocalMachine\Root - Copiez l'empreinte de la CA que nous venons de créer. Remplacez ci-dessous
THUMBPRINTpar cette empreinte :$cert = Get-ChildItem -Path Cert:\LocalMachine\Root\THUMBPRINT - Exportez le certificat racine dans le dossier commun :
Export-Certificate -Cert $cert -FilePath \\SRV-PM01\commun\root-ca-cert.cer -Type CERT - On le réencode au format pem (format textuel base64) :
certutil -encode \\SRV-PM01\commun\root-ca-cert.cer \\SRV-PM01\commun\root-ca-cert.pem
Nous aurons besoin de ce certificat pour configurer la connexion LDAPS de pfSense au contrôleur de domaine.
¶ Paramétrage de pfSense
Nous allons désormais paramétrer pfSense pour que ces utilisateurs puissent accéder à quelques fonctions de supervision du firewall (nous nous limiterons au dashboard et à la liste des baux DHCP).
¶ Création de l'utilisateur pfSense
Sur le serveur, créez un user pfsense.connect avec le mot de passe de votre choix (il doit être complexe, ne doit pas expirer et l'utilisateur ne peut pas le modifier). Ce compte servira à authentifier pfsense auprès du Domaine (via LDAP). Placez cet utilisateur dans l’OU Sécurité.
Ceci peut se faire graphiquement depuis la gestion de l'AD, ou par PowerShell :
New-ADUser -Name "pfsense.connect" -SamAccountName "pfsense.connect" -UserPrincipalName "pfsense.connect@pascal.lan" -Path "OU=Sécurité,DC=pascal,DC=lan" -AccountPassword (ConvertTo-SecureString "Azerty/123567" -AsPlainText -Force) -Enabled $true -PasswordNeverExpires $true -CannotChangePassword $true
¶ Importation du certificat racine de l'AD
Depuis l’interface d’administration web de pfSense, créez une nouvelle autorité et importez (par copier/coller) le certificat que l'on vient de générer, via le menu System > Certificates > Authorities :
Le nouveau certificat apparaît dans la liste :
¶ Création du serveur d'authentification
Depuis l’interface d’administration web de pfSense, créer le serveur d’authentification dans le menu System > User Manager > Authentification Server :
Remplissez les différents champs selon les spécificités de notre configuration.
Quelques indications importantes :
- Hostname or IP address : il ne faut pas mettre l'adresse IP du serveur, mais son FQDN, car celui-ci fait l'objet d'une vérification via le certificat.
- Port :
636car on fonctionne en LDAPS - Domaine de recherche (search scope) :
Entire Subtree; avec cette option, pfSense cherchera dans toute l’arborescence sous le DN de base défini ci-dessous. - Base DN : indiquez la racine de l’AD :
DC=votre_nom,DC=lan - Authentication Container : ne rien mettre pour le moment
- Décochez l'option
Bind anonymouspour s'authentifier pour requête l'AD avec le compte créé pour cela (pfsense.connect)- Pour récupérer de façon sûre le DN de cet utilisateur, on peut requêter l’AD par PowerShell :
(get-aduser -filter 'samaccountname -eq "pfsense.connect"').DistinguishedName- Exemple :
CN=pfsense.connect,OU=Sécurité,DC=pascal,DC=lan - Copier la valeur retournée dans le champ
Bind credentialsde la page de configuration pfSense, - Puis dans le champ juste à droite indiquez le mot de passe associé à ce compte.
- Schéma initial (initial template) :
Microsoft AD; ceci fera correspondre correctement les champs pfSense aux champs LDAP de l’AD :- User naming attribute => samAccountName
- Group naming attribute => cn
- Group member attribute => memberOf
- Enregistrer la configuration (SAVE) : un message d’erreur apparaît
- Revenir sur
Authentication containers: cliquer surSelect a containerpermet de vérifier que la connexion au serveur est correcte ; choisir celui qui permettra de chercher dans le bon groupe (sécurité).- Si la case est préalablement vide, vous aurez un message d’erreur (c’est un bug en réalité), il faut donc avant de cliquer mettre un caractère quelconque dans cette case.
- Enregistrer de nouveau la configuration (SAVE)
¶ Création du groupe associé et de ses privilèges
Créez un groupe pfSense correspondant au groupe des observateurs pfSense de l’AD :
- Il faut utiliser strictement le même nom que dans l’AD (sensible à la casse)
- Il ne faut lui ajouter aucun membre, car c’est justement géré depuis l’AD.
Une fois le groupe créé, il faut ensuite le modifier pour pouvoir lui accorder des privilèges sur pfSense. Ici nous allons uniquement ajouter le droit d’affichage du dashboard et les baux DHCP :
¶ Test de la configuration
Une fois la configuration de l’accès réalisée et le groupe créé, on peut tester la connexion avec le menu Diagnostics > Authentication (avec un des utilisateurs de notre liste) :
Le groupe Observateurs pfSense doit apparaître dans la fenêtre verte, c'est la preuve que pfSense associe bien cet utilisateur au groupe créé juste avant, avec les droits associés.
¶ Finalisation
Ensuite, modifier et tester le mode d’authentification de pfSense en choisissant le serveur AD-DS :
Puis se connecter avec les identifiants d'un des utilisateurs autorisés :
¶ Conclusion
Au terme de cette séquence, nous avons donc pu expérimenter l'authentification sécurisée associée à un contrôleur de domaine, avec notamment la mise en place de l'infrastructure à clés publiques (PKI) au sein du domaine. Ce scénario sera identique dans bien des contextes où l'authentification à un service est centralisée sur un domaine Active Directory.