Mon réseau

Mon réseau d’entreprise

14.4 Utilisez LDAP pour gérer les utilisateurs

Précédent   Suivant

Le protocole LDAP Lightweight Directory Access Protocol est un protocole d’annuaire qui facilite la diffusion d’informations en réseau. Il est utilisé, en particulier, pour diffuser les logins d’utilisateurs aux stations de travail du réseau local. Il peut être utilisé pour diffuser beaucoup d’autres types de données.

Nous allons maintenant montrer comment gérer les utilisateurs en réseau. Leur définition reposera sur un serveur central. Chaque ordinateur client aura accès aux mêmes informations. En particulier, la modification des mots de passe sera effectuée sur une machine et prendra effet sur toutes.

Il faudra donc mettre en place un serveur, le configurer, puis indiquer aux clients qu’ils peuvent utiliser ce server pour identifier et autoriser une connexion.

14.4.1 Installation du serveur

Le serveur utilisé sera openldap. Le nom du paquet est différent, c’est slapd. Il faut donc installer ce paquet sur le serveur. Il faut définir un nom de domaine. Ce nom peut être le même que celui du serveur de nom, par exemple : luminy.univ-amu.fr ou indépendant. Nous utiliserons osaka.rtlum pour le réseau opérationnel local.

Il faut alors fournir un mot de passe et l’installation se termine. Il est alors possible de gérer directement les fichiers de configuration ou reconfigurer le paquet. Nous allons suivre cette dernière méthode.

LA commande est dpkg-reconfigure slapd

  • 1. Cela commence par une double négation : « il ne faut pas omettre la configuration ». Réponse : non.

  • 2. Nom de domaine : osaka.rtlum.

  • 3. L’organisation sera osaka.

  • 4. Le mot de passe administrateur sera sérieux.

  • 5. Le module de base de données à utiliser sera MDB.

  • 6. Selon votre décision, la base de données sera ou non purgée lors de la suppression du paquet.

  • 7. Il faut déplacer l’ancienne base de données.

Tout est prêt pour accueillir les nouveaux utilisateurs. Il est néanmoins conseillé de vérifier si la création s’est bien passée. Pour cela, nous allons ajouter quelques outils en ligne de commande : le paquet ldap-utils.

# ldapsearch -x -b dc=osaka,dc=rtlum
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# osaka.rtlum
dn: dc=osaka,dc=rtlum
objectClass: top
objectClass: dcObject
objectClass: organization
o: osaka
dc: osaka

# admin, osaka.rtlum
dn: cn=admin,dc=osaka,dc=rtlum
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2

Le résultat semble bon.

Les bases de données ldap peuvent être utilisées pour de nombreux usages. Nous allons l’utiliser pour gérer les utilisateurs. Il faut donc adapter la structure pour des utilisateurs. Nous allons commencer par des humains (People) et des groupes.

Nous allons créer le fichier suivant (struct.ldif) (LDAP Data Interchange Format).

dn: ou=People,dc=osaka,dc=rtlum
objectClass: organizationalUnit
ou: People

dn: ou=Groups,dc=osaka,dc=rtlum
objectClass: organizationalUnit
ou: Groups

Une fois le fichier créé, il faut indiquer au serveur slapd les commandes :

# ldapadd -c -x -D cn=admin,dc=osaka,dc=rtlum -f struct.ldif -W
Enter LDAP Password:
adding new entry "ou=People,dc=osaka,dc=rtlum"

adding new entry "ou=Groups,dc=osaka,dc=rtlum"

Pour chaque paragraphe, le serveur indique le succès de l’opération. Nous pouvons maintenant créer des utilisateurs. Pour chaque utilisateur, il est possible de créer un fichier ldif qui contient ses informations.

dn: uid=gandalf,ou=People,dc=osaka,dc=rtlum
uid: gandalf
cn: gandalf
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}$6$rlWmT3BJ$ZqG...longue chaîne chiffrée
shadowLastChange: 17351
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 3001
gidNumber: 3000
homeDirectory: /users/magic/gandalf
gecos: Gandalf The Grey, directeur secteur magie

Les informations sont similaires à celles du fichier /etc/passwd. Le mot de passe peut être copié depuis le fichier shadow d’un autre compte. Il peut aussi être généré par la commande mkpasswd du paquet whois.

