Mise en place d’un cluster OpenLDAP avec Corosync / Pacemaker [2/3]

cluster_openldap

Comme je vous l’expliquais il y a quelques jours, j’ai récemment travaillé sur un cluster OpenLDAP à deux nœuds utilisant la réplication OpenLDAP ainsi que Corosync et Pacemaker.

Voici mes notes de travail. Elles me resserviront sans doute ou vous seront peut-être utiles.

Le « tutoriel » est découpé en trois parties :

Introduction

Rendu où nous en sommes, OpenLDAP diffuse l’intégralité des données (mots de passe compris) en clair sur le réseau… Pour remédier à cela, je vous propose d’encapsuler ce trafic dans une couche SSL afin de chiffrer nos données et de sécuriser nos échanges.

De quoi avons-nous besoin pour chiffrer nos échanges ?

  • Les outils du paquet openssl, que vous pouvez installer si ce n’est pas déjà fait,
  • un couple de clés : une clé publique envoyée aux clients désirant se connecter au serveur LDAP et une clé privée permettant au serveur de déchiffrer les données chiffrées par les clients avec la clé publique.
    Les données chiffrées grâce à la clé publique ne sont déchiffrables uniquement qu’avec la clé privée, c’est pourquoi il faut la garder en sécurité…
  • La clé publique envoyée sera accompagnée d’un certificat, lié à cette clé, permettant d’en assurer l’authenticité.
  • Enfin le certificat sera lui-même signé par une autorité de certification faisant office de « tiers de confiance ». Ici le tiers de confiance sera nous-même. C’est-à-dire que notre certificat sera auto-signé.

Au boulot…

Configuration d’OpenSSL

Sous Red Hat / CentOS, OpenSSL est fourni avec un script tout prêt pour générer votre autorité de certification, vos clés et signer leur certificat mais avant de commencer, nous allons lui configurer deux ou trois paramètres.

Éditez le fichier /etc/pki/tls/openssl.cnf. J’ai simplement modifié les valeurs suivantes mais après vous personnalisez comme vous voulez :

# Les clés seront signées pour environ 10 ans
default_days = 3650
 
# On génère une clé 2048 bits. Les 1024 par défaut ne sont plus suffisants aujourd'hui...
default_bits = 2048
 
# Personnalisation de la section [ req_distinguished_name ]
countryName_default            = FR
stateOrProvince_default        = Bretagne
localityName_default           = Rennes
0.organizationName_default     = Guillaume
organizationalUnitName_default = Networks

Soyez conscient que c’est à titre d’exemple hein…

Création de l’autorité de certification et des clés

Une fois le fichier enregistré, placez-vous dans le dossier /etc/pki/tls/misc et exécutez le script intitulé CA. :

cd /etc/pki/tls/misc
./CA -newca
CA certificate filename (or enter to create)
 
Making CA certificate ...
Generating a 2048 bit RSA private key
.........................................................................................+++
...............+++
writing new private key to 'newkey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [FR]:
State or Province Name (full name) [Bretagne]:
Locality Name (eg, city) [Rennes]:
Organization Name (eg, company) [Guillaume]:
Organizational Unit Name (eg, section) [Networks]:
Common Name (eg, your name or your server s hostname) []:ldap.guillaume-leduc.fr
Email Address []:contact@guillaume-leduc.fr
 
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Request is in newreq.pem, private key is in newkey.pem

L’option -newca permet, comme son nom l’indique, de créer une nouvelle autorité de certification. Si une autorité existé déjà sur votre machine, vous pouvez utiliser l’option -newreq. Deux fichiers sont alors générés :

  • newreq.pem contient la clé publique, à partir de laquelle nous allons générer un certificat.
  • newkey.pem contient la clé privée.

Création du certificat

Passons maintenant à la création du certificat. Celui-ci sera signé par l’autorité de certification. Notez l’utilisation de l’option -nodes afin d’éviter que le passphrase de la clé soit demandé au démarrage du daemon slapd. La clé publique signée est intégrée dans la demande de signature (slapd-req.pem) et la clé privée qui correspond placée dans slapd-key.pem.

openssl req -new -nodes -subj '/CN=ldap.guillaume-leduc.fr/O=Guillaume/C=FR/ST=Bretagne/L=Rennes' -keyout slapd-key.pem -out slapd-req.pem -days 3650
Generating a 2048 bit RSA private key
......................................................+++
....................+++
writing new private key to 'slapd-key.pem'
-----

Signature du certificat par l’autorité de certification

