Installation et configuration d’un annuaire OpenLDAP

Magazine
Marque
Linux Pratique
Numéro
115
Mois de parution
septembre 2019
Domaines


Résumé

OpenLDAP est une implémentation libre du standard d’interrogation et de modification d’annuaire LDAP. Cet article ambitionne de vous donner les clés pour centraliser vos utilisateurs Linux dans un annuaire LDAP. Cependant, les connaissances acquises pourront également vous servir dans le monde Microsoft, car Active Directory s’appuie également sur le protocole LDAP.


Body

1. LDAP in a nutshell

Un annuaire est une base de données contenant différents types d’objets. Ces objets sont formés de couples attribut/valeur. Par exemple, je pourrais me définir par l’attribut Nom ayant pour valeur Greneche et l’attribut Prénom ayant comme valeur Nicolas. Les attributs composant un objet sont normés par des schémas. Les applications clientes de l’annuaire sont multiples (serveur de messagerie, terminal de téléphonie sur IP, authentification des ouvertures de sessions, portail WiFi, etc.) et elles doivent toutes utiliser la même façon d’interroger l’annuaire. Un effort de standardisation a donc été fourni pour aboutir au protocole LDAP (Lightweight Directory Access Protocol). Ce protocole permet d’interagir avec les objets stockés dans l’annuaire.

La dernière chose à savoir est que cet annuaire est stocké de façon hiérarchique. C'est-à-dire que nous avons une racine et des feuilles. Chaque objet est identifié par un attribut DN (Distinguished Name) qui reflète son positionnement dans l'annuaire. Dans notre exemple, nous allons créer une racine correspondant au domaine DNS calcul.univ-paris13.fr. Dans le monde LDAP, cela se traduirait par le DN suivant : dc=calcul,dc=univ-paris13,dc=fr. Un DC est un composant du domaine (Domain Component). Nous allons également créer deux feuilles sous cette racine afin d'y stocker les utilisateurs et les groupes UNIX en vue de les distribuer sur le réseau. Ces deux feuilles seront des OU (Organizational Unit), c'est-à-dire des sortes de boites où on peut mettre des choses (en l’occurrence, les utilisateurs et les groupes) pour aboutir à l'annuaire présenté en figure 1. Ne vous inquiétez pas, ces notions vont vite se concrétiser dans la suite. Toutes les manipulations de cet article sont réalisées sous Debian Buster.

 

ldap

 

Fig. 1 : Annuaire cible.

2. Installation d’OpenLDAP

Un service d’annuaire traditionnel est composé de deux éléments : un processus réseau qui attend les requêtes et une base de données stockée sur le système de fichiers. À la réception d’une requête LDAP émise depuis un client de l'annuaire, le processus va lire ou écrire (selon la nature de la requête) dans cette base de données. Dans le monde OpenLDAP, le processus réseau se nomme slapd et les fichiers composant la base de données sont dans /var/lib/ldap. Un utilisateur système est souvent lié à slapd. Sous Debian, il s’agit de l’utilisateur openldap. Le processus slapd va donc tourner avec l’identité openldap et par conséquent le répertoire /var/lib/ldap doit lui appartenir.

Nous disposons de deux machines pour monter l’environnement de test de notre article. Le serveur slapd sera installé sur la machine nommée 'serveur' et la machine nommée 'client' sera cliente de cet annuaire. Commençons par installer le service slapd :

root@serveur:~# DEBIAN_FRONTEND=noninteractive apt-get -yq install slapd

Le premier élément DEBIAN_FRONTEND=noninteractive peut vous interpeller. Il faut savoir qu'avec l'interpréteur de commande Bash, il est possible de passer des variables d’environnement au processus fils généré par l'invocation de la commande (ici, apt-get). Cette variable précise que l'installation du paquet (ici, slapd) va se faire en mode non interactif. Les paramètres -yq précisent également que l'installation devra se faire en mode silencieux. Le paquet sera donc installé sans aucune action de post-configuration.

3. Configuration initiale

Pour créer un squelette de configuration de slapd, nous allons utiliser la commande dpkg-reconfigure comme suit :

root@serveur:~# dpkg-reconfigure slapd

