Gnuragist.es

Support Gnu/Linux

Outils pour utilisateurs

Outils du site


documentation:gitea:ldap-ssl

**Ceci est une ancienne révision du document !**

Table des matières

* Utilisation de Setup OpenLDAP Server with SSL/TLS on Debian 10 * Utilisation de Setting up an OpenLDAP Server with SSL + NFS for User Home Directories on CentOS 7

Ce guide vous expliquera comment configurer le serveur OpenLDAP avec SSL/TLS sur Debian 10 Buster. Les clients et serveurs OpenLDAP sont capables d'utiliser le cadre de sécurité de la couche transport (TLS) pour fournir des protections d'intégrité et de confidentialité et pour prendre en charge l'authentification LDAP en utilisant le mécanisme SASL EXTERNAL.

Installer OpenLDAP Server avec SSL/TLS sur Debian 10

Mettre à jours le système à jour.

# apt update && apt -y upgrade

Installer les paquets LDAP

# apt -y install slapd ldap-utils ldapscripts

Durant l'installation, vous serez invitez à définir le mot de passe administrateur·ice de LDAP.

Afficher les paramètre de la base de données LDAP

Lors de l'installation, la base de données LDAP est automatiquement configurée sur base du nom de domaine distinctif (DN), le nom de l'organisation étant défini sur la base du nom d'hôte du système par défaut. Pour afficher les paramètres de la base de données SLAPD, vous pouvez utiliser la commande slapcat.

# slapcat
dn: dc=nodomain
objectClass: top
objectClass: dcObject
objectClass: organization
o: nodomain
dc: nodomain
structuralObjectClass: organization
entryUUID: ff8c93b2-8f04-103a-8b71-4d0da1e98502
creatorsName: cn=admin,dc=nodomain
createTimestamp: 20200919204655Z
entryCSN: 20200919204655.426161Z#000000#000#000000
modifiersName: cn=admin,dc=nodomain
modifyTimestamp: 20200919204655Z

dn: cn=admin,dc=nodomain
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: e1NTSEF9TXdINjVrRkFwcEs4NjhQY3NaK0dnQmVFZm16UUdoK3c=
structuralObjectClass: organizationalRole
entryUUID: ff8d539c-8f04-103a-8b72-4d0da1e98502
creatorsName: cn=admin,dc=nodomain
createTimestamp: 20200919204655Z
entryCSN: 20200919204655.431118Z#000000#000#000000
modifiersName: cn=admin,dc=nodomain
modifyTimestamp: 20200919204655Z

Sur base de la configuration SLADP affichée ci-dessus,

  • Le DN de base est définis à dn: dc=nodomain
  • L'organigation est définis à o: nodomain
  • L'administrateur·ice est définis à dn: cn=admin,dc=nodomain

Modifier le BaseDN par défaut de OpenLDAP

Si vous avez toutefois besoin du DN de base OpenLDAP par défaut, vous devez reconfigurer le paquet slapd comme indiqué ci-dessous et suivre les instructions.

# dpkg-reconfigure slapd

Lorsque la commande s'exécute, vous êtes invité à indiquer si vous souhaitez omettre la configuration du serveur OpenLDAP. Sélectionnez Non pour que la configuration soit créée pour vous.

Ensuite, configurez le nom de domaine pleinement qualifié (FQDN) de votre serveur OpenLDAP qui sera utilisé pour créer votre DN de base.

Par exemple ldap.domaine.xyz

Définissez ensuite le nom de votre organisation, le nom de domaine faisant l'affaire.

Par exemple domaine.xyz

Et choisissez un nouveau mot de passe pour l'administrateur·ice (cela peut-être le même que choisi précédemment)

Selectionnnez ensuite le backend de la base de données OpenLDAP. MDB étant recommandé, selectionnez le est continuez.

Il vous sera demandé si vous souhaitez supprimer la base de données lors de la « purge » du pacquet, rpondez oui.

Et ensuite il vous sera demandé si vous souhaitez déplacer « l'ancienne » base de données, répondez également oui. L'ancienne base de données sera déplacée dans /var/backups.

Pour vérifer la nouvelle configuration, exécutez simplement slapcat.

