Contenu de /etc/nsswitch ne fonctionne pas correctement

Support Debian
#1

Bonjour à tous,

J’ai un petit problème sur l’authentification de mes users.

Ma debian 7 se connecte à un serveur LDAP en utilisant le fichier /etc/libnss-ldap.conf

J’ai donc des user locaux et des user LDAP

dans le fichier nsswitch.conf, j’ai fait en sorte (normalement), que les users soient d’abord cherchés dans “files”, et seulement dans “ldap” si pas trouvé dans “files”.

Le problème est que pour un user local qui effectue le monitoring (nagios), j’ai des timeouts pendant mes checks. Quand je fait su nagios, ca prends bien 2 min avant d’avoir un prompt.

J’ai essayer strace su nagios, et je peux voir qu’il y a beaucoup de requêtes faite à mon srv LDAP, alors que ca ne devrait pas.

Sauriez vous pourquoi ldap continu d’etre utilisé et/ou pk ca met autant de temps?

Voilà le contenu du fichier nsswitch :

passwd:         files [SUCCESS=return] ldap
group:          files [SUCCESS=return] ldap
shadow:         files [SUCCESS=return] ldap

hosts:          files dns
networks:       files

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

netgroup:       nis

Je suspect quelque chose dans un des fichiers se trouvant dans /etc/pam.d. Voici leur contenu:

common-account :

account	[success=2 new_authtok_reqd=done default=ignore]	pam_unix.so broken_shadow
account	[success=1 default=ignore]	pam_ldap.so 
account	requisite			pam_deny.so
account	required			pam_permit.so

common-auth :

auth	[success=2 default=ignore]	pam_unix.so nullok_secure
auth	[success=1 default=ignore]	pam_ldap.so use_first_pass
auth	requisite			pam_deny.so
auth	required			pam_permit.so
auth	optional	pam_mount.so 
auth	optional			pam_smbpass.so migrate

common-password:

password	[success=2 default=ignore]	pam_unix.so obscure sha512
password	[success=1 user_unknown=ignore default=die]	pam_ldap.so use_authtok try_first_pass
password	requisite			pam_deny.so
password	required			pam_permit.so
password	optional			pam_smbpass.so nullok use_authtok use_first_pass

Merci par avance

#2

Pour vérifier l’aiguillage dans la recherche des noms, LDAP/NSS, pouvez-vous nous donner les retours de

getent passwd nagios
getent passwd 1000
apt-cache policy libpam-ldap libpam-ldapd

Je suppose que vous n’avez rien touché à la configuration de libpam* (répertoire /etc/pam.d ).

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.

Demain est souvent le jour le plus chargé de la semaine.
Proverbe espagnol

#3

Bonjour,

oui rien n’as été changer dans /etc/pam.d. Voici le résultat des commandes:

# getent passwd nagios
nagios:x:1000:1000::/home/nagios:/bin/sh

# getent passwd 1000
nagios:x:1000:1000::/home/nagios:/bin/sh

# grep root /etc/passwd
root:x:0:0:root:/root:/bin/bash

# apt-cache policy libpam-ldap libpam-ldapd
libpam-ldap:
Installed: 184-8.6
Candidate: 184-8.6
Version table:
*** 184-8.6 0
500 http://mirror.0x.sg/debian/ wheezy/main amd64 Packages
100 /var/lib/dpkg/status
libpam-ldapd:
Installed: (none)
Candidate: 0.8.10-4
Version table:
0.8.10-4 0
500 http://mirror.0x.sg/debian/ wheezy/main amd64 Packages
#4

Deux remarques :

  1. La présence du préfixe ‘#’ m’interpelle, car c’est l’invite habituelle du compte d’administration ( compte root uid 0).
    J’ose espérer que vous ne lancez pas des commandes au hasard avec ce compte root. Si vous avez l’habitude de procéder ainsi, il est temps de changer pour sudo

  2. L’utilisateur nagios a le numéro 1000, c’est-à-dire le numéro du premier utilisateur créé sur le système. ( utilisateur habituel )

Comment avez-vous installé nagios ? Je n’ai pas le paquet nagios3 amoureusement construit par le Debian Nagios Maintainer Group installé, mais je me doute bien que si nagios3-cgidépend de adduser ce n’est pas pour rien, c’est pour créer un compte système pour nagios et pas un compte de simple utilisateur.

Quand vous vous connectez en simple utilisateur, la commande

id

vous donne à la fois votre identifiant (le nom du compte) et l’identifiant numérique uid.