À l'invocation de cette commande, une suite de menus en ncurses vont se succéder pour configurer le paquet slapd. Il faut utiliser tabulation pour se déplacer dans ces menus et la touche [Entrée] pour valider. Deux captures suivent pour vous présenter l'aspect des menus ncurses. Le premier menu nous demande si on veut omettre la configuration de slapd, il faut évidemment répondre non (figure 2).

 

reconfigure-1

 

Fig. 2 : Configuration slapd - étape 1.

La question suivante sert à fixer la racine de l'annuaire LDAP. Comme vu dans la partie 1, cette racine va correspondre au domaine DNS. Nous entrons donc calcul.univ-paris13.fr (figure 3).

 

reconfigure-2

 

Fig. 3 : Configuration slapd - étape 2.

À l'issue de cette étape, la racine dc=calcul,dc=univ-paris13,dc=fr est créée. L'étape suivante est liée, il s'agit de fixer l'attribut organization pour cette racine. Traditionnellement, on laisse le domaine DNS, donc calcul.univ-paris13.fr. Ensuite, dpkg-reconfigure demande d'affecter un mot de passe à l'administrateur de la racine. Cet administrateur est identifié par le DN cn=admin,dc=calcul,dc=univ-paris13,dc=fr. En lisant le DN, on voit sans ambiguïté qu'il est placé directement sous la racine. L'étape suivante est de fixer le moteur de base de données de l'annuaire. Nous choisirons MDB qui est le standard actuel. L'avant-dernière question concerne le comportement en cas de purge du paquet. La purge intervient lorsque l'on utilise l'option --purge à la suppression d'un paquet avec apt-get. La purge détruit également les fichiers de configuration, logs, bases de données, etc., liés au paquet. Ici c'est à vous de décider, le choix le plus conservateur étant non. Enfin, dpkg-reconfigure demande s’il doit bouger la base de données actuelle pour la sauvegarder, idem c'est à vous de voir. Le choix le plus conservateur est évidemment oui. Nous avons maintenant un slapd opérationnel !

4. Tests fonctionnels

Les deux premières choses à faire sont respectivement d'activer slapd au démarrage et de le lancer. Ces actions se font avec systemctl :

root@serveur:~# systemctl enable slapd

slapd.service is not a native service, redirecting to systemd-sysv-install.

Executing: /lib/systemd/systemd-sysv-install enable slapd

Puis :

root@serveur:~# systemctl start slapd

Regardons sur quel port réseau écoute slapd :

root@serveur:~# netstat -laputn | grep slapd

Connexions Internet actives (serveurs et établies)

Proto Recv-Q Send-Q Adresse locale       Adresse distante     Etat     PID/Program name

tcp     0   0 0.0.0.0:389          0.0.0.0:*            LISTEN   3450/slapd

On voit que slapd attend les requêtes LDAP sur le port TCP 389. Regardons avec quels arguments s’exécute le service :

root@serveur:~# cat /var/run/slapd/slapd.args

/usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d