On signe donc le certificat et la clé avec l’autorité de certification (CA) préalablement créée :

openssl ca -out slapd-cert.pem -infiles slapd-req.pem
Using configuration from /etc/pki/tls/openssl.cnf
Enter pass phrase for /etc/pki/CA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number:
            a4:f9:a7:80:fa:d2:a7:75
        Validity
            Not Before: Aug 22 12:15:12 2013 GMT
            Not After : Aug 22 12:15:12 2023 GMT
        Subject:
            countryName               = FR
            stateOrProvinceName       = Bretagne
            organizationName          = ETIAM
            commonName                = ldap.guillaume-leduc.fr
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Comment:
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier:
                DC:EB:0B:D6:BF:72:D2:09:10:F0:C7:42:FF:16:3C:E5:6B:19:01:1E
            X509v3 Authority Key Identifier:
                keyid:85:0B:2C:9D:93:E1:5A:C9:83:0A:45:EB:7D:C1:36:07:D5:ED:BA:8
 
Certificate is to be certified until Aug 20 12:15:12 2023 GMT (3650 days)
Sign the certificate? [y/n]:y
 
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

Copie des clés vers OpenLDAP

On peut maintenant copier les clés, le certificat et la signature de l’autorité de certification vers le dossier /etc/openldap. Je vous conseille de conserver les droits d’accès proposés ici.

cp -p slapd-key.pem /etc/openldap/slapdkey.pem
cp -p slapd-cert.pem /etc/openldap/slapdcert.pem
chown ldap:ldap /etc/openldap/slapdcert.pem
chmod 644 /etc/openldap/slapdcert.pem
chown ldap:ldap /etc/openldap/slapdkey.pem
chmod 400 /etc/openldap/slapdkey.pem
 
mkdir /etc/openldap/cacerts/
cp /etc/pki/CA/cacert.pem /etc/openldap/cacerts/cacert.pem
chown ldap:ldap /etc/openldap/cacerts/cacert.pem
chmod 644 /etc/openldap/cacerts/cacert.pem

Envoyez-les aussi vers le deuxième nœud. Et oui en cas de bascule du cluster, il faut qu’il présente la même clé et le même certificat sinon on risque d’avoir des soucis…

scp cacerts/cacert.pem ldap2:/etc/openldap/cacerts/
scp slapdcert.pem ldap2:/etc/openldap/
scp slapdkey.pem ldap2:/etc/openldap/

Pensez à réappliquer les bons droits d’accès.

Modification de la configuration OpenLDAP

La suite se passe dans le fichier /etc/openldap/slapd.conf où vous ajoutez les paramètres suivants :

TLSCipherSuite        HIGH:MEDIUM:+SSLv2
TLSCACertificateFile  /etc/openldap/cacerts/cacert.pem
TLSCertificateFile    /etc/openldap/slapdcert.pem
TLSCertificateKeyFile /etc/openldap/slapdkey.pem

Je pense que les directives sont assez explicites, si vous avez besoin de détails demandez-moi via les commentaires.

Pour la partie client, ajoutez les lignes suivantes au fichier /etc/openldap/ldap.conf :

TLS_CACERTDIR   /etc/openldap/cacerts
TLS_REQCERT     allow
 
ssl             start_tls
tls_checkpeer   yes
tls_cacertfile  /etc/openldap/cacerts/cacert.pem

Enfin, il faut indiquer à OpenLDAP d’accepter les connexions chiffrées (LDAPS), dans le fichier /etc/sysconfig/ldap :

SLAPD_LDAPS=yes

Vous pouvez même mettre la directive SLAPD_LDAP à « no » si vous souhaitez forcer l’utilisation de LDAPS.

Voilà j’espère que je n’ai perdu personne pour le moment. J’écris cette série d’article car j’ai mis quelques temps avant de bien comprendre l’architecture que je devais mettre en place et j’ai trouvé peu de documentation claire et en français.

Si l’on reprend le schéma du début, nous sommes rendu ici :

Cluster OpenLDAP - Couche SSL

Et vous devez pouvoir être en mesure de vous connecter à vos deux nœuds via JXplorer sur le port 636 (LDAPS).

Dans le prochain article, nous mettrons en place le cluster à proprement parler : une adresse IP flottante qui pointera vers un nœud ou l’autre en fonction de leur état. Ce cluster reposera sur Corosync et le service OpenLDAP ainsi que l’IP flottante (VIP) seront pris en charge par Pacemaker !

Cet article vous a plu ? Partagez-le sur les réseaux sociaux !

Twitter Facebook Google Plus email