/etc/ldap.conf et /etc/openldap/ldap.conf

[rvfranck]

Salut,

J'ai supprimer le fichier /etc/openldap/ldap.conf hier par mégarde mais pas de problème lorsque je lance le serveur ldap. l'authentification, les recherches, l'ajout, etc... (en local) tout ça passe. Je ne comprends pas, est ce normal?

Aussi, j'aimerais savoir où doivent se trouver /etc/ldap.conf et /etc/openldap/ldap.conf (chez le client, le serveur)? Là je peux pas tester je n'ai qu'un seul pc.

Merci

[septox]

slt man ,

donne nous un peu plus d'infos sur les systemes (serveurs, clients ).

[julp]

Envoyé par rvfranck

J'ai supprimer le fichier /etc/openldap/ldap.conf hier par mégarde mais pas de problème lorsque je lance le serveur ldap. l'authentification, les recherches, l'ajout, etc... (en local) tout ça passe. Je ne comprends pas, est ce normal?

Oui, ce fichier ne sert qu'au client.

Envoyé par rvfranck

Aussi, j'aimerais savoir où doivent se trouver /etc/ldap.conf et /etc/openldap/ldap.conf (chez le client, le serveur)? Là je peux pas tester je n'ai qu'un seul pc.

Ne serait-ce pas le même fichier (l'un ne serait-il pas un lien symbolique pointant sur l'autre) ?


Julp.

[rvfranck]

Merci de vous être arreté sur mon post,

Julp a dit:
Oui, ce fichier ne sert qu'au client.

Le client et le serveur sont sur le même pc. Donc son absence devrait quand même changer quelque chose non?

Julp a dit:
Ne serait-ce pas le même fichier (l'un ne serait-il pas un lien symbolique pointant sur l'autre) ?

Je suis sous fédora 4 et j'avais fais attention à ça: le contenu des deux fichiers n'est pas exactement le même.

Septox a dit:
donne nous un peu plus d'infos sur les systemes (serveurs, clients ).

Je suis sous Fedora 4. je n'ai qu'un seul pc, le client et le serveur sont donc sur le même pc. Je voulais juste savoir qui est necessaire pour le poste client et qui l'est pour le serveur.

Encore Merci!!!

[julp]

Envoyé par rvfranck

Le client et le serveur sont sur le même pc. Donc son absence devrait quand même changer quelque chose non?

1. Le serveur est capable de fonctionner sans le client. Le client, lui, ne sert quà consulter l'annuaire (recherche, ...).
2. Oui, le fichier ldap.conf n'est pas vital pour les clients (sauf peut être si vous veniez à utiliser PAM/NSS pour faire de l'authentification via LDAP).

Envoyé par man ldap.conf

The ldap.conf configuration file is used to set system-wide defaults to be applied when running ldap clients.

Par ailleurs et comme le stipule cette page du man, on peut redéfinir individuellement (niveau utilisateur) les paramètres pour une connection cliente (très utile pour gérer les certificats côté client) ou encore par des variables d'environnement.

Envoyé par rvfranck

Je suis sous fédora 4 et j'avais fais attention à ça: le contenu des deux fichiers n'est pas exactement le même.

Sous FreeBSD, nous sommes obligés de faire des liens symboliques car en utilisant les ports, le fichier de configuration se situe, après installation dans /usr/local/etc/openldap/ldap.conf alors qu'il est cherché ailleurs (/etc/ldap.conf). Mais normallement, vous ne devriez pas avoir deux "configurations" différentes : l'un sert certainement à rien.

Envoyé par rvfranck

Je suis sous Fedora 4. je n'ai qu'un seul pc, le client et le serveur sont donc sur le même pc. Je voulais juste savoir qui est necessaire pour le poste client et qui l'est pour le serveur.

