Centralized authentication using OpenLDAP/fr

Ce guide introduit les bases de LDAP et montre comment configurer OpenLDAP pour des besoin d'authentification dans un groupe d'ordinateurs.

Qu'est-ce que LDAP ?
LDAP signifie Lightweight Directory Access Protocol (Protocole Allégé pour accès à des annuaires). Basé sur X.500 il couvre la plupart de ses fonctions primaires, mais ne possède pas ses fonctions les plus ésotériques. Maintenant, qu'est-ce que ce X.500 et pourquoi LDAP existe-t-il ?

X.500 est un modèle pour les services d'annuaires dans de concept OSI. Il comprend des définitions d'espaces de noms et les protocoles pour interroger et mettre à jour l'annuaire. Néanmoins, X.500 s'est avérer être surdimensionné dans maintes situations. C'est là qu'entre en scène LDAP. Comme X.500 il procure un modèle données/espace de noms pour l'annuaire et un protocole. Cependant, LDAP est conçu pour tourner directement au-dessus de la pile TCP/IP. Considérez LDAP comme une version allégée de X:500.

Je n'ai pas saisi. Qu'est-ce qu'un annuaire ?
Un annuaire est une base de données spécialisée conçue pour des interrogations fréquentes mais avec des mises à jour moins fréquentes. Au contraire des bases de données générales, il ne comprend pas de prise en charge des transactions ou de fonctionnalités de retour en arrière. Les annuaires sont facilement répliqués pour en augmenter la disponibilité et la fiabilité. Lorsque les annuaires sont répliqués, des incohérences temporaires sont autorisées jusqu'à ce qu'elles soient synchronisées à la fin.

Comment l'information est-elle structurée ?
Toutes les informations dans un annuaire sont organisées de manière hiérarchisée. Même plus, si vous voulez entrer des données dans un annuaire, cet annuaire doit savoir comment ranger ces informations dans un arbre. Jetons un coup d'œil à une société imaginaire et un arbre similaire à Internet :

Structure de l'organisation de GenFic, une société Gentoo imaginaire

Comme vous n'entrez pas les données dans la base de données de cette façon ascii-artistique, chacun des nœuds d'un tel arbre doit être défini. Pour nommer de tels nœuds, LDAP utilise un schéma de nommage. La plupart des distributions LDAP (y compris OpenLDAP) contiennent déjà un certain nombre de schémas prédéfinis (et largement approuvés), tels que l'inetOrgPerson, un schéma fréquemment utilisé pour définir les utilisateurs que des machines Unix/Linux peuvent utiliser, appelés posixAccount (comptes posix). Notez qu'il existe des interfaces graphiques basées sur le web pour faciliter la gestion de LDAP : reportez-vous à Working with OpenLDAP pour une liste non exhaustive.

Les utilisateurs intéressés sont encouragés à lire le guide d'administration de OpenLDAP.

D'accord... Mais à quoi ça sert ?
LDAP peut être utilisé pour différentes choses. Ce document est centré sur la gestion centralisée d'utilisateurs, en conservant tous les comptes utilisateur dans un emplacement LDAP unique (ce qui ne veut pas dire qu'il est hébergé sur un serveur unique, LDAP prenant en charge une haute disponibilité et la redondance), bien que d'autres objectifs peuvent être atteints en utilisant LDAP également.


 * Infrastructure de clés publiques


 * Calendrier partagé


 * Carnet d'adresses partagé


 * Espace de stockage pour DHCP, DNS, ...


 * Directives de configuration des classes système (conserver la trace de la configuration de plusieurs serveurs)


 * Authentification centralisée (PosixAccount)



Configurer le serveur OpenLDAP
Commençez par installer OpenLDAP. Assurez-vous que les options de la variable USE, "berkdb, crypt, gnutls, ipv6, sasl, ssl, syslog" et "tcpd" sont utilisés.

OpenLDAP has a main user called "rootdn" (Root Distinguished Name), which is hardcoded in the application. Unlike the classic Unix root user, the rootdn user still needs to be assigned with proper permissions. The rootdn user may be used only in the context of the configuration, but it can also be used in the directory definition. In that case a user can authenticate himself as rootdn with either the configuration used password and the tree (directory-based) password.

User passwords (regardless if it is for rootdn users or others) for verification purposes can be stored as cleartext or hashed. Multiple different hash algorithms are available, but usage of weak algorythms (up to MD5) is not recommended. SHA is currently considered sufficiently cryptographically secure.

In the below command, a hashed value is created for a given password; the result of this command can be used in the configuration file, or in the internal directory definition of a user:

Éditez maintenant la configuration du serveur LDAP dans. Le fichier de configuration provient des sources originales de openLDAP. Ci-dessous, nous donnons un exemple de fichier de configuration pour le remplacer et démarrer.

/etc/openldap/slapd.conf

Pour une analyse plus détaillée du fichier de configuration, nous vous suggérons d'utiliser de le Guide de l'administrateur de OpenLDAP.

Vérifier la configuration
Après avoir personnalisé le fichier vous pouvez le tester à l'aide de la commande suivante :