Le paramètre -h indique les modalités d'accès à slapd : ldap et ldapi. L'accès en mode ldap sous-entend des requêtes en clair (ou en start_tls, mais nous n'avons pas encore configuré les certificats). Cet accès se fait via le port TPC 389 observé ci-dessus. L'accès en ldapi se fait par un socket UNIX (donc local à la machine, non exposé sur le réseau) et le contrôle se fait en se basant sur l'UID de l’initiateur de la connexion. En gros si l'accès à la socket se fait depuis le compte root local ça marche, sinon non. Les options -g (groupe) et -u (utilisateur) définissent l'identité sous laquelle tourne le processus slapd. Enfin, -F donne l'emplacement de la configuration de slapd. Nous n'allons jamais taper directement dans les fichiers de ce répertoire, car la configuration de slapd se fait désormais directement dans la base LDAP elle-même pour une configuration à chaud sans redémarrage.

Le test ultime est de tenter un affichage des données de l'annuaire. Pour ce faire, nous allons installer l'outil ldapsearch contenu dans le paquet ldap-utils :

root@serveur:~# apt-get install ldap-utils

Et l’exécuter :

root@serveur:~# ldapsearch -x -H ldap://serveur.calcul.univ-paris13.fr -b 'dc=calcul,dc=univ-paris13,dc=fr'

[...]

dn: dc=calcul,dc=univ-paris13,dc=fr

objectClass: top

objectClass: dcObject

objectClass: organization

o: calcul.univ-paris13.fr

dc: calcul

# admin, calcul.univ-paris13.fr

dn: cn=admin,dc=calcul,dc=univ-paris13,dc=fr

objectClass: simpleSecurityObject

objectClass: organizationalRole

cn: admin

description: LDAP administrator

# search result

search: 2

result: 0 Success

# numResponses: 3

# numEntries: 2

Reprenons les arguments de ldapsearch. L'option -x indique que nous utilisons une connexion type simple bind. C'est-à-dire que nous utilisons un compte défini à l’intérieur de la base LDAP pour accéder à l'annuaire. Pour garder cette requête la plus simple possible, nous ne spécifions pas de compte, ce qui sous-entend un accès anonyme (anonymous binding). L'option -H avec la valeur ldap://serveur.calcul.univ-paris13.fr indique que l'accès se fait en ldap (et non en ldapi) sur la machine serveur.calcul.univ-paris13.fr. Enfin, le -b définit la racine à parcourir, donc ici 'dc=calcul,dc=univ-paris13,dc=fr'. En résultat, on voit bien qu'on retrouve les deux entrées créées au moment du dpkg-reconfigure, à savoir les deux DN dc=calcul,dc=univ-paris13,dc=fr (la racine) et cn=admin,dc=calcul,dc=univ-paris13,dc=fr (le compte administrateur de cette racine).

5. Peuplement de l'annuaire

Nous allons peupler l'annuaire en créant les deux OU puis un compte système avec son groupe primaire. Dans le monde LDAP, les données à ajouter à l'annuaire peuvent être inscrites dans un fichier rédigé au format LDIF (LDAP Data Interchange Format). Ce format présente les objets à manipuler dans l'annuaire accompagnés de leurs attributs. Par exemple, pour nos deux OU le fichier se présente de la façon suivante :

root@serveur:~# cat ou.ldif

dn: ou=posixaccounts,dc=calcul,dc=univ-paris13,dc=fr

objectclass: OrganizationalUnit

dn: ou=posixgroups,dc=calcul,dc=univ-paris13,dc=fr

objectclass: OrganizationalUnit

Nous avons deux OU : posixaccounts (qui va contenir les comptes UNIX) et posixgroups (qui va contenir les groupes UNIX). L'OU étant un objet assez simple, il va contenir que deux attributs : le DN qui positionne sans ambiguïté l'objet dans l'arbre (ici juste sous la racine) et l'objectclass qui indique que l'objet à ajouter est de type OrganizationalUnit. Les objectclass sont définis dans les schémas et un objet de l'annuaire peut appartenir à plusieurs objectclass pour multiplier les attributs possibles. Ajoutons-les à l'annuaire via la commande ldapadd :

root@serveur:~# ldapadd -x -H ldap://serveur.calcul.univ-paris13.fr -D 'cn=admin,dc=calcul,dc=univ-paris13,dc=fr' -f ou.ldif -W

Enter LDAP Password:

adding new entry "ou=posixaccounts,dc=calcul,dc=univ-paris13,dc=fr"

adding new entry "ou=posixgroups,dc=calcul,dc=univ-paris13,dc=fr"

Par rapport à la commande ldapadd de tout à l'heure, deux nouveaux attributs se sont positionnés : -D avec la valeur 'cn=admin,dc=calcul,dc=univ-paris13,dc=fr' qui sert à préciser quel compte on va utiliser pour se connecter à slapd (ici l'administrateur de la racine concernée par l'ajout) et -W qui indique à la commande de demander le mot de passe associé interactivement. Nous avons également un -f pour indiquer le fichier LDIF à traiter. Il nous reste à ajouter le compte avec le groupe primaire :

root@serveur:~# cat userandupg.ldif

dn: uid=nicolas.greneche,ou=posixaccounts,dc=calcul,dc=univ-paris13,dc=fr

uid: nicolas.greneche

sn: nicolas.greneche

homeDirectory: /home/nicolas.greneche

cn: nicolas.greneche

objectClass: inetOrgPerson

objectClass: posixAccount

objectClass: top

loginShell: /bin/bash

uidNumber: 6001

gidNumber: 6001

gecos: nico

mail: nicolas.greneche@univ-paris13.fr

userPassword: {SSHA}XXXXXXXXXXXXXXXXXXXXXXXX

dn: cn=nicolas.greneche,ou=posixgroups,dc=calcul,dc=univ-paris13,dc=fr

objectClass: posixGroup

objectClass: top

gidNumber: 6001

cn: nicolas.greneche

Si on examine ce fichier LDIF, on se rend compte qu'il contient deux objets : le compte système 'uid=nicolas.greneche,ou=posixaccounts,dc=calcul,dc=univ-paris13,dc=fr' (objectclass posixAccount) et le groupe primaire associé 'cn=nicolas.greneche,ou=posixgroups,dc=calcul,dc=univ-paris13,dc=fr' (objectclass posixGroup), chacun rangé dans son OU respective. On notera que les attributs de ces deux objets coïncident avec les informations qu'on trouverait dans les fichiers /etc/passwd, /etc/shadow et /etc/group.

Pour créer l'empreinte du mot de passe userPassword, il est possible d'utiliser la commande slappasswd comme suit :

root@serveur:~# slappasswd

New password:

Re-enter new password:

{SSHA}XXXXXXXXXXXXXXXXXXXXXXXX

Ajoutons les deux objets :

root@serveur:~# ldapadd -x -H ldap://serveur.calcul.univ-paris13.fr -D 'cn=admin,dc=calcul,dc=univ-paris13,dc=fr' -f userandupg.ldif -W

Enter LDAP Password:

adding new entry "uid=nicolas.greneche,ou=posixaccounts,dc=calcul,dc=univ-paris13,dc=fr"

adding new entry "cn=nicolas.greneche,ou=posixgroups,dc=calcul,dc=univ-paris13,dc=fr"

6. Sécurisation avec SSL

SSL (Secure Socket Layer) est une couche additionnelle à TCP ajoutant une propriété de confidentialité à la connexion en chiffrant les échanges lors de son établissement. La sécurisation de notre serveur LDAP va se résumer à activer l'accès en ldaps (en plus du ldap et ldapi mentionnés ci-dessus). Pour autoriser l'accès en ldaps, il faut modifier les paramètres de lancement du service ldap pour ajouter ldaps à ldap et ldapi et générer un certificat. Commençons par le certificat.

6.1 Création des certificats

Le plus simple est de créer un sous-répertoire ssl où mettre le certificat et de se placer dedans :

root@serveur:/etc/ldap/ssl# mkdir /etc/ldap/ssl && cd /etc/ldap/ssl

Puis d'utiliser la commande openssl pour générer un certificat autosigné :

root@serveur:/etc/ldap/ssl# openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 3650 -nodes

Generating a RSA private key

...........................................................................++++

.................................................................................++++

writing new private key to 'key.pem'

Cette commande va créer deux fichiers : key.pem (clé privée) et cert.pem (certificat contenant la clé publique). Comme le certificat est autosigné, le fichier cert.pem fait également office de CA (Certificate Authority). En résumé, ce qui est chiffré avec la clé privée est déchiffrable avec la clé publique et ce qui est chiffré avec la clé publique est déchiffrable par la clé privée. En conséquence, slapd présentera le certificat au client souhaitant se connecter en ldaps (LDAP over SSL). Le client extraira la clé publique du certificat et utilisera cette clé pour discuter de façon chiffrée avec le serveur afin de se mettre d'accord sur les modalités d'établissement d'une session SSL par laquelle faire passer les données. Les données circuleront donc chiffrées sur le réseau. Une fois cette commande validée, elle nous demande un certain nombre d'informations :

Country Name (2 letter code) [AU]:FR

State or Province Name (full name) [Some-State]:IdF

Locality Name (eg, city) []:Paris

Organization Name (eg, company) [Internet Widgits Pty Ltd]:Université Paris 13

Organizational Unit Name (eg, section) []:DSI

Common Name (e.g. server FQDN or YOUR name) []:serveur.univ-paris13.fr

On peut répondre ce qu'on veut partout SAUF la dernière concernant le Common Name. Il faut absolument mettre le nom d'hôte complet (FQDN) de la machine faisant office de serveur LDAP. C'est une vérification basée sur DNS pour le client qui valide (dans la limite de l'intégrité possible avec DNS) que le certificat est bien distribué pour la machine au bout de l'IP contactée. On change ensuite les permissions sur les deux fichiers générés. Les fichiers doivent appartenir à l'utilisateur openldap (identité utilisée par slapd) :

