+++ This bug was initially created as a clone of Bug #207286 +++ Description of problem: We are using Fedora Directory Server for authentication with password policies configured. When a user's account is locked out, xscreensaver allows access for that user with *any* password. Version-Release number of selected component (if applicable): This has only been noticed in xscreensaver-4.18-5.rhel4.11. We have not tried any prior versions supplied with RHEL 4. How reproducible: Always Steps to Reproduce: 1. Configure system to authenticate against Fedora Directory Server. 2. Log in as a user and start xscreensaver 3. Lockout the account (in this case, 3 bad passwords causes a lockout) 4. Enter any password into the xscreensaver login prompt Actual results: Xscreensaver does not deny access to locked out accounts. Expected results: Xscreensaver should not allow access to a locked out account. -- Additional comment from nalin on 2006-09-22 01:17 EST -- I'm looking at the pam_ldap sources, and it looks to me as though, when the directory server responds with a PasswordPolicyResponse control, the error for the bind request itself is suppressed so that it can be reported later from the pam_acct_mgmt() callback. So in this case, xscreensaver gets a success result from pam_authenticate(). It calls pam_acct_mgmt(), gets the error code which pam_ldap reports, and discards it. Steve, if you can attach a dump of the traffic between the client and the directory server (without SSL, using 'tcpdump -s 0'), we can verify that this is indeed what's happening in your setup. -- Additional comment from tmraz on 2006-09-22 02:13 EST -- I'm really curious why it was implemented this way in pam_ldap. It doesn't seem to be right behaviour at all. Regardless missing pam_acct_mgmt() result check in screensaver. -- Additional comment from srigler on 2006-09-22 08:29 EST -- Created an attachment (id=136939) tcpdump output I set the lockout threshold down to 1 bad password attempt. This tcpdump is of the initial bad password and then a second attempt using the same bad password where xscreensaver allows access. -- Additional comment from nalin on 2006-09-22 16:59 EST -- (In reply to comment #11) > I'm really curious why it was implemented this way in pam_ldap. It > doesn't seem to be right behaviour at all. Regardless missing > pam_acct_mgmt() result check in screensaver. I think the intent is to keep track of failure status which was received as part of the authentication response from the server, so that it can be reported from the account management phase, which is when the PAM spec says the application will expect it. -- Additional comment from nalin on 2006-09-22 18:01 EST -- Created an attachment (id=136980) updated source package with proposed patch Steve, can you rebuild the attached package and give it a try? I think the patch is correct, and will solve the problem, but I don't have a suitable test environment at the moment. -- Additional comment from srigler on 2006-09-22 18:26 EST -- This package clears up the immediate issue with xscreensaver. I can now lockout the user's account and xscreensaver won't let me back in no matter what password I give it. The only side-affect I've noticed is that other services (gdm and telnet) don't provide a notification that the account is locked. This isn't a show-stopper for us in any way and it might even be debatable (from a security perspective) whether it's really necessary to provide that much information for a login failure. Thanks for the quick turn around! -- Additional comment from bressers on 2006-09-27 16:33 EST -- Nalin, Does this bug affect all ldap servers, or only Fedora/RHDS? -- Additional comment from nalin on 2006-09-27 17:18 EST -- It's triggered by servers which implement the control. I don't really know how common it is, but my understanding is that current versions of OpenLDAP also implement it. A web search for the control's OID (1.3.6.1.4.1.42.2.27.8.5.1) suggests that IBM/Tivoli and Sun (of course) also implement it. -- Additional comment from bressers on 2006-09-29 10:26 EST -- Nalin, I'm under the impression we shold call this a secuirty issue and get a CVE id. Do you know if this issue also affects RHEL2.1, RHEL3, and Fedora Core? -- Additional comment from mjc on 2006-10-04 06:32 EST -- ping comment #18 -- Additional comment from nalin on 2006-10-04 10:33 EST -- The support for parsing and using the data from a password policy control received in the bind response was introduced in pam_ldap 169, so only RHEL 4 and Fedora Core versions 3 and later are affected.
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
This bug is open for a Fedora version that is no longer maintained and will not be fixed by Fedora. Therefore we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen thus bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.