Configurer LDAPs et TLS sur un Active Directory

tbowan

2 Novembre 2020

Centraliser l’authentification, c’est bien, mais en protégeant ses communications, c’est mieux. Parce que, par défaut, Active Directory n’utilise pas TLS, on va devoir lui fournir un certificat.

L’un des intérêts lorsqu’on a un Active Directory @home, c’est qu’on peut s’en servir comme fournisseur d’identité pour tous ses autres services via le protocole LDAP.

En configurant tous les services compatibles pour utiliser LDAP lors de l’authentification, vos utilisateurs pourront alors utiliser leur compte du domaine partout. Et vu qu’ils n’utiliseront qu’un seul mot de passe, on peut leur demander d’en choisir un robuste, ils auront moins envie de tricher.

Le problème, c’est que le service LDAP d’Active Directory écoute en clair par défaut. Si vous l’utilisez tel quel, n’importe qui qui peut écouter le réseau peut lire tout le trafic (avec potentiellement les mots de passes en clair).

Protéger ses données, ses mieux. Illustration de Olivier Duquesne

Heureusement, on peut configurer son serveur pour protéger les échanges avec TLS. Pour compléter la documentation officielle, on a décidé de vous partager notre méthode.

Divulgâchage : On va créer un certificat (avec quelques petites conventions) et une clé qu’on va importer (au bon endroit) dans le contrôleur de domaine. Lors du démarrage, le service voyant qu’il a un certificat disponible, écoutera automatiquement en TLS.

Créer un certificat

Qui dit TLS dit certificat qu’il faut générer. Vous pourriez partir bille en tête mais Active Directory a ses petites conventions pour que tout tombe en marche.

Attention : dans la suite, je considère que vous savez déjà créer des certificats et ne vais donc vous montrer que les trucs spécifiques (sinon l’article serait bien trop long). Si vous avez des doutes, vous pouvez lire notre autre article sur comment utiliser XCA (qui contient toutes les étapes habituelles).

Signer avec une autorité

C’est évident quand on part du principe qu’un certificat auto-signé, c’est pas sécurisé, mais ça peut valoir la peine de rappeler que le certificat devra être signé par une autorité dûment reconnue (nous).

Le certificat a été émis par une autorité de certification approuvée par le contrôleur de domaine et par les clients LDAPs. […]

Source : La documentation officielle.

Donc, dès le début, premier onglet de configuration, vous choisissez le certificat pour signer celui de votre LDAP (chez nous, notre racine s’appelle root).

Premier onglet, choisir une CA pour signer.

Comme c’est pour un serveur TLS on a pris un petit raccourci en appliquant le modèle « HTTPS Server » dès le premier onglet de configuration.

Premier onglet, appliquer le modèle de serveur HTTPS.

Nom d’hôte

Cette convention vient ensuite dans la doc officielle mais on a trouvé que c’est plus pratique à faire dès le début…

Le nom de domaine complet Active Directory du contrôleur de domaine (par exemple, DC01. DOMAIN.COM) doit apparaître à l’un des emplacements suivants :

  • Nom commun (CN) dans le champ Subject.
  • Entrée DNS dans l’extension autre nom de l’objet.

Source : La documentation officielle.

Pour le nom commun, c’est dans le premier onglet de XCA, dans la case « commonName ». Vous pouvez bien sûr configurer les autres champs pour faire plus propre mais ça n’impactera pas le service.

Deuxième onglet, configurer le Nom Commun.

Pour l’autre nom, il s’agit en fait du « subject alternative name » qui se configure dans le troisième onglet. Vous pouvez, comme nous, cocher « copier le nom commun » pour éviter de l’entrer une deuxième fois.

Troisième onglet, configurer le nom alternatif.

Extension de la clé

Lorsqu’on sait de quoi on parle, c’est très simple ici aussi. Le problème, c’est que la traduction automatique (et le jargon de Microsoft) n’aident pas vraiment…

L’extension d’utilisation de clé améliorée inclut l’identificateur d’objet d’authentification du serveur (1.3.6.1.5.5.7.3.1) (également appelé OID).

