Il y a quelques mois, une annonce de Microsoft relative à la configuration du protocole LDAP a provoqué une certaine perplexité dans la communauté. Ces annonces recommandent aux administrateurs Active Directory d’activer deux paramètres aux noms ésotériques :
- LDAP Signing
et encore plus mystérieux :
- LDAP Channel Binding
La documentation Microsoft se garde bien de détailler quel est l’impact technique exact de ces options, cependant on comprend à demi mots que l’exigence LDAP Signing signifie concrètement que les applications qui utilisent un annuaire Active Directory comme source de données (LDAP Synchronisation Connector, LemonLDAP::NG, saslauthd ou encore LTB White Pages) devront désormais se connecter à Active Directory via une connexion sécurisée par TLS. L’exigence sur le Channel Binding, ne semble pas, d’après nos tests, avoir d’impact sur le bon fonctionnement des applications.
L’impact de ces recommandations sur les applications LSC, LemonLDAP::NG, saslauthd, White Pages, Self Service Password est identique : afin de correspondre aux nouvelles recommandations Microsoft, il est désormais nécessaire de configurer ces applications pour communiquer avec Active Directory via le protocole LDAPS.
Constater le problème
Afin de vérifier la connexion entre un serveur Linux et un AD, le plus simple est d’utiliser la commande ldapsearch. Cette commande s’installe via le package ldap-utils sous Debian et Ubuntu, ou via le package openldap-clients sous RHEL et CentOS.
On se contentera d’une requête LDAP sur la racine de l’annuaire, via un compte de service :
ldapsearch -x -H ldap://ad-test.mslab.intra.worteks.com -D compte_service@domaine -w password -s base
Le résultat en temps normal devrait être un long listing technique qui se termine par :
result: 0 Success
Cependant, une fois les recommandations Microsoft appliquées, la signature des communications devient nécessaire, et le message suivant apparaît alors :
ldap_bind: Strong(er) authentication required (8)
additional info: 00002028: LdapErr: DSID-0C09023C, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v4563
C’est le signe qu’il est temps (et en 2020, il est en effet temps) de passer au protocole LDAP sécurisé !
Deux approches sont alors possibles :
- Utiliser le mode STARTTLS, qui passe par le port 389
- Utiliser le mode LDAPS, qui passe par le port 636
On fera dans la suite de ce billet l’hypothèse que les flux réseau entre le serveur Linux et l’Active Directory sur le port TCP 636 sont ouverts, et on utilisera donc le protocole LDAPS.
Essayons donc de contacter Active Directory sur le port dédié à LDAPS :
ldapsearch -x -H ldaps://ad-test.mslab.intra.worteks.com -D compte_service@domaine -w password -s base
Si cette commande réussit, alors félicitations, vous pouvez mettre à jour la configuration de vos applications pour utiliser des URL en ldaps:// au lieu de ldap://. Cependant la plupart du temps, vous ne serez pas tout à fait au bout de vos peines, et le message suivant risque d’apparaître :
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
Ce message d’erreur indique que le serveur LDAP (Active Directory dans notre cas), n’a pu être joint. Attention, car cette erreur très générique peut cacher de nombreux problèmes différents. Les plus fréquents sont :
- Flux réseau non ouvert sur le port TCP 636
- Certificat manquant dans Active Directory
- Erreur de validation du certificat serveur
Pour y voir plus clair, augmentons le niveau de log via l’option -d 1:
ldapsearch -x -H ldaps://ad-test.mslab.intra.worteks.com -D compte_service@domaine -w password -s base -d 1
On voit alors apparaître un message plus précis. Partons du principe que les flux réseau sont ouverts et voyons quelques cas d’erreurs possibles.
Certificat manquant
TLS: can't connect: The TLS connection was non-properly terminated..
Cette erreur indique que le serveur Active Directory n’a pas présenté de certificat, il est probable qu’aucun certificat serveur n’ait été généré sur le serveur Active Directory.
Pour ce faire, à moins de disposer déjà d’une PKI interne, Worteks recommande l’installation du service de certificats Active Directory. Ce service permet facilement de générer des certificats pour le service LDAPS.
Attention simplement lors de la configuration initiale de l’autorité de certification à bien choisir un algorithme de signature suffisamment robuste :
Attention également à la durée de vie de l’autorité de certification. Elle est par défaut de 5 ans, ce qui veut dire que le certificat devra être renouvelé 5 ans après sa création.
Une fois l’autorité de certification installée, il est possible de générer un certificat. Cette opération doit être faite sur tout les contrôleurs de domaine, via le MMC “Certificats” avec la portée “Machine” :
La politique “Contrôleur de domaine” conviendra à l’usage du nouveau certificat sur une connexion LDAPS.
Une fois ce certificat généré, Active Directory sera capable de répondre via le protocole LDAPS.
Autorité de certification non reconnue
Qu’un certificat LDAPS ait déjà été crée préalablement sur l’AD, ou que vous veniez tout juste de le mettre en place, vous rencontrerez ensuite très probablement l’erreur suivante :
TLS: peer cert untrusted or revoked (0x42)
TLS: can't connect: (unknown error code).
Cette erreur indique que le certificat présenté par Active Directory n’a pas pu être validé par le serveur Linux. C’est parfaitement normal puisqu’il n’a pas été émis par une autorité publique reconnue par le serveur Linux.
Pour que le certificat racine ainsi généré soit reconnu, il suffit de l’exporter au format PEM et de le copier sur le serveur Linux.
Pour ce faire, ouvrir la console des certificats sur l’AD, pour le compte “Ordinateur Local”. Et afficher le certificat de l’autorité de certification :
Attention, il faut bien prendre le certificat qui se termine par CA et non pas le certificat du serveur.
Pour exporter ce certificat, afficher l’onglet détails :
Utiliser le bouton “Copy to file” et choisir le format Base64 :
On obtient un fichier avec l’extension .cer qu’il faut alors copier sur les serveurs Linux.
Ensuite, la procédure diffère en fonction de la distribution. On choisit dans cet exemple le nom mon_AD.crt. Le nom de fichier n’a pas d’importance, mais l’extension doit être .crt.
Debian :
cp certificat.cer /usr/local/share/ca-certificates/mon_AD.crt
update-ca-certificates
RedHat :
cp certificat.cer /etc/pki/ca-trust/source/anchors/mon_AD.crt
update-ca-trust
Le cas particulier de Java
La méthode présentée ci dessus pour enregistrer une nouvelle autorité de certification fonctionne avec la plupart des langages installés sur la machine: PHP, Python, Ruby…
Elle fonctionne également si vous utilisez OpenJDK, et que vous l’avez installé avec les packages Yum ou APT fournis par la distribution.
Cependant, si vous utilisez une JVM installée manuellement, une étape supplémentaire est nécessaire. Il faut inscrire le certificat d’autorité de l’AD dans le fichier cacerts fourni par la JVM, généralement dans jre/lib/security. Pour ce faire, lancer la commande suivante :
keytool -import -trustcacerts -alias my_ad -file mon_AD.crt \
-keystore jre/lib/security/cacerts
Le mot de passe par défaut est changeit
Nom de certificat incorrect
La dernière erreur qui peut se présenter est la suivante :
TLS: hostname (192.168.122.12) does not match common name in certificate (ad-test.mslab.intra.worteks.com).
Elle signifie que le nom de serveur fourni à la commande ldapsearch ou renseigné dans la configuration d’une application ne correspond pas au nom présenté par le certificat du serveur. Ce contrôle est indispensable pour se prémunir des attaques de type Man-In-The-Middle.
Il est donc indispensable de renseigner une URL de connexion qui corresponde bien au certificat généré.
Le service de certificats Active Directory permet de générer des certificats avec des alias (SubjectAltName), très utile dans des situations où des IP virtuelles sont utilisées.
Conclusion
Une fois notre Active Directory muni d’un certificat, l’autorité émettrice enregistrée auprès des serveurs Linux, et l’URL de connexion mise en conformité avec le certificat (ou réciproquement !), on peut finalement réussir notre recherche LDAP :
ldapsearch -x -H ldaps://ad-test.mslab.intra.worteks.com -D compte_service@domaine -w password -s base
...
result: 0 Success
Il ne reste plus qu’à configurer la nouvelle URL LDAPS dans les applications.