Or, if you decide to use OLC:

Jouez sur le niveau de déverminage (le -d 1 ci-dessus) pour plus d'informations. Si tout se passe bien, vous verrez config file testing succeeded. Si une erreur s'est produite,  indiquera  le numéro de ligne (du fichier  )  à laquelle elle s'applique.

Note that since version 2.4.23, OpenLDAP moved from traditional flat config files to OLC (OnLineConfiguration, also known through its   structure) as default configuration method. One of benefits of using OLC is that the dynamic back-end (cn=config) doesn't require restart of server after updating the configuration. Existing users can migrate to the new configuration method by invoking  setting both -f and -F options. Traditionally OLC is stored in ldif back-end (which keep benefits of human-readability) in the directory. In Gentoo it is not required to convert the configuration yet, but support for the currently documented approach will be removed in the future.

If you want to be able to change OpenLDAP server's configuration, you must define at least write (or normally manage) access to.

The example below shows how to grant manage access to OLC (cn=config database) to the system administrator (root user) by adding the proper lines at the end of the file:

Running this command will transfer and translate the configuration. After that you are expected to update the configuration using specially prepared ldif files. And only if you aren't enough familiar with them, you can first edit and after that re-translate the  into. Don't forget to check the directory's permissions.

Pour plus d'instruction, reportez-vous aux commentaires en ligne des fichiers générés.

La ligne ci-dessous activera la méthode de configuration.

/etc/conf.d/slapd

Pour finir, créez la structure  :

Start slapd:

If it does not start then increase the loglevel variable in to 4 or more, and look in  for more information.

Example OLC-style update LDIFs
Some examples of updates on the OLC-style configuration are mentioned below.

For instance, to change the location of the OLC configuration directory:

fix-configs.ldif

To change the log level used by the OpenLDAP instance:

loglevel.ldif

In order to apply the changes, run the following command:

Configurer les outils client d'OpenLDAP
Éditez les fichiers de configuration du client LDAP. Ce fichier est lu par ldapsearch et les autres outils en ligne de commande de ldap.

Nous pouvons tester le serveur en service à l'aide de la commande suivante :

Si vous obtenez une erreur, essayez d'ajouter  pour augmenter la verbosité et résoudre votre problème.

Configuration du client pour une authentification centralisée
Il existe de nombreuses méthodes ou de nombreux outils à utiliser pour une authentification à distance. Quelques distributions disposent également de leur propre outil convivial de configuration. Ci-dessous, nous en présentons quelques uns sans ordre particulier. Il est possible des combiner des comptes d'utilisateurs locaux et des comptes autorisés de manière centralisée en même temps. Ceci est important parce que, par exemple, si le serveur LDAP n'est pas accessible, on peut toujours se connecter en tant qu'utilisateur root.


 * SSSD (Single Sign-on Services Daemon). Son premier rôle est de fournir un accès à une identité et à une ressources distante d'authentification à travers une structure commune qui assure la mise en cache et une assistance hors ligne au système. IL fournit des modules PAM et NSS, et dans le futur prendra en charge les interfaces D-Bus pour une information utilisateur étendue. Il procure aussi une base de données meilleure pour stocker les utilisateurs locaux et des données utilisateur étendues.


 * Utilise  pour se connecter au serveur  LDAP et s'authentifier. Les mots de passe ne sont pas envoyés en clair sur le réseau.


 * NSLCD (Name Service Look up Daemon ou démon de service de recherche de nom). Similaire à SSSD, mais plus ancien.


 * NSS (Name Service Switch ou commutateur de service ). Il utilise le module    traditionnel pour aller chercher les hachages des mots de passe  sur le réseau. Pour permettre aux utilisateurs de mettre leur mot de passe à jour, ceci doit être combiné avec la méthode.

Les deux premiers sont démontrés ci-après avec les options minimales de configuration pour que ça fonctionne.

Configuration PAM du client par la méthode SSSD
Voici une méthode plus directe. Les trois fichiers à éditer sont indiqués ci-dessous :

Ajoutez sss à la fin comme indiqué ci-dessous pour activer la recherche par le service système sssd. Une fois que vous avez terminé l'édition, démarrez le démon sssd.

Le dernier fichier est le plus critique. Ouvrez un terminal root supplémentaire en tant que secours avant d'éditer cela. Les lignes en gras ont été ajoutées pour activer l'authentification à distance. Notez l'utilisation de  pour la prise en charge de la création des répertoire home des utilisateurs.

Maintenant essayez de vous connecter depuis une autre machine.

Configurer le PAM client par la méthode du module pam_ldap
Tout d'abord, vous allez configurer PAM pour permettre l,autorisation LDAP. Installez afin que PAM prenne en charge l'autorisation LDAP, et   afin que votre système puisse coopérer avec les serveurs LDAP pour une information additionnelle (utilisée par  ).

Le dernier fichier est le plus critique. Ouvrez quelques terminaux root en tant que secours avant d'éditer ces lignes. Les lignes en gras ont été ajoutées pour activer l'authentification à distance.