fp2x@masime:~$ id
uid=1000(fp2x) gid=1000(fp2x) groupes=1000(fp2x),4(adm),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev)

Dans l’annuaire LDAP, est-ce que l’utilisateur nagios apparaît ?

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

#5

Nagios (ou plutot nrpe) est installé via le package “nagios-nrpe-server”

Dans l’annuaire LDAP, il y a effectivement un autre utilisateur “nagios”, mais cet utilisateur n’est pas censé apparaitre sur le system (quand on fait getent passwd par exemple) , car dans /etc/libnss-ldap.conf je filtre les users devant apparaitre, avec ce type de ligne:

nss_base_passwd ou=MonOU - Users,dc=openldap,dc=lan?one?|(memberOfGID=MyGroup)

Du coup seul les user du group “MyGroup” apparaissent.

mais le pb de nsswitch est bien que lors de l’authentification le user nagios devrait etre d’abord chercher dans “files” (donc user locaux), et la recherche devrait s’arréter à ce moment.

Merci

#6

Ceci n’explique pas pourquoi il a pris le numéro 1000.

Quand vous dites “autre utilisateur”, vous imaginez que par un tour de passe-passe vous allez pouvoir fourguer dans l’annuaire une entrée nommée “nagios” et la cacher sous le tapis, avec une histoire de groupe.
A mon avis, vous êtes sur une fausse piste.

Pour y voir plus clair :

  • Pourquoi tenez-vous à avoir le même nom pour des utilisateurs en fait différents ? (au moins dans votre esprit)

  • Peut-on avoir l’information complète dans le LDAP, c’est-à-dire les attributs “dn” distinguished name et cn “canonical name” des entrées suivantes : utilisateur qui vous sert pour gérer l’annuaire (BINDDN), et les soi-disant deux utilisateurs “nagios” (*) ?

  • Peut-on avoir la sortie de

id

lorsque vous êtes connecté (utilisateur local) sur le PC avec le compte qui vous sert pour vous authentifier. Autrement dit, vous pouvez avoir dans le répertoire personnel de cet utilisateur, un fichier nommé .ldaprc ( voir ldap.conf(5) ) qui vous simplifie la vie pour les requêtes ldapsearch avec des entrées BASE URI BINDDN

  • Sortie de
getent passwd user

pour un de ce que vous appelez “users locaux” et pour un “utilisateur LDAP”.

Note
(*) Pour distinguer les nagios, nous appellerons celui qui a le numéro 1000, l’utilisateur nagios canal historique :slight_smile:

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

#7

D’habitude je n’utilise que le user ldap, mais là le srv ldap est tellement loin du client que ca génére un timeout au niveau des check nagios. De plus, l’attribut du shell des user LDAP est “overrider” à un shell minimaliste qui ne permet pas au user nagios ldap de lancer les check (sinon il serait beaucoup moins minimaliste), et il est impossible de faire une exception dans ce “forcage” d’attribut

cn=admin,dc=openldap,dc=mondomain,dc=lan
cn=nagios,ou=monOU,dc=openldap,dc=mondomain,dc=lan
dn=dc=openldap,dc=mondomain,dc=lan

Je ne suis pas sur de comprendre, mais dans le doute:

uid=10076(monuser) gid=10038(groupe1) groups=10038(group1),10000(group2)

user local : getent passwd nagios
nagios:x:107:112::/var/lib/nagios:/bin/sh

user ldap : getent passwd userldap
userldap:x:10076:10038:user ldap:/home/userldap:/usr/bin/lshell

#8

Il y a 14 jours

Il y a 11h

Comment voulez-vous qu’un lecteur s’y retrouve ? J’ai bien l’impression que vous-même vous ne vous y retrouvez pas :cry:

De toute évidence vous recopiez les sorties des commandes en les éditant, et en oubliant de mettre la commande exacte que vous avez passé.

Si vous voulez vraiment qu’on vous aide, il serait bon de décrire un peu plus clairement votre problème, et lorsque vous devez mettre des retours de commandes utilisez les balises adéquates (ligne seule avec 3 backticks == 3 caractères AltGr+7 ), et n’hésitez pas à mettre aussi les sorties de

hostname --fqdn

en précisant de quoi il s’agit (client, serveur LDAP, station, autre ).
Car on en est arrivé à ne plus savoir qui est qui, et qui fait quoi. Le numéro 1000 sur on ne sait quelle machine était nagios, maintenant cet utilisateur aurait un numéro 107 (un numéro système).

