From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 Description of problem: Since I installed RH 7.2 on my client I can no longer login in. I use ldap authentification with an openldap 2.0.11 server running in a linux RH 7.1 i386 server. I worked with a RH 7.1 client. I noticed in the /var/log/messages, that it was pam_unix that refused the connection ! > Oct 25 09:47:56 corne login(pam_unix)[2864]: check pass; user unknown > Oct 25 09:47:56 corne login(pam_unix)[2864]: authentication failure; > logname= uid=0 euid=0 tty=pts/3 ruser= rhost=localhost.localdomain Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.telnet localhost 2.or su - username (present in openldap) 3.here what is happening: > Client: > > [mciadmin@corne mciadmin]$ telnet localhost > Trying 127.0.0.1... > Connected to localhost. > Escape character is '^]'. > Red Hat Linux release 7.2 (Enigma) > Kernel 2.4.9-7 on an i686 > login: test > > openldap server log after the client entered the login: > > Oct 25 09:47:33 openldap slapd[6264]: daemon: conn=6 fd=16 connection from > IP=157.159.21.54:1170 (IP=157.159.15.17:34049) accepted. > Oct 25 09:47:33 openldap slapd[6264]: conn=6 op=0 BIND dn="" method=128 > Oct 25 09:47:33 openldap slapd[6264]: conn=6 op=0 RESULT tag=97 err=0 > text= > Oct 25 09:47:33 openldap slapd[6264]: conn=6 op=1 SRCH > base="dc=int-evry,dc=fr" scope=2 > filter="(&(objectClass=posixAccount)(uid=test))" > Oct 25 09:47:33 openldap slapd[6264]: conn=6 op=1 SEARCH RESULT tag=101 > err=0 text= > Oct 25 09:47:33 openldap slapd[6264]: conn=6 op=2 SRCH > base="dc=int-evry,dc=fr" scope=2 > filter="(&(objectClass=posixAccount)(uid=test))" > Oct 25 09:47:33 openldap slapd[6264]: conn=6 op=2 SEARCH RESULT tag=101 > err=0 text= > Oct 25 09:47:33 openldap slapd[6264]: conn=6 op=3 SRCH > base="dc=int-evry,dc=fr" scope=2 > filter="(&(objectClass=shadowAccount)(uid=test))" > Oct 25 09:47:33 openldap slapd[6264]: conn=6 op=3 SEARCH RESULT tag=101 > err=0 text= > > Back to the client, where user test enter his password > > Password: xxxxxxx > > Authentication failure> Connection closed by foreign host. > > openldap server log says after the client entered the password: > > Oct 25 09:47:56 openldap slapd[6264]: conn=6 op=4 SRCH > base="dc=int-evry,dc=fr" scope=2 > filter="(&(objectClass=posixAccount)(uid=test))" > Oct 25 09:47:56 openldap slapd[6264]: conn=6 op=4 SEARCH RESULT tag=101 > err=0 text= > Oct 25 09:47:56 openldap slapd[6264]: conn=6 op=5 SRCH > base="dc=int-evry,dc=fr" scope=2 > filter="(&(objectClass=shadowAccount)(uid=test))" > Oct 25 09:47:56 openldap slapd[6264]: conn=6 op=5 SEARCH RESULT tag=101 > err=0 text= > Oct 25 09:47:56 openldap slapd[6264]: daemon: conn=7 fd=17 connection from > IP=157.159.21.54:1171 (IP=157.159.15.17:34049) accepted. > Oct 25 09:47:56 openldap slapd[6264]: conn=7 op=0 BINDdn="" method=128 > Oct 25 09:47:56 openldap slapd[6264]: conn=7 op=0 RESULT tag=97 err=0 > text=> Oct 25 09:47:56 openldap slapd[6264]: daemon: conn=7 fd=17 connection from > IP=157.159.21.54:1171 (IP=157.159.15.17:34049) accepted. > Oct 25 09:47:56 openldap slapd[6264]: conn=7 op=0 BIND dn="" method=128 > Oct 25 09:47:56 openldap slapd[6264]: conn=7 op=0 RESULT tag=97 err=0 > text= > Oct 25 09:47:56 openldap slapd[6264]: conn=7 op=1 SRCH > base="dc=int-evry,dc=fr" scope=2 filter="(uid=test)" > Oct 25 09:47:56 openldap slapd[6264]: conn=7 op=1 SEARCH RESULT tag=101 > err=0 text= > Oct 25 09:47:56 openldap slapd[6264]: conn=7 op=2 BIND > dn="UID=TEST,OU=PEOPLE,DC=INT-EVRY,DC=FR" method=128 > Oct 25 09:47:56 openldap slapd[6264]: conn=7 op=2 RESULT tag=97 err=0 > text= > Oct 25 09:47:56 openldap slapd[6264]: conn=7 op=3 BIND dn="" method=128 > Oct 25 09:47:56 openldap slapd[6264]: conn=7 op=3 RESULT tag=97 err=0 > text= > Oct 25 09:47:56 openldap slapd[6264]: conn=6 op=6 SRCH > base="dc=int-evry,dc=fr" scope=2 > filter="(&(objectClass=posixAccount)(uid=test))"> Oct 25 09:47:56 openldap slapd[6264]: conn=6 op=6 SEARCH RESULT tag=101 > err=0 text= > Oct 25 09:47:56 openldap slapd[6264]: conn=6 op=7 SRCH > base="dc=int-evry,dc=fr" scope=2 > filter="(&(objectClass=shadowAccount)(uid=test))" > Oct 25 09:47:56 openldap slapd[6264]: conn=6 op=7 SEARCH RESULT tag=101 > err=0 text= > Oct 25 09:47:56 openldap slapd[6264]: conn=7 op=4 UNBIND > Oct 25 09:47:56 openldap slapd[6264]: conn=-1 fd=17 closed > Oct 25 09:47:56 openldap slapd[6264]: conn=-1 fd=16 closed > > back to localhost (client corne ) /var/log/messages says: > > Oct 25 09:47:56 corne login(pam_unix)[2864]: check pass; user unknown > Oct 25 09:47:56 corne login(pam_unix)[2864]: authentication failure; > logname= uid=0 euid=0 tty=pts/3 ruser= rhost=localhost.localdomain > Oct 25 09:47:56 corne login[2864]: Authentication failure > client (corne) /etc/ldap.conf is left to default, everything commented > exept: > > host openldap.int-evry.fr > base dc=int-evry,dc=fr > ssl no > pam_password md5 Actual Results: $ telnet localhost Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Red Hat Linux release 7.2 (Enigma) Kernel 2.4.9-7 on an i686 login: procacci Password: Authentication failure Connection closed by foreign host. Expected Results: $ telnet localhost Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Red Hat Linux release 7.2 (Enigma) Kernel 2.4.9-7 on an i686 login: procacci Password: Last login: Mon Oct 29 09:12:18 from localhost.localdomain corne.int-evry.fr:/mci/mci/procacci> Additional info: I did solved the problem, modifying /etc/pam.d/login : original pam stack ( which doesn't work !) $ cat /etc/pam.d/login.orig #%PAM-1.0 auth required /lib/security/pam_securetty.so auth required /lib/security/pam_stack.so service=system-auth auth required /lib/security/pam_nologin.so account required /lib/security/pam_stack.so service=system-auth password required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_stack.so service=system-auth session optional /lib/security/pam_console.so $ cat /etc/pam.d/system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required /lib/security/pam_env.so auth sufficient /lib/security/pam_unix.so likeauth nullok auth sufficient /lib/security/pam_ldap.so use_first_pass auth required /lib/security/pam_deny.so account required /lib/security/pam_unix.so account required /lib/security/pam_ldap.so password required /lib/security/pam_cracklib.so retry=3 type= password sufficient /lib/security/pam_unix.so nullok use_authtok md5 shadow password sufficient /lib/security/pam_ldap.so use_authtok password required /lib/security/pam_deny.so session required /lib/security/pam_limits.so session required /lib/security/pam_unix.so session optional /lib/security/pam_ldap.so Now I changed /etc/pam.d/login to : $ cat /etc/pam.d/login.rh7.1 #%PAM-1.0 auth required /lib/security/pam_securetty.so auth required /lib/security/pam_nologin.so auth sufficient /lib/security/pam_ldap.so auth required /lib/security/pam_unix_auth.so try_first_pass account sufficient /lib/security/pam_ldap.so account required /lib/security/pam_unix_acct.so password required /lib/security/pam_cracklib.so password required /lib/security/pam_ldap.so password required /lib/security/pam_pwdb.so use_first_pass session required /lib/security/pam_unix_session.so #session optional /lib/security/pam_console.so And it works ! ( I didn't check password changing ; /etc/pam.d/passwd yet however ).
Very similar problem from barry.ac.nz Have ldap authentication using TLS working with RH7.1 kernel 2.4.3-12 (openldap 2.0.11-8, openssh 2.5.2p2-5, nss_ldap 149-4, openssl 0.9.6-9) on a 800MHz 686. When upgrade client to 7.2 kernel 2.4.7-10 (openldap 2.0.11-13, openssh 2.9p2-12, nss_ldap 172-2, openssl 0.9.6b-8) it will not authenticate to either 7.2 or 7.1 server. An existing 7.1 client will ldap authenticate to the 7.2 server. Failure of TLS apparent when upgrading nss_ldap. Removing TLS requirement fixes problem but password is now clear text. The above changes to /etc/pam.d/login is not a fix for this problem. Client snip from /var/log/messages client1 login(pam_unix)[16563]: check pass; user unknown client1 login(pam_unix)[16563]: authentication failure; logname= uid=0 euid=0 tty=tty1 ruser= rhost= Dec 14 13:17:32 client1 login[16563]: pam_ldap: ldap_set_option(LDAP_OPT_X_TLS_REQUIRE_CERT) :Unknown error client1 login[16563]: pam_ldap: _set_ssl_default_options failed client1 login[16563]: pam_ldap: ldap_starttls_s: Connect error client1 login[16563]: FAILED LOGIN 1 FROM (null) FOR sastaff, Authentication failure client1 login(pam_unix)[16563]: check pass; user unknown client1 login(pam_unix)[16563]: could not identify user (from getpwnam(sastaff)) client1 login[16563]: User not known to the underlying authentication module client1 login(pam_unix)[16563]: 1 more authentication failure; logname=uid=0 euid=0 tty=tty1 ruser= rhost= I believe a seperate openldap problem is resulting in the ldap_start_tls_s error.
Please ignore previous comment, the problem was that the SSL certificate was not signed with the FQDN hostname. openldap and nss_ldap released with 7.1 were not as strict as the 7.2 releases.