Bug 782917

Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/bfdbd3b6ad7c437e7dd293d2488b2d53f4ea7ba6

Upstream fix was reverted as severe regressions were found, see
https://fedorahosted.org/freeipa/ticket/1539#comment:35
for details.

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

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  |
       |                 |
       |                 |
       +-----------------+

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.

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.

The engineering team have not reached agreement on the implementation detail.
Thus, there is no ETA yet.

Fixed upstream
master:
https://pagure.io/freeipa/c/f347c3f2302e468b7f92ec0146100b19570e382e
https://pagure.io/freeipa/c/2d5e6935140c92b4faf0e2866c8f80f6a53c73d9
https://pagure.io/freeipa/c/aefa5f22520d565f5accfc2257f48ff31be9b17b

ipa-4-9:

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

Handle upgrades
Fixed upstream
master:
https://pagure.io/freeipa/c/773d3cb45d70e53e971f0efbbcecb0e54cb52d04

Handle upgrades
Fixed upstream
ipa-4-9:
https://pagure.io/freeipa/c/62bafcc53d4f45b28eb9a541e5385c2f1e7a3f97

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

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

Moving back to ASSIGNED. An issue was discovered during verification of the 9.1 clone.

Additional fix:
master:
    22d1392 Only calculate LDAP password grace when the password is expired

Fixed upstream
ipa-4-9:
https://pagure.io/freeipa/c/3675bd1d7aca443832bb9bb2f521cc4d3a088aec

Fixed upstream
ipa-4-10:
https://pagure.io/freeipa/c/33cd62e0daa68fa6a9b3ca495d97ac5ce8713349

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