Full_Name: Guillaume Rousse Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.83.212.136) Current ppolicy implementation allows to administratively lock a password, by setting pwdAccountLockedTime attribute to '000001010000Z' value. However, despite this value actually being a generalized date, setting it to any other date in the future doesn't work as expected. Moreover, this is an operational attribute, which is primarily supposed to be handled by slapd itself. As a consequence, a normal pwdExpirationDate attribute, which itself would set a boolean operational attribute pwdExpired attribute to a true value, would be desirable.
Guillaume.Rousse@inria.fr wrote: > Full_Name: Guillaume Rousse > Version: 2.4.16 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.83.212.136) > > > Current ppolicy implementation allows to administratively lock a password, by > setting pwdAccountLockedTime attribute to '000001010000Z' value. However, > despite this value actually being a generalized date, setting it to any other > date in the future doesn't work as expected. Moreover, this is an operational > attribute, which is primarily supposed to be handled by slapd itself. > > As a consequence, a normal pwdExpirationDate attribute, which itself would set > a > boolean operational attribute pwdExpired attribute to a true value, would be > desirable. Since the ppolicy module's behavior is dictated by the Behera draft, any suggestions for changes in this area should probably first be raised on the ietf-ldapext mailing list. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Howard Chu a écrit : > Since the ppolicy module's behavior is dictated by the Behera draft, any > suggestions for changes in this area should probably first be raised on > the ietf-ldapext mailing list. Right, but openldap implementation already have extension, such pwdCheckModule. Additional extension could be implemented, before getting standardized. Also, the ietf-ldapext seems to be an highly-technical list, and I don't feel confortable enough to post this kind of request directly there. Discussing various limitations of ppolicy among openldap users first would probably allow openldap core team to suggest a more polished extension request themselves. -- BOFH excuse #287: Telecommunications is downshifting.
Guillaume Rousse wrote: > Howard Chu a écrit : >> Since the ppolicy module's behavior is dictated by the Behera draft, any >> suggestions for changes in this area should probably first be raised on >> the ietf-ldapext mailing list. > Right, but openldap implementation already have extension, such > pwdCheckModule. Additional extension could be implemented, before > getting standardized. > > Also, the ietf-ldapext seems to be an highly-technical list, and I don't > feel confortable enough to post this kind of request directly there. > Discussing various limitations of ppolicy among openldap users first > would probably allow openldap core team to suggest a more polished > extension request themselves. The draft doesn't say anything about setting pwdAccountLockedTime to a value in the future; since it doesn't preclude it I've fixed up the code to handle this case. However, it's not a good solution for your purpose, since the pwdAccountLockedTime value is automatically replaced with the current time if too many Bind failures occur, and it's automatically deleted when a password is changed. We'll leave this in HEAD on an experimental basis for now, until a real solution is spec'd out. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes changed state Open to Test moved from Incoming to Development
Howard Chu a écrit : > Guillaume Rousse wrote: >> Howard Chu a écrit : >>> Since the ppolicy module's behavior is dictated by the Behera draft, any >>> suggestions for changes in this area should probably first be raised on >>> the ietf-ldapext mailing list. >> Right, but openldap implementation already have extension, such >> pwdCheckModule. Additional extension could be implemented, before >> getting standardized. >> >> Also, the ietf-ldapext seems to be an highly-technical list, and I don't >> feel confortable enough to post this kind of request directly there. >> Discussing various limitations of ppolicy among openldap users first >> would probably allow openldap core team to suggest a more polished >> extension request themselves. > > The draft doesn't say anything about setting pwdAccountLockedTime to a > value in the future; since it doesn't preclude it I've fixed up the code > to handle this case. However, it's not a good solution for your purpose, > since the pwdAccountLockedTime value is automatically replaced with the > current time if too many Bind failures occur, and it's automatically > deleted when a password is changed. We'll leave this in HEAD on an > experimental basis for now, until a real solution is spec'd out. Indeed. Moreover, a variable date field is not a practical field for sorting out valid accounts in search requests, for authorization purposes. Anyway, thanks for the change. -- BOFH excuse #320: You've been infected by the Telescoping Hubble virus.
leave in HEAD
ppolicy draft 10 has a way to set a password validity and is implemented now. *** This issue has been marked as a duplicate of issue 9156 ***