Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

we have a couple of servers with PAM+LDAP.

The configuration is standard (see http://arthurdejong.org/nss-pam-ldapd/setup or http://wiki.debian.org/LDAP/PAM). For example, /etc/pam.d/common-auth contains:

auth sufficient pam_unix.so nullok_secure
auth requisite pam_succeed_if.so uid >= 1000 quiet
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so

And, of course, it works for both ldap and local users. But every login goes first to pam_unix.so, fails, and only then tries pam_ldap.so successfully. As a result, we have a well-known failure message for every single ldap user login:

pam_unix(<some_service>:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<some_host>  user=<some_user>

I have up to 60000 of such log messages per day and I want to change the configuration so, that PAM will try ldap authentication first, and only if it fails - try pam_unix.so (I think it can improve the i/o performance of the server). But if I change common-auth to the following:

auth sufficient pam_ldap.so use_first_pass
auth sufficient pam_unix.so nullok_secure
auth required pam_deny.so

Then I simply can't login anymore with local (non-ldap) user (e.g., via ssh).

Does somebody know the right configuration? Why Debian and nss-pam-ldapd have pam_unix.so at first by default? Is there really no way to change it?

Thank you in advance.

P.S. I don't want to disable logs, but want to set ldap authentication on the first place.

share|improve this question
3  
try deleting use_first_pass –  hayalci Dec 3 '12 at 17:06
    
Thanks a lot - it works! –  Andrey Sapegin Dec 4 '12 at 9:50
1  
Maybe you want to use ldap in your shadow database. You have to have a ldap nss module, configure it via /etc/libnss-ldap.conf and activate it nsswitch.conf: shadow files ldap After this your pam_unix.so module will lookup ldap entries for himself without need for the pam_ldap.so module. –  sebokopter Dec 4 '12 at 11:05

3 Answers 3

If local and network users are in separate uid ranges (which is a good idea), you may add a line like this one (supposing local users are in range 0-4999):

auth [success=1 default=ignore] pam_succeed_if.so uid >= 5000 quiet

before the pam_unix.so line. It will pass 1 line if uid >= 4999. It will go directly to pam_ldap.so.

And you have to change pam_ldap.so use_first_pass to pam_ldap.so or pam_ldap.so try_first_pass if you don't have a line that ask for the password before pam_ldap.so.

I'd test with :

auth [success=1 default=ignore] pam_succeed_if.so uid >= 4999 quiet
auth sufficient pam_unix.so nullok_secure
auth requisite pam_succeed_if.so uid >= 4999 quiet
auth sufficient pam_ldap.so
auth required pam_deny.so
share|improve this answer
    
It doesn't work: _____09:55:57 systemtests1 sshd[9933]: PAM pam_parse: expecting return value; [..., default=ignore] _____09:55:57 systemtests1 sshd[9933]: PAM pam_parse: expecting return value; [..., default=ignore] _____09:56:02 systemtests1 sshd[9933]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x user=yyy _____09:56:02 systemtests1 sshd[9933]: pam_ldap: error trying to bind as user "uid=yyy,ou=Users,dc=z,dc=local" (Invalid credentials) _____09:56:03 systemtests1 sshd[9933]: Failed password for yyy from 172.16.162.1 port 33112 ssh2 –  Andrey Sapegin Dec 4 '12 at 9:04
    
Sorry, there was a syntax error in my answer. Try with: [success=1 default=ignore] –  Christophe Drevet Dec 4 '12 at 9:07
    
I think first string should be '< 1000', and not '>=1000' It works then for ssh, but I cant 'su' as local user anymore. –  Andrey Sapegin Dec 4 '12 at 9:58
1  
No. With < 1000 pam_unix will be skipped for all users < 1000 (that's why you can't su). The line auth [success=1 default=ignore] pam_succeed_if.so uid >= 1000 quiet is actually working for me. There a catch: with this line, all local users won't be able to connect if their uid is greater than 1000. So, you can't filter with this number. Maybe all ldap users have uid greater than another number (say 5000). In this case you will be able to do what you want with: auth [success=1 default=ignore] pam_succeed_if.so uid >= 5000 quiet –  Christophe Drevet Dec 4 '12 at 11:31
up vote 0 down vote accepted

hayalci answered it in the comment:

auth sufficient pam_ldap.so
auth sufficient pam_unix.so nullok_secure try_first_pass
auth required pam_deny.so
share|improve this answer
2  
There's no argument try_first_path in the pam_unix.so module. And try_first_pass is useless in the first line. You can delete it like hayalci said. –  sebokopter Dec 4 '12 at 11:08
    
thanks. it should be try_first_pass, of course –  Andrey Sapegin Dec 4 '12 at 11:30
    
You'll have errors while local users try to connect. Am I wrong? –  Christophe Drevet Dec 4 '12 at 11:40
    
no, I don't have any errors with this configuration –  Andrey Sapegin Dec 4 '12 at 11:52

Your:

auth sufficient pam_unix.so nullok_secure  
auth requisite pam_succeed_if.so uid >= 1000 quiet  
auth sufficient pam_ldap.so use_first_pass  
auth required pam_deny.so  

Change to: (use_first_pass means use the password from the preceding module, which is pam_ldap.so)
a

uth sufficient pam_ldap.so  
auth requisite pam_succeed_if.so uid >= 1000 quiet  
auth sufficient pam_unix.so use_first_pass nullok_secure  
auth required pam_deny.so  

Disavantage (for hpux): If your ldap server hang (sync attack; see https://fedorahosted.org/389/ticket/47554 ) your client will hang as well, it happens for HPUX servers (not linux and aix; hpux process named ldapclientd). It means all login (even as root from ILO/MP) is blocked. Solution is reboot the server :-(. So I prefer pam_unix before pam_ldap on hpux

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.