Bonjour à tous,
Je cherche actuellement à faire de l'authentification LDAP sur ma
Debian
Lenny. Quand je fais getent passwd mes users aparaissent bien, mais pas l es
mots de passe, le compte a l'air vérouillé :
ttest:*:5000:5000:test test:/srv/vusers/linuxmiroir.fr/ttest:
Je ne peux évidement pas me logguer. Ais-je oublié quelque chose?
Merci d'avance pour vos lumières
Kévin C
Bonjour à tous,
Je cherche actuellement à faire de l'authentification LDAP sur ma
Debian
Lenny. Quand je fais getent passwd mes users aparaissent bien, mais pas l es
mots de passe, le compte a l'air vérouillé :
ttest:*:5000:5000:test test:/srv/vusers/linuxmiroir.fr/ttest:
Je ne peux évidement pas me logguer. Ais-je oublié quelque chose?
Merci d'avance pour vos lumières
Kévin C
Bonjour à tous,
Je cherche actuellement à faire de l'authentification LDAP sur ma
Debian
Lenny. Quand je fais getent passwd mes users aparaissent bien, mais pas l es
mots de passe, le compte a l'air vérouillé :
ttest:*:5000:5000:test test:/srv/vusers/linuxmiroir.fr/ttest:
Je ne peux évidement pas me logguer. Ais-je oublié quelque chose?
Merci d'avance pour vos lumières
Kévin C
2009/1/13 Kevin COUSIN
> Bonjour à tous,
>
> Je cherche actuellement à faire de l'authentification LDAP su r ma
> Debian
> Lenny. Quand je fais getent passwd mes users aparaissent bien, mais pas
> les mots de passe, le compte a l'air vérouillé :
>
> ttest:*:5000:5000:test test:/srv/vusers/linuxmiroir.fr/ttest:
>
> Je ne peux évidement pas me logguer. Ais-je oublié quelque chose?
>
> Merci d'avance pour vos lumières
>
> Kévin C
Bonjour,
L'intérêt de LDAP dans le cas de l'authentification est de ne pas les avoir
dans le fichier /etc/passwd mais dans la base LDAP et la ligne que tu as
mis plus haut est typiquement celle du fichier /etc/passwd donc tu dois
avoir un problème quelque part dans ce que tu veux faire ou dans ce que tu
expliques.
Kévin H
2009/1/13 Kevin COUSIN <kevin@cousin-online.fr>
> Bonjour à tous,
>
> Je cherche actuellement à faire de l'authentification LDAP su r ma
> Debian
> Lenny. Quand je fais getent passwd mes users aparaissent bien, mais pas
> les mots de passe, le compte a l'air vérouillé :
>
> ttest:*:5000:5000:test test:/srv/vusers/linuxmiroir.fr/ttest:
>
> Je ne peux évidement pas me logguer. Ais-je oublié quelque chose?
>
> Merci d'avance pour vos lumières
>
> Kévin C
Bonjour,
L'intérêt de LDAP dans le cas de l'authentification est de ne pas les avoir
dans le fichier /etc/passwd mais dans la base LDAP et la ligne que tu as
mis plus haut est typiquement celle du fichier /etc/passwd donc tu dois
avoir un problème quelque part dans ce que tu veux faire ou dans ce que tu
expliques.
Kévin H
2009/1/13 Kevin COUSIN
> Bonjour à tous,
>
> Je cherche actuellement à faire de l'authentification LDAP su r ma
> Debian
> Lenny. Quand je fais getent passwd mes users aparaissent bien, mais pas
> les mots de passe, le compte a l'air vérouillé :
>
> ttest:*:5000:5000:test test:/srv/vusers/linuxmiroir.fr/ttest:
>
> Je ne peux évidement pas me logguer. Ais-je oublié quelque chose?
>
> Merci d'avance pour vos lumières
>
> Kévin C
Bonjour,
L'intérêt de LDAP dans le cas de l'authentification est de ne pas les avoir
dans le fichier /etc/passwd mais dans la base LDAP et la ligne que tu as
mis plus haut est typiquement celle du fichier /etc/passwd donc tu dois
avoir un problème quelque part dans ce que tu veux faire ou dans ce que tu
expliques.
Kévin H
2009/1/13 Kevin COUSIN
> Bonjour à tous,
>
> Je cherche actuellement à faire de l'authentification LDAP su r ma
> Debian
> Lenny. Quand je fais getent passwd mes users aparaissent bien, mais pas
> les mots de passe, le compte a l'air vérouillé :
>
> ttest:*:5000:5000:test test:/srv/vusers/linuxmiroir.fr/ttest:
>
> Je ne peux évidement pas me logguer. Ais-je oublié quelque chose?
>
> Merci d'avance pour vos lumières
>
> Kévin C
Bonjour,
L'intérêt de LDAP dans le cas de l'authentification est de ne pas les avoir
dans le fichier /etc/passwd mais dans la base LDAP et la ligne que tu as
mis plus haut est typiquement celle du fichier /etc/passwd donc tu dois
avoir un problème quelque part dans ce que tu veux faire ou dans ce que tu
expliques.
Kévin H
2009/1/13 Kevin COUSIN <kevin@cousin-online.fr>
> Bonjour à tous,
>
> Je cherche actuellement à faire de l'authentification LDAP su r ma
> Debian
> Lenny. Quand je fais getent passwd mes users aparaissent bien, mais pas
> les mots de passe, le compte a l'air vérouillé :
>
> ttest:*:5000:5000:test test:/srv/vusers/linuxmiroir.fr/ttest:
>
> Je ne peux évidement pas me logguer. Ais-je oublié quelque chose?
>
> Merci d'avance pour vos lumières
>
> Kévin C
Bonjour,
L'intérêt de LDAP dans le cas de l'authentification est de ne pas les avoir
dans le fichier /etc/passwd mais dans la base LDAP et la ligne que tu as
mis plus haut est typiquement celle du fichier /etc/passwd donc tu dois
avoir un problème quelque part dans ce que tu veux faire ou dans ce que tu
expliques.
Kévin H
2009/1/13 Kevin COUSIN
> Bonjour à tous,
>
> Je cherche actuellement à faire de l'authentification LDAP su r ma
> Debian
> Lenny. Quand je fais getent passwd mes users aparaissent bien, mais pas
> les mots de passe, le compte a l'air vérouillé :
>
> ttest:*:5000:5000:test test:/srv/vusers/linuxmiroir.fr/ttest:
>
> Je ne peux évidement pas me logguer. Ais-je oublié quelque chose?
>
> Merci d'avance pour vos lumières
>
> Kévin C
Bonjour,
L'intérêt de LDAP dans le cas de l'authentification est de ne pas les avoir
dans le fichier /etc/passwd mais dans la base LDAP et la ligne que tu as
mis plus haut est typiquement celle du fichier /etc/passwd donc tu dois
avoir un problème quelque part dans ce que tu veux faire ou dans ce que tu
expliques.
Kévin H
J'ai fais la commande getent passwd : elle me renvoie toute les lignes du
fichier /etc/passwd ainsi que mon user de test
ttest:*:5000:5000:test test:/srv/vusers/linuxmiroir.fr/ttest:
j'ai mais exprès un UID assez haut pour mes users LDAP. je peux bien
m'authentifier avec ce user quand je suis root quand je fais su - ttest. Le mot
de passe stocké dans LDAP n'a pas l'air d'être pris en compte.
J'ai fais la commande getent passwd : elle me renvoie toute les lignes du
fichier /etc/passwd ainsi que mon user de test
ttest:*:5000:5000:test test:/srv/vusers/linuxmiroir.fr/ttest:
j'ai mais exprès un UID assez haut pour mes users LDAP. je peux bien
m'authentifier avec ce user quand je suis root quand je fais su - ttest. Le mot
de passe stocké dans LDAP n'a pas l'air d'être pris en compte.
J'ai fais la commande getent passwd : elle me renvoie toute les lignes du
fichier /etc/passwd ainsi que mon user de test
ttest:*:5000:5000:test test:/srv/vusers/linuxmiroir.fr/ttest:
j'ai mais exprès un UID assez haut pour mes users LDAP. je peux bien
m'authentifier avec ce user quand je suis root quand je fais su - ttest. Le mot
de passe stocké dans LDAP n'a pas l'air d'être pris en compte.
* Kevin COUSIN [2009-01-13 15:07:54 +0100]:
> J'ai fais la commande getent passwd : elle me renvoie toute les lignes du
> fichier /etc/passwd ainsi que mon user de test
>
> ttest:*:5000:5000:test test:/srv/vusers/linuxmiroir.fr/ttest:
>
> j'ai mais exprès un UID assez haut pour mes users LDAP. je peux bien
> m'authentifier avec ce user quand je suis root quand je fais su - ttest.
> Le mot de passe stocké dans LDAP n'a pas l'air d'être pris en compt e.
Le fait que tu récupères cette ligne signifie que les utilisateurs so nt
bien récupérés dans la base ldap par nscd. J'en déduis donc que t u as
mis en place nss-ldap ou libnss-ldapd avec succès.
Pour que l'authentification LDAP soit possible, il faut configurer un
plugin PAM pour identifier les utilisateurs sur la base LDAP. Le paquet
libpam-ldap est-il installé et configuré ?
A+,
* Kevin COUSIN <kevin@cousin-online.fr> [2009-01-13 15:07:54 +0100]:
> J'ai fais la commande getent passwd : elle me renvoie toute les lignes du
> fichier /etc/passwd ainsi que mon user de test
>
> ttest:*:5000:5000:test test:/srv/vusers/linuxmiroir.fr/ttest:
>
> j'ai mais exprès un UID assez haut pour mes users LDAP. je peux bien
> m'authentifier avec ce user quand je suis root quand je fais su - ttest.
> Le mot de passe stocké dans LDAP n'a pas l'air d'être pris en compt e.
Le fait que tu récupères cette ligne signifie que les utilisateurs so nt
bien récupérés dans la base ldap par nscd. J'en déduis donc que t u as
mis en place nss-ldap ou libnss-ldapd avec succès.
Pour que l'authentification LDAP soit possible, il faut configurer un
plugin PAM pour identifier les utilisateurs sur la base LDAP. Le paquet
libpam-ldap est-il installé et configuré ?
A+,
* Kevin COUSIN [2009-01-13 15:07:54 +0100]:
> J'ai fais la commande getent passwd : elle me renvoie toute les lignes du
> fichier /etc/passwd ainsi que mon user de test
>
> ttest:*:5000:5000:test test:/srv/vusers/linuxmiroir.fr/ttest:
>
> j'ai mais exprès un UID assez haut pour mes users LDAP. je peux bien
> m'authentifier avec ce user quand je suis root quand je fais su - ttest.
> Le mot de passe stocké dans LDAP n'a pas l'air d'être pris en compt e.
Le fait que tu récupères cette ligne signifie que les utilisateurs so nt
bien récupérés dans la base ldap par nscd. J'en déduis donc que t u as
mis en place nss-ldap ou libnss-ldapd avec succès.
Pour que l'authentification LDAP soit possible, il faut configurer un
plugin PAM pour identifier les utilisateurs sur la base LDAP. Le paquet
libpam-ldap est-il installé et configuré ?
A+,
J'ai ajouté ça dans /etc/pam.d/system-password
J'ai ajouté ça dans /etc/pam.d/system-password
J'ai ajouté ça dans /etc/pam.d/system-password
L'intérêt de LDAP dans le cas de l'authentification est de ne pas
les avoir dans le fichier /etc/passwd mais dans la base LDAP et la
ligne que tu as mis plus haut est typiquement celle du fichier
/etc/passwd donc tu dois avoir un problème quelque part
L'intérêt de LDAP dans le cas de l'authentification est de ne pas
les avoir dans le fichier /etc/passwd mais dans la base LDAP et la
ligne que tu as mis plus haut est typiquement celle du fichier
/etc/passwd donc tu dois avoir un problème quelque part
L'intérêt de LDAP dans le cas de l'authentification est de ne pas
les avoir dans le fichier /etc/passwd mais dans la base LDAP et la
ligne que tu as mis plus haut est typiquement celle du fichier
/etc/passwd donc tu dois avoir un problème quelque part
On Tue, Jan 13, 2009 at 05:32:27PM +0100,
Kevin C 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 lequ el
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 230 7).
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 cnmin,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 ser veur
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, ma is
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 fic hier
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
'cnmin,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
'cnmin,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 ce la
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 c omme
(au moment d'une connexion SSH de l'utilisateur bleriot) :
Mar 26 10:15:05 lilith slapd[15932]: connA0 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 excelle nte page
sur LDAP (http://www.cru.fr/documentation/ldap/index), contenant des
pointeurs vers toutes les documentations nécessaires.
On Tue, Jan 13, 2009 at 05:32:27PM +0100,
Kevin C <linux@tuxalafenetre.net> 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 lequ el
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 230 7).
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 ser veur
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, ma is
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 fic hier
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 ce la
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 c omme
(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 excelle nte page
sur LDAP (http://www.cru.fr/documentation/ldap/index), contenant des
pointeurs vers toutes les documentations nécessaires.
On Tue, Jan 13, 2009 at 05:32:27PM +0100,
Kevin C 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 lequ el
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 230 7).
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 cnmin,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 ser veur
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, ma is
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 fic hier
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
'cnmin,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
'cnmin,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 ce la
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 c omme
(au moment d'une connexion SSH de l'utilisateur bleriot) :
Mar 26 10:15:05 lilith slapd[15932]: connA0 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 excelle nte page
sur LDAP (http://www.cru.fr/documentation/ldap/index), contenant des
pointeurs vers toutes les documentations nécessaires.