RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 782917 - [RFE] Add code to check password expiration on ldap bind
Summary: [RFE] Add code to check password expiration on ldap bind
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: ipa
Version: ---
Hardware: Unspecified
OS: Unspecified
Target Milestone: pre-dev-freeze
: ---
Assignee: Rob Crittenden
QA Contact: ipa-qe
Filip Hanzelka
Depends On:
Blocks: 2091988
TreeView+ depends on / blocked
Reported: 2012-01-18 20:54 UTC by Dmitri Pal
Modified: 2023-10-06 17:25 UTC (History)
42 users (show)

Fixed In Version: ipa-4.9.10-1.module+el8.7.0+15691+2b2c1dd5
Doc Type: Enhancement
Doc Text:
.IdM now supports a limit on the number of LDAP binds allowed after a user password has expired With this enhancement, you can set the number of LDAP binds allowed when the password of an Identity Management (IdM) user has expired: -1:: IdM grants the user unlimited LDAP binds before the user must reset the password. This is the default value, which matches the previous behavior. 0:: This value disables all LDAP binds once a password is expired. In effect, the users must reset their password immediately. 1-MAXINT:: The value entered allows exactly that many binds post-expiration. The value can be set in the global password policy and in group policies. Note that the count is stored per server. In order for a user to reset their own password they need to bind with their current, expired password. If the user has exhausted all post-expiration binds, then the password must be administratively reset.
Clone Of:
: 2091988 (view as bug list)
Last Closed: 2022-11-08 09:35:45 UTC
Type: Bug
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker FREEIPA-6974 0 None None None 2021-09-29 14:23:53 UTC
Red Hat Product Errata RHBA-2022:7540 0 None None None 2022-11-08 09:36:23 UTC

Description Dmitri Pal 2012-01-18 20:54:00 UTC
This bug is created as a clone of upstream ticket:

We have code to hook pre_bind in the paswword plugin but we use it only for password migrations.

We should add code to check if the password is expired in order to fail the bind.
The code requires only a minimal change to do that.

Comment 3 Martin Kosek 2014-06-09 06:20:22 UTC
Fixed upstream

Comment 4 Martin Kosek 2014-06-11 12:28:43 UTC
Upstream fix was reverted as severe regressions were found, see
for details.

Comment 14 Dmitri Pal 2019-03-13 00:10:03 UTC

This issue has been lingering around for several years.
The reason it was not addressed is that it turned out to be not that simple as it was originally anticipated.
The problem is that closing the ability to bind while the password is expired prevents from password being changed.
Over the years several ideas have been proposed but none of them seems like a viable solution.
In the past couple rounds of patches have been produced but those led to unforeseen breakages in the client applications and were pulled out.
It is unlikely that a good solution that would not have a negative impact on the existing deployments will be found (this was tried multiple times, see upstream ticket and upstream mail archives).
We will look at this issue once again during this calendar year. But if we still can't find a safe solution that would not lead to regressions we would have to close this issue as WONTFIX.

Thank you,

Comment 20 Josh Preston 2019-08-26 23:04:12 UTC
I am working with a customer (see RH case 02436959) on a couple ideas to work around this security issue.  We are curious whether the following 1) made sense 2) would work.  The current thought would be to present a proxied login where filters could be applied:

LDAP Clients would connect to a proxied directory server / instance (backed by 389 IdM), where filters could deny logins for expired passwords, locked accounts, etc.  By pointing authentication clients to this source, we could enforce those policies for other third party applications that utilize LDAP for authentication.

       |                 |
       |  LDAP Clients   |
       |  Non-RH OS      |
       |  3rd Party App  |
       |                 |
|  User Authentication          |
       |                 |
       |   LDAP          |
       |   Proxy Cache   |
       |                 |
       |                 |
|  Password Expiration Filter   <
|  Account Lockout Filter       <
|  Password Reset Filter        <
       |                 |
       |                 |
       |  RH IdM 389 DS  |
       |                 |
       |                 |

Comment 21 Rob Crittenden 2019-09-10 20:25:25 UTC
You'd have to really trust this cache because it would be handling unhashed passwords. And be sure that there is no other route from whatever 3rd party app directly to the IdM server. I imagine it would be trivial to bypass unless you firewalled it off.

You don't need to deal with lockout as that is already handled. I'm not sure what you mean by password reset.

The only thing the proxy would need to do is look at krbpasswordexpiration and reject the login if it is expired. Otherwise it would need to be a transparent proxy.

I don't think I'd use the cache either as that suggests it will maintain its own cache of results which could be dangerous on its own.

Comment 22 Dmitri Pal 2019-09-11 21:49:04 UTC
The reason for the behavior is that one should be able to change the password over LDAP once the password has expired.
It is a bit of a chicken and egg problem. If we do not allow the change people will be stuck and would not be able to change the password.

If this is a problem the better approach would be not to use LDAP but rather Kerberos or integrate with SSSD.
IMO it would be faster and simpler than building the cache solution proposed in #20.

Comment 38 Ding-Yi Chen 2022-01-13 07:37:00 UTC
The engineering team have not reached agreement on the implementation detail.
Thus, there is no ETA yet.

Comment 44 Florence Blanc-Renaud 2022-05-31 12:20:00 UTC

    4fcbf2d Implement LDAP bind grace period 389-ds plugin
    6b3ab98 Remove the replicated attribute constants
    87fe3fb Exclude passwordgraceusertime from replication

Comment 45 Rob Crittenden 2022-06-02 19:25:53 UTC
Handle upgrades
Fixed upstream

Comment 46 Florence Blanc-Renaud 2022-06-03 07:54:23 UTC
Handle upgrades
Fixed upstream

Comment 51 Rob Crittenden 2022-06-30 12:38:07 UTC
Moving back to ASSIGNED. An issue was discovered during verification of the 9.1 clone.

Comment 52 Florence Blanc-Renaud 2022-06-30 14:31:24 UTC
Additional fix:
    22d1392 Only calculate LDAP password grace when the password is expired

Comment 53 Rob Crittenden 2022-06-30 18:57:19 UTC
Fixed upstream

Comment 56 Florence Blanc-Renaud 2022-07-06 16:27:12 UTC
Fixed upstream

Comment 71 errata-xmlrpc 2022-11-08 09:35:45 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (idm:client and idm:DL1 bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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