Forum Linux.debian/ubuntu Quelques petits problèmes LDAP et autres considérations sans importance sauf pour moi.

Posté par  .
Étiquettes : aucune
1
3
nov.
2008
Bonjour,

A l'occasion de l'achat d'un nouveau serveur pour remplacer la vieille machine fatiguée qui remplissait ce rôle dans mon labo, je me suis dit in petto (1) "Tiens, c'est l'occasion d'installer un annuaire LDAP, depuis le temps que tu dis qu'il faut le faire...". Dont acte. Malheureusement, tout ne se passe pas vraiment aussi simplement que j'aurais pu l'espérer. Pour tout vous dire, après quelques dizaines d'heures d'avancées (maigres), d'échecs (cuisants), de bidouillages (approximatifs), de déceptions (cruelles) et autres arrachages de cheveux (capilo-douloureux), je suis pas loin de la crise de nerfs.

Mais avant de vous exposer par le menu le détail de mes misères, j'aurais besoin de quelques éclaircissements au niveau sécurité. Voilà, comme je suis derrière les pare-feu de l'université, je n'ai pas vraiment besoin d'un niveau de sécurité top-mega-secure, mais d'un autre côté, j'ai pas envie non plus que le moindre clampin puisse lire mon mot de passe rien qu'en sniffant une petite trame passant sur le réseau. Du coup, je me demande si j'ai besoin de TLS ou pas. En d'autre termes, avec le protocole ldap par défaut (celui qu'on trouve en 389 généralement), est-ce que les mots de passe circulent en clair sur le réseau ?

Ceci étant, j'ai quand même pas mal de problèmes...

Mais commençons par le commencement : tout d'abord, j'utilise une lenny
$ cat debian_version
lenny/sid
$ uname -a
Linux serv 2.6.26-1-amd64 #1 SMP Wed Sep 10 15:31:12 UTC 2008 x86_64 GNU/Linux

Ensuite mon annuaire LDAP est destiné à
- gérer en local les noms de machines (ou=Hosts), les groupes (ou=Groups) et les utilisateurs non-root (ou=Users,ou=People)
- permettre le login des utilisateurs en local (via PAM) ou en SSH depuis les postes clients
- permettre l'authentification pour divers services Web depuis le serveur Apache local et d'autres serveurs Apache (distants)
- permettre l'authentification Samba
- permettre l'utilisation de l'annuaire comme carnet d'adresse pour les clients mails des utilisateurs qui le supportent.

Le serveur LDAP en tant que tel a l'air de fonctionner correctement ; en tout cas depuis la machine locale. J'ai pu créer mon arborescence, et y ajouter des enregistrements.

Ensuite, si je tape (en root)
$ ldapsearch -x -H ldap://serv -b ou=Users,ou=People,dc=####,dc=####,dc=fr"
il m'affiche bien tout le contenu de mon annuaire.

A l'aide de Webmin, j'ai créé le certifiact indispensable à l'utilisation en TLS. Après celà, si je tape (toujours en root)
$ ldapsearch -x -H ldaps:// -Z -b "ou=Users,ou=People,dc=####,dc=####,dc=fr
il m'affiche aussi tout le contenu de mon annuaire comme prévu.

