Active Directory – Comment configurer le LDAPS avec un certificat autosigné ?

I. Présentation

Dans ce tutoriel, nous allons voir comment passer de LDAP à LDAPS en environnement Active Directory, à l’aide d’un certificat autosigné. Cette méthode présente l’avantage de ne pas nécessiter une autorité de certification.

Pour sécuriser les flux LDAP en environnement Microsoft, plusieurs solutions sont offertes aux administrateurs. L’option recommandée par Microsoft pour sécuriser les échanges entre les contrôleurs de domaine et les machines Windows, c’est l’utilisation du LDAPS Signing (qui fera l’objet d’un autre tutoriel), ou la signature LDAP si vous préférez. Une autre option disponible, c’est celle évoquée dans cet article : le LDAPS (LDAP over SSL). Elle est surtout utile pour sécuriser les connexions entre certains services / applications avec l’Active Directory.

Peu importe la méthode utilisée, l’objectif est de sécuriser les communications LDAP entre le client et le serveur. Dans le cas présent, avec le LDAPS, un certificat SSL/TLS auto-signé sera utilisé pour chiffrer les échanges de données, offrant ainsi une protection accrue contre certaines attaques, dont les attaques man-in-the-middle.

Si vous utilisez des machines Windows 10 et/ou Windows 11, et que vous souhaitez sécuriser les connexions LDAP, vous n’avez pas besoin de mettre en œuvre le LDAPS. En effet, il est préférable de forcer l’activation du LDAP Signing.

Voici un exemple concret d’utilisation du LDAPS : vous utilisez une application, et vous souhaitez mettre en œuvre l’authentification LDAP pour que les utilisateurs s’y connectent avec leur compte Active Directory. Plutôt que d’utiliser une simple connexion LDAP, vous pouvez passer sur LDAPS pour apporter une couche de sécurité important à cette connexion. Dans un prochain tutoriel, nous prendrons l’exemple de l’application GLPI puisque c’est un cas d’usage très fréquent.

II. LDAPS avec un certificat autosigné : pour qui ? Pourquoi ?

En environnement Active Directory, pour mettre en œuvre le LDAPS, il y a deux méthodes :

• Utiliser un certificat TLS obtenu auprès d’une autorité de certification d’entreprise. Par exemple, avec une autorité de certification Active Directory gérée via le rôle ADCS.
• Utiliser un certificat TLS créé sur le serveur et autosigné, c’est-à-dire qu’il n’émane pas d’une autorité de certification.

L’avantage de la méthode présentée dans cet article, c’est qu’elle n’implique pas la mise en œuvre d’une autorité de certification Active Directory (appelée également « PKI« ). Ainsi, sans même procéder à l’installation d’ADCS (ou d’un équivalent), il est possible de sécuriser les connexions LDAP grâce au passage au LDAPS.

Cette méthode est avantageuse pour les organisations n’ayant pas les ressources techniques et humaines pour la mise en œuvre, l’administration et la maintenance d’une autorité de certification.

Pour la suite du tutoriel, nous supposons que vous avez déjà un serveur Active Directory fonctionnel, ainsi qu’un serveur ou un poste de travail membre du domaine pour effectuer des tests de connexion.

III. Créer le certificat autosigné pour LDAPS

La première étape consiste à créer le certificat autosigné. Tout au long de cette procédure, nous allons prioriser l’utilisation de PowerShell pour être plus efficace et automatiser la configuration. La machine depuis laquelle vous exécutez les commandes doit disposer du module ActiveDirectory de PowerShell (c’est le cas sur un contrôleur de domaine).

Remarque : je vous recommande de copier-coller toutes les lignes de code PowerShell et de les insérer dans le même script, pour assurer son bon fonctionnement. En effet, les mêmes variables sont utilisées tout au long de la procédure, et il y a un lien entre les différentes étapes. De plus, exécutez ces commandes sur un contrôleur de domaine, que ce soit en local ou via une session PSRemoting.

Vous devez créer le certificat autosigné avec le nom de domaine Active Directory (nom DNS) comme « subject » (objet) et les noms DNS des DC en tant que « DnsName« , en plus du nom de domaine.

Les commandes ci-dessous vont permettre d’accomplir cette action, avec la création d’un certificat valide pour 1 an. Vous n’avez pas à modifier le code ci-dessous, il va récupérer automatiquement les valeurs correspondant à votre domaine.

# Liste de tous les DC du domaine actuel et racine du domaine
$ListOfDC = (Get-ADDomainController -Filter *).Hostname
$ListOfDC += $((Get-ADDomain).DNSroot)

# Durée de validité du certificat (1 an)
$ExpirationDate = (Get-Date).AddYears(1)

# Création du certificat autosigné
$MyLDAPSCert = New-SelfSignedCertificate -Subject $((Get-ADDomain).DNSroot) -DnsName $ListOfDC -CertStoreLocation cert:/LocalMachine/My -NotAfter $ExpirationDate
$MyLDAPSCertThumbprint = $MyLDAPSCert.Thumbprint

$MyLDAPSCert | Format-list

Suite à l’exécution de ce bloc de code, vous devez disposer d’un certificat autosigné prêt à l’emploi ! Les informations correspondantes à ce certificat seront affichées à la fin de la commande.

