Bug 52618
| Summary: | pam/ldap authentication weirdness | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Mike Nolta <mike> |
| Component: | pam_ldap | Assignee: | Nalin Dahyabhai <nalin> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.1 | ||
| 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:00:30 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: | |||
ssh pam configuration seems to OK in RH 7.3 su pam configuration is still wrong when pam_ldap is used. Apparently this is fixed in the current release. |
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.