16/12/2024

Active DirectoryCybersécurité

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.

Importer certificat PFX LDAPS sur DC

À 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.

author avatar
Florian BURNEL Co-founder of IT-Connect
Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture.
Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Envoyer par mail

13 commentaires sur “Active Directory – Comment configurer le LDAPS avec un certificat autosigné ?

  • Bonjour la team It-connect
    Merci pour le travail toujours très intéressant!!

    Petite question, que ce passe t’il au bout d’un an?
    Il faut refaire la manip ou est ce que le certificat se renouvelle pour un an de plus?

    Répondre
    • Hello,
      Il faut refaire la manip car c’est un certificat auto-signé donc il n’y a aucun processus de renouvellement automatique.
      Sinon, pour que le certificat soit valide plus longtemps, il faut modifier cette ligne (remplacer « 1 » par une autre valeur) :
      $ExpirationDate = (Get-Date).AddYears(1)

      Répondre
  • Juste l’article dont j’avais besoin. Merci !

    Répondre
    • Je n’ai finalement pas vraiment compris 🙂

      Imaginons que nous ayons 2 DC et que nous voulons utiliser LDAPS pour les connexions VPN d’un Firewall par exemple.

      Sur le DC 1, nous créons les fichiers CER et PFX. Le fichier CER est à passer dans « Autorités de certification racines de confiance » de ce DC1, c’est bien cela ?
      C’est ici où j’ai un doute. Le fichier CER est plutôt à importer sur les serveurs autres que l’AD qui ont besoin de LDAPS, non ? Donc ici mon Firewall pour l’exemple ?

      Merci par avance !

      Répondre
      • Hello,
        Effectivement, le fichier CER donc ici le fichier « Cert-LDAPS-it-connect.local-Public.cer » doit être importé dans le magasin des certificats (dans « Autorités de certification racines de confiance« ) des serveurs applicatifs qui ont besoin d’effectuer une connexion LDAPS (donc oui ton firewall). Le fichier PFX contient la clé privée, donc il est uniquement réservé aux DC.

        Répondre
  • Pile le jour où je cherchais à faire sur mon AD de test. C’est nickel ça m’a résolu mon souci. Merci 🙂

    Répondre
  • Bonjour,

    merci pour cet article.

    Il me semble que que une fois ldaps activé les DC ne traitent plus les connexions LDAP est-ce exacte? (dans le cas ou des applications ne supportent pas ldaps)

    Répondre
    • Bonjour,
      Question pertinente et pour y répondre : les connexions en LDAP et LDAPS seront possibles, cela ne désactive pas les connexions LDAP. En fait, les connexions LDAP/389 sont toujours nécessaires pour les connexions effectuées par les serveurs et les postes de travail, et celles-ci sont sécurisées par la signature LDAP (un article sortira prochainement sur le sujet)

      Répondre
  • Bonjour
    Merci pour l’article 🙂
    Dans le chapitre 5 il est indiqué d’importer le certificat dans le root ca du DC et dans le chapitre 6 on n’importe le certificat dans le dossier personnel des autres DC, on ne doit pas plutôt importer le certificat dans le root ca egalement ?

    Répondre
  • Hello ,

    Pas besoin de redémarrer les domaines contrôleurs après injection des certificats ?

    Sur l’article de Microsoft, il préconisent un reboot

    Répondre
  • Bonjour et merci pour cet article très intéressant.

    Serait-il possible de rajouter les commandes PowerShell pour copier et importer le certificat sur les autres contrôleurs de domaine, afin d’avoir une procédure 100%en PowerShell ?

    Comment faire sur une machine cliente (Windows, mais aussi Linux) pour faire un test en LDAP et un test en LDAPS vers les serveurs de domaine ?

    J’ai vu que vous aviez sorti un article sur OpnSense:

    Répondre
  • Salut,

    Excellent article qui va en aider plus d’un, et une 1ère étape indispensable avant de forcer LDAPS par GPO !
    Perso, je n’utilise plus cette méthode depuis peu car depuis la version de FortiOS v7.4.4, il faut un RootCA pour que LDAPS fonctionne.
    Je n’utilise pas non plus l’autorité de certification AD qui est une usine à gaz : j’ai installé OpenSSL et je génère le RootCA et mes certificats avec ça… Pratique, rapide et scriptable !

    Sinon, il y a une coquille dans le script qui liste les contrôleurs de domaine…
    Dans le cas de plusieurs serveurs AD, le résultat est correct :
    $ListOfDC
    srv-ad1.domaine.local
    srv-ad2.domaine.local
    domaine.local

    Mais dans le cas d’un seul serveur AD, le résultat est incorrect :
    $ListOfDC
    srv-ad.domaine.localdomaine.local

    Quick fix :
    $ListOfDC = @()
    $ListOfDC += (Get-ADDomainController -Filter *).Hostname
    $ListOfDC += $((Get-ADDomain).DNSroot)

    Répondre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.