Lorsque je passe en utilisateur lambda (qui existe dans l'annuaire)
$ su - lambda
il me dit "I have no name!", mais si j'active le service de cache nscd cette mention disparaît rapidement. Mais bon, pour l'instant, je laisse le cache désactivé (j'ai lu quelque part qu'il avait du mal à cohabiter avec Samba ; qu'en est-il ?).
Je peux alors faire des recherches en tant qu'utilisateur lambda depuis le serveur lui-même.

J'ai aussi testé la connection SSH depuis le serveur lui-même :
$ ssh lambda@localhost
et ça marche pas ! dans auth.log, le module pam_ldap me sort un fatidique "Invalid credentials"

Depuis un poste distant, la recherche en ldap:// marche, mais la recherche en ldaps:// ne marche pas ! La connection en ssh depuis un poste distant ne marche pas non plus...

Devant cet état de fait, j'ai essayé de regarder en détail les modules PAM qui interviennent dans l'affaire et même après les bricolés dans tous les sens, je ne note pas d'amélioration notable à mon grand dam !

Voilà, voilà, voilà....

Je suis à l'écoute de toute remarque, source d'information ou quoi que ce soit qui pourrait m'aider.

Merci d'avance.

PS : Voilà la config actuelle (j'ai simplement viré les commentaires et remplacé les valeurs locales par des ####). Désolé pour la longueur que ça donne au message, mais comme je ne sait pas trop d'où peuvent venir mes problèmes, je met tout ...

#########################################
# fichier /etc/default/slapd (extrait): #
#########################################
SLAPD_SERVICES="ldap:/// ldaps:///"
###

##################################
# fichier /etc/ldap/slapd.conf : #
##################################
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/samba.schema

TLSCertificateFile /etc/ssl/ldap.cert
TLSCertificateKeyFile /etc/ssl/ldap.key

pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
loglevel 8
modulepath /usr/lib/ldap
moduleload back_hdb
sizelimit 500
tool-threads 1
backend hdb
database hdb

suffix dc=####,dc=####,dc=fr
password-hash {MD5}
rootdn cn=admin,dc=####,dc=####,dc=fr
rootpw {MD5}####

directory "/var/lib/ldap"
dbconfig set_cachesize 0 2097152 0
dbconfig set_lk_max_objects 1500
dbconfig set_lk_max_locks 1500
dbconfig set_lk_max_lockers 1500
index objectClass,uid,uidNumber,gidNumber eq
lastmod on
checkpoint 512 30

access to attrs=userPassword
by self write
by anonymous auth
by * none
access to attrs=sambaLMPassword,sambaNTPassword
by self write
by anonymous auth
by * none
access to dn.base=""
by * read
access to *
by * read
###

#################################
# fichier /etc/ldap/ldap.conf : #
#################################
base dc=####,dc=####,dc=fr
uri ldap://localhost/

binddn cn=nss,dc=####,dc=####,dc=fr
bindpw {MD5}aitP7fMRPBRSmYGVus966g==

rootbinddn cn=admin,dc=####,dc=####,dc=fr
pam_password crypt

TLS_REQCERT allow

nss_base_passwd ou=Users,ou=People,dc=####,dc=####,dc=fr
nss_base_shadow ou=Users,ou=People,dc=####,dc=####,dc=fr
nss_base_group ou=Groups,dc=####,dc=####,dc=fr
nss_base_hosts ou=Hosts,dc=####,dc=####,dc=fr
###

Pour permettre la connection des utilisateurs, j'ai configuré libnss-ldap et libpam-ldap de la manière suivante :

##############################
# fichier /etc/nsswitch.conf #
##############################
passwd: files ldap
group: files ldap
shadow: files ldap

hosts: files dns

networks: files

protocols: db files
services: db files
ethers: db files
rpc: db files

netgroup: nis
###

#################################
# fichier /etc/libnss-ldap.conf #
#################################
host 127.0.0.1
base dc=####,dc=####,dc=fr
ldap_version 3

nss_base_passwd ou=Users,ou=People,dc=####,dc=####,dc=fr?one
nss_base_shadow ou=Users,ou=People,dc=####,dc=####,dc=fr?one
nss_base_group ou=Groups,dc=####,dc=####,dc=fr?one
nss_base_hosts ou=Hosts,dc=####,dc=####,dc=fr?one

uri ldap://127.0.0.1
rootbinddn cn=admin,dc=####,dc=####,dc=fr
# le password du root est stocke en clair dans /etc/libnss-ldap.secret (mode 600)
binddn cn=nss,dc=dc=####,dc=####,dc=fr
bindpw ####

bind_policy soft
###

################################
# fichier /etc/pam_ldap.conf : #
################################
uri ldap://127.0.0.1
base dc=####,dc=####,dc=fr
ldap_version 3

rootbinddn cn=admin,dc=####,dc=####,dc=fr
# le password du root est stocke en clair dans /etc/pam_ldap.secret (mode 600)

pam_password crypt

binddn cn=nss,dc=####,dc=####,dc=fr
bindpw ####
###

Modules PAM :

#######################################
# fichier /etc/pam.d/common-account : #
#######################################
account sufficient pam_ldap.so
account required pam_unix.so shadow
###

####################################
# fichier /etc/pam.d/common-auth : #
####################################
auth required pam_env.so
auth sufficient pam_ldap.so
auth required pam_unix.so shadow use_first_pass
###

########################################
# fichier /etc/pam.d/common-password : #
########################################
password required pam_cracklib.so retry=3
password sufficient pam_ldap.so use_authtok
password required pam_unix.so shadow use_authtok
###

#######################################
# fichier /etc/pam.d/common-session : #
#######################################
session required pam_limits.so
session required pam_mkhomedir.so skel=/etc/skel
session optional pam_ldap.so
session required pam_unix.so shadow
###

#############################
# fichier /etc/pam.d/sshd : #
#############################
@include common-account
account required pam_nologin.so

@include common-auth

@include common-password

session optional pam_motd.so
session optional pam_mail.so standard noenv
@include common-session
###
  • # Et elle dape dape ....

    Posté par  . Évalué à 2.

    N'aimant pas trop les fichiers de confs à disséquer sans véritablement connaître l'environnement et les paquets présents, je vais te répondre de manière non exhaustive mais avec quelques pistes. Je te laisse faire les recherches sur chacun des points.

    Concernant tes interrogations sur nscd dans un environnement Samba, il faut surtout faire attention aux interactions entre nscd et winbind. Ces deux là ne peuvent pas s'encadrer.

    A propos de l'auth LDAP avec SSH, tu dois avoir correctement configuré pam_ldap et la bibliothèque NSS ldap qui va avec (sans oublier le nsswitch.conf). Ensuite, il faut que l'entrée correspondant à l'utilisateur qui s'authentifie soit "ressemblante" à un compte système standard (account, posixAccount, shadowAccount, etc... ), et surtout qu'elle dispose d'un shell.
    Ensuite, pour le common-auth, je mettrais le 'sufficient ldap' avant le env. Un bon moyen de tester sa conf pam est de bosser en adaptant dans un premier temps la configuration pam pour 'su' et de changer d'utilisateur pour valider les tests.

    Enfin, sur ta question à propos TLS, tu sais peut-être que OpenLDAP dispose, en plus de SASL, de deux manières (qui peuvent être utilisées en même temps) pour appréhender les échanges sécurisés: le StartTLS et le ldaps://. Grossièrement, la première négocie la sécurité tout en gardant la communication sur le port 389, et la deuxième, toujours grossièrement, travaille sur le port 636 et la communication est négociée à la manière d'un https.

    Bon courage !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.