Bug 55283

Summary:	nss_ldap, pam_ldap not authentificating against openldap server
Product:	[Retired] Red Hat Linux	Reporter:	jehan procaccia <jehan.procaccia>
Component:	nss_ldap	Assignee:	Nalin Dahyabhai <nalin>
Status:	CLOSED NOTABUG	QA Contact:	Aaron Brown <abrown>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.2
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2003-07-13 13:19:08 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description jehan procaccia 2001-10-29 08:58:29 UTC

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 ).

Comment 1 Barry Wright 2001-12-14 02:24:49 UTC

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.

Comment 2 Barry Wright 2001-12-17 03:37:06 UTC

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.