Bug 55283 - nss_ldap, pam_ldap not authentificating against openldap server
nss_ldap, pam_ldap not authentificating against openldap server
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: nss_ldap (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-10-29 03:58 EST by jehan procaccia
Modified: 2007-04-18 12:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-07-13 09:19:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description jehan procaccia 2001-10-29 03:58:29 EST
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-13 21:24:49 EST
Very similar problem from barry@atlas.otago.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-16 22:37:06 EST
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.

Note You need to log in before you can comment on or make changes to this bug.