Source : La documentation officielle.

Pour vous la traduire et que vous compreniez, il faut partir de la fin… L’OID, c’est la suite de chiffres entre parenthèse, c’est ce que s’échangent les logiciels pour se comprendre. Pour que nous autres humains on comprenne, on leur donne des noms (qui sont sensé évoquer leur utilité).

En utilisant un répertoire en ligne, on trouve que l’OID 1.3.6.1.5.5.7.3.1 s’appelle en fait « Transport Layer Security (TLS) World Wide Web (WWW) server authentication » (on retrouve bien cette idée d’authentification d’un serveur, mais c’est plus précis).

Pour configurer notre certificat, on va alors dans le quatrième onglet et dans la zone des utilisations étendues (Extended key usage, rien à voir avec des « utilisation de clé améliorée »), on sélectionne le premier élément.

Quatrième onglet, ajout d’une utilisation pour authentifier le serveur.

Exporter les certificats

Pour la racine, je part du principe que vous avez déjà exporté le certificat dans un fichier spécifique (du genre root.crt).

Pour le certificat LDAP, ça n’est pas, à proprement parler, obligatoire, mais j’ai trouvé bien plus pratique pour la suite d’exporter le certificat et la clé dans un seul fichier au format PKCS#12 (plutôt que les deux fichiers que je suffixe d’habitude .crt pour le certificat et .key pour la clé mais chacun ses petites manies).

Si ces acronymes vous effrayent, dites vous que le format PKCS#12 est un fichier qui a le bon goût de contenir à la fois le certificat ET sa clé, le tout protégé par un mot de passe pour éviter que n’importe qui puisse en faire n’importe quoi.

Avec XCA, vous devez sélectionner votre nouveau certificat dans la liste puis cliquer sur le bouton « Exporter » (c’est aussi accessible via un clic droit).

Dans l’écran d’exportation, choisissez le format PKCS #12 (*.p12), sélectionnez l’emplacement et le nom de votre fichier et cliquez sur OK.

Export au format PKCS #12.

Comme promis, XCA vous demande un mot de passe, deux fois pour être sûr que vous n’avez pas fait de faute de frappe.

Mot de passe pour protéger le fichier p12.

Importer la PKI

Pour que LDAP écoute sur le porte idoine (par convention, le port TCP 636), il suffit d’intégrer les certificats dans « le magasin de certificats personnels de l’ordinateur local » (dixit la doc) et le service ouvrira le port tout seul. Ne vous en faites pas, comme toujours, c’est plus facile qu’il n’y paraît.

Il y a des tutoriel pour utiliser des commandes, du PowerShell et tout mais personnellement, j’ai trouvé que leur outil graphique était plus intuitif à utiliser.

Dans une invite de commande (cmd.exe, via le raccourci ctrl+r ou via le menu), lancez l’outil ultime (en tant qu’administrateur mais vu que vous êtes sur votre AD, ça devrait déjà être le cas) :

certlm.msc

Comme son nom l’indique, vous êtes dans le magasin des certificats de l’ordinateur local 🎉.

Gestionnaire du magasin des certificats de l’ordinateur local.

Importer la CA

Je ne résiste pas à vous citer le reste de la documentation concernant la signature par une autorité :

[…] L’approbation est établie en configurant les clients et le serveur de sorte qu’ils approuvent l’autorité de certification racine à laquelle l’autorité de certification émettrice est chaînée.

Pour les clients, ça concerne les différents services qui se connecteront au LDAP, ça ne nous concernent pas pour cette fois. On va plutôt s’occuper du serveur.

Dans la liste de gauche, déroulez le deuxième dossier « Autorités de certification racines de confiance » puis sélectionnez le sous-dossier « Certificats ».

Si vous êtes joueur, faite un clic droit dans la zone blanche après les certificats, sans toucher un certificat, le menu « Toutes les tâches » contiendra alors un item « Importer… ». Si vous touchez une ligne avec un certificat, le menu ne contiendra que « ouvrir » et « Exporter ».

