Installation et configuration d’un annuaire OpenLDAP

Magazine
Marque
Linux Pratique
Numéro
115
Mois de parution
septembre 2019
Spécialité(s)


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).



Article rédigé par

Par le(s) même(s) auteur(s)

Intégration d’ownCloud pour servir un partage de fichiers existant

Magazine
Marque
Linux Pratique
Numéro
136
Mois de parution
mars 2023
Spécialité(s)
Résumé

Le logiciel libre ownCloud est une solution de partage et de stockage des fichiers en mode web. Avec la profusion des plateformes commerciales de ce type (Google Drive, iCloud, Dropbox, etc.), l’accès web aux fichiers est devenu le nouveau standard. Dans cet article, nous allons explorer une méthode pour interfacer cette méthode d’accès aux fichiers avec un serveur NFS (Network File System) existant.

Équilibrage de charge avec IPVS

Magazine
Marque
Linux Pratique
HS n°
Numéro
55
Mois de parution
octobre 2022
Spécialité(s)
Résumé

IP Virtual Server (IPVS) est un équilibreur de charge agissant au niveau 4 du modèle OSI. Il est implémenté sous forme d’un module noyau s’appuyant sur le framework Netfilter, ce qui le rend efficace sur l’équilibrage des services par rapport à leurs ports TCP/UDP, mais totalement agnostique aux protocoles applicatifs transportés (LDAP, HTTP, etc.).

Libre-service de machines virtuelles avec OpenNebula

Magazine
Marque
Linux Pratique
Numéro
130
Mois de parution
mars 2022
Spécialité(s)
Résumé

Dans un article précédent, nous avons mis en place une infrastructure OpenNebula basique [1]. Nous allons maintenant configurer cette plateforme pour proposer aux utilisateurs un guichet de libre-service de machines virtuelles. L’idée est que les utilisateurs puissent créer eux-mêmes leurs machines virtuelles.

Les derniers articles Premiums

Les derniers articles Premium

Petit guide d’outils open source pour le télétravail

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Ah le Covid ! Si en cette période de nombreux cas resurgissent, ce n’est rien comparé aux vagues que nous avons connues en 2020 et 2021. Ce fléau a contraint une large partie de la population à faire ce que tout le monde connaît sous le nom de télétravail. Nous avons dû changer nos habitudes et avons dû apprendre à utiliser de nombreux outils collaboratifs, de visioconférence, etc., dont tout le monde n’était pas habitué. Dans cet article, nous passons en revue quelques outils open source utiles pour le travail à la maison. En effet, pour les adeptes du costume en haut et du pyjama en bas, la communauté open source s’est démenée pour proposer des alternatives aux outils propriétaires et payants.

Sécurisez vos applications web : comment Symfony vous protège des menaces courantes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les frameworks tels que Symfony ont bouleversé le développement web en apportant une structure solide et des outils performants. Malgré ces qualités, nous pouvons découvrir d’innombrables vulnérabilités. Cet article met le doigt sur les failles de sécurité les plus fréquentes qui affectent même les environnements les plus robustes. De l’injection de requêtes à distance à l’exécution de scripts malveillants, découvrez comment ces failles peuvent mettre en péril vos applications et, surtout, comment vous en prémunir.

Bash des temps modernes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les scripts Shell, et Bash spécifiquement, demeurent un standard, de facto, de notre industrie. Ils forment un composant primordial de toute distribution Linux, mais c’est aussi un outil de prédilection pour implémenter de nombreuses tâches d’automatisation, en particulier dans le « Cloud », par eux-mêmes ou conjointement à des solutions telles que Ansible. Pour toutes ces raisons et bien d’autres encore, savoir les concevoir de manière robuste et idempotente est crucial.

Présentation de Kafka Connect

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Un cluster Apache Kafka est déjà, à lui seul, une puissante infrastructure pour faire de l’event streaming… Et si nous pouvions, d’un coup de baguette magique, lui permettre de consommer des informations issues de systèmes de données plus traditionnels, tels que les bases de données ? C’est là qu’intervient Kafka Connect, un autre composant de l’écosystème du projet.

Les listes de lecture

8 article(s) - ajoutée le 01/07/2020
Découvrez notre sélection d'articles pour faire vos premiers pas avec les conteneurs, apprendre à les configurer et les utiliser au quotidien.
11 article(s) - ajoutée le 02/07/2020
Si vous recherchez quels sont les outils du DevOps et comment les utiliser, cette liste est faite pour vous.
8 article(s) - ajoutée le 02/07/2020
Il est essentiel d'effectuer des sauvegardes régulières de son travail pour éviter de perdre toutes ses données bêtement. De nombreux outils sont disponibles pour nous assister dans cette tâche.
Voir les 60 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous