1

I have a little problem regarding the way my users are authenticated.

My debian 7 is connected to an LDAP server using /etc/libnss-ldap.conf

I have some local users, and some ldap users.

On the nsswitch.conf file, I want that users are first search for in the "files" and only in "ldap" if not found in "files".

The problem is that for a local user that does the monitoring (nagios) I have some timeouts on my checks. When I try to "su nagios", it takes so much time!

When I try "strace su nagios", I can see there is a lot of request to the LDAP server, why that?

Here is the content of 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

I suspect something in the files that stand in /etc/pam.d. here is the content of some files:

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

Thx a lot in advance

HBruijn
  • 72,524
  • 21
  • 127
  • 192
vercetty92
  • 11
  • 4
  • It might be worth reviewing the strace output to identify which database (passwd, group, other) `su` is consulting when it's doing the LDAP lookups. Could it be trying to evaluate all the groups the target account belongs to? If that doesn't work then (if it can be done safely) enabling PAM debugging as suggested at http://serverfault.com/questions/249671/switch-on-pam-debugging-to-syslog might be worth a try, – Paul Haldane Sep 26 '16 at 20:59
  • the block that always come back on strace is: – vercetty92 Sep 27 '16 at 15:43
  • the pb is exactly what you said Paul! the system was looking for which ldap group a user belong to. I have also minimize the LDAP group presence using nss_base_group in /etc/libnss-ldap.conf, and now the authentication is fast! – vercetty92 Oct 17 '16 at 13:22
  • That's good to hear. I've combined my suggestion and the config tweak you found into an answer. – Paul Haldane Oct 17 '16 at 19:45

1 Answers1

0

It would be worth using strace and reviewing the output to identify which database (passwd, group, other) su is consulting when it's doing the LDAP lookups.

Sounds like it is searching the LDAP directory to find all the groups the target account belongs to. Solution was to set nss_base_group in /etc/libnss-ldap.conf to reduce the search space.

Paul Haldane
  • 4,457
  • 1
  • 20
  • 31