Active Directory – Comment configurer le LDAPS avec ADCS ?
Sommaire
I. Présentation
Dans ce tutoriel, nous allons apprendre à délivrer un certificat LDAPS à partir d'une autorité de certification d'entreprise basée sur ADCS. Ce certificat TLS sera déployé sur les contrôleurs de domaine (DC) afin de chiffrer les échanges LDAPS entre les DC et les clients LDAP.
Cela ajoute une couche de sécurité absente par défaut avec le protocole LDAP, notamment pour les connexions LDAP en Simple Bind. Il s'agit donc d'une mesure complémentaire à la signature LDAP, qui s'applique à des cas d'usage différents (une application web qui s'appuie sur l'authentification LDAP, par exemple).
- Active Directory – Comment configurer le LDAPS avec un certificat autosigné ?
- ADCS : Comment créer une autorité de certification racine d’entreprise sous Windows Server ?
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.
II. LDAPS avec ADCS : deux approches possibles
Pour mettre en œuvre le LDAPS en environnement Active Directory, par l'intermédiaire d'une autorité de certification ADCS, il y a deux approches possibles. La première méthode évoquée ci-dessous sera expliquée en détail dans ce tutoriel.
- Avec un alias DNS « ldaps.it-connect.local »
La première approche consiste à créer un enregistrement DNS pour englober tous les serveurs à contacter pour les connexions LDAPS, par exemple "ldaps.it-connect.local". Il s'agira de créer un enregistrement A, avec le même nom, pour chaque contrôleur de domaine à contacter (principe du Round-Robin). Ceci permet d'avoir un seul certificat pour le LDAPS, peu importe le nombre de contrôleurs de domaine.
Cette méthode facilite l’intégration sur les applications tierces pour avoir un seul nom qui renvoie vers un pool de DC. Ce qui assure aussi la disponibilité de la connectivité LDAPS.
Une fois que le certificat sera généré, il sera nécessaire de l'exporter puis de l'importer sur tous les contrôleurs de domaine. Cette méthode implique de déclarer tous les DC en tant que nom DNS dans le certificat, au moment de faire la demande de certificat, sinon la connexion est refusée.
Pour effectuer un déploiement basé sur cette méthode, il est nécessaire de cocher l’option « Fournir dans la demande » dans les options du modèle ce certificat. C'est un risque pour la sécurité, mais nous verrons qu'une bonne configuration des permissions nous permettra de maitriser ce risque.
- Sans alias DNS
La seconde méthode consiste à générer un certificat pour chaque DC. L’option « Fournir dans la demande » n’est pas activée dans les propriétés du modèle de certificat, donc le certificat contient uniquement le nom DNS du DC à l’origine de la demande (par exemple « SRV-ADDS-01 »). Cette option présente, par défaut, moins de risques de sécurité, mais elle est moins pratique. Elle peut être préférée à l'autre méthode si vous envisagez d'établir les connexions LDAPS uniquement vers un DC.
Dans le certificat, il y a bien le nom de domaine « it-connect.local », en plus du nom FQDN du serveur. Donc, il est possible d'établir une connexion LDAPS en précisant le nom complet du DC, mais aussi le nom de domaine Active Directory, sauf que cela peut ne pas fonctionner à tous les coups :
- Si la connexion LDAPS initiée sur le nom « it-connect.local » renvoie sur le serveur « SRV-ADDS-01 », ça passe.
- Si la connexion LDAPS initiée sur le nom « it-connect.local » renvoie sur le serveur « SRV-ADDS-02 », qui est l’autre DC, non renseigné dans le certificat, ça ne passe pas.
C'est pour cette raison que cette méthode implique de créer un certificat pour chaque contrôleur de domaine. Le certificat racine de la CA doit être importé aussi sur le serveur client LDAPS (serveur applicatif, par exemple), comme pour la première méthode.
Pour le déploiement, il y a des étapes communes entre ces deux méthodes, mais il y a des différences dans la configuration du modèle de certificat.
III. Étape préparatoire : enregistrement DNS
La première étape consiste à créer un enregistrement DNS "ldaps.it-connect.local" dans la zone de recherche directe de votre domaine. Ici, il y a un enregistrement A pour chacun de mes deux DC : "SRV-ADDS-01" et "SRV-ADDS-02". Vous pouvez utiliser le nom de votre choix pour l'enregistrement DNS.
Commencez par ouvrir la console "Gestionnaire DNS" sur le serveur, puis accédez aux propriétés du serveur DNS. Dans l'onglet "Avancé", vérifiez que l'option "Activer le tourniquet (round robin)" est cochée. En principe, c'est le cas avec la configuration par défaut.
Ensuite, il convient de créer un enregistrement A nommé "ldaps" associé à l'adresse IP de chaque DC à interroger. Ces enregistrements sont à créer dans la zone "it-connect.local", c'est-à-dire la zone de recherche directe du domaine AD. La création d'un enregistrement s'effectue à partir du clic droit.
Voici les deux enregistrements créés pour "ldaps.it-connect.local"en spécifiant les adresses IP des contrôleurs de domaine :
Une fois que c'est fait, vous pouvez contrôler la résolution de noms sur ce nom DNS, via la commande nslookup.
nslookup ldaps.it-connect.local
Ceci doit retourner les adresses IP des DC.
Quand c'est fait, vous pouvez passer à la suite.
IV. Délivrer un certificat LDAPS avec ADCS
A. Créer un modèle de certificat LDAPS
La première étape consiste à créer un nouveau modèle de certificat pour le LDAPS, en prenant comme base le modèle pour Kerberos.
Ouvrez la console "Autorité de certification" afin d'administrer votre CA montée avec le rôle ADCS. Effectuez un clic droit sur "Modèles de certificats" (ceci implique d'avoir une CA d'entreprise) puis cliquez sur "Gérer".
Ensuite, effectuez un clic droit sur "Modèles de certificats", puis cliquez sur "Gérer". Une nouvelle fenêtre va s'ouvrir. Dans la liste, effectuez un clic droit sur le modèle nommé "Authentification Kerberos" et choisissez "Dupliquer le modèle".
Nous allons personnaliser notre nouveau modèle. Commencez par l'onglet "Général". Nommez ce modèle, par exemple "LDAPS".
Basculez dans l'onglet "Traitement de la demande" afin de cocher l'option "Autoriser l'exportation de la clé privée". Ceci est nécessaire dans le but de pouvoir exporter le certificat au format PFX (il permet d'inclure la clé privée) et de l'importer ensuite sur les autres DC.
Remarque : si vous choisissez l'autre méthode évoquée en introduction, il n'est pas nécessaire de cocher l’option « Autoriser l’exportation de la clé privée » puisque chaque DC dispose de son certificat qui lui est propre.
Ensuite, poursuivez avec l'onglet nommé "Nom du sujet". Ici, vous devez choisir "Fournir dans la demande" pour que les propriétés du certificat soient définies au moment où nous allons en faire la demande. Ceci permettra de spécifier le nom DNS personnalisé "ldaps.it-connect.fr". C'est également accompagné par un avertissement de sécurité (validez).
Pour finir, cliquez sur l'onglet "Sécurité" pour limiter l'accès à ce modèle de certificat. Supprimez les permissions inutiles. Il est surtout essentiel de conserver les permissions pour les "Contrôleurs de domaine" (inscription) ainsi que pour les "Utilisateurs authentifiés" (en lecture seule). Pour affiner les permissions, vous pouvez supprimer "Utilisateurs authentifiés" et ajouter à la place le compte ordinateur correspondant au serveur hébergeant l'autorité de certification.
Validez. Cliquez sur "Modèles de certificats" et cette fois-ci, accédez à "Nouveau" pour cliquer sur "Modèle de certificat à délivrer".
Dans la liste, sélectionnez le modèle "LDAPS" et validez. S'il n'apparaît pas dans la liste, patientez jusqu'à la prochaine synchronisation Active Directory et réessayez. Vous pouvez aussi forcer la synchronisation AD avec repadmin.
Voilà, le modèle de certificat est créé.
B. Demander un certificat LDAPS
Le modèle étant prêt, nous allons demander un nouveau certificat basé sur ce modèle.
Connectez-vous sur un contrôleur de domaine, ouvrez le menu "Exécuter" avec le raccourci "Win + R" puis saisissez "mmc" avant d'appuyer sur Entrée. Ensuite, cliquez sur le menu "Fichier", puis sur "Ajouter/Supprimer un composant logiciel enfichable".
Sélectionnez le composant nommé "Certificats" et cliquez sur le bouton "Ajouter". Dans la fenêtre qui apparaît, choisissez l'option "Un compte d'ordinateur" et poursuivez jusqu'à la fin (conservez l'ordinateur local).
Une fois que la console est ouverte, accédez à "Personnel" puis effectuez un clic droit sur "Certificats". À partir du menu "Toutes les tâches", cliquez sur "Demander un nouveau certificat".
Passez les premières étapes...
L'assistant va lister les modèles de certificats disponibles. Cochez "LDAPS" et cliquez sur le lien "L'inscription pour obtenir...". Cette option est disponible, car nous avons activé l'option "Fournir dans la demande" pour le nom du sujet. Si les permissions sur le modèle ne sont pas assez restrictives, un attaquant pourrait accéder à ce modèle pour obtenir un certificat pour le nom de son choix.
Dans la fenêtre qui apparaît, commencez par ajouter "ldaps.it-connect.local" en tant que "Nom commun" et "DNS". Comme ceci :
Puis, ajoutez les noms complets des contrôleurs de domaine dans la partie "DNS", comme sur l'exemple ci-dessous. Afin de respecter les bonnes pratiques, vous devez aussi ajouter d'autres champs comme le pays, l'organisation et le service (OU).
Validez et finalisez la demande. Vous devriez obtenir un message de confirmation, ce qui signifie que votre machine a pu obtenir le certificat souhaité.
Remarque : si vous obtenez l'erreur 0x80094800 "-2146875392 CERTSRV_E_UNSUPPORTED_CERT_TYPE" au moment de finaliser la demande de certificat, c'est que vous avez un problème de permissions. En général, cette erreur se produit lorsque le groupe "Utilisateurs authentifiés" n'a plus aucun droit sur le modèle de certificat, car la CA elle-même n'a plus accès en lecture au modèle (voir cette page).
Le certificat LDAPS est bien présent dans le magasin des certificats du DC :
Du côté du serveur ADCS, vous pouvez retirer le modèle correspondant au LDAPS de la liste des modèles publiés, puisque nous n'en aurons plus besoin. Ceci évite qu'il soit accessible à un tiers non autorisé (en cas de mauvaise gestion des permissions) : il vous suffira de le republier pour les phrases de renouvellement (via le menu "Nouveau" puis "Modèle de certificat à délivrer" tel que nous l'avons fait précédemment).
C. Exporter le certificat LDAPS
Vous devez exporter le certificat et sa clé privée dans le but de l'importer sur les autres contrôleurs de domaine. Attention, cet export est destiné uniquement aux contrôleurs de domaine ! Pour importer le certificat sur un serveur applicatif, réalisez un export sans la clé privée !
Effectuez un clic droit sur le certificat, puis sous "Toutes les tâches", choisissez l'option "Exporter...".
Suivez l'assistant... Choisissez d'exporter la clé privée.
Le format de sortie est "PFX" puisque nous avons pris la décision d'inclure la clé privée au fichier de sortie.
Je vous encourage à protéger ce certificat avec nom d'utilisateur ou un groupe de sécurité, ou à minima avec un mot de passe. Ceci évite que n'importe qui puisse le lire et l'importer.
Spécifiez le nom et l'emplacement du fichier de sortie.
Poursuivez et validez. Vous voilà en possession du certificat LDAPS au format PFX.
D. Importer le certificat LDAPS sur les DC
Copiez-collez le fichier "LDAPS-AD.pfx" sur les autres DC et importez-le. Ici, nous utilisons la méthode manuelle, mais il est possible de s'appuyer sur PowerShell pour gagner du temps. Double-cliquez sur le fichier, puis choisissez "Ordinateur actuel" avant de continuer.
Passez les premières étapes en conservant les choix par défaut. Veillez à placer le certificat dans le magasin "Personnel" en cliquant sur le bouton "Parcourir".
Poursuivez jusqu'à la fin... Voilà, le certificat LDAPS est désormais présent dans le magasin des certificats de mes 2 contrôleurs de domaine.
V. Configurer la connexion sur un client LDAPS
A. La configuration d'un client LDAPS
Lorsqu'un appareil va établir une connexion en LDAPS auprès d'un contrôleur de domaine, il devra faire confiance au certificat présenté, à savoir le certificat correspondant à "ldaps.it-connect.local". Si le client LDAPS est un appareil membre du domaine Active Directory, il acceptera le certificat, car il dispose du certificat de l'autorité racine dans son magasin local. À l'inverse, si c'est un appareil qui n'est pas membre du domaine (un équipement réseau, une machine sous Linux, etc.), le certificat sera refusé et la connexion échouera.
Pour ce second scénario (étudié ici car il demande des étapes supplémentaires), vous devez donc exporter le certificat de l'autorité de certification afin de l'importer sur le client LDAPS. Ainsi, notre CA d'entreprise sera reconnu comme étant une autorité de certification racine de confiance. Nous pourrions aussi exporter et importer directement le certificat LDAPS, mais il est plus cohérent de le faire avec le certificat de la CA en elle-même (avec un certificat auto-signé, nous n'avons pas le choix que de prendre le certificat spécifique au LDAPS).
À partir de votre serveur ADCS, vous devez exporter le certificat sans la clé privée. Vous pouvez utiliser la console MMC et utiliser l'option "Exporter..." du menu contextuel, sur un principe semblable à ce que nous avons fait précédemment (mais sans la clé privée, j'insiste).
Sinon, vous pouvez utiliser PowerShell pour gagner du temps.... Exécutez la commande ci-dessous pour stocker les informations sur votre certificat dans la variable "$CertCA". Adaptez simplement la valeur "CN=IT-Connect-CA-Root".
$CertCA = Get-ChildItem "Cert:\LocalMachine\My\" | Where-Object { $_.Subject -match "CN=IT-Connect-CA-Root" } | Get-Item
Puis, exportez le certificat de cette façon :
Export-Certificate -Cert $CertCA -FilePath "C:\Cert-IT-Connect-CA-Root.cer"
Le nom de votre domaine sera inclus dans le fichier de sortie. Pour ma part, j'obtiens le fichier "Cert-IT-Connect-CA-Root.cer". La prochaine étape se passera sur le serveur correspond au client LDAPS !
B. Quel outil pour tester une connexion LDAPS ?
Si vous utilisez Windows Server, vous pouvez utiliser l'outil "ldp.exe" en tant que client LDAP pour tester votre configuration. Il est présent sur les contrôleurs de domaine, car il est inclus dans les outils d'administration AD. Sur un autre serveur, vous pouvez l'installer de cette façon :
Si vous utilisez Linux, vous pouvez installer le paquet "ldap-utils" sur votre serveur pour avoir accès à la commande "ldapsearch" :
sudo apt-get install ldap-utils
Nous verrons un exemple d'utilisation dans la suite de cet article.
C. Tester la connexion LDAPS avec Linux
Pour tester le bon fonctionnement de la connexion LDAPS, je vais utiliser une machine Linux (hors domaine) qui héberge une application... Mais cela importe peu, puisque nous allons utiliser la commande "ldapsearch".
Tout d'abord, vous devez copier le fichier "Cert-IT-Connect-CA-Root.cer" sur le serveur Linux. Si votre serveur est équipé d'un accès SSH, vous pouvez utiliser WinSCP pour effectuer le transfert du fichier via SFTP.
Puis, à l'aide de l'outil openssl, vous devez convertir le fichier CER au format CRT avant de l'ajouter au magasin de certificats de la machine Linux. Positionnez le terminal dans le répertoire où se situe le fichier ".cer". Ensuite, exécutez cette commande :
openssl x509 -inform der -in Cert-IT-Connect-CA-Root.cer -out Cert-IT-Connect-CA-Root.crt
Le fichier "Cert-IT-Connect-CA-Root.crt" obtenu en sortie doit être copié dans le répertoire "/usr/local/share/ca-certificates/" du serveur. Vous devez disposer de privilèges élevés pour effectuer cette manipulation, car cela ajoute un nouveau certificat au magasin de la machine.
sudo cp /home/flo/Cert-IT-Connect-CA-Root.crt /usr/local/share/ca-certificates/
Quand c'est fait, mettez à jour le magasin des certificats :
sudo update-ca-certificates
La commande ci-dessous permet de tenter une connexion LDAPS (donc sur le port 636) en ciblant le nom "ldaps.it-connect.local". Nous spécifions aussi un compte utilisateur avec lequel s'authentifier (ici "Sync_GLPI" précisé via son DistinguishedName). Puis, nous cherchons à récupérer tous les utilisateurs présents sous la base "OU=IT-Connect,DC=it-connect,DC=local".
ldapsearch -H ldaps://ldaps.it-connect.local:636 -x -W -D "CN=Sync_GLPI,OU=Connecteurs,DC=it-connect,DC=local" -b "OU=IT-Connect,DC=it-connect,DC=local"
Suite à l'exécution de cette commande, le mot de passe du compte "Sync_GLPI" est demandé. Si la configuration est correcte, le contenu de l'annuaire est retourné :
Quelques précisions sur les options utilisées :
- -D : DistinguishedName de l'utilisateur qui doit être utilisé pour s'authentifier auprès de l'annuaire Active Directory.
- -x : authentification simple.
- -W : demander à ce que le mot de passe soit saisit de façon interactive.
- -b : base DN pour la recherche des objets dans l'annuaire (DistinguishedName de la racine sur laquelle se positionner pour effectuer la recherche).
D. Tester la connexion LDAPS avec Windows
Sur Windows, vous devez également importer le certificat de l'autorité de certification (sauf s'il s'agit d'une machine intégrée au domaine AD). Dans ce cas, transférez sur la machine le fichier "Cert-IT-Connect-CA-Root.cer" et double-cliquez dessus.
Cliquez sur le bouton "Installer un certificat", choisissez "Ordinateur local" puis cliquez sur le bouton "Suivant".
Suivez l'assistant en veillant à placer ce certificat dans le magasin nommé "Autorités de certification racines de confiance". Cliquez sur le bouton "Parcourir" pour sélectionner ce magasin.
Finalisez l'importation.
Ensuite, vous pouvez faire vos tests à partir de l'outil "LDP". Il vous suffit de l'appeler à partir de la zone de recherche de la machine (ldp.exe).
Indiquez "ldaps.it-connect.local" en tant que serveur, spécifiez le numéro de port "636" et cochez la case "SSL". Cliquez sur "OK" pour tenter une connexion.
Si la connexion réussie, vous obtiendrez un résultat similaire à celui présenté ci-dessous. Sinon, il n'y aura que quelques lignes, ainsi qu'une erreur.
Vous pouvez considérer que la connexion LDAPS est opérationnelle !
E. Le trafic LDAPS vu par Wireshark
Si nous capturons les échanges entre le DC et le serveur client, avec une application telle que Wireshark, nous pouvons voir que les échanges LDAP sont chiffrés à l'aide de TLS.
Si nous regardons de plus près l'un des paquets, nous pouvons voir qu'il s'agit de données applicatives "LDAP" et qu'elles sont chiffrées. Ainsi, nous ne pouvons pas lire le contenu. En temps normal, avec le LDAP, nous aurions pu voir en clair le contenu des échanges.
Missions accomplie avec succès !
VI. Conclusion
En suivant ce tutoriel pas-à-pas, tout en l'adaptant à votre infrastructure, vous devriez être en mesure de mettre en œuvre le LDAPS en vous appuyant sur une autorité de certification d'entreprise ! Le certificat de la CA peut être importé sur des serveurs Linux ou Windows, ou des équipements réseau tels que des firewalls, en fonction de la machine qui doit être en mesure de se connecter en LDAPS.
Sur le même sujet, nous vous invitons à lire cet article :
Merci à Hugues Moccand d’avoir pris le temps de me conseiller pour la rédaction de cet article.
Bonjour,
Merci pour vos articles très instructifs dans le monde de l’IT !
Je me permets un petit complément, car nous avons été confronté à une situation similaire, et avons trouvé une solution Microsoft dans la même philosophie, mais permettant d’automatisé la génération des certificats.
En remplaçant le model de certificat « Domain controller » par « Kerberos Authentification », les certificats autorenouvellés par les DCs intègrent directement le fqdn du domain (lui-même répondant déjà en round robin sur les IPs des DCs).
https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust
Ce mode de fonctionnement est similaire à ceci près qu’il n’est pas possible d’utiliser un nom dns personnalisé, ce serait pour vous « it-connect.local ».
Bonne continuation
Au temps pour moi, après relecture, nous sommes dans le deuxième cas de figure évoqué dans l’article. Nous n’avons cependant pas rencontré de problème particulier sous réserve de bien faire ses requêtes avec le nom dns du domaine… L’avantage du renouvellement automatique a appréciable, tout en gardant un bon niveau de sécurité avec uniquement les DCs ayant les droits de renouvellement sur le modèle de certificat. Cela a été implémenté sur un environnement composé de 6 domaines (5 historiques) et un AD CS cross-forest. Bonne continuation.