Bug 52618 - pam/ldap authentication weirdness
pam/ldap authentication weirdness
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: pam_ldap (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-08-27 02:44 EDT by Mike Nolta
Modified: 2007-04-18 12:36 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:00:30 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 Mike Nolta 2001-08-27 02:44:26 EDT
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:
Always

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

Notation 
--------

* 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"
means:

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.

Results
-------

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 08:49:54 EDT
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 09:00:30 EDT
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.