CertificatVoici le troisième article dans notre série sur l’authentification centralisée avec 389 Directory Server. Les deux précédents articles traitaient de l’installation du serveur d’annuaires et de la création des utilisateurs. Dans l’état actuel des choses, rien ne nous empêcherait de connecter un poste client à notre serveur pour lui permettre de récupérer les données d’authentification. Le seul problème, c’est que les données des utilisateurs comme les identifiants et les mots de passe transiteraient en clair dans le réseau local, ce qui n’est pas idéal en termes de sécurité. L’article du jour se penche donc sur la question de la sécurité des connexions.

Créer une autorité de certification TLS

Différents chemins mènent à Saint-Bauzille-de-Putois, comme le dit un proverbe un peu moins connu. La première chose que nous devons faire, c’est mettre en place une autorité de certification TLS. Nous avons le choix entre plusieurs façons de faire. Je n’aime pas me compliquer la vie inutilement, mon choix se porte donc sur Easy-RSA. La mise en place d’une autorité de certification TLS avec Easy-RSA est décrite en détail dans cet article.

Initialer la base de données NSS

389 Directory Server stocke les certificats dans la base de données NSS (Network Security Services). Cette base doit être initialisée avant la première utilisation.

Retournez dans la console d’administration > Server Group > Directory Server > Open. Dans la fenêtre subséquente, cliquez sur Manage Certificates dans l’onglet Tasks.

389 Directory Server

Initialisez la base NSS en choisissant un mot de passe.

389 Directory Server

Générer une demande de certificat CSR

La prochaine étape consiste à générer une demande de certificat (Certificate Signing Request).

Dans l’onglet Server Certs, cliquez sur Request > Request certificate manually > Next.

389 Directory Server

Renseignez le formulaire de la demande de certificat et cliquez sur Next.

389 Directory Server

Définissez les paramètres de la clé.

389 Directory Server

Renseignez le mot de passe de la clé privée.

389 Directory Server

Cliquez sur Save to file.

389 Directory Server

Enregistrez le fichier dans votre répertoire utilisateur en lui donnant un nom cohérent, par exemple server-cert.csr, et cliquez sur Done.

389 Directory Server

Signer le certificat

La prochaine étape consiste à signer notre demande de certificat. C’est ce que nous allons faire très simplement en utilisant Easy-RSA.

Dans un premier temps, nous devons importer la demande de certificat.

$ cd easy-rsa-3.0.7/easyrsa3/
$ ./easyrsa import-req ~/server-cert.csr server-cert

Using SSL: openssl OpenSSL 1.0.2k-fips 26 Jan 2017

The request has been successfully imported with a short name of: server-cert
You may now use this name to perform signing operations on this request.

Il ne reste plus qu’à le signer en précisant qu’il s’agit d’un certificat de type server.

$ ./easyrsa sign-req server server-cert

Using SSL: openssl OpenSSL 1.0.2k-fips  26 Jan 2017

You are about to sign the following certificate.
Please check over the details shown below for accuracy. Note that this request
has not been cryptographically verified. Please be sure it came from a trusted
source or that you have verified the request checksum with the sender.

Request subject, to be signed as a server certificate for 1080 days:

subject=
    countryName               = FR
    stateOrProvinceName       = Gard
    localityName              = Montpezat
    organizationName          = Microlinux
    organizationalUnitName    = IT
    commonName                = amandine.microlinux.lan

Type the word 'yes' to continue, or any other input to abort.
  Confirm request details: yes

...

Write out database with 1 new entries
Data Base Updated

Certificate created at: ~/easy-rsa-3.0.7/easyrsa3/pki/issued/server-cert.crt

Le certificat signé server-cert.crt est désormais disponible dans l’arborescence d’Easy-RSA, dans le répertoire pki/issued.

Importer le certificat du CA

Maintenant, nous devons importer le certificat de l’autorité de certification (CA ou Certificate Authority). Retournez dans la console d’administration et rendez-vous dans la section Manage Certificates. Ouvrez l’onglet CA Certs et cliquez sur Install.

