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
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: ipa
Version: ---
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: pre-dev-freeze
: ---
Assignee: Rob Crittenden
QA Contact: ipa-qe
Filip Hanzelka
URL:
Whiteboard:
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)
Environment:
Last Closed: 2022-11-08 09:35:45 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
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:
https://fedorahosted.org/freeipa/ticket/1539

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
master:
https://fedorahosted.org/freeipa/changeset/bfdbd3b6ad7c437e7dd293d2488b2d53f4ea7ba6
Comment 4 Martin Kosek 2014-06-11 12:28:43 UTC 
Upstream fix was reverted as severe regressions were found, see
https://fedorahosted.org/freeipa/ticket/1539#comment:35
for details.
Comment 14 Dmitri Pal 2019-03-13 00:10:03 UTC 
Hello,


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,
Dmitri
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  |
       |                 |
       +-------+---------+
               |
               v
+--------------+----------------+
|  User Authentication          |
+--------------+----------------+
               |
               v
       +-------+---------+
       |                 |
       |   LDAP          |
       |   Proxy Cache   |
       |                 |
       |                 |
       +-------+---------+
               |
               v
+--------------+----------------+
|  Password Expiration Filter   <
+-------------------------------+
+-------------------------------+
|  Account Lockout Filter       <
+-------------------------------+
+-------------------------------+
|  Password Reset Filter        <
+--------------+----------------+
               |
               v
       +-------+---------+
       |                 |
       |                 |
       |  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 42 Alexander Bokovoy 2022-05-30 14:25:23 UTC 
Fixed upstream
master:
https://pagure.io/freeipa/c/f347c3f2302e468b7f92ec0146100b19570e382e
https://pagure.io/freeipa/c/2d5e6935140c92b4faf0e2866c8f80f6a53c73d9
https://pagure.io/freeipa/c/aefa5f22520d565f5accfc2257f48ff31be9b17b
Comment 44 Florence Blanc-Renaud 2022-05-31 12:20:00 UTC 
ipa-4-9:

    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
master:
https://pagure.io/freeipa/c/773d3cb45d70e53e971f0efbbcecb0e54cb52d04
Comment 46 Florence Blanc-Renaud 2022-06-03 07:54:23 UTC 
Handle upgrades
Fixed upstream
ipa-4-9:
https://pagure.io/freeipa/c/62bafcc53d4f45b28eb9a541e5385c2f1e7a3f97
Comment 47 Rob Crittenden 2022-06-06 15:26:11 UTC 
Design document, default grace period change, upgrade fix
master:
https://pagure.io/freeipa/c/08ab274744794f269081f4ba0259e662038ab9a3
https://pagure.io/freeipa/c/deb0c765561bc5dbc42c509005e4aab57d0b4a0b
https://pagure.io/freeipa/c/420344ed49e5b50454853969c5edfcc7190d1de7
Comment 49 Florence Blanc-Renaud 2022-06-07 06:16:39 UTC 
Design document, default grace period change, upgrade fix
Fixed upstream
ipa-4-9:
https://pagure.io/freeipa/c/d2b296454c57ab639b8e023050dabc193693c42f
https://pagure.io/freeipa/c/9b0fbdc37b92981d541a4152fdfeb0964692878f
https://pagure.io/freeipa/c/e6cc41094b2bc526e9f8e87229e8f83a74cfc263
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:
master:
    22d1392 Only calculate LDAP password grace when the password is expired
Comment 53 Rob Crittenden 2022-06-30 18:57:19 UTC 
Fixed upstream
ipa-4-9:
https://pagure.io/freeipa/c/3675bd1d7aca443832bb9bb2f521cc4d3a088aec
Comment 56 Florence Blanc-Renaud 2022-07-06 16:27:12 UTC 
Fixed upstream
ipa-4-10:
https://pagure.io/freeipa/c/33cd62e0daa68fa6a9b3ca495d97ac5ce8713349
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.

https://access.redhat.com/errata/RHBA-2022:7540
Note You need to log in before you can comment on or make changes to this bug.