Full_Name: Noel K�the Version: 2.4.25 OS: Debian GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.187.103.39) Hello, using the ppolicy overlay with no special options: slapd.conf ... overlay ppolicy ppolicy_default "cn=ppolicy,dc=domain,dc=lan" ppolicy_use_lockout ... cn=ppolicy,dc=domain,dc=lan objectClass: top objectClass: device objectClass: pwdPolicy objectClass: pwdPolicyChecker cn: ppolicy pwdMaxAge: 2592000 pwdExpireWarning: 3600 pwdMaxFailure: 5 pwdLockout: TRUE pwdMustChange: TRUE pwdMinLength: 6 pwdSafeModify: FALSE pwdAttribute: userPassword I'm scanning the LDAP data for PWDFAILURETIME attributes from time to time and found the following ou with this attribute (slapcat output): dn: ou=test,dc=domain,dc=lan objectClass: organizationalUnit ou: test structuralObjectClass: organizationalUnit entryUUID: ad5a6bc6-8a9c-1030-810d-db1b7d10e7b5 creatorsName: cn=admin,dc=domain,dc=lan createTimestamp: 20111014104028Z PWDFAILURETIME: 20111115101034Z PWDFAILURETIME: 20111115101036Z PWDFAILURETIME: 20111115101039Z PWDFAILURETIME: 20111115111624Z PWDFAILURETIME: 20111115111629Z PWDACCOUNTLOCKEDTIME: 20111115111629Z entryCSN: 20111115111629.327963Z#000000#000#000000 modifiersName: cn=admin,dc=domain,dc=lan modifyTimestamp: 20111115111629Z The PWDFAILURETIME on an organizationalUnit were created by: $ ldapsearch -x -W -D ou=test,dc=domain,dc=lan Enter LDAP Password: ldap_bind: Invalid credentials (49) IMHO it is a bug that the ppolicy adds the PWDFAILURETIME attribute to DN's which don't have a userPassword attribute and cannot get one. Do you aggree? Thanks for your answer. Regards Noel K�the
noel@debian.org wrote: > IMHO it is a bug that the ppolicy adds the PWDFAILURETIME attribute to DN's > which don't have a userPassword attribute and cannot get one. Hmm, this is somewhat debatable. I'm not sure. But I also don't see any harm in the current behaviour. It's surely the client configuration which needs to be fixed. Ciao, Michael.
Hello Michael, >noel debian.org wrote: >> IMHO it is a bug that the ppolicy adds the PWDFAILURETIME attribute to DN's >> which don't have a userPassword attribute and cannot get one. > Hmm, this is somewhat debatable. I'm not sure. But I also don't see any harm > in the current behaviour. It's surely the client configuration which needs to :( > be fixed. In my case the behaviour is pollution my data with unneeded and unwanted data in ous which I want to prevent. I don't have control over the clients so sadly I cannot fix the source of the problem (the requests). The PWDFAILURETIME (and PWDACCOUNTLOCKEDTIME) is only useful when there is a userPassword: attribute ( when using pwdAttribute: userPassword). Is there any chance that the behaviour is accepted as a problem? -- Noël Köthe <noel debian.org> Debian GNU/Linux, www.debian.org
Noël Köthe wrote: >> noel debian.org wrote: >>> IMHO it is a bug that the ppolicy adds the PWDFAILURETIME attribute >>> to DN's which don't have a userPassword attribute and cannot get >>> one. > >> Hmm, this is somewhat debatable. I'm not sure. But I also don't see any >> harm in the current behaviour. It's surely the client configuration >> which needs to > > :( > >> be fixed. > > In my case the behaviour is pollution my data with unneeded and unwanted > data in ous which I want to prevent. I don't have control over the > clients so sadly I cannot fix the source of the problem (the requests). > The PWDFAILURETIME (and PWDACCOUNTLOCKEDTIME) is only useful when there > is a userPassword: attribute ( when using pwdAttribute: userPassword). Is > there any chance that the behaviour is accepted as a problem? Maybe you got me wrong: I don't have a really strong opinion on that (nor am I the one who decides on this). The question is: What should the pwdFailureTime exactly mean? I understand what's your personal opinion on that and I somewhat support it. But there might be corner-cases where the current behaviour makes sense. Ciao, Michael.
draft-behera-ldap-password-policy: - Says this should be supported via attribute SubtreeSpecification in the pwdPolicy subentry. I think OpenLDAP does not support this attribute, it accepts it but does not do anything. - Leaves room to make the requested behavior configurable in cn=config, or for that matter make it the default: The draft mostly says ppolicy applies to "user entries". Browsing it quicly, I don't see it define what that means, nor consider the existence of non-user entries. A config attribute could define that. I don't know if anyone will bother to implement this (patches welcome) but I don't see a formal problem with whether it could/should be done. -- Hallvard
moved from Incoming to Software Enhancements
Ondrej, can you take a look at this one?
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.
• 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