root@serveur:~/config/slapd# chown openldap:openldap /etc/ldap/ssl/cert.pem

root@serveur:~/config/slapd# chown openldap:openldap /etc/ldap/ssl/key.pem

La clé privée ne doit être accessible que par root :

root@serveur:~/config/slapd# chmod 400 /etc/ldap/ssl/key.pem

6.2 Configuration de slapd

Il faut ajouter deux directives dans la configuration de slapd pour qu'il trouve le couple clé/certificat à utiliser lors de l'établissement d'une connexion SSL d'un client. La configuration se fait via un fichier LDIF modifiant la racine cn=config de l'annuaire LDAP. Cette racine contient tous les éléments de configuration. Voici le fichier à utiliser :

root@serveur:~/config/slapd# cat cert.ldif

dn: cn=config

changetype: modify

replace: olcTLSCACertificateFile

olcTLSCACertificateFile: /etc/ldap/ssl/cert.pem

-

replace: olcTLSCertificateFile

olcTLSCertificateFile: /etc/ldap/ssl/cert.pem

-

replace: olcTLSCertificateKeyFile

olcTLSCertificateKeyFile: /etc/ldap/ssl/key.pem

Dans ce fichier, on informe que c'est une modification (changetype : modify) qui va porter sur la racine cn=config pour le remplacement des valeurs de trois attributs (olcTLSCACertificateFile, olcTLSCertificateFile et olcTLSCertificateKeyFile) avec celles correspondant aux emplacements des fichiers générés avec la commande openssl. Pour appliquer les modifications induites par le fichier LDIF, nous allons passer par l'accès en ldapi, car il n'y a pas de compte administrateur associé à la racine cn=config :

