Bug 52618 - pam/ldap authentication weirdness
Summary: pam/ldap authentication weirdness
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: pam_ldap   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2001-08-27 06:44 UTC by Mike Nolta
Modified: 2007-04-18 16:36 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-07-13 13:00:30 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Mike Nolta 2001-08-27 06:44:26 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.2-2 i686; Nav)

Description of problem:

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. (see Additional Information)

Additional info:

I'm setting up ldap authenication using the standard RH packages
(openldap*, nss_ldap). I basically followed the instructions in the
Reference Guide and used authconfig and the migrate scripts from
padl.com. After a little nashing of teeth I got it to work - sort of. 

Some background: there's a user ('testuser') in the LDAP directory which
isn't in the flat files. The nsswitch.conf is set to look in "files ldap".
The regular users work fine; the only problems are with testuser.

I noticed some strange behavior while playing around with
/etc/pam.d/system-auth, centering on the {use,try}_first_pass options. I
only modified the following lines, which were setup by authconfig:

auth        sufficient    /lib/security/pam_unix.so likeauth
auth        sufficient    /lib/security/pam_ldap.so use_first_pass

For each configuration I tried two tests: 1) ssh'ing in as testuser (ssh -l
testuser myhost), and 2) su'ing to testuser from a normal (i.e. non-LDAP)
account (su - testuser).

This table summarizes the results:

         pam.d/system-auth      ssh             su
         unix,ldap use          +2              -1
         unix,ldap try          +1              +2
         unix,ldap              +2              -2

         ldap,unix use          +2              -1
         ldap,unix try          +2              -1
         ldap,unix              +2              -2
         +/-n : sucess/fail after entering password n times


* pam.d/system-auth column:

The first column is a shorthand description of the modifications made to
/etc/pam.d/system-auth. The entry on the first line "unix,ldap use"
corresponds to the original configuration listed above. It says "do
pam_unix.so, then do pam_ldap.so with the use_first_pass option". The
keyword "try" is short for "try_first_pass". For example, "ldap,unix try"

auth        sufficient    /lib/security/pam_ldap.so
auth        sufficient    /lib/security/pam_unix.so try_first_pass likeauth

The "likeauth" option was always passed to pam_unix. 

* ssh/su columns:

These columns show the status of the ssh and su tests. The +/- indicates
whether the test succeeded/failed (i.e. was I able to become testuser). The
number indicates how many times I was asked for a password.


With the authconfig configuration (line 1), I can ssh in (but need to enter
the password twice) and can't su. Switching "use_first_pass" to
"try_first_pass" fixes both problems (but I need to enter the password
twice for su).  From what I understand about the use/try options this
behavior doesn't make sense, since I made sure to enter the same
password both times.

Comment 1 Pawel Salek 2002-08-08 12:49:54 UTC
ssh pam configuration seems to OK in RH 7.3
su pam configuration is still wrong when pam_ldap is used.

Comment 2 Nils Philippsen 2003-07-13 13:00:30 UTC
Apparently this is fixed in the current release.

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