IV. Exporter le certificat autosigné

La seconde étape consiste à exporter le certificat autosigné que nous venons de créer. Dans quel but ? Il y a deux réponses à cette question :

• Exporter le certificat, sans la clé privée (au format CER), pour qu’il puisse être importé sur les serveurs où il y a un service ou une application qui a besoin de pouvoir établir des connexions LDAPS.
• Exporter le certificat, avec la clé privée (au format PFX), pour qu’il soit importé sur les autres contrôleurs de domaine Active Directory, du domaine.

Le code ci-dessous va donc générer deux fichiers de sortie, à la racine de « C:\« . Vous pouvez modifier le chemin si vous le souhaitez en modifiant le paramètre « -FilePath » des commandes « Export-Certificate » et « Export-PfxCertificate« .

# Exporter le certificat (sans la clé privée)
Export-Certificate -Cert $MyLDAPSCert -FilePath "C:\Cert-LDAPS-$((Get-ADDomain).DNSroot)-Public.cer"
    
# Exporter le certificat (PFX) pour importer sur les autres DC
# Exportation protégée par mot de passe : $MotDePasse = ConvertTo-SecureString -String 'Password' -Force -AsPlainText
Export-PfxCertificate -Cert $MyLDAPSCert -FilePath "C:\Cert-LDAPS-$((Get-ADDomain).DNSroot).pfx" -ProtectTo $env:username

Il est à noter que le certificat PFX (seconde commande) est protégé et l’autorisation est associée au compte qui est utilisé pour exécuter la commande. Si vous préférez, remplacez le paramètre « -ProtectTo » par « -Password » et indiquez un mot de passe via une chaîne sécurisée.

À la fin, nous obtenons deux fichiers :

• Cert-LDAPS-it-connect.local-Public.cer
• Cert-LDAPS-it-connect.local.pfx

V. Copier le certificat dans le magasin des CA de confiance

Sur le contrôleur de domaine, le certificat autosigné que nous avons créé est stocké dans le magasin « Personnel » du magasin des certificats. Pour que la configuration soit opérationnelle, vous devez copier-coller ce certificat dans le magasin « Autorités de certification racines de confiance« .

Bien que cette manipulation soit possible avec un simple copier-coller à l’aide de la console MMC de gestion des certificats, nous allons poursuivre en PowerShell.

Voici le code à exécuter (aucune adaptation nécessaire) :

# Copier le certificat du magasin "Personnel" dans le magasin "Root CA"
$CertStoreCA = New-Object System.Security.Cryptography.X509Certificates.X509Store -ArgumentList "Root","LocalMachine"
$CertStoreCA.Open("ReadWrite")
$GetMyLDAPSCert = Get-ChildItem -Path "Cert:\LocalMachine\My" | Where-Object { $_.Thumbprint -eq $MyLDAPSCertThumbprint }
$CertStoreCA.Add($GetMyLDAPSCert)
$CertStoreCA.Close()

VI. Importer le certificat PFX sur un contrôleur de domaine

Si votre environnement dispose de plusieurs contrôleurs de domaine AD, vous devez importer le certificat sur chacun de ces serveurs. Vous devez transférer le fichier « Cert-LDAPS-it-connect.local.pfx » sur chaque DC et exécuter la commande suivante (ici, le certificat a été copié dans « C:\ ») :

Import-PfxCertificate -CertStoreLocation Cert:\LocalMachine\my -FilePath "C:\Cert-LDAPS-it-connect.local.pfx"

Si vous procédez avec l’interface graphique, il suffit de double-cliquer sur le fichier PFX et de suivre l’assistant.

À partir de maintenant, il est possible de tenter une connexion LDAPS entre deux contrôleurs de domaine. Éventuellement, nous aurions aussi pu faire le test en local, sur le premier DC.

VII. Tester la connexion LDAPS

Pour tester la connexion LDAPS, comment faire ? Nous allons utiliser l’outil « ldp.exe » présent par défaut sur Windows Server. Si vous effectuez un test de connexion LDAPS avant même de mettre en place le certificat, vous obtiendrez une erreur comme celle-ci ci-dessous.

Rappel : le certificat doit être présent dans le magasin « Autorités de certification racine de confiance » du contrôleur de domaine, sinon la connexion sera rejetée.

Recherchez simplement « ldp » ou « ldp.exe » dans la zone de recherche de votre serveur pour ouvrir cet outil. Ensuite, cliquez sur « Connexion » puis « Se connecter« . Renseignez le formulaire avec le nom DNS complet du serveur DC, indiquez le numéro de port « 636 » et cochez l’option « SSL« . Comme ceci :

Cliquez sur « OK » pour lancer un test de connexion. Vous devriez obtenir un résultat similaire à celui-ci :

VIII. Conclusion

En suivant ce tutoriel, vous avez maintenant toutes les informations nécessaires pour laisser de côté les connexions LDAP au profit de connexions LDAPS, sans avoir besoin de mettre en œuvre une autorité de certification. Un autre article abordera l’obtention d’un certificat pour le LDAPS avec une autorité de certification ADCS.