root@serveur:~/config/slapd# ldapmodify -Y EXTERNAL -H ldapi:/// -f cert.ldif

SASL/EXTERNAL authentication started

SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth

SASL SSF: 0

modifying entry "cn=config"

L'argument -x a donc disparu au profit de -Y EXTERNAL pour s'authentifier via l'UID. L'option -H a comme valeur ldapi:/// qui pointe sur la socket UNIX gérée par slapd.

La dernière étape est de modifier le fichier /etc/default/slapd pour lui dire qu'il doit maintenant gérer la méthode d'accès ldaps et plus de ldap et ldapi :

root@serveur:~/config/slapd# vim.tiny /etc/default/slapd

SLAPD_SERVICES="ldap:/// ldapi:/// ldaps:///"

Il ne reste plus qu'à redémarrer slapd (on a pas fait que modifier la configuration, on a également ajouté un socket SSL à gérer, donc redémarrage) :

root@serveur:~/config/slapd# systemctl restart slapd

Vérification :

root@serveur:~/config/slapd# netstat -laputn -A inet | grep slapd

tcp     0   0 0.0.0.0:389          0.0.0.0:*            LISTEN   7238/slapd

tcp     0   0 0.0.0.0:636          0.0.0.0:*            LISTEN   7238/slapd

Nous avons le service slapd qui écoute bien en SSL sur le port 636. Le serveur est fin prêt, passons au client.

7. Configuration du client

La configuration du client va se faire en deux temps. Premièrement, nous allons raccorder le client au serveur LDAP. Nous allons vérifier que la connexion entre les deux permet la consultation de l'annuaire depuis le client. Ensuite, nous allons installer la partie cliente qui va augmenter la base des comptes locaux avec celle contenue dans la base LDAP. Nous pourrions nous passer de la première étape, mais elle permet de bien valider l'accès au serveur LDAP en cas de soucis avec la seconde.

7.1 Raccordement au LDAP

Avant tout, il faut installer le paquet ldap-utils pour disposer des commande ldap* (ldapsearch, ldapadd, etc.) :

root@client:~# apt-get install ldap-utils

Commençons par vérifier que le client peut bien se connecter au port TCP/636 en SSL sur le serveur et consulter le certificat :