# slapcat
dn: dc=buster,dc=caldarium,dc=be
objectClass: top
objectClass: dcObject
objectClass: organization
o: caldarium.be
dc: buster
structuralObjectClass: organization
entryUUID: 31a906a8-8f07-103a-9631-e7451d28f069
creatorsName: cn=admin,dc=buster,dc=caldarium,dc=be
createTimestamp: 20200919210238Z
entryCSN: 20200919210238.492144Z#000000#000#000000
modifiersName: cn=admin,dc=buster,dc=caldarium,dc=be
modifyTimestamp: 20200919210238Z

dn: cn=admin,dc=buster,dc=caldarium,dc=be
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: e1NTSEF9c0tQM3RQQTBCZWlKWmMyZGZDZGFXNTdwVG1ZdFVnRUE=
structuralObjectClass: organizationalRole
entryUUID: 31aa2e52-8f07-103a-9632-e7451d28f069
creatorsName: cn=admin,dc=buster,dc=caldarium,dc=be
createTimestamp: 20200919210238Z
entryCSN: 20200919210238.499757Z#000000#000#000000
modifiersName: cn=admin,dc=buster,dc=caldarium,dc=be
modifyTimestamp: 20200919210238Z

Vous pouvez également vérifier le DN de base en utilisant ldapsearch comme ci-dessous;

# ldapsearch -H ldapi:/// -x -LLL -s base -b "" namingContexts

Qui devrait vous sortir quelque chose comme ceci;

dn:
namingContexts: dc=buster,dc=caldarium,dc=be

Et pour afficher le DN racine (Root DN), exécutez la commande suivante;

# ldapsearch -H ldapi:/// -Y EXTERNAL -b "cn=config" "(olcRootDN=*)"

Ce qui devrait afficher quelque chose comme ceci;

dn: dc=buster,dc=caldarium,dc=be
objectClass: top
objectClass: dcObject
objectClass: organization
o: caldarium.be
dc: buster
structuralObjectClass: organization
entryUUID: 31a906a8-8f07-103a-9631-e7451d28f069
creatorsName: cn=admin,dc=buster,dc=caldarium,dc=be
createTimestamp: 20200919210238Z
entryCSN: 20200919210238.492144Z#000000#000#000000
modifiersName: cn=admin,dc=buster,dc=caldarium,dc=be
modifyTimestamp: 20200919210238Z

dn: cn=admin,dc=buster,dc=caldarium,dc=be
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: e1NTSEF9c0tQM3RQQTBCZWlKWmMyZGZDZGFXNTdwVG1ZdFVnRUE=
structuralObjectClass: organizationalRole
entryUUID: 31aa2e52-8f07-103a-9632-e7451d28f069
creatorsName: cn=admin,dc=buster,dc=caldarium,dc=be
createTimestamp: 20200919210238Z
entryCSN: 20200919210238.499757Z#000000#000#000000
modifiersName: cn=admin,dc=buster,dc=caldarium,dc=be
modifyTimestamp: 20200919210238Z

Et pour tester si la connection au serveur LDAP fonctionne, utilisez ldapwhoami comme ci-dessous;

# ldapwhoami -H ldapi:/// -x

Ce qui devrait afficher anonymous si le serveur LDAP fonctionne bien sans authentification.

anonymous