Vous n’avez pas répondu à la question [quote=“littlejohn75, post:4, topic:71088”]
Comment avez-vous installé nagios ? Je n’ai pas le paquet nagios3 amoureusement construit par le Debian Nagios Maintainer Group installé,
[/quote]
qui faisait allusion au paquet debian.

Je me doutais bien que nagios était une usine à gaz, et après deux semaines on ne connait toujours pas l’architecture de l’ensemble, un schéma conceptuel des systèmes et des relations entre eux ne serait pas du luxe pour tout le monde.
Vous parlez de distance excessive entre machines, pourriez-vous être plus précis ?

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.

« Ce que l’on conçoit bien s’énonce clairement,
Et les mots pour le dire arrivent aisément. »
Boileau De L’Art poétique (Chant I)

« Avant donc que d’écrire, apprenez à penser »
Boileau De L’Art poétique (Chant I)

#9

Dsl, mauvais serveur sur lequel j’ai lancé la commande, le bon retour pour un user local est :

[code]

getent passwd nagios

nagios:x:1000:1000::/home/nagios:/bin/sh [/code]

oui j’édite. les commandes sont celle que vous avez demandé…

Mon problème est dans le 1er message, nsswitch etant configuré pour censé s’arréter de chercher quand un user local est trouvé, mais il ne le fait pas.

Depuis le début de l’histoire il n’y a qu’un seulet unique serveur, c’est mon client LDAP qui possède ce fameux fichier nsswitch.conf ( je n’ai jamais parlé station de travail)

hostname --fqdn :

monserveur

La distance entre les machines est une très longue distance (plusieurs milliers de km). pour le schéma ce serait assez simple:

‘monserver <–> serveurLDAP’

“monserver” étant un “client LDAP”

Le vrai problème est que “monserver” continu de faire des requetes LDAP alors qu’il devrait s’arréter une fois trouver le user local.

merci

#10

Là on est mal !

Si le retour avait été du genre monserveur.mondomain.lan, peut-être qu’on aurait un début de piste.

Résumons [quote=“vercetty92, post:9, topic:71088”]
La distance entre les machines est une très longue distance (plusieurs milliers de km).
[/quote]
ok. Vous êtes obnubilé par ce foutu serveur LDAP qui se trouve à des milliers de km, et du coup vous oubliez que d’autres paramètres entrent en jeu, je veux parler de la résolution de noms des machines (systèmes, hôtes).
Vous n’avez pas une configuration DNS correcte, dès le début de mon premier message, je vous fais implicitement remarquer que deux minutes pour la commande

su nagios

ce n’est pas normal. En effet, le système semble se poser des questions du genre « on recherche un certain dénommé nagios parmi les utilisateurs de monserveur, lequel système est dans un domaine indéfini » Comme c’est pour que le sieur nagios puisse enter dans le système, nous devons vérifier ses papiers et voir s’il ne débarque pas d’un bateau de migrants :slight_smile:
J’exagère à peine, mais reconnaissez qu’avec le peu d’informations fiables que vous donnez, il m’est impossible de vous conseiller.

Où se trouve les serveurs DNS pour monserveur et pour serveurLDAP ? (je suppose à quelques millier de km ).

Avez-vous tenté les commandes ldapsearch qui se trouvent sur la page LDAP/NSS que j’avais donnée il y a 15 jours ?
Pourquoi le serveur LDAP est-il si loin ?

Les informations retournées par les commandes sont-elles classées confidentiel Défense pour que vous vous sentiez obligé de les éditer ? (ce qui prend du temps pour tout le monde et introduit une foule d’erreurs )

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.

« pay peanuts, get monkeys » ou « pay monkeys, get peanuts ».

#11

C’est résolu!

En fait le client ldap fait des requêtes au srv LDAP pour connaitre les éventuels groupes ldap auxquel pourrait appatenir un user lors d’une authentification, et il y en a beaucoup.

Comme tous les groupes ldap ne sont pas utilisés sur ce client ldap, j’en ai sélectionné quelques un, grâce à un autre “tour de passe-passe” et l’utiisation de :

nss_base_group

dans /etc/libnss-ldap.conf

Du coup maintenant très peu de groupes ldap sont intérrogés, et l’authentification est très rapide.

[quote]Quand vous dites “autre utilisateur”, vous imaginez que par un tour de passe-passe vous allez pouvoir fourguer dans l’annuaire une entrée nommée “nagios” et la cacher sous le tapis, avec une histoire de groupe.
[/quote]

Merci pour l’ecoute