mkpasswd toto
$y$j9T$JbbpuYet6tC2... (plus long)

La commande est la même que précédement :

ldapadd -c -x -D cn=admin,dc=osaka,dc=rtlum -f gandalf.ldif -W
Enter LDAP Password:
adding new entry "uid=gandalf,ou=People,dc=osaka,dc=rtlum"

Les caractères accentués risquent de générer une erreur de syntaxe. Il faut pouvoir modifier un élément. Pour cela, il faut indiquer l’élément à modifier.

dn: uid=gandalf,ou=People,dc=osaka,dc=rtlum
changetype: modify
replace: gecos
gecos: Gandalf The White, directeur secteur magie

La première ligne identifie l’enregistrement à modifier. La deuxième demande une modification, la troisième indique le champ à modifier, la valeur vient ensuite.

# ldapadd -c -x -D cn=admin,dc=osaka,dc=rtlum -f gw.ldif -W
Enter LDAP Password:
modifying entry "uid=gandalf,ou=People,dc=osaka,dc=rtlum"

Pour supprimer un utilisateur, il fait indiquer delete comme changement :

dn: uid=gandalf,ou=People,dc=osaka,dc=rtlum
changetype: delete

Et toujours la même commande :

# ldapadd -c -x -D cn=admin,dc=osaka,dc=rtlum -f dg.ldif -W
deleting entry "uid=gandalf,ou=People,dc=osaka,dc=rtlum"

14.4.2 Installation d’un client LDAP

Il faut commencer par vérifier la connexion au serveur. Pour cela, installer le paquet ldap-utils.

Il est alors possible de tester la connexion en utilisant la commande de recherches :

ldapsearch -x -b dc=osaka,dc=rtlum -H ldap://serveur

Note : Vous pouvez trouver l’option -h, celle ci est dépréciée et ne fonctionnera plus longtemps. Il faut maintenant utiliser l’option -H avec une URL.

Ensuite, il faut installer le serveur sssd. Pour finaliser la configuration il faut éditer le fichier /etc/sssd/sssd.conf (en l’adaptant, bien sûr). Le fichier doit appartenir à root et posséder les droits 600.

Le démon de services de sécurité pour le system (SSSD - System Security Services Daemon) fournit les services pour accéder à des mécanismes d’authentification de de partage de fichiers. Le code et la documentation sont disponibles.

[sssd]
config_file_version = 2
domains = fevrier.rtS3
services = nss, pam

[domain/fevrier.rtS3]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://10.4.163.2
cache_credentials = True
ldap_search_base = dc=fevrier,dc=rtS3

N’oubliez pas de relancer le serveur après modification.

Ensuite, il est possible de valider la configuration en utilisant la commande getent passwd qui doit lister les comptes locaux et LDAP. Ou juste getent passwd gandalf

Installez le paquet libpam-ldap.

La connexion d’un utilisateur est alors possible. Il faut cependant que l’utilisateur dispose d’un répertoire personnel, soit local, soit fourni par un serveur NFS.

14.4.3 Sauvegardez votre serveur LDAP

Un serveur n’est pas bien installé sans un PRA (Plan de Reprise d’Activité). Il faut pouvoir le reconstruire si l’ordinateur est détruit. Pour LDAP, il y a plusieurs stratégies :

  • sauvegarder la machine virtuelle ;

  • sauvegarder le serveur slapd.

C’est plus simple de prendre un snapshot de la machine virtuelle et de sauvegarder cette image. Cette méthode a l’avantage de fonctionner de la même manière quelque soit le service hébergé. Par contre, il y a toujours le risque d’obtenir une version inconsistente de la base de données si les transactions ne sont pas abouties. De plus, cette méthode est assez lourde en espace disque.

Le serveur slapd fournit les commandes permettant de sauvegarder la configuration de la base et les enregistrements :

service slapd stop
slapcat -n 0 > backupLDAPconfig.ldif
slapcat -n 1 > domaine.ldif
service sldapd start