Pour rechercher tout les DNs (le DN (Distinguished Name) de l'entrée à partir de laquelle effectuer une recherche) qui descendend du DN de base;

# ldapsearch -H ldapi:/// -x -LLL -b dc=buster,dc=caldarium,dc=be dn

Devrait afficher ceci;

dn: dc=buster,dc=caldarium,dc=be

dn: cn=admin,dc=buster,dc=caldarium,dc=be

Créer un DN de base pour les Utilisateur·ice·s et les Groupes

À partir de la configuration de la base de données SLAPD ci-dessus, le DN de base pour l'administrateur·ice OpenLDAP a été créé. Cependant, comme nous allons gérer d'autres utilisateur·ice·s en dehors de l'administrateur·ice LDAP, il nous faut créer un DN de base pour les utilisateur·ice·s et les groupes.

Créez donc un fichier de format d'échange LDAP (ldif) avec le contenu suivant et utilisez-le pour créer le DN de base des utilisateur·ice·s/groupes. Veillez à remplacer le nom de domaine pour correspondre à vos besoins.

# cd /root
# mkdir ldap # pour se créer un dossier de travail
# cd ldap
# vi user_group_base.ldif

Pour y écrire les informations suivantes, en remplaçant en fonction de vos besoins;

dn: ou=people,dc=buster,dc=caldarium,dc=be
objectClass: organizationalUnit
ou: people

dn: ou=group,dc=buster,dc=caldarium,dc=be
objectClass: organizationalUnit
ou: group

Ajouter les DN de base user et group dans la base de données SLAPD

Avec le fichier user_group_base.ldif vous allez pouvoir remplir la base de données SLADP en utilisant la commande ldapadd en remplaçant les cn et dc en fonction de votre configuration;

# ldapadd -x -D cn=admin,dc=buster,dc=caldarium,dc=be -W -f user_group_base.ldif

Vous serrez inviter à taper le mot de passe de l'administrateur·ice (admin) que vous avez défini lors de la reconfiguration de votre serveur ldap.

Vous derviez avoir ce genre de sortie à l'écran;

Enter LDAP Password: 
adding new entry "ou=people,dc=buster,dc=caldarium,dc=be"

adding new entry "ou=group,dc=buster,dc=caldarium,dc=be"

Créer des comptes utilisateur·ice·s LDAP

Pour ajouter des comptes utilisateur·ice·s au server LDAP, il faut créer un fichier ldif qui contient la définition des attributs des utilisateur·ice·s.

Pour ajouter un·e utilisateur·ice avec un mote de passe, il faut générer le hachage de ce mot de passe à l'aide de la commande slappasswd.

# slappasswd 
New password: TAPER_UN_MOT_DE_PASSE
Re-enter new password: RETAPER_LE_MÊME_MOT_DE_PASSE
{SSHA}9H/LYt91G2lRZuS6Hsml6ZYt5NFcNW6O

Il est possible de créer le mot de passe d'un·e utilisateur·ice à l'aide de la même commande ldappasswd après avoir créer le compte. Voir la section ci-dessous à propose de Réinitialiser un mot de passe utilisateur·ice.

Revenons en à créer un fichier ldif pour définir le compte d'un·e utilisateur·ice.

# vi nouveau_compte.ldif

Et ajouter au fichier des informations comme ci-dessous en tenant compte de vos besoins. Vous pourrez utiliser le hachage du mot de passe généré ci-dessus pour le coller dans le fichier.

dn: uid=bernadette,ou=people,dc=buster,dc=caldarium,dc=be
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: bernadette
cn: bernadette
givenName: Bernadette
sn: Lasouris
userPassword: {SSHA}9H/LYt91G2lRZuS6Hsml6ZYt5NFcNW6O
loginShell: /bin/bash
uidNumber: 10000
gidNumber: 10000
homeDirectory: /home/bernadette
shadowMax: 60
shadowMin: 1
shadowWarning: 7
shadowInactive: 7
shadowLastChange: 0

dn: cn=bernadette,ou=group,dc=buster,dc=caldarium,dc=be
objectClass: posixGroup
cn: bernadette
gidNumber: 10000
memberUid: bernadette

Vous noterez qu'il y a la définition de l'utilisateur·ice et celle de son groupe.

Ajouter des utilisateur·ice·s à la base de données SLAPD

Une fois que vous avez complété le fichier ldif qui définit un·e utilisateur·ice, vous serrez en mesure de l'ajouter avec la commande ldapadd et votre compte administrateur·ice.

# ldapadd -x -D cn=admin,dc=buster,dc=caldarium,dc=be -W -f nouveau_compte.ldif

Il vous sera demandé de taper le mot de passe de l'administrateur·ice. Et si votre fichier ldif ne contient pas d'erreur, les messages suivants devraient s'afficher.

Enter LDAP Password: 
adding new entry "uid=bernadette,ou=people,dc=buster,dc=caldarium,dc=be"

adding new entry "cn=bernadette,ou=group,dc=buster,dc=caldarium,dc=be"

En cas d'erreur, vérifiez le contenu de votre fichier ldif.

Lister des utilisateur·ice·s

Vous pourrez utiliser la commande ldapsearch pour voir défiler la liste des comptes utilisateur·ice·s sous un DN de base.

# ldapsearch -x -LLL -b "dc=buster,dc=caldarium,dc=be"

Lister des groupes

La même commande avec un autre DN de base vous listera les groupes.

# ldapsearch -x -LLL -b "ou=group,dc=buster,dc=caldarium,dc=be"

Lister des attributs particuliers depuis les ```objectClass```

Pour obtenir une partie des informations relative à un·e utilisateur·ice, par exemple son prénom (givenName), son nom de famille (sn), son identifiant (uid) et son répertoire personnel (homeDirectory), vous pourrez construire une requête comme celle ci-dessous.

# ldapsearch -x -LLL -b "ou=people,dc=buster,dc=caldarium,dc=be" '(objectclass=*)' uid givenName sn homeDirectory

Et elle devrait vous afficher quelque chose comme ceci;

dn: ou=people,dc=buster,dc=caldarium,dc=be

dn: uid=bernadette,ou=people,dc=buster,dc=caldarium,dc=be
uid: bernadette
givenName: Bernadette
sn: Lasouris
homeDirectory: /home/bernadette

Que vous pouvez évidemment filtrer avec la commande grep comme ceci par exemple.

# ldapsearch -x -LLL -b "ou=people,dc=buster,dc=caldarium,dc=be" '(objectclass=*)' uid givenName sn homeDirectory | grep uid:

Ce qui devrait vous afficher uniquement la ligne suivante;

uid: bernadette

Supprimer des utilisateur·ice·s et des groupes

C'est la commande ldapdelete qu'il vous faudra utiliser. Par exemple pour supprimer l'utilisatrice bernadette créée ci-dessus. Il vous faudra, bien évidemment, adapter la commande en fonction de la configuration de votre instance LDAP.

# ldapdelete -x -W -D "cn=admin,dc=buster,dc=caldarium,dc=be" "uid=bernadette,ou=people,dc=buster,dc=caldarium,dc=be"

Et il en va de même pour le groupe qui lui était associé.

# ldapdelete -x -W -D "cn=admin,dc=buster,dc=caldarium,dc=be" "cn=bernadette,ou=group,dc=buster,dc=caldarium,dc=be"

Dans les deux cas, vous devrez taper le mot de passe administrateur·ice de votre serveur LDAP.

Ajouter à nouveau l'utilisateur·ice

Parce qu'on vient de supprimer son compte, il faut le recréer si on veut changer son mot de passe.

Pour se faire, il suffit de relancer la commande utilisée plus haut dans le tutoriel.

# ldapadd -x -D cn=admin,dc=buster,dc=caldarium,dc=be -W -f nouveau_compte.ldif

Réinitialiser le mot de passe d'un·e utilisateur·ice

En fonction que vous soyez un·e administarteur·ice ou un·e utilisateur·ice, les commandes et les ordinateurs desquels vous les exécuterez, seront différentes.

Depuis le serveur, en tant qu'administrateur·ice

Si vous avez besoin de réinitialiser le mot de passe d'un·e utilisateur·ice, vous pouvez utiliser la commande ldappasswd. Par exemple, pour le mot de passe de bernadette que nous venons de recréer dans le serveur LDAP et il vous faudra, comme pour les commandes utilisées avant, les adapter selon votre configuration;

ldappasswd -H ldapi:/// -x -D "cn=admin,dc=buster,dc=caldarium,dc=be" -W -S "uid=bernadette,ou=people,dc=buster,dc=caldarium,dc=be"

Attention qu'il vous sera demandé d'abord le nouveau mot de passe et sa confirmation, avant celui de votre compte administarteur·ice.

New password: 
Re-enter new password: 
Enter LDAP Password: 

Depuis un ordinateur, également en tant qu'administrateur·ice

Pour ce faire, c'est la même commande ldappasswd qui pourra être utilisée sur un ordinateur client, à condition que le packet ldap-utils soit installé.

Il faudra simplement définir l'adresse du serveur LDAP avec le paramètre suivant -H ldap://<ldap-server-IP> et son nom (si une résolution de nom à été mise en place sur votre réseau) ou son adresse IP.

ldappasswd -H ldap://buster -x -D "cn=admin,dc=buster,dc=caldarium,dc=be" -W -S "uid=bernadette,ou=people,dc=buster,dc=caldarium,dc=be"

Il vous sera également demandé d'abord le nouveau mot de passe et sa confirmation, avant celui du compte administarteur·ice.

New password: 
Re-enter new password: 
Enter LDAP Password: 

Vérifier si le mot de passe d'un·e utilisateur·ice fonctionne

Comme pour modifier un mot de passe, il est possible de le faire depuis le serveur ou depuis un ordinateur client.

Depuis le serveur

Et pour tester si le nouveau mot de passe fonctionne, vous pourrez utiliser la commande suivante;

# ldapwhoami -vvv -h localhost -D "uid=bernadette,ou=people,dc=buster,dc=caldarium,dc=be" -x -W

Qui vous demandera de taper le mot de pass que vous venez de changer avant de vous afficher le résultat;

ldap_initialize( ldap://localhost )
Enter LDAP Password: 
dn:uid=bernadette,ou=people,dc=buster,dc=caldarium,dc=be
Result: Success (0)

Si le mot de passe n'est pas le bon, le résultat sera de ce genre;

ldap_bind: Invalid credentials (49)

Depuis un ordinateur client

Même principe que pour le changement de mot de passe, si ce n'est qu'il n'est pas nécessaire de connaître le mot de passe de l'administarteur·ice pour tester la connexion. Pas besoin non plus de le faire depuis une session root, puisqu'un·e utilisateur·ice peut tester la connexion à un serveur LDAP sans avoir besoin de droits « élevés ».

Il faudra également définir l'adresse du serveur LDAP avec le paramètre suivant -h ldap://<ldap-server-IP> et son nom (si une résolution de nom à été mise en place sur votre réseau) ou son adresse IP.

$ ldapwhoami -vvv -h buster -D "uid=bernadette,ou=people,dc=buster,dc=caldarium,dc=be" -x -W

Il vous sera également demandé de taper le mot de pass que vous venez de changer avant de vous afficher le résultat;

ldap_initialize( ldap://localhost )
Enter LDAP Password: 
dn:uid=bernadette,ou=people,dc=buster,dc=caldarium,dc=be
Result: Success (0)

Si le mot de passe n'est pas le bon, le résultat sera de ce genre;

ldap_bind: Invalid credentials (49)

Configurer OpenLDAP avec SSL/TLS

Générer des certificats SSL/TLS

Dans ce guide nous allons utiliser des certificats auto-signés. Il est possible d'utiliser des certificats commerciaux issus d'Aucorités Certificatives ou des certificats issus de Let's Encrypt.

Pour configurer un serveur OpenLDAP avec des certificats SSL/TLS, il faut trois fichiers; un certificat CA (CA certificate), un certificat pour le serveur (server certificate), et une clé de certificat serveur (server certificate key).

Créer un ensemble de dossiers pour stocker les certificats.

# mkdir -p /etc/ssl/openldap/{private,certs,newcerts}

Lorsque ces dossiers sont créés, il faut renseigner le dossier principal pour stocker les certificats SSL/TLS et les clés dans la section [ CA_default ] du fichier /usr/lib/ssl/openssl.cnf.

vi /usr/lib/ssl/openssl.cnf

La partie concernée de ce fichier devrait ressembler à ça;

...
[ CA_default ]

#dir            = ./demoCA              # Where everything is kept
dir             = /etc/ssl/openldap
certs           = $dir/certs            # Where the issued certs are kept
crl_dir         = $dir/crl              # Where the issued crl are kept
database        = $dir/index.txt        # database index file.
...

Il faudra également quelques autres fichiers pour assurer le suivi des certificats signés.

# echo "1001" > /etc/ssl/openldap/serial
# touch /etc/ssl/openldap/index.txt

CA Key (clé de l'autorité certificative)

Créer le fichier de la clé de l'autorité certificative (CA Key) à l'aide de la commande ci-dessous et lui renseigner une phrase de passe (passphrase).

# openssl genrsa -aes256 -out /etc/ssl/openldap/private/cakey.pem 2048

Pour enlever la phrase de passe, notamment pour éviter de devoir la déverrouiller à chaque fois qu'on en a besoin, voici comment faire;

# openssl rsa -in /etc/ssl/openldap/private/cakey.pem -out /etc/ssl/openldap/private/cakey.pem

CA Certificate (certificat de l'autorité certificative)

openssl req -new -x509 -days 3650 -key /etc/ssl/openldap/private/cakey.pem -out /etc/ssl/openldap/certs/cacert.pem

Lors de la création de ce certificat, vous avez la possibilité de remplir « une sorte de fiche d'identité » pour votre serveur.

Seul le FQDN (Fully Qualified Domain Name) est important si votre serveur est joignable depuis Internet. Si c'est un serveur qui sera utilisé uniquement sur un réseau local (LAN), il est tout de même recommandé de mettre son nom pour le FQDN.

Vous pouvez définir le FQDN de votre serveur en modifiant le fichier ```/etc/hosts``` pour y modifier la ligne qui commence par ```127.0.1.1 nom_du_serveur``` pour le faire correspondre à vos besoins. Selon les exemples utilisés dans ce totoriel, la ligne ressemblerait à ceci : ```127.0.1.1 buster.caldarium.be buster```. Cf la [page (en anglais) à propos du hostname](https://manpages.debian.org/buster/hostname/hostname.1.en.html) sur le site de Debian.

Voici par exemple les coordonnées renseignée pour le serveur de ce tutoriel.

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) [AU]:BE
State or Province Name (full name) [Some-State]:Bruxelles
Locality Name (eg, city) []:Laeken  
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Caldarium Corp
Organizational Unit Name (eg, section) []:Maison Mère
Common Name (e.g. server FQDN or YOUR name) []:buster.caldarium.be
Email Address []:root@caldarium.be

Server Key (clé privée du serveur)

C'est également un fichier qui nécessitera de définir une phrase de passe (passphrase), que nous enlèveront ensuite pour ne pas avoir à la taper chaque fois que nous devrons acéder à cette clé privée.

Générer la clé privée;

# openssl genrsa -aes256 -out /etc/ssl/openldap/private/ldapserver-key.key 2048

Lui renseigner une phrase de passe;

Generating RSA private key, 2048 bit long modulus (2 primes)
..................................................................+++++
................................................+++++
e is 65537 (0x010001)
Enter pass phrase for /etc/ssl/openldap/private/ldapserver-key.key:
Verifying - Enter pass phrase for /etc/ssl/openldap/private/ldapserver-key.key:

Et supprimer la phrase de passe;

# openssl rsa -in /etc/ssl/openldap/private/ldapserver-key.key -out /etc/ssl/openldap/private/ldapserver-key.key

Générer un fichier de demande de certification (Certificate Sining Request)

Générer la demande de signature de certificat (CSR). Veillez à configurer les mêmes coordonnées que celles que vous avez utilisés pour générer le fichier de certificat CA ci-dessus.

# openssl req -new -key /etc/ssl/openldap/private/ldapserver-key.key -out /etc/ssl/openldap/certs/ldapserver-cert.csr

Lors de la génération de ce fichier CSR, il vous sera également demandé de définir une phrase de passe, mais contrairement au CA Certificate et à la Server Key, il est possible de laisser ce champ vide et de ne rien y écrire.

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) [AU]:BE
State or Province Name (full name) [Some-State]:Bruxelles
Locality Name (eg, city) []:Laeken
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Caldarium Corp
Organizational Unit Name (eg, section) []:Maison Mère
Common Name (e.g. server FQDN or YOUR name) []:buster.caldarium.be
Email Address []:root@caldarium.be

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Sever Certificate (Certificat du serveur)

Nous allons maintenant pouvoir générer un certificat pour le serveur LDAP et le signer avec la clé privée faite ci-dessus.

# openssl ca -keyfile /etc/ssl/openldap/private/cakey.pem -cert /etc/ssl/openldap/certs/cacert.pem -in /etc/ssl/openldap/certs/ldapserver-cert.csr -out /etc/ssl/openldap/certs/ldapserver-cert.crt

Vérifiez une seconde fois la correspondance des coordonées;

Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 4097 (0x1001)
        Validity
            Not Before: Sep 26 18:06:16 2020 GMT
            Not After : Sep 26 18:06:16 2021 GMT
        Subject:
            countryName               = BE
            stateOrProvinceName       = Bruxelles
            organizationName          = Caldarium Corp
            organizationalUnitName    = Maison M\C3\A8re
            commonName                = buster.caldarium.be
            emailAddress              = root@caldarium.be
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Comment: 
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier: 
                A2:B2:57:9B:D6:DD:36:8F:B4:64:B5:EA:F2:B9:F7:A8:C5:9E:21:92
            X509v3 Authority Key Identifier: 
                keyid:86:10:11:56:B5:E6:CD:D4:50:74:46:CD:EC:C3:E9:6B:00:E9:86:AC

Certificate is to be certified until Sep 26 18:06:16 2021 GMT (365 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

Vérifier l'authenticité du serveur LDAP auprès du CA

La commande suivante nous permettra de vérifier que la chaine de certification est valable entre l'autorité de certification que nous avons créé au début et le certificat du serveur LDAP.

# openssl verify -CAfile /etc/ssl/openldap/certs/cacert.pem /etc/ssl/openldap/certs/ldapserver-cert.crt

Le résultat devrait être le suivant;

/etc/ssl/openldap/certs/ldapserver-cert.crt: OK

Maintenant nous disposons, enfin, des trois fichiers indispensable pour garantir l'identité de notre serveur; le certificat de l'autorité (CA Certificate), le certificat du serveur (Server Certificate) et la clé du serveur (Server Key).

/etc/ssl/openldap/certs/cacert.pem
/etc/ssl/openldap/certs/ldapserver-cert.crt
/etc/ssl/openldap/private/ldapserver-key.key

Changer le propriétaire de ces fichiers

Ensuite, il est nécessaire de définir que l'utilisateur système openldap soit le propriétaire du dossier et des fichiers que nous avons créé.

# chown -R openldap: /etc/ssl/openldap/

Mettre à jour le serveur OpenLDAP avec les nouveaux certificats TLS

Ensuite, vous devez mettre à jour les certificats TLS du serveur OpenLDAP. Créez donc un fichier LDIF pour définir les attributs TLS comme indiqué ci-dessous;

# cd /root/ldap
# vim ldap-tls.ldif

Et y renseigner les informations relatives aux fichiers que nous avons créés et n'hésitez pas a adapter les chemins et noms de fichiers en fonction de vos besoins.

dn: cn=config
changetype: modify
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/openldap/certs/cacert.pem
-
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/openldap/certs/ldapserver-cert.crt
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/openldap/private/ldapserver-key.key

Pour appliquer ces modifications dans la base de données LDAP, c'est la commande ldapmodify qui sera utilisée.

# ldapmodify -Y EXTERNAL -H ldapi:/// -f ldap-tls.ldif

Et le réssultat devrait correspondre à ceci.

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"

Pour vérifier que les fichiers sont bien pris en compte;

# slapcat -b "cn=config" | grep -E "olcTLS"

Ce qui dervait donner ceci comme résultat;

olcTLSCACertificateFile: /etc/ssl/openldap/certs/cacert.pem
olcTLSCertificateFile: /etc/ssl/openldap/certs/ldapserver-cert.crt
olcTLSCertificateKeyFile: /etc/ssl/openldap/private/ldapserver-key.key

Testons également la validité de la nouvelle configuration du LDAP avec la commande suivante;

# slaptest -u

Et le résultat devrait être le suivant;

config file testing succeeded

Ensuite il faut modifier le fichier /etc/ldap/ldap.conf pour y renseigner également la localisation du nouveau certifict TLS.

# vi /etc/ldap/ldap.conf

Et le modifier comme dans l'extrait ci-dessous;

...
# TLS certificates (needed for GnuTLS)
#TLS_CACERT	/etc/ssl/certs/ca-certificates.crt
TLS_CACERT	/etc/ssl/openldap/certs/cacert.pem

Et redémarrer le service OpenLDAP;

# systemctl restart slapd

Vérifier la connectivité au LDAP

# ldapwhoami -H ldap://buster.caldarium.be -x -ZZ

Devrait donner ceci si ça fonctionne;

anonymous

Sinon, il se pourrait qu'une erreur du genre vous soit retournée;

ldap_start_tls: Connect error (-11)
	additional info: (unknown error code)

Dans ce cas, vous pourriez essayer une commande plus verbeuse pour

# ldapsearch -d -1 -x -ZZ -b 'dc=caldarium,dc=be' '(objectclass=*)' | grep TLS:

Et peut-être que vous trouvez deux lignes du genre;

TLS: hostname (buster) does not match common name in certificate (buster.caldarium.be).
TLS: can't connect: (unknown error code).

Ce qui signifie que le FQDN définis lors de la génération des certificats ne correspond pas au FQDN de votre serveur (cf. une note à propos du FQDN).

Désactiver l'accès anonyme au serveur OpenLDAP

Pour désactiver l'accès anonyme et rendre l'authentification obligatoire pour pouvoir accéder au serveur LDAP, il faut, comme d'habitude maintenant, créer un fichier ldif;

# cd /root/ldap
# vi disable-anon.ldif

Y mettre les infosmations suivantes;

dn: cn=config
changetype: modify
add: olcDisallows
olcDisallows: bind_anon

dn: cn=config
changetype: modify
add: olcRequires
olcRequires: authc

dn: olcDatabase={-1}frontend,cn=config
changetype: modify
add: olcRequires
olcRequires: authc

Et mettre à jour la base de données slapd;

# ldapadd -Y EXTERNAL -H ldapi:/// -f disable-anon.ldif

Tester l'accès anonyme, qui ne devrait pas fonctionner comme ci-dessus, mais renvoyer un message d'erreur.

# ldapwhoami -H ldapi:/// -x -ZZ

Devrait retourner ceci;

ldap_bind: Inappropriate authentication (48)
	additional info: anonymous bind disallowed

Tester l'accès authentifé

Puisque l'accès anonyme n'est plus possible, voyons si l'accès en tant qu'utilisateur·ice fonctionne bien;

# ldapwhoami -H ldapi:/// -x -ZZ -D "uid=bernadette,ou=people,dc=buster,dc=caldarium,dc=be" -x -W

Taper le mot de passe de l'utilisatrice Bernadette, et si tout se passe bien, vous devriez avoir ce genre de message en sortie;

Enter LDAP Password: 
dn:uid=bernadette,ou=people,dc=buster,dc=caldarium,dc=be

Configurer la journalisation (Logging)

De manière similaire, à l'aide d'un fichier ldif, nous allons activer la journalisation vers un fichier log. Tout d'abord, il faut configurer OpenLDAP pour enregistrer les connexions, les opérations et les statistiques de résultats. Cette journalisation est activée au niveau 256 du journal avec les statistiques par mot-clé. Cela peut être fait en modifiant l'attribut olcLogLevel comme indiqué ci-dessous.

Créons un fichier ldif avec les options nécessaires;

# cd /root/ldap
# vi enable-ldap-log.ldif

Pour y mettre le contenu suivant;

dn: cn=config
changeType: modify
replace: olcLogLevel
olcLogLevel: stats

Et mettons ça dans la base de données slapo;

ldapmodify -Y external -H ldapi:/// -f enable-ldap-log.ldif

Ce qui devrait nous répondre un truc du genre;

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"

Vérifions si c'est bien pris en compte dans la DB;

ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config "(objectClass=olcGlobal)" olcLogLevel -LLL

Ce qui devrait retourner ceci;

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: cn=config
olcLogLevel: stats

Il faut maintenant configurer rsyslog pour demander à OpenLDAP d'écrire les journaux dans dans fichier donné. Pour plus d'explications sur le fonctionnement de rsyslog, n'hésitez pas à jeter un coup d'œil sur le wiki de Archlinux *(anglais)*.

# echo "local4.* /var/log/slapd.log" >> /etc/rsyslog.conf

Et redémarrons rsyslog et slapd

# systemctl restart rsyslog
# systemctl restart slapd

Il est maintenant possible de suivre le journal dans /var/log/slapd.log

# tail -f /var/log/slapd.log
Utilisez CTRL+C pour arrêter le suivi continu

Voilà ! Jusqu'à présent, nous avons appris comment configurer le serveur OpenLDAP avec SSL/TLS sur Debian 10.

ÇA serait chouette de faire un autre guide sur la configuration des clients LDAP pour l'authentification via le serveur LDAP.

documentation/gitea/ldap-ssl.1616588872.txt.gz · Dernière modification : 2021/03/24 13:27 de tierce