Précédent Remonter

5  SSL

Afin de sécuriser les échanges d'informations avec les différents serveurs LDAP, on peut utiliser SSL (Secure Sockets Layer), qui est en fait une couche se rajoutant dans les paquets transmis, et permettant de crypter les données transmises.

J'ai tenté d'utiliser SSL avec OpenLDAP et Active Directory .

5.1  SSL avec OpenLDAP

Pour pouvoir utiliser SSL avec OpenLDAP , il faut l'avoir compilé avec le support SSL/TLS (TLS : Transport Layer Security). Il faut avoir au préalable installé OpenSSL .

(On peut aussi installer un package rpm, mais au moment de la rédaction de ce document, la dernière version que j'ai trouvée est OpenLDAP 2.1.25 (pas en paquet officiel, mais sur http://www.int-evry.fr/mci/user/procacci/SRPMS/9/ ). Cette version possède le support SSL, on peut donc l'utiliser)

Pour compiler OpenLDAP avec le support SSL/TLS, j'ai dû taper les commandes suivantes depuis le répertoire des sources : 
$ export CPPFLAGS='-I/usr/local/BerkeleyDB.4.2/include -I/usr/kerberos/include'
      # configure ne trouvant pas les headers kerberos, il a fallu lui indiquer
      # où ils se trouvent
$ export LDFLAGS='-L/usr/local/BerkeleyDB.4.2/lib'
$ ./configure --with-tls=yes --with-cyrus-sasl=no
      # l'utilisation de tls et de cyrus sasl est choisie automatiquement par défaut,
      # ici on force l'utilisation de tls, et on interdit celle de cyrus sasl
      # (en effet, il y a déjà une version trop ancienne de cyrus sasl installée,
      # que je ne peux pas supprimer car c'est une dépendance de sendmail, mutt
      # et squid, et en compilant la dernière version, j'ai un problème de conflit de 
      # versions que je n'ai pas réussi à résoudre)
$ make depend
$ make
$ make test
$ su -c "make install"
Pour pouvoir utiliser SSL, il faut créer un certificat, reconfigurer le serveur, et le relancer en lui indiquant d'utiliser ssl.

5.1.1  Création d'un certificat

