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 (et, entre autre, retrouver les mots de passes).

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.

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.

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. […]

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

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.

Nom d’hôte

Cette convention vient plus tard dans la doc officielle mais on trouve 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.

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.

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.

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

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.

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.

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.

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

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.

La documentation officielle

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

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

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

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

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

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

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

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

La documentation officielle

Ç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. S’il contient déjà des certificats, un sous répertoire est présent. Vous pouvez vous y rendre (mais ça marche aussi directement dans Personnel).

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

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

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.

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

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

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

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 forcémetn 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 ?

Lorsque votre Active Directory démarrera, il verra votre certificat, se rendra compte qu’il peut l’utiliser pour sécuriser ses connexions avec LDAPs ou starttls et activera donc ces fonctionnalités.

Il ne vous reste donc plus qu’à aller configurer tous vos services pour utiliser le LDAP de votre AD comme fournisseur d’identité et éviter d’avoir plein de comptes partout. Vos utilisateurs apprécierons (et vous aussi).