root@client:~# openssl s_client -connect serveur.calcul.univ-paris13.fr:636 -showcerts

Cette commande devrait vous renvoyer les données du certificat créé précédemment. Nous devons ensuite envoyer le certificat du serveur vers le client pour qu'à la connexion le client puisse valider qu'il s'adresse bien à la bonne machine :

root@client:~# mkdir /etc/ldap/ssl

root@client:~# scp root@serveur:/etc/ldap/ssl/cert.pem /etc/ldap/ssl/cert.pem

root@serveur's password:

cert.pem

Enfin, il nous faut configurer le fichier /etc/ldap/ldap.conf pour y insérer les informations de connexion au serveur LDAP :

root@client:~# cat /etc/ldap/ldap.conf

BASE dc=calcul,dc=univ-paris13,dc=fr

URI  ldaps://serveur.calcul.univ-paris13.fr

TLS_CACERT   /etc/ldap/ssl/cert.pem

Ce fichier contient les 3 paramètres essentiels à la connexion : la racine (BASE, synonyme de l'option -b des commandes clientes ldap*), l'emplacement et la méthode d'accès au service d'annuaire (URI, synonyme de l'option -H) et l'emplacement du certificat permettant de vérifier celui présenté par le serveur. Il ne reste plus qu'à tester avec une commande ldapsearch depuis le client :

root@client:~# ldapsearch -x

[...]

# search result

search: 2

result: 0 Success

# numResponses: 7

# numEntries: 6

Cette commande nous renvoie bien les 6 entrées de l'annuaire (racine + 2 OU + administrateur de la racine + compte + groupe). On voit qu'elle est bien plus courte qu'avant, car les applications clientes LDAP vont chercher leurs valeurs par défaut dans le fichier ldap.conf.

7.2 Complétion des comptes locaux avec LDAP

Le programme gérant les bases de comptes utilisables par un système Linux se nomme NSS (Name Switching Service). Il va s'appuyer sur un service nommé SSSD (System Security Services Daemon) qui pointe sur le serveur LDAP et lui présente les comptes qui y sont stockés. Commençons par installer le service SSSD :

root@client:~# apt-get install sssd

Regardons la configuration du programme NSS à la suite de cette installation :

root@client:~# cat /etc/nsswitch.conf

[...]

passwd:         files systemd sss

group:          files systemd sss

shadow:         files sss

On voit que le programme NSS va interroger le service SSSD (sss) en vue de compléter la base locale (files) pour ce qui concerne les bases passwd, group et shadow. La dernière étape sur le client est de configurer le service SSSD avec les informations de notre serveur LDAP. La configuration se passe dans le fichier sssd.conf :

root@client:~# cat /etc/sssd/sssd.conf

[sssd]

services = nss, pam

domains = LOCAL, LDAP

[domain/LOCAL]

description = LOCAL Users domain

id_provider = local

enumerate = true

[domain/LDAP]

id_provider = ldap

auth_provider = ldap

ldap_schema = rfc2307

ldap_uri = ldaps://serveur.calcul.univ-paris13.fr

ldap_search_base = dc=calcul,dc=univ-paris13,dc=fr

enumerate = true

ldap_tls_cacert = /etc/ldap/ssl/cert.pem

Ce fichier configure le service sssd. La ligne services indique que SSSD sera utilisé pour la gestion des comptes (nss) et l'authentification (pam). La ligne domains prend deux valeurs : LOCAL et LDAP. LOCAL correspond aux comptes locaux de la machine (/etc/passwd, /etc/shadow et /etc/group) et LDAP à ceux stockés dans le LDAP. Dans la section domain/LDAP, nous retrouvons les paramètres du ldap.conf ainsi que la spécification du protocole LDAP comme méthode d'accès au compte (id_provider) et credentials d'authentification (auth_provider). Activons et démarrons le service SSSD :

root@serveur:~# systemctl enable sssd

root@serveur:~# systemctl start sssd

Vérification :

root@client:~# getent passwd | grep greneche

nicolas.greneche:*:6001:6001:nico:/home/nicolas.greneche:/bin/bash

La commande getent prend comme paramètre une base NSS (passwd, group ou shadow) et en affiche le contenu. Nous demandons la base passwd et en résultat nous obtenons bien le compte nicolas.greneche qui est défini dans le LDAP. La base de comptes locaux est donc bien complétée avec les utilisateurs définis dans l'annuaire LDAP. Créons un home pour notre utilisateur :

root@client:~# mkdir /home/nicolas.greneche

Positionnons les droits appropriés :

root@client:~# chown nicolas.greneche:nicolas.greneche /home/nicolas.greneche

root@client:~# chmod 750 /home/nicolas.greneche

On se déconnecte du client :

root@client:~# logout

On s’authentifie avec l'identifiant créé dans le LDAP :

nicolas.greneche@client:~$ id

nicolas.greneche:*:6001:6001:nico:/home/nicolas.greneche:/bin/bash

La commande id affiche l'identité en cours d'utilisation. Notre utilisateur est bien reconnu sur le système, mission accomplie !

Conclusion

Avec cet article, nous avons déployé une configuration OpenLDAP de base solide. Pour lui faire passer le cap de la production, j'invite le lecteur à investiguer du côté de deux technologies. La première est intégrée à OpenLDAP, il s'agit des modules syncprov et accesslog destinés à faire de la réplication entre plusieurs services slapd afin de disposer de plusieurs machines hébergeant la base de données. La seconde est externe et se nomme HAProxy. L'idée est de placer une machine HAProxy en frontal de notre ferme de serveurs slapd pour équilibrer la charge (évidemment, il faudra redonder le HAProxy).

 



Articles qui pourraient vous intéresser...

Sécurisation du serveur

Magazine
Marque
Linux Pratique
HS n°
Numéro
48
Mois de parution
septembre 2020
Domaines
Résumé

Notre serveur RHEL est désormais fin prêt à être utilisé et maintenu, sans peine et de manière confortable. Cependant, notre travail n’est pas terminé. Il nous reste encore un élément crucial à valider : nous assurer que le serveur est aussi sûr et protégé que possible face à un éventuel assaillant mal attentionné.

Surveillance des accès de production en télétravail

Magazine
Marque
MISC
Numéro
111
Mois de parution
septembre 2020
Domaines
Résumé

Il est courant de protéger l'accès aux infrastructures de production au travers de VPN ou de bastions SSH, et beaucoup d’organisations limitent encore ces points d'entrée à leur infrastructure interne. Lorsque l'organisation passe en mode télétravail à 100%, il faut forcément permettre l'accès depuis des adresses IP arbitraires, et se pose alors la question de surveiller ces accès pour détecter et bloquer rapidement une tentative d'accès malveillante.

Mise en place de l’intranet

Magazine
Marque
Linux Pratique
HS n°
Numéro
48
Mois de parution
septembre 2020
Domaines
Résumé

Le précédent chapitre a présenté, de manière sommaire et limitée aux besoins de ce dossier, les fonctionnalités d’Ansible. Nous allons donc maintenant revenir au cas d’étude en tant que tel et continuer la configuration de notre serveur RHEL, en utilisant désormais un playbook Ansible.

Covid-19, télétravail : mise en œuvre d’accès distants sécurisés pour se rapprocher du SI

Magazine
Marque
MISC
Numéro
111
Mois de parution
septembre 2020
Domaines
Résumé

Les mesures de confinement prises par le gouvernement mi-mars 2020 pour contrer la propagation du Covid-19 ont poussé les entreprises et administrations de toutes tailles à promouvoir le télétravail. Cet article présente le retour d’expérience d’une partie de l’équipe EDF en charge des « accès distants sécurisés » pendant cette période.

Premiers pas et prérequis

Magazine
Marque
Linux Pratique
HS n°
Numéro
48
Mois de parution
septembre 2020
Domaines
Résumé

Dans ce premier chapitre, nous allons aborder de nombreux sujets, allant du respect des conditions d’utilisation de « Red Hat Enterprise Linux » (RHEL), de l’installation du système, de sa connexion au réseau « Red Hat » jusqu’à la description de notre cas d’étude. Une fois ces prérequis évoqués et ces étapes préliminaires étudiées, nous passerons au vif du sujet en installant Ansible, que nous utiliserons dans le prochain chapitre afin de commencer à mettre en place notre serveur.