(cf http://www.openldap.org/pub/ksoper/OpenLDAP_TLS_howto.html (en anglais))

On peut assez aisément créer un certificat à l'aide d'OpenSSL .

En fait, on a besoin de : Pour les obtenir, on procède ainsi : Maintenant qu'on a les certificats nécessaires, on peut passer à la configuration du serveur OpenLDAP .

5.1.2  Configuration

On commence par copier les fichiers que l'on vient de générer à un endroit accessible par OpenLDAP , par exemple /usr/local/etc/openldap : 
$ su
Password: <pass root>
# cp ./demoCA/cacert.pem /usr/local/etc/openldap/
# cp ./newcert.pem /usr/local/etc/openldap/ldap_crt.pem
# cp ./newreq.pem /usr/local/etc/openldap/ldap_key.pem
Puis on modifie le fichier slapd.conf, en ajoutant à la fin les lignes suivantes : 
TLSCertificateFile     /usr/local/etc/openldap/ldap_crt.pem
TLSCertificateKeyFile  /usr/local/etc/openldap/ldap_key.pem
TLSCACertificateFile   /usr/local/etc/openldap/cacert.pem
Ca y est, le serveur OpenLDAP est correctement configuré pour gérer le SSL!

On configure aussi les clients afin de ne pas avoir à demander de certificat client (dans le cas contraire il faudrait créer des certificats pour les clients). Pour cela on rajoute dans ldap.conf la ligne : 
TLS_REQCERT never

5.1.3  Utilisation

Si un serveur OpenLDAP tournait déjà en tâche de fond, on l'arrête proprement avec la commande : 
kill -2 `cat /usr/local/var/run/slapd.pid`
(faire attention aux backquotes (`) (AltGr-7) qui ne sont pas des quotes (') ...)

Pour lancer le serveur OpenLDAP avec accès au port sécurisé uniquement, on tape la commande : 
/usr/local/libexec/slapd -h "ldaps:///"
Pour le lancer avec à la fois accès au port sécurisé et au port classique, on tape : 
/usr/local/libexec/slapd -h "ldap:/// ldaps:///"
On peut alors tester que tout fonctionne bien avec : 
ldapsearch -b dc=example,dc=com -H ldaps://localhost
Dorénavant, lorsqu'on s'authentifie auprès du serveur LDAP (si on utilise bien le port ldaps), le mot de passe ne circule plus en clair sur le réseau, et on ne peut plus l'intercepter à l'aide d'un sniffer...

5.2  SSL avec Active Directory

Pour utiliser le SSL avec Active Directory , il faut aussi créer un certificat.

On procède ainsi :
Remarque
Apparemment, dans Windows 2000 Server (pas vérifié dans le 2003), s'il y a plusieurs certificats valides dans le magasin de l'ordinateur local,ce sera toujours le 1er trouvé qui sera sélectionné, donc pas forcément le bon, alors qu'avec OpenLDAP on indique tout simplement quel certificat on veut utiliser...



On peut maintenant tester la connexion SSL : 
$ openssl s_client -connect 101.0.50.41:636 -showcerts -state -CAfile demoCA/cacert.pem
(on remplace bien sûr l'ip après "-connect" par l'adresse du serveur Active Directory ...)

Si tout se passe bien, on devrait avoir un certain nombre d'informations qui devraient s'afficher, comme sur l'exemple suivant : 
$ openssl s_client -connect 101.0.50.41:636 -showcerts -state -CAfile demoCA/cacert.pem
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=1 /C=FR/ST=77/L=Melun/O=CG77/CN=act2000.demo-cg77.org
verify return:1
depth=0 /C=FR/ST=77/L=Melun/O=CG77/CN=act2000.demo-cg77.org
verify return:1
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server certificate request A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client certificate A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read finished A
---
Certificate chain
 0 s:/C=FR/ST=77/L=Melun/O=CG77/CN=act2000.demo-cg77.org
   i:/C=FR/ST=77/L=Melun/O=CG77/CN=act2000.demo-cg77.org
-----BEGIN CERTIFICATE-----
MIIDCDCCAnGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBZMQswCQYDVQQGEwJGUjEL
MAkGA1UECBMCNzcxDjAMBgNVBAcTBU1lbHVuMQ0wCwYDVQQKEwRDRzc3MR4wHAYD
VQQDExVhY3QyMDAwLmRlbW8tY2c3Ny5vcmcwHhcNMDQwMjI2MTQxNzI0WhcNMDUw
MjI1MTQxNzI0WjBZMQswCQYDVQQGEwJGUjELMAkGA1UECBMCNzcxDjAMBgNVBAcT
BU1lbHVuMQ0wCwYDVQQKEwRDRzc3MR4wHAYDVQQDExVhY3QyMDAwLmRlbW8tY2c3
Ny5vcmcwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAK78N9OZ58meYVWABeKN
E4gNT8Nl7t1FftOpp4qWQm63XVoMhOvioPJfrXwpjIeVlHHluFX3bmd7+QcrgLhe
gxEuffBv+FTS1VSqWr3EZArpk5d70l5ueUjLJGihG9gAZw/e23QJQcyT5kDr8aaZ
ZzdzPUd+97URBKKIXBDuhcUtAgMBAAGjgd8wgdwwCQYDVR0TBAIwADAsBglghkgB
hvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYE
FLHG6t5N4zDcaUlo1fmUYOuHbEarMIGBBgNVHSMEejB4gBTAAn0nbntcY51kBaAg
oDpdptYzUqFdpFswWTELMAkGA1UEBhMCRlIxCzAJBgNVBAgTAjc3MQ4wDAYDVQQH
EwVNZWx1bjENMAsGA1UEChMEQ0c3NzEeMBwGA1UEAxMVYWN0MjAwMC5kZW1vLWNn
Nzcub3JnggEAMA0GCSqGSIb3DQEBBAUAA4GBAAOdM1OPLCEVpGLJjz8czhPVg42y
QNUiQYvTmSmG8868GjvKl2iPBmSp9ZEVNv2xVyUHb6E0VTwwWih1cujYLbWw9ixM
MhgENCSyrVHT59Y7m0P7vH1FRZMhfko04FiVHP7HWtDGL3B9wxK/M4SIPyRzE0Cr
i83N1Dd5i1Ecew9a
-----END CERTIFICATE-----
---
Server certificate
subject=/C=FR/ST=77/L=Melun/O=CG77/CN=act2000.demo-cg77.org
issuer=/C=FR/ST=77/L=Melun/O=CG77/CN=act2000.demo-cg77.org
---
Acceptable client certificate CA names
/C=US/O=VeriSign, Inc./OU=Class 1 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network
/C=US/O=VeriSign, Inc./OU=Class 4 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network
/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting/OU=Certification Services
Division/CN=Thawte Personal Freemail CA/emailAddress=personal-freemail@thawte.com
/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting/OU=Certification Services
Division/CN=Thawte Personal Premium CA/emailAddress=personal-premium@thawte.com
/C=US/O=First Data Digital Certificates Inc./CN=First Data Digital Certificates
Inc. Certification Authority
/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting/OU=Certification Services
Division/CN=Thawte Personal Basic CA/emailAddress=personal-basic@thawte.com
/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
/C=US/O=VeriSign, Inc./OU=Class 2 Public Primary Certification Authority
/C=US/O=VeriSign, Inc./OU=Class 1 Public Primary Certification Authority
/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network
/C=HU/L=Budapest/O=NetLock Halozatbiztonsagi Kft./OU=Tanusitvanykiadok/CN=NetLock Uzleti (Class B) Tanusitvanykiado
/C=US/O=GTE Corporation/CN=GTE CyberTrust Root
/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
/C=US/O=Entrust.net/OU=www.entrust.net/CPS incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Secure Server Certification Authority
/C=HU/ST=Hungary/L=Budapest/O=NetLock Halozatbiztonsagi Kft./OU=Tanusitvanykiadok/CN=NetLock Kozjegyzoi (Class A) Tanusitvanykiado
/C=US/O=VeriSign, Inc./OU=Class 2 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network
/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Root/C=HU/L=Budapest/O=NetLock Halozatbiztonsagi Kft./OU=Tanusitvanykiadok/CN=NetLock Expressz (Class C) Tanusitvanykiado
/OU=Copyright (c) 1997 Microsoft Corp./OU=Microsoft Corporation/CN=Microsoft Root Authority
/DC=com/DC=microsoft/CN=Microsoft Root Certificate Authority
/C=FR/ST=77/L=Melun/O=CG77/CN=act2000.demo-cg77.org
---
SSL handshake has read 4098 bytes and written 336 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 1024 bit
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-MD5
    Session-ID: DB17000043304AC576E0586E82B6139839D1D812DA0C3C707CD1CABF390A1965    Session-ID-ctx:
    Master-Key: 149A4A63893D34003E4D5AC2C9223040D68CAA2714AE7709193C64E7C2BE4B49AB7EA0B619DD8146F147FD0EE76DE1C3
    Key-Arg   : None
    Krb5 Principal: None
    Start Time: 1077894853
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
(le programme ne rend pas la main, il faut l'interrompre par Ctrl-c)

Si par contre il y a un problème, le programme rendra la main après avoir affiché la cause de l'erreur, et il faudra essayer de comprendre pourquoi ça ne marche pas...

Une fois que tout ceci fonctionne, on peut enfin accéder à Active Directory au moyen d'une connexion LDAP sécurisée par SSL/TLS, ce qui permet entre autres de changer le mot de passe d'un utilisateur (voir 4.4.1).

5.3  SSL avec Squid

Maintenant que les annuaires fonctionnent correctement avec SSL, on peut passer à la configuration de Squid .

A priori, la seule chose à faire pour que Squid utilise SSL pour communiquer avec les serveurs LDAP est de rajouter ldaps:// en tête de l'adresse du serveur dans les appels de squid_ldap_auth et squid_ldap_group .

Cependant, il y avait un bug dans le code source de ces 2 helpers (le bug #887 de Squid , cf http://www.squid-cache.org/bugs/show_bug.cgi?id=887 ), qui empêchait d'utiliser correctement SSL/TLS, mais ce bug a été corrigé le 05/01/2004.

Il faut donc patcher les sources de la version utilisée de Squid , ou récupérer la dernière version de Squid (la version 2.5STABLE5 est sortie le 01/03/2004), et la recompiler avec support SSL (paramètre --enable-ssl de configure).

Si on veut utiliser cette dernière version de Squid , il faut la compiler avec toutes les options adaptées, par exemple : 
$ ./configure --prefix=/usr/local/squid 
            --enable-default-err-language=French
            --enable-err-languages="English French"
            --enable-basic-auth-helpers="LDAP NCSA"
            --enable-external-acl-helpers="ldap_group"
            --enable-ssl
$ make
$ su -c "make install"
Par contre, on peut ne récupérer que les dernières versions de squid_ldap_auth et squid_ldap_group , dans ce cas on ne fait pas de make install, mais après le make on récupère les fichiers helpers/basic_auth/LDAP/squid_ldap_auth et helpers/external_acl/ldap_group/squid_ldap_group, et on les place par exemple à l'endroit où se trouvaient les vieilles versions de ces fichiers (qu'on aura sauvegardés avant au cas où).

Remarque

Lors de la compilation de Squid , en fait lors de la compilation de squid_ldap_auth et squid_ldap_group , j'ai été confronté à une erreur, et il a fallu que je rajoute -L/usr/local/lib à la ligne LDADD=... des Makefile correspondants.



Ensuite, il suffit effectivement de modifier les 2 lignes de squid.conf qui appellent squid_ldap_auth et squid_ldap_group , afin d'indiquer le nouveau chemin de ces 2 programmes si celui-ci a changé, et de rajouter ldaps:// en tête de l'adresse du serveur LDAP.

Il ne reste plus qu'à relancer le serveur Squid , et maintenant l'authentification par groupes s'effectue de manière cryptée par SSL/TLS. (On peut le vérifier avec Ethereal : aucun mot de passe ne circule plus en clair)

Précédent Remonter