389 Directory Server

Choisissez l’option in this local file et cliquez sur Browse.

389 Directory Server

Naviguez dans l’arborescence de Easy-RSA, sélectionnez le fichier pki/ca.crt et cliquez sur Next.

389 Directory Server

Vérifiez les informations du certificat.

389 Directory Server

Confirmez le type de certificat.

389 Directory Server

Acceptez le choix par défaut pour le type de connexion.

389 Directory Server

Si tout s’est bien passé, le certificat apparaît dans la fenêtre CA Certs.

389 Directory Server

Importer le certificat du serveur

À présent, nous pouvons importer le certificat du serveur. Ouvrez l’onglet Server Certs, cliquez sur Install, choisissez l’option in this local file, cliquez sur Browse, sélectionnez le fichier server-cert.crt dans le répertoire pki/issued de l’arborescence d’Easy-RSA et cliquez sur Next.

389 Directory Server

Là aussi, vérifiez les informations du certificat, confirmez le type et saisissez le mot de passe pour la clé privée.

389 Directory Server

Le certificat du serveur a été importé avec succès.

389 Directory Server

Activer les connexions sécurisées

Maintenant que les certificats divers et variés sont installés, nous pouvons activer TLS. Dans la console d’administration, cliquez sur Server Group > Directory Server > Open. Dans la fenêtre subséquente, ouvrez l’onglet Configuration. Dans la section Network Settings, notez le port utilisé pour les connexions sécurisées (Encrypted Port).

389 Directory Server

Ouvrez l’onglet Encryption, cochez Enable SSL for this server et Use this cipher family: RSA. Vérifiez si l’option Certificate affiche bien le certificat server-cert.

ImportantGardez les autres options telles quelles, et ne cochez surtout pas Use SSL in Console, sous peine de vous tirer dans le pied.

389 Directory Server

Cliquez sur Save et prenez note des avertissements divers et variés qui s’affichent.

Gérer le démarrage du service

La console d’administration nous a averti que l’activation de TLS nécessitait un redémarrage du service pour prendre effet. Or, voilà comment se présentent les choses.

$ sudo systemctl restart dirsrv.target
Enter PIN for Internal (Software) Token: *********

Dorénavant, le service requiert la saisie du mot de passe de la base NSS pour démarrer. Ce qui signifie qu’il ne peut plus se lancer de manière autonome au démarrage du serveur.

Pour éviter d’avoir à saisir le mot de passe à chaque redémarrage du service, on peut ranger le mot de passe dans un fichier pin.txt.

$ sudo vim /etc/dirsrv/slapd-amandine/pin.txt

Voici la syntaxe qu’il faudra utiliser.

Internal (Software) Token:mot_de_passe

Étant donné que le mot de passe est stocké en clair, il faut impérativement restreindre les permissions de ce fichier.

$ sudo chown dirsrv:dirsrv /etc/dirsrv/slapd-amandine/pin.txt
$ sudo chmod 0400 /etc/dirsrv/slapd-amandine/pin.txt

InfoCette solution n’est pas idéale en termes de sécurité. La démarche la plus sûre consiste sans doute à gérer le service manuellement et saisir le mot de passe à chaque démarrage.

Notre serveur est désormais capable de gérer des connexions sécurisées. Dans notre prochain article, nous allons tenter de connecter les postes clients du réseau pour leur permettre de s’authentifier.


La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce blog ? Offrez un café au rédacteur en cliquant sur la tasse.

 


2 commentaires

laurent · 28 avril 2020 à 20 h 49 min

j’apprécie beaucoup vos publications, concernant cette série d’articles sur 389 Directory server, quelle différence faites vous sur ce projet par rapport à Samba4 ?

    kikinovak · 28 avril 2020 à 21 h 34 min

    Merci pour les fleurs.

    Samba, je l’utilise juste pour mettre en place des serveurs de fichiers simples, c’est tout.

Les commentaires sont fermés.