Merci pour cet article très interessant, je vais m'y atteler!
Le mardi 13 janvier 2009 21:33:47, vous avez écrit : > On Tue, Jan 13, 2009 at 05:32:27PM +0100, > Kevin C <[email protected]> wrote > > a message of 47 lines which said: > > J'ai ajouté ça dans /etc/pam.d/system-password > > Non, cela ne concerne que le changement de mot de passe, pas la > connexion. > > Comptes Unix stockés sur LDAP > > http://www.bortzmeyer.org/comptes-unix-ldap.html > > ---------------------------- > > Si on gère de nombreux ordinateurs multi-utilisateurs, on se pose > forcément la question de la centralisation des *comptes*, des > informations sur les utilisateurs. Il est très pénible de devoir créer > un compte sur N machines dès qu'un nouvel employé arrive ou de devoir > se rappeler des M mots de passe précédents parce qu'on ne les a pas > changé sur toutes les machines. Il existe plusieurs solutions > techniques à ce problème, et je présente ici l'utilisation de LDAP pour > gérer une base centralisée de comptes, notamment pour des machines > Unix. > > LDAP est un protocole client-serveur d'interrogation d'un annuaire. Il > offre donc quelques analogies avec le DNS. Mais son histoire est très > différente. Issu à l'origine du projet X.500, il en est aujourd'hui le > seul survivant. LDAP est normalisé dans les RFC 4510 et suivants. > > LDAP est juste un protocole, il n'impose rien sur le mécanisme de > stockage des données, dont on dira un mot au moment de configurer le > *serveur*. Mais nous allons commencer par la configuration du *client*, > car il y a davantage de clients que de serveurs. > > Nous avons donc une machine Unix (en l'occurrence une Debian) qui a une > base d'utilisateurs traditionnelle (le fichier /etc/passwd) et qui > voudrait l'enrichir avec les informations venues du serveur LDAP > ldap.example.org. L'administrateur de ce serveur nous a donné le nom du > serveur et la *base* à utiliser, dc=example,dc=org (contrairement au > DNS, LDAP ne part pas de la racine mais d'une base, souvent dérivée > d'un nom de domaine). L'administrateur nous dira également la version > utilisée (la version 3 reste aujourd'hui la seule) et le mécanisme > d'authentification auprès du serveur (contrairement au DNS, un serveur > LDAP peut nécessiter une authentification des clients), l'usage ou non > de TLS, etc. Les objets LDAP décrivant les utilisateurs seront > probablement de la *classe* posixAccount. > > Que faut-il connaitre sur LDAP encore ? Outre les références à la fin > de cet article, nécessaires pour tout savoir, notons simplement que > chaque objet stocké dans la base LDAP a un DN ("Distinguished Name") et > que ce DN l'identifie de manière unique. Le DN est formé de plusieurs > composants, chaque composant étant un doublet attribut=valeur. Par > exemple, uid=bleriot,ou=People,dc=example,dc=org est un DN. > > Utilisons le client ldapsearch (un outil de test, comme dig pour le > DNS ; sur Debian, il est dans le paquetage ldap-utils) pour tester que > notre machine peut joindre le serveur : > > % ldapsearch -h ldap.example.org -x -b dc=example,dc=org \ > '(objectClass=posixAccount)' > ... > dn: cn=Louis Bleriot,ou=People,dc=example,dc=org > objectClass: posixAccount > objectClass: shadowAccount > cn: Louis Bleriot > sn: bleriot > uid: bleriot > uidNumber: 1011 > homeDirectory: /home/bleriot > gecos: Louis Bleriot > loginShell: /usr/bin/zsh > ... > (-x veut dire accès anonyme, sans authentification) > Une fois qu'on est sûr du serveur, nous pouvons commencer à configurer > le client. > > > Pour éviter de mettre du code LDAP dans chaque application qui fait de > l'authentification (une liste pas du tout limitative nous donne sshd, > login, sudo, etc), Unix utilise en général le système PAM dans lequel > l'application appelle un greffon PAM pour les différentes opérations. > PAM à son tour charge, selon sa configuration, du code LDAP (ou bien > utilisant d'autres techniques d'authentification). > > On va donc installer le support LDAP de PAM. Sur une Debian, c'est le > paquetage libpam-ldap. Il faut le configurer pour lui donner les > informations que nous a transmises l'administrateur système. Cela se > fait dans /etc/pam_ldap.conf dont voici les extraits pertinents : > > # On peut aussi indiquer le serveur par la directive "uri" mais je n'ai > # jamais réussi à la faire fonctionner > host ldap.example.org > base dc=example,dc=org > # Ne pas oublier ces trois lignes, commentées par défaut ! > nss_base_passwd ou=People,dc=example,dc=org?one > nss_base_shadow ou=People,dc=example,dc=org?one > nss_base_group ou=Group,dc=example,dc=org?one > # Pour savoir quel couple attribut/valeur ajouter à la base (ici > ou=People), # demander à l'administrateur du serveur LDAP. > On configure ensuite PAM pour > utiliser LDAP, dans /etc/pam.d. Chaque application > qui authentifie a un fichier dans ce répertoire mais la plupart des > fichiers se contentent d'inclure les fichiers communs comme > common-auth. Éditons > common-auth pour se servir de LDAP (l'ordre du > fichier est significatif, c'est celui dans lequel on utilisera les > différentes techniques) : > > > # Utiliser LDAP > auth sufficient pam_ldap.so > # Garder une authentification traditionnelle au cas où... > auth required pam_unix.so nullok_secure > > Même chose pour common-account et > common-password. > > Sommes-nous prêts, désormais, à authentifier ? Pas tout à fait. PAM ne > fait que l'authentification. Mais une base d'utilisateurs, sur Unix, > sert à bien d'autres choses. Par exemple, même une commande aussi > simple que ls -l va nécessiter de traduire les uid numériques que > contient le fichier en noms alphabétiques. Unix fait pour cela appel à > un autre système, dont la configuration doit se faire indépendamment de > LDAP, NSS (le projet NSS a été décrit à l'origine dans le RFC 2307). > > Installons donc NSS LDAP, c'est le paquetage Debian libnss-ldap. Puis > configurons-le dans /etc/libnss-ldap.conf : > > # On peut aussi indiquer le serveur par la directive "uri" mais je n'ai > # jamais réussi à la faire fonctionner > host ldap.example.org > base dc=example,dc=org > # rootbinddn ne fonctionne pas pour moi et n'est de toute façon pas > # très utile > #rootbinddn cn=admin,dc=example,dc=org > # Ne pas oublier ces trois lignes, commentées par défaut ! > nss_base_passwd ou=People,dc=example,dc=org?one > nss_base_shadow ou=People,dc=example,dc=org?one > nss_base_group ou=Group,dc=example,dc=org?one > # Pour savoir quel couple attribut/valeur ajouter à la base (ici > ou=People), # demander à l'administrateur du serveur LDAP. > > Puis indiquons à NSS qu'il doit utiliser LDAP, ce qui se fait dans > /etc/nsswitch.conf : > > > passwd: compat ldap > group: compat ldap > shadow: compat ldap > > Maintenant, tout devrait marcher. Il est temps de tester. Commençons > par demander la liste des comptes : > > > % getent passwd > ... > bleriot:x:1011:110:Louis Bleriot, Test account:/home/bleriot:/usr/bin/zsh > > On doit voir apparaitre les comptes purement LDAP. On peut aussi > utiliser des commandes qui affichent des informations sur les > utilisateurs : > > > % finger bleriot > Login: bleriot Name: Louis Bleriot > Directory: /home/bleriot Shell: /usr/bin/zsh > Office: Test account > ... > > Ou bien (*attention*, après la modification de > nsswitch.conf, les applications qui tournent > doivent être redémarrées. finger était lancé > après mais le shell a sans doute été lancé avant et c'est lui qui > interpréte le tilde) : > > > % cd ~bleriot > % pwd > /home/bleriot > > > > Enfin, il ne reste qu'à s'authentifier (même avertissement : il faut > redémarrer les programmes qui utilisent NSS comme le serveur SSH). > Normalement, on doit pouvoir désormais se connecter et travailler comme > si on avait un compte local. > > Et si cela ne marche pas ? Il faut tester avec ldapsearch, regarder les > journaux du serveur SSH et, si on y a accès, regarder le journal du > serveur LDAP (/var/log/syslog par défaut sur Debian). On peut aussi se > servir d'autres clients LDAP comme ldapsh > (http://ldapsh.sourceforge.net/) qui permet de naviguer dans la base > LDAP comme si c'était un système de fichiers, ou comme l'excellent > programme graphique GQ (http://gq-project.org/). > > D'autres programmes peuvent s'authentifier avec LDAP. Par exemple, le > SGBD PostgreSQL a une telle option > (http://www.postgresql.org/docs/current/static/auth-methods.html#AUTH-LD > AP) qu'on peut mettre dans son pg_hba.conf. Elle a l'air simple mais je > ne suis jamais arrivé à obtenir de PostgreSQL des requêtes LDAP > correctes, même après avoir beaucoup regardé ce que recevait le serveur > LDAP. L'authentification LDAP de PostgreSQL est en outre assez rigide > (pas de filtres, par exemple). Donc, j'utilise plutôt l'option PAM qui > tire profit de la configuration ci-dessus : > > hostssl all USERNAME 192.0.2.240/28 pam > > > Maintenant, si le système d'exploitation utilisé n'est pas Debian, mais > FreeBSD ? Depuis quelques années, FreeBSD dispose également de PAM et > de NSS. La démarche est la suivante (elle est bien documentée dans > "LDAP Authentication > (http://www.freebsd.org/doc/en/articles/ldap-auth/index.html)" : > * Installer les ports pam_ldap et nss_ldap. > * Configurer le client LDAP en /usr/local/etc/openldap/ldap.conf. > * Configurer PAM en /etc/pam.d. > * Configurer NSS en /usr/local/etc/nss_ldap.conf et /etc/nsswitch.conf. > > > Une fois les ports installés, il faut indiquer au client LDAP de la > machine où trouver les informations. Voici un exemple de > /usr/local/etc/openldap/ldap.conf : > > BASE dc=example,dc=org > URI ldap://ldap.example.org/ > pam_login_attribute uid > > On a indiqué la base LDAP, l'URI du serveur > LDAP et l'attribut LDAP qui servira de nom au compte Unix > (uid). > > Ensuite, il faut configurer PAM dans chaque application, via les > fichiers en /etc/pam.d. Le port FreeBSD de PAM n'inclus pas de fichiers > communs, hélas, et il faut donc configurer un fichier par application > (peut-être peut-on les réécrire avec des directives incluant un fichier > commun, je n'ai pas essayé). Par exemple, pour SSH, on édite > /etc/pam.d/ssh ainsi : > > auth sufficient /usr/local/lib/pam_ldap.so no_warn > ... > auth required pam_unix.so no_warn > try_first_pass > > account required /usr/local/lib/pam_ldap.so no_warn > ignore_authinfo_unavail ignore_unknown_user ... > account required pam_unix.so > > > > Maintenant, on peut se connecter mais, pour avoir tous les services de > noms, il faut NSS. On édite /usr/local/etc/nss_ldap.conf ainsi : > > host ldap.example.org > base dc=example,dc=org > nss_base_passwd ou=People,dc=example,dc=org?one > nss_base_shadow ou=People,dc=example,dc=org?one > nss_base_group ou=Group,dc=example,dc=org?one > > Et il faut indiquer à la libc d'utiliser LDAP > en modifiant /etc/nsswitch.conf : > > > group: files ldap > passwd: files ldap > > Désormais, tout marche, notre machine FreeBSD peut utiliser tous les > services de noms que fournit LDAP. > > > Et sur le serveur ? Si on doit le configurer, s'il n'a pas déjà été > fait, voici les étapes. > > On install le logiciel serveur d'OpenLDAP (paquetage slapd). Pour sa > configuration, on édite /etc/ldap/slapd.conf notamment pour y mettre : > > suffix "dc=example,dc=org" > > et s'assurer que les permissions (directives > access) comportent bien notre base. > > Si on a un schéma LDAP spécifique, il faut aussi le mettre dans ce > fichier : > > include /etc/ldap/schema/example.schema > > On relance le serveur, on vérifie qu'il tourne et qu'on peut > l'interroger avec ldapsearch. > > Sa base est actuellement vide, il nous faut donc créer des comptes. Il > existe plusieurs solutions, le choix dépend des circonstances. > * Si on a une liste d'utilisateurs dans une autre base de données, on > peut écrire un programme qui exporte cette base en format LDIF et > charger ensuite le fichier LDIF, serveur arrêté, avec slapadd < > example.ldif. > * Si on veut procéder entrée par entrée, on peut aussi utiliser un > fichier LDIF (comme celui-ci (en ligne sur > http://www.bortzmeyer.org/files/yet-another-account.ldif)) et le > charger via le protocole LDAP, avec ldapadd -W -D > 'cn=admin,dc=example,dc=org' -f yet-another-account.ldif, ce qui ne > nécessite pas d'arrêter le serveur et permet de travailler depuis une > autre machine. > * On peut aussi utiliser un programme local de création de compte comme > ce petit programme (en ligne sur > http://www.bortzmeyer.org/files/addluser.py) écrit en Python, avec la > bibliothèque Python-LDAP (http://python-ldap.sourceforge.net). Ce > programme dépend d'un fichier de configuration (voici un exemple (en > ligne sur http://www.bortzmeyer.org/files/ldapsimpletools.ini)) et > s'utilise en tapant simplement addluser USERNAME (il demandera ensuite > les autres informations nécessaires). Il n'existe pas de tel programme > « standard » car chaque site a son propre modèle de données et ses > propres règles. > > Une fois le ou les comptes créés, il faut évidemment tester que les > clients LDAP puissent s'en servir, comme indiqué plus haut, lors de la > configuration du client. > > Détruire un compte peut également se faire de plusieurs façons : > * Avec ldapdelete en indiquant le DN :ldapdelete -W -D > 'cn=admin,dc=example,dc=org' -x 'cn=Louis Bleriot,ou=People,dc=example, > dc=org'. > * Avec addluser et son option -r (comme "remove"). > > Il peut être pratique, notamment pour déboguer des problèmes avec un > client récalcitrant, de demander au serveur d'écrire dans son journal > toutes les requêtes LDAP reçues. Cela ralentit le serveur, cela peut > être très indiscret, mais c'est un bon outil de test. Il faut pour cela > modifier la directive loglevel de slapd.conf : > > # Read slapd.conf(5) for possible values > loglevel 256 > > On trouvera alors dans le journal des informations très indiscrètes comme > (au moment d'une connexion SSH de l'utilisateur bleriot) : > > > Mar 26 10:15:05 lilith slapd[15932]: conn=410 op=1 > SRCH base="ou=People,dc=example,dc=org" > scope=1 deref=0 filter="(uid=bleriot)" > > (Un petit mot sur le journal : comme chaque requête LDAP est notée, > cela peut ralentir sérieusement le serveur. Vérifiez bien dans la > configuration de syslog que l'écriture est > asynchrone, en mettant un tiret devant le nom du fichier journal.) > > N'oubliez pas les sauvegardes ! La perte de la base de données du > serveur LDAP peut être catastrophique. Les données étant stockées par > OpenLDAP dans un fichier binaire, il est prudent de les sauvegarder en > mode texte, avec le format LDIF. On peut copier toute la base avec > slapcat . > > Une fois les sauvegardes faites et vérifiées, vous pouvez aussi vous > préoccupper des performances du serveur LDAP. echoping > (http://echoping.sourceforge.net) a un greffon LDAP qui permet de > tester les perfomances dudit serveur : > > % echoping -n 5 -m ldap ldap.example.org \ > -b ou=People,dc=example,dc=org -s one -r '(uid=bleriot)' > Elapsed time: 0.000606 seconds > Elapsed time: 0.000493 seconds > Elapsed time: 0.000446 seconds > Elapsed time: 0.000425 seconds > Elapsed time: 0.000393 seconds > --- > Minimum time: 0.000393 seconds (651399 bytes per sec.) > Maximum time: 0.000606 seconds (422442 bytes per sec.) > Average time: 0.000472 seconds (542373 bytes per sec.) > Standard deviation: 0.000074 > Median time: 0.000446 seconds (573991 bytes per sec.) > > > Les utiisateurs d'Ubuntu apprécieront sans doute une documentation > équivalente en http://doc.ubuntu-fr.org/ldap_client. Terminons par une > bonne référence. Le Comité Réseau des Universités a une excellente page > sur LDAP (http://www.cru.fr/documentation/ldap/index), contenant des > pointeurs vers toutes les documentations nécessaires. -- ----- Kévin C www.tuxalafenetre.net -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:" To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