Le client fait partie des dépendances pour l'installation du serveur (tout du moins avec les paquets/ports). Donc le client (compilé) a besoin des librairies (libldap, liblber) et pour le serveur c'est pas aussi simple (il inclue un démon pour la réplication, il a besoin d'une base de données (type db par défaut), son fichier de configuration, ...) : donc je dirais tout ce avec quoi il est livré.


Julp.

[rvfranck]

Bien, là c'est clair.Merci Julp

[rvfranck]

Salut,

J'ai emprunté la machine d'un pote (fedora 3) pour essayer de configurer le client distant et voir ce que ça donne.
J'ai donc configurer les fichiers /etc/pam.d/system-auth, /etc/nsswitch.conf et /etc/ldap.conf.

Depuis le client, un getent passwd me renvoit les comptes locaux et ceux se trouvant dans l'annuaire qui se trouve sur le serveur. Mais quand j'essaye de me connecter depuis le client ça passe pas (pourtant ça marche chez le serveur):

Code :

1
2
 
# su herve

message d'erreur:

creating directory '/home/herve'
could not open session

/etc/pam.d/system-auth (il est le même chez le client et chez le serveur)

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
 
auth        required      /lib/security/$ISA/pam_env.so
auth	    sufficient    /lib/security/pam_ldap.so use_first_pass
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
auth        required      /lib/security/$ISA/pam_deny.so
 
accoutn     sufficient    /lib/security/pam_ldap.so use_first_pass
account     required      /lib/security/$ISA/pam_unix.so
account     sufficient    /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet
account     required      /lib/security/$ISA/pam_permit.so
 
password    requisite     /lib/security/$ISA/pam_cracklib.so retry=3
password    sufficient    /lib/security/pam_ldap.so use_first_pass
password    sufficient    /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow
password    required      /lib/security/$ISA/pam_deny.so
 
session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/pam_mkhomedir.so skel=/etc/skel umask=0022
session     sufficient    /lib/security/pam_ldap.so use_first_pass
session     required      /lib/security/$ISA/pam_unix.so

Merci

[rvfranck]

Julp a dit:
Sous FreeBSD, nous sommes obligés de faire des liens symboliques car en utilisant les ports, le fichier de configuration se situe, après installation dans /usr/local/etc/openldap/ldap.conf alors qu'il est cherché ailleurs (/etc/ldap.conf). Mais normallement, vous ne devriez pas avoir deux "configurations" différentes : l'un sert certainement à rien.

J'ai remarqué que /etc/openldap/ldap.conf servait a definir le contexte de recherche des clients: chez le client distant, je l'ai renommé en ldap.conf.save puis j'ai lancé la recherche:

Code :

1
2
 
ldapsearch -x -b "dc=example,dc=sn"

et j'avais le message suivant:

ldap_bind: Can't contact LDAP server (-1)

mais la recherche suivante marche:

Code :

1
2
 
ldapsearch -H ldap://adresseIP_du_serveur -x -b "dc=example,dc=sn"

j'ai donc defini l'uri du serveur et la base de recherche dans /etc/openldap/ldap.conf.save, après je lui ai donné son nom initial. et là la recherche

Code :

1
2
 
ldapsearch -x -b "dc=example,dc=sn"

donnait le resultat attendu.

[julp]

Code :

1
2
 
accoutn     sufficient    /lib/security/pam_ldap.so use_first_pass

Faute de frappe sur account ? Votre message d'erreur vient, je pense, de la configuration de PAM.

Envoyé par rvfranck

J'ai remarqué que /etc/openldap/ldap.conf servait a definir le contexte de recherche des clients: chez le client distant, je l'ai renommé en ldap.conf.save puis j'ai lancé la recherche:

Et avec le deuxième ? Vous avez donc pu vérifier que ce fichier n'est pas vital.


Julp.

[rvfranck]

Merci big Julp,

effectivement il y' avait erreur de frappe . Mais, même après correction j'ai le même message d'erreur chez le client distant lorsque j'essaye de me connecter avec un user qui se trouve dans l'annuaire.

creating directory '/home/herve'
could not open session

Et si c'était une mauvaise config de /etc/ldap.conf? je le poste, on ne sait jamais.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
 
# adresse du serveur ldap
host 192.168.0.1
 
# The distinguished name of the search base.
base dc=example,dc=sn
 
# Another way to specify your LDAP server is to provide an
# uri with the server name. This allows to use
# Unix Domain Sockets to connect to a local LDAP Server.
uri ldap://192.168.0.1/
#uri ldaps://127.0.0.1/   
 
# The LDAP version to use (defaults to 3
# if supported by client library)
ldap_version 3
 
# The port.
# Optional: default is 389.
port 389
 
# Filter to AND with uid=%s
pam_filter objectclass=posixAccount
 
# The user ID attribute (defaults to uid)
pam_login_attribute uid
 
# Hash password locally; required for University of
# Michigan LDAP server, and works with Netscape
# Directory Server if you're using the UNIX-Crypt
# hash mechanism and not using the NT Synchronization
# service. 
pam_password crypt
 
nss_base_passwd	ou=People,dc=example,dc=sn?one
nss_base_shadow	ou=People,dc=example,dc=sn?one
nss_base_group		ou=Group,dc=example,dc=sn?one
 
# Client certificate and key
# Use these, if your server requires client authentication.
#tls_cert
#tls_key
ssl no
pam_password md5

Julp à dit:
Et avec le deuxième ? Vous avez donc pu vérifier que ce fichier n'est pas vital.

Comme vous me l'avez dis plus haut, /etc/ldap.conf est necessaire si l'on veut utiliser PAM/NSS pour faire de l'authentification via LDAP.

Merci

[julp]

Dans votre ldap.conf, il y a quelques "conflits" :

• host 192.168.0.1 et uri ldap://192.168.0.1/ (l'un des deux suffira, de plus, host est déprécié)
• pam_password crypt et pam_password md5

Voilà, ce que j'utilisais pour PAM (system-auth) :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
#%PAM-1.0
 
auth        required      pam_env.so
auth        sufficient    pam_unix.so likeauth nullok
auth        sufficient    pam_ldap.so use_first_pass
auth        required      pam_deny.so
 
account     required      pam_unix.so
account     sufficient    pam_ldap.so
 
password    required      pam_cracklib.so retry=3 minlen=2  dcredit=0  ucredit=0
password    sufficient    pam_unix.so nullok use_authtok md5 shadow
password    sufficient    pam_ldap.so use_authtok
password    required      pam_deny.so
 
session     required      pam_limits.so
session     required      pam_unix.so
session     optional      pam_ldap.so

Et pour terminer, vous pouvez lier (par un lien symbolique) vos deux fichiers ldap.conf. Le tout c'est de garder celui qui contient la configuration de NSS.


Julp.

Edit : le system-auth vient de ma Mandrake (c'était pas encore Mandriva)

[rvfranck]

Merci Julp de prendre la peine de me repondre, là je suis en cours. Une fois de retour à la maison je modifie mon fichier de config et je vous mets au courant.

Merci,

[rvfranck]

Salut,

Julp j'ai essayé avec ton system-auth et j'ai ceci quand j'essaie de me connecter:

Code :

1
2
 
bash-3.00$

là il attend que je frappe une commande je suppose, c'est normal?

Je crois que je vais reprendre la config du client distant, parce que c'est pas normal qu'en local ça marche et que chez les clients distants ça passe pas. Dans la plupart des tutos qui traitent du sujet on demande de recopier le même system-auth chez les clients.

Merci du coup de main et a+++++

[rvfranck]

Salut,

J'ai essayé de réconfigurer, même résultat : En local ça marche, depuis un client distant ça marche pas.
Et si c'était depuis le serveur que ça cloche: du genre, une option qui autorise les connexions à distantes?

Merci!!!

[julp]

Vérifions que j'ai bien compris : vous avez un serveur LDAP pour centraliser l'authentification et tout fonctionne sur ce dernier, mais pas depuis un autre client réseau ? Si oui, je pencherais pour un problème de pare-feu (niveau serveur) ou alors dans la configuration de NSS (niveau client).


Julp.

[rvfranck]

Salut,

Effectivement vous avez bien compris. Mais j'avais autoriser les connexions (depuis le serveur) sur le port 389. Aussi, les commandes ldapsearch et getent passwd depuis les clients me renvoient le résultat attendu, mais je vais désactiver le pare feu et tester.

Merci

[julp]

S'agit-il toujours du même message (could not open session) ? Quel est l'OS de la machine cliente ? Avez-vous des messages d'erreur dans vos logs concernant des échecs d'authentification (système client) ?


Julp.

[rvfranck]

Julp, j'ai désactiver le pare-feu et ça ne marche toujours pas. Je crois que le problème c'est au niveau de la ligne ci de /etc/pam.d/system-auth

Code :

1
2
 
session     required      /lib/security/pam_mkhomedir.so skel=/etc/skel umask=0022

J'ai comme l'impression que lorsque je fais un "su herve" depuis le client, le système n'arrive pas à créer le repertoire /home/herve et m'affiche ce message d'erreur:

creating directory '/home/herve'
could not open session

J'ai donc crée le repertoire /home/herve chez le client avant de me connecter (su herve), et là j'ai l'invite de commande:

Code :

1
2
 
bash-3.00$

Aussi je voudrais savoir, au cas où la connexion reussirait le client serait connecté à quel ordinateur (le sien ou sur le serveur)? comment se présente l'invite de commande?

Merci

[julp]

Envoyé par rvfranck

Julp, j'ai désactiver le pare-feu et ça ne marche toujours pas.

Ce n'est pas la peine puisque la connexion à l'annuaire se fait très bien (getent, ldapsearch par exemple).

Envoyé par rvfranck

J'ai comme l'impression que lorsque je fais un "su herve" depuis le client, le système n'arrive pas à créer le repertoire /home/herve et m'affiche ce message d'erreur:

Effectivement, dans ce cas ça ne concerne pas LDAP (et les modules pam/nss) sauf si c'était dû à un problème d'ordre entre les modules (dans votre fichier de configuration PAM).

Envoyé par rvfranck

Aussi je voudrais savoir, au cas où la connexion reussirait le client serait connecté à quel ordinateur (le sien ou sur le serveur)? comment se présente l'invite de commande?

La machine à laquelle vous vous connectez/cible. L'invite de commande dépend de la configuration du shell (variable prompt ou similaire). Par ailleurs, le shell qu'il utilise est renseigné par l'attribut loginShell (classe PosixAccount) (s'il est omis j'ignore comment il fait son choix) et les fichiers de configuration d'un shell se situent dans /etc et/ou dans le répertoire personnel de l'utilisateur.


Julp.

[rvfranck]

Merci,

donc si je comprends bien si tout marche correctement après un "su nomuser" sur un poste client. Je me retrouve sur le serveur, par exemple "/home/nomuser" et là, j'ai accès aux fichiers qui s'y trouvent (enfin,ça depend des droits)?

Je vais d'abord me calmer un peu. Dormir et revoir ce problème plus tard.

Merci big Julp.