Bug 120694
Summary: | pam_unix logs pointless authentication failures when using LDAP | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 3 | Reporter: | Terry Griffin <griffint> |
Component: | pam | Assignee: | Tomas Mraz <tmraz> |
Status: | CLOSED UPSTREAM | QA Contact: | |
Severity: | low | Docs Contact: | |
Priority: | medium | ||
Version: | 3.0 | CC: | andyj, bugzilla_rhn, dlehman, jpay, tao |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-01-05 09:00:54 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
Terry Griffin
2004-04-13 02:15:18 UTC
I can confirm this bug in RHEL3, and would like to suggest that its underlying cause is creating more trouble than just annoying log messages. I think this bug also allows unprivileged users to crash the cron service by simply editing their crontabs. The ipop3d and imapd services seem to try authenticating twice. They fail on the pam_unix.so line in system-auth, but succeed on the next try which calls pam_ldap.so. Cron appears to try once, and fails for non-local users--those that need to be authenticated via ldap: Jun 17 11:40:31 bengal crontab[3025]: (andyj) BEGIN EDIT (andyj) Jun 17 11:40:59 bengal crontab[3025]: (andyj) REPLACE (andyj) Jun 17 11:40:59 bengal crontab[3025]: (andyj) END EDIT (andyj) Jun 17 11:41:00 bengal crond[2762]: nss_ldap: reconnecting to LDAP server... Jun 17 11:41:00 bengal crond[2762]: nss_ldap: reconnected to LDAP server after 1 attempt(s) At this point the cron daemon is dead. I have reversed the order of the pam_unix.so and pam_ldap.so lines in my /etc/pam.d/system-auth file. This eliminates both the annoying log messages from imap3 and ipop3d and fixes the problem with cron. My experimental system-auth contains: auth sufficient /lib/security/$ISA/pam_ldap.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok use_first_pass We're using vixie-cron-3.0.1. This isn't a manifestation of #5160, is it? Andy, I may be very wrong on this. But, if the user lookup in LDAP fails, or the server is unavailable to answer, how will that inpact the system once you have reversed the entries? I'm just wondering if you'll run in to problems when you are unable to cleanly shutdown the system, or log in as root when the LDAP server is non-responsive. doug This is in response to Comment #1, which I realize is probably in vain. First, it seems worth noting that vixie-cron3.0.1 doesn't use PAM at all. The message you are seeing suggests the nss_ldap library is having trouble connecting with your LDAP server (otherwise it wouldn't need to reconnect). A related problem in nss_ldap is that LDAP libraries generate SIGPIPE when they encounter certain connectivity problems (I'm no LDAP expert) and nss_ldap doesn't properly ignore SIGPIPE signals recieved during LDAP operations. So, when nss_ldap recieves the SIGPIPE instead of ignoring it, the default action is to kill the caller, which in this case is crond. There is a fix for this in later upstream sources. I'm not sure how much coincidence was involved in the resolution of Andy's problem, and I am not absolutely certain I have the right answer here. I am currently in the process of verifying the fix I mention in a similar scenario. Good morning Dave. Can you point me towards the other ¨scenario¨ you were refering to? As I am having the same error messages appearing in my log files, and am also using LDAP. The errors only appear one a user connects that is not a local users, but IS listed in the LDAP directory. I've seen ssh sessions getting dropped after repeatedly expanding ~someuser (which was verified as caused by the behavior I describe above - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134567). I'm now seeing a case where running 'crontab -e' as an LDAP user crashes crond (it is not yet clear that this is caused by nss_ldap). If you are not seeing applications die your messages simply mean your LDAP server has connectivity issues: you get those messages after failed attempts to connect to the LDAP server. Fixed in upstream CVS - if the pam_unix module finds passwd entry but it can't find password for that, it won't log 'user unknown' failure. This should fix the bug in the most common circumstances. The problem you describe as solved isn't the problem I reported. In my scenario there's no passwd entry _at all_ because the user is defined entirely in LDAP. In that case pam_unix logs a "user unknown" error followed by an "authentication failure" error even though the user is ultimately authenticated by pam_ldap. Why do individual PAM modules have to log anything at all (except maybe for debug mode)? When individual PAM modules in a PAM stack do logging it leads to useless clutter in the logs files and unintended consequences like bug #120368. (Since claimed to have been fixed but I don't know how.) Leave it to the services (imapd etc.) do the logging after a final authentication pass/fail result has been returned from the PAM stack. Yes it is the problem. Maybe my comment wasn't clear. It will find a passwd entry not directly from /etc/passwd file but by a getpwnam/getpwuid call through nss_ldap. Otherwise your authentication wouldn't work at all. About your idea that all logging should be done only in debug mode - feel free to propose it on PAM mailing list pam-list. But I think that only way how it could be implemented is that you would have to add a quiet option to all modules and if it would be present it would disable all logging of the modules. The current default behaviour shouldn't be changed as too many people depend on it. I have implamented AD4UNIX, I am able to login with the AD/LDAP user, quickly and without errors in messages. Problem I have is that after I have connected with ldap account, when I sudo I get sudo: nss_ldap: reconnecting to LDAP server (sleeping 4 and repeats, 4,8,16,32,64 till server is unavailable, Strange thing is, once the timeouts have finished, I get prompted for the ldap password and I am able to sudo. The group which is being used as the sudo rule is also an LDAP group, so the authentication is actually working, but there is a delay. Any advise would be helpfull. Jason, that is a completely different bug or configuration problem. You can report it against nss_ldap. |