Importer un certificat via le clic-droit.

Sinon, en vous assurant qu’aucun certificat n’est sélectionné, (vous pouvez cliquer sur un autre dossier puis revenir à celui-ci), le menu « Action » contient les sous-menus « Toutes les tâches » puis « Importer… ».

Importer un certificat via le menu.

L’assistant s’ouvre et vous permet de procéder à l’importation. Le premier écran n’est qu’informatif, cliquez sur « Suivant ».

Démarrage de l’assistant.

Le deuxième permet de choisir le certificat, cliquez sur le bouton « Parcourir ». Choisissez le fichier (correspondant au certificat de votre CA).

Choix du fichier à importer.

Cliquez sur « Suivant » vous amène sur un récapitulatif, vérifiez que vous êtes bien dans le magasin des autorités (ce devrait être le cas).

Choix de l’emplacement de l’import.

Cliquez sur « Suivant » vous amène sur le dernier récapitulatif…

Récapitulatif avant import.

Cliquez sur « Terminer » et votre certificat apparaîtra dans la liste.

Liste des certificats.

Importer le certificat p12

Vous pouvez maintenant poursuivre la lecture de la documentation… dans le désordre pour simplifier (sinon on devrait générer le certificat avant de le configurer…).

Le certificat LDAPs se trouve dans le magasin de certificats personnels de l’ordinateur local (appelé par programmation mon magasin de certificats de l’ordinateur).

Ça paraît bizarre, c’est en fait tout simple, dans la liste des dossiers à gauche, le premier s’appelle « Personnel », c’est lui qu’il faut choisir. Si des certificats sont déjà présents, il faut ensuite cliquer sur son sous-dossier « Certificats ».

Sélection du magasin personnel de l’ordinateur local.

Cette fois, toute la zone est vide, on peut cliquer droit plus facilement, choisir « Toutes les tâches » puis « Importer… » (marche aussi avec le menu).

Importer un certificat, clic-droit

Le même assistant que précédemment s’ouvre et vous pouvez poursuivre (cliquer sur « Suivant »).

Démarrage de l’assistant.

Le deuxième permet de choisir le certificat, cliquez sur le bouton « Parcourir » et cette fois, choisissez le fichier du certificat prévu pour LDAP, au format PKCS #12 et dont le nom se termine par .p12.

Choix du fichier.

Comme le fichier est protégé, l’écran suivant vous demande le mot de passe. Entrez-le puis cliquez sur « Suivant ».

Mot de passe pour ouvrir le fichier p12.

Cliquez sur « Suivant » vous amène sur un récapitulatif, vérifiez que vous êtes bien dans le magasin des autorités (ce devrait être le cas).

Choix de l’emplacement pour l’import.

Dernière vérification (on est jamais trop prudents) et ça sera terminé.

Récapitulatif.

Redémarrer l’AD

Pour que LDAP écoute en TLS, il faudrait le redémarrer et tout se ferait alors automatiquement.

Le problème, c’est qu’il y a tout un écosystème de programmes qui gèrent les services, les certificats et dieu seul sait quoi d’autre, ça ne servira à rien de ne redémarrer que LDAP car les autres ne seront pas prêts et il ne verra pas la différence

Redémarrez donc votre contrôleur de domaine (de préférence lorsque personne n’en a besoin).

Et après ?

Maintenant que vous avez un service d’annuaire LDAP disponible via TLS, il ne vous reste plus qu’à configurer vos services pour l’utiliser lors de l’authentification et simplifier la vie de vos gentils utilisateurs.

LDAPs vs starttls

9 Novembre 2020 Le premier est sensé être déprécié au profit du second. C’est ce qu’on dit partout mais qu’est-ce que ça change ?

Restreindre un compte Active Directory pour des services

23 Novembre 2020 Parce qu’on est jamais à l’abri qu’un compte utilisé par un programme ou un service soit détourné, il est utile de peaufiner ces comptes spéciaux pour restreindre leurs possibilités.