Ensuite, pour reconstruire l’image, il faut installer un serveur neuf et ajouter la version sauvegardée. Il faut que :

  • Le service slapd soit arrêté ;

  • Le répertoire /etc/ldap/slapd.d/ doit être vide ;

  • Le répertoire /var/lib/ldap/ doit être vide ;

  • Après avoir reconstitué les fichiers par la commande slapadd, il faut que les fichiers appartiennent à l’utilisateur openldap.

service sldapd stop
slapadd -F /etc/ldap/slapd.d -n 0 -l backupLDAPconfig.ldif
slapadd -F /etc/ldap/slapd.d -n 1 -l domaine.ldif
service sldapd start

14.4.4 Ajout du chiffrement StartTLS

L’utilisation du chiffrement se fait sur le port classique ldap. La communication commence en clair, puis le mode chiffré démarre. D’où le nom Start TLS. Merci à Digital Ocean.

L’utilisation du chiffrement avec LDAP peut s’utiliser avec un port distinct (WKP 636). La connexion est complétement chiffrée. Cette méthode semble être dépréciée.

14.4.4.1 Déterminez le nom d’hôte FQDN

Cette méthode utilise les certificats. Il faut donc que la résolution du nom coïncide avec le certificat. La machine, et ses clientes, doivent donc connaître son nom et son FQDN (Fully Qualified Domain Name).

Le nom complet, défini dans le fichier /etc/hosts, s’obtient par la commande :

hostname -f

14.4.4.2 Installation des paquets de chiffrement

Il faut installer les paquets pour le chiffrement.

apt-get install gnutls-bin ssl-cert

Avec la Debian Trixie, le chiffrement utilise directement openssl.

14.4.4.3 Création des modèles

Nous allons créer deux certificats : un pour l’autorité de certification et un pour le service LDAP. Il faut commencer par créer les fichiers qui fournissent les informations pour ces certificats :

mkdir /etc/ssl/templates

Le modèle de l’autorité :

cat < /etc/ssl/templates/ca_server.conf
cn = RtLum's LDAP Server CA
ca
cert_signing_key
EOF

Puis celui du service LDAP :

cat > /etc/ssl/templates/ldap_server.conf <

14.4.4.4 La clef et le certificat de la CA
certtool -p --outfile /etc/ssl/private/ca_server.key
certtool -s --load-privkey /etc/ssl/private/ca_server.key --template /etc/ssl/templates/ca_server.conf --outfile /etc/ssl/certs/ca_server.pem

14.4.4.5 La clef et le certificat du service LDAP
certtool -p --sec-param high --outfile /etc/ssl/private/ldap_server.key
certtool -c --load-privkey /etc/ssl/private/ldap_server.key --load-ca-certificate /etc/ssl/certs/ca_server.pem --load-ca-privkey /etc/ssl/private/ca_server.key --template /etc/ssl/templates/ldap_server.conf --outfile /etc/ssl/certs/ldap_server.pem

Il faut maintenant autoriser LDAP à gérer les clefs :

usermod -aG ssl-cert openldap
chown :ssl-cert /etc/ssl/private/ldap_server.key
chmod 640 /etc/ssl/private/ldap_server.key

Puis configurer LDAP pour qu’il utilise ces clefs :

pitet un reboot...


    mkdir -p /tmp/LEC

    cat > /tmp/LEC/addcerts.ldif <

Pour vérifier la configuration du serveur, il est possible d’utiliser la commande slapcat :

slapcat -n 0 | grep /etc/ssl
olcTLSCACertificateFile: /etc/ssl/certs/ca_server.pem
olcTLSCertificateFile: /etc/ssl/certs/ldap_server.pem
olcTLSCertificateKeyFile: /etc/ssl/private/ldap_server.key

14.4.4.6 Test du client sur le serveur

Jusqu’ici, rien n’est véritablement prouvé. Le serveur LDAP doit pouvoir être son propre client, pour cela, il faut modifier la configuration de LDAP (client).

Copier le certificat pour LDAP :

cp /etc/ssl/certs/ca_server.pem /etc/ldap/ca_certs.pem

Modifier le fichier /etc/ldap/ldap.conf :

TLS_CACERT /etc/ldap/ldap.conf

Puis vérifier qu’il soit possible de se connecter en anonyme :

ldapwhoami -H ldap:// -x -ZZ
anonymous

Précédent   Suivant