/etc/pam.d/system-auth

Maintenant changez pour lire :

/etc/ldap.conf

Ensuite copiez le fichier  (de OpenLDAP) du serveur vers le client afin que le clients soient conscients de l'environnement LDAP :

Pour terminer, configurez les clients afin qu'ils interrogent LDAP sur les comptes du système :

/etc/nsswitch.conf

Si vous avez observé qu'une des lignes que vous avez collées dans votre fichier  était commentée (la ligne  ): vous n'en avez pas besoin sauf si vous voulez changer le mot de passe d'un utilisateur en mot de passe super-utilisateur. Dans un tel cas, vous devez envoyer en écho le mot de passe root à   en texte simple. Ceci est DANGEREUXet les droits devraient être mis à 600. Ce que vous pouvez désirer faire et c'est conserver ce fichier vierge et lorsque vous avez besoin de changer le mot de passe de quelqu'un qui est à la fois dans LDAP et dans  , y mettre le mot de passe pendant 10 secondes, le temps de changer le mot de passe de l'utilisateur, puis le retirer une fois la chose faite.

Migrer des données existantes vers ldap
Configurer OpenLDAP pour une administration centralisée et la gestion d'items Linux/Unix communs n'est pas chose facile, mais grâce à quelques outils et scripts disponibles sur Internet, migrer un système conçu pour être administré en tant que système unique vers un système à gestion centralisée basé sur LDAP n'est pas difficile.

Rendez-vous sur http://www.padl.com/OSS/MigrationTools.html et recherchez-y les scripts. Vous avez besoin des outils de migration et du script.

Ensuite, extrayez les outils et copiez le script  dans l'emplacement d'extraction :

L'étape suivante est maintenant de migrer les informations de votre système vers OpenLDAP. Le script le fera pour vous, après que vous lui ayez fourni l'information concernant votre structure LDAP et votre environnement.

Au moment de l'écriture, les outils ont besoin des entrées suivantes :

L'outil vous demandera aussi quels comptes et quelles configurations vous voulez migrer.

Haute disponibilité
Pour configurer la réplication des changements à travers de multiples systèmes LDAP. Le réplication avec OpenLDAP est, dans ce guide, configurée en uilisant un compte dédié à la réplication  qui a des droits de lecture et écriture sur le serveur LDAP primaire et qui tire les changements du serveur primaire vers le serveur secondaire.

Cette configuration est ensuite réfléchie, autorisant le serveur LDAP secondaire à fonctionner comme serveur primaire. Grâce à la structure interne d'OpenLDAP, les changements ne sont pas ré-appliqués s'ils sont déjà dans la structure LDAP.

Configurer la réplication
Pour configurer la réplication, commencez par configurer un deuxième serveur OpenLDAP, de façon similaire à ce qui a été décrit ci-dessus. Néanmoins, assurez-vous que dans le fichier de configuration,


 * sync replication providerpointe sur other system.


 * L'identifiant (serverID) est différent pour chacun des serveurs OpenLDAP.

Créez ensuite le compte de synchronisation. Créez un fichier LDIF (le format utilisé en tant que données d'entrée pour les serveurs LDAP) et ajoutez le à chaque serveur LDAP.

Permissions OpenLDAP
Si vous regardez le fichier  vous verrez que vous pouvez spécifier les ACL (permissions si vous préférez) de ce que les utilisateurs peuvent être lire/écrire :

/etc/openldap/slapd.conf

Ceci vous donne accès à tout ce qu'un utilisateur est capable de changer. Si ce sont vos données, alors vous y avez accès en écriture ; si ce sont des données d'un autre utilisateur alors vous pouvez les lire ; des personnes non identifiées peuvent envoyer un mot de passe de connexion pour se connecter. Il y a quatre niveaux qui sont, en les rangeant du plus faible au plus fort :

L'ACL suivante est un peu plus sécurisée parce qu'elle empêche le lire le mot de passe shadowed des autres utilisateurs :

/etc/openldap/slapd.conf

Cet exemple donne à root et à John un accès en lecture/écriture à tout ce qui se trouve dans l'arbre ci-dessous. Ceci permet aussi aux utilisateurs de changer leur propre. Quant à l'instruction finale, tout autre personne possède une possibilité de recherche, ce qui signifie qu'elle peut remplir un filtre de recherche. Maintenant, vous pouvez avoir de multiples ACLs mais, en règle générale, elles sont traitées du bas vers le haut, c'est pourquoi le niveau supérieur devrait être le plus restrictif.

Maintenir l'annuaire
Vous pouvez commencer à utiliser l'annuaire pour l'authentification des utilisateurs dans apache/proftpd/qmail/samba. Vous pouvez le gérer avec LAM (Ldap Account Manager), phpldapadmin, diradm, jxplorer, ou lat, qui procurent des interfaces de gestion conviviales.

Remerciements
Nous tenons à remercier Matt Heler qui nous a prêté sa machine pour réaliser ce guide. Merci aussi aux gars très compétents de #ldap @ irc.freenode.net.