Issue 7788 - pwdFailureTime and pwdChangedTime registered in user entry even if no ppolicy associated with the entry
Summary: pwdFailureTime and pwdChangedTime registered in user entry even if no ppolicy...
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: 2.4.38
Hardware: All All
: --- normal
Target Milestone: 2.5.3
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-16 16:53 UTC by Clément OUDOT
Modified: 2021-03-25 22:17 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Clément OUDOT 2014-01-16 16:53:46 UTC
Full_Name: Clement OUDOT
Version: 2.4.38
OS: GNU/Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (83.145.72.122)


Hi,

I have configured a ppolicy overlay without olcPPolicyDefault value. So I use
pwdPolicySubentry in user entries to bind them to their policy configuration
entry.

Overlay ppolicy is compiled in slapd, not as module. I use LTB package.

If I create an account without pwdPolicySubentry, the attributes pwdChangedTime
and pwdFailureTime are generated for this entry. And as the entry is never
locked (which is a normal behavior, fixed in
http://www.openldap.org/its/index.cgi?findid=6168), the number of values in
pwdFailureTime can grow indefinitely.

IMHO, no ppolicy operational attributes should be present in an entry not linked
to a password policy.
Comment 1 Michael Ströder 2014-03-01 12:27:17 UTC
I do not consider this to be a bug.
I'd vote for closing it as "won't fix".

Comment 2 Quanah Gibson-Mount 2020-03-20 18:12:27 UTC
Could examine if it's possible to have ppolicy not process entries with no policy.  May not be possible w/o unreasonable overhead.
Comment 3 Ondřej Kuzník 2020-06-02 16:53:46 UTC
Hi Clément,
this should still be possible if you set a default policy with pwdMaxRecordedFailure == 0, is there a reason this would not be appropriate before we go changing the default behaviour?

Thanks,
Ondrej
Comment 4 Clément OUDOT 2020-06-02 17:30:46 UTC
I don't think this solves the issue. The problem is on entries that are not linked to any password policy are updated by ppolicy overlay. Adding a parameter in the password policy is not a good solution from my point of view.

The entry should never be updated by ppolicy overlay if no ppolicy definition is applied to it.

Note that this bug was opened 6 years ago, I did not test recent OpenLDAP versions.
Comment 5 Ondřej Kuzník 2020-06-03 13:20:18 UTC
I have created a patchset that attempts to address this and other ppolicy related issues here:
https://git.openldap.org/openldap/openldap/-/merge_requests/77

Please review, test and let me know if this addresses the issue and if you have any other comments.
Comment 6 Quanah Gibson-Mount 2020-07-06 17:58:01 UTC
  • 49504c16 
by Ondřej Kuzník at 2020-07-03T20:42:14+00:00 
Fix whitespace in ppolicy.c


  • 3e0447f4 
by Ondřej Kuzník at 2020-07-03T20:42:14+00:00 
ITS#7089 Skip lockout checks/modifications if password attribute missing


  • 3ec005a0 
by Ondřej Kuzník at 2020-07-03T20:42:14+00:00 
ITS#7788 Report if there is a policy that applies


  • 0b6ac3fd 
by Ondřej Kuzník at 2020-07-03T20:42:14+00:00 
ITS#7788 Skip lockout processing if no policy applies


  • a030aacc 
by Ondřej Kuzník at 2020-07-03T20:42:14+00:00 
ITS#7788 Allow pwdFailureTime tracking be disabled in policy


  • 376d5d65 
by Ondřej Kuzník at 2020-07-03T20:42:14+00:00 
ITS#7084 ACL of 'manage' gives pasword administrator access

Password administrators can bypass safeModify, password quality checks
and trigger reset if policy instructs the server to.


  • e05c09b9 
by Ondřej Kuzník at 2020-07-03T20:42:14+00:00 
ITS#8762 Clear pwdFailureTime on unlock


  • 5bf16496 
by Ondřej Kuzník at 2020-07-03T20:42:14+00:00 
ITS#7084, ITS#7089, ITS#7788 Update test to account for new functionality
Comment 7 Quanah Gibson-Mount 2021-03-25 22:17:29 UTC
Commits: 
  • 109d967f 
by Ondřej Kuzník at 2021-03-25T19:43:18+00:00 
ITS#7788 Hashing should be independent of a useable policy