Full_Name: Andrew Findlay Version: 2.4.24 OS: OpenSuSE 11.3 URL: ftp://ftp.openldap.org/incoming/afindlay-ppolicy-man-patch-20110215 Submission from: (NULL) (88.97.25.132) slapo-ppolicy.5 incorrectly includes the NO-USER-MODIFICATION flag in the schema fragments for pwdPolicySubentry and pwdAccountLockedTime. In addition, the description of pwdAccountLockedTime does not make it clear that this attribute can be changed by administrative action. The attached patch is a suggested clarification for the manpage.
andrew.findlay@skills-1st.co.uk wrote: > Full_Name: Andrew Findlay > Version: 2.4.24 > OS: OpenSuSE 11.3 > URL: ftp://ftp.openldap.org/incoming/afindlay-ppolicy-man-patch-20110215 > Submission from: (NULL) (88.97.25.132) > > > slapo-ppolicy.5 incorrectly includes the NO-USER-MODIFICATION flag in the schema > fragments for pwdPolicySubentry and pwdAccountLockedTime. That's how they were defined in the IETF Draft. The schema fragments in the manpage were copied directly from the spec. The fact that the current implementation deviates from the spec is just out of necessity to make things work at all in our present code base. Things will not always work this way... > In addition, the description of pwdAccountLockedTime does not make it clear that > this attribute can be changed by administrative action. > > The attached patch is a suggested clarification for the manpage. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On Tue, Feb 15, 2011 at 05:02:52AM -0800, Howard Chu wrote: > >slapo-ppolicy.5 incorrectly includes the NO-USER-MODIFICATION flag in the schema > >fragments for pwdPolicySubentry and pwdAccountLockedTime. > > That's how they were defined in the IETF Draft. The schema fragments > in the manpage were copied directly from the spec. The fact that the > current implementation deviates from the spec is just out of > necessity to make things work at all in our present code base. Certainly the use of pwdPolicySubentry differs from the intention of the draft (which I believe was intending to use real X.500-style subentries). The case of pwdAccountLockedTime is arguable. draft-behera-ldap-password-policy-xx.txt says: This attribute holds the time that the user's account was locked. A locked account means that the password may no longer be used to authenticate. A 000001010000Z value means that the account has been locked permanently, and that only a password administrator can unlock the account. Unfortunately it says nothing about *how* a password administrator should do that when the attribute is marked NO-USER-MODIFICATION. I would argue that this is a deficiency in the draft, and that the current OpenLDAP behaviour is more useful. > Things will not always work this way... Indeed, but I would prefer the manpages to reflect the reality of the current release! Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------
Andrew Findlay wrote: > On Tue, Feb 15, 2011 at 05:02:52AM -0800, Howard Chu wrote: > >>> slapo-ppolicy.5 incorrectly includes the NO-USER-MODIFICATION flag in the schema >>> fragments for pwdPolicySubentry and pwdAccountLockedTime. >> >> That's how they were defined in the IETF Draft. The schema fragments >> in the manpage were copied directly from the spec. The fact that the >> current implementation deviates from the spec is just out of >> necessity to make things work at all in our present code base. > > Certainly the use of pwdPolicySubentry differs from the > intention of the draft (which I believe was intending to use > real X.500-style subentries). > > The case of pwdAccountLockedTime is arguable. > draft-behera-ldap-password-policy-xx.txt says: > > This attribute holds the time that the user's account was locked. A > locked account means that the password may no longer be used to > authenticate. A 000001010000Z value means that the account has been > locked permanently, and that only a password administrator can unlock > the account. > > Unfortunately it says nothing about *how* a password > administrator should do that when the attribute is marked > NO-USER-MODIFICATION. I would argue that this is a > deficiency in the draft, and that the current OpenLDAP > behaviour is more useful. > >> Things will not always work this way... > > Indeed, but I would prefer the manpages to reflect the > reality of the current release! I note that in ppolicy.c we have: { "( 1.3.6.1.4.1.42.2.27.8.1.17 " "NAME ( 'pwdAccountLockedTime' ) " "DESC 'The time an user account was locked' " "EQUALITY generalizedTimeMatch " "ORDERING generalizedTimeOrderingMatch " "SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 " "SINGLE-VALUE " #if 0 /* Not until Relax control is released */ "NO-USER-MODIFICATION " #endif "USAGE directoryOperation )", We have in fact released support for the Relax control, so it's probably time to unifdef these bits and go back to the documented behavior. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On Thu, Jun 09, 2011 at 01:45:17AM -0700, Howard Chu wrote: > I note that in ppolicy.c we have: > > { "( 1.3.6.1.4.1.42.2.27.8.1.17 " > "NAME ( 'pwdAccountLockedTime' ) " > "DESC 'The time an user account was locked' " > "EQUALITY generalizedTimeMatch " > "ORDERING generalizedTimeOrderingMatch " > "SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 " > "SINGLE-VALUE " > #if 0 > /* Not until Relax control is released */ > "NO-USER-MODIFICATION " > #endif > "USAGE directoryOperation )", > > We have in fact released support for the Relax control, so it's > probably time to unifdef these bits and go back to the documented > behavior. That seems reasonable in the long term, though it will break many sites' existing password management procedures. The change will have to be mentioned in the updated manpage, noting the version at which it takes effect. Should I produce an updated version of the manpage patch? Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------
Andrew Findlay wrote: > On Thu, Jun 09, 2011 at 01:45:17AM -0700, Howard Chu wrote: > >> I note that in ppolicy.c we have: >> >> { "( 1.3.6.1.4.1.42.2.27.8.1.17 " >> "NAME ( 'pwdAccountLockedTime' ) " >> "DESC 'The time an user account was locked' " >> "EQUALITY generalizedTimeMatch " >> "ORDERING generalizedTimeOrderingMatch " >> "SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 " >> "SINGLE-VALUE " >> #if 0 >> /* Not until Relax control is released */ >> "NO-USER-MODIFICATION " >> #endif >> "USAGE directoryOperation )", >> >> We have in fact released support for the Relax control, so it's >> probably time to unifdef these bits and go back to the documented >> behavior. > > That seems reasonable in the long term, though it will break many sites' > existing password management procedures. The change will have to be > mentioned in the updated manpage, noting the version at which it takes > effect. > > Should I produce an updated version of the manpage patch? Well since you raise the question, what do you think is the more sensible approach to all of this? I was the one who argued in ldapext that these attributes should be no-user-modification but perhaps that makes them too inconvenient to administer. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On Thu, Jun 30, 2011 at 03:11:05AM -0700, Howard Chu wrote: > Well since you raise the question, what do you think is the more > sensible approach to all of this? I was the one who argued in > ldapext that these attributes should be no-user-modification but > perhaps that makes them too inconvenient to administer. I think that the best approach would be to make no change in 2.4 code but to flag in the docs that the behaviour will change for 2.5. The NO-USER-MODIFICATION flags have been in draft-behera since 2005, but draft-zeilenga-ldap-relax has only been around since 2007. The latter document says that rules may not be relaxed unless there is a document saying that they may be. pwdAccountLockedTime is not mentioned in draft-zeilenga-ldap-relax and the relax control is not mentioned in draft-behera-ldap-password-policy, so one of those docs needs updating to make the behaviour legal. It would be interesting to survey other LDAP implementations to see how they currently treat the password-policy attributes. This is already a minefield due to uncertainties and variations in the replication process. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------
hyc@symas.com wrote: > Andrew Findlay wrote: >> On Thu, Jun 09, 2011 at 01:45:17AM -0700, Howard Chu wrote: >> >>> I note that in ppolicy.c we have: >>> >>> { "( 1.3.6.1.4.1.42.2.27.8.1.17 " >>> "NAME ( 'pwdAccountLockedTime' ) " >>> "DESC 'The time an user account was locked' " >>> "EQUALITY generalizedTimeMatch " >>> "ORDERING generalizedTimeOrderingMatch " >>> "SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 " >>> "SINGLE-VALUE " >>> #if 0 >>> /* Not until Relax control is released */ >>> "NO-USER-MODIFICATION " >>> #endif >>> "USAGE directoryOperation )", >>> >>> We have in fact released support for the Relax control, so it's >>> probably time to unifdef these bits and go back to the documented >>> behavior. >> >> That seems reasonable in the long term, though it will break many sites' >> existing password management procedures. The change will have to be >> mentioned in the updated manpage, noting the version at which it takes >> effect. >> >> Should I produce an updated version of the manpage patch? > > Well since you raise the question, what do you think is the more sensible > approach to all of this? I was the one who argued in ldapext that these > attributes should be no-user-modification but perhaps that makes them too > inconvenient to administer. Given the fact that the Relax Rules control still has .666 OID it cannot be used (see my related messages to openldap-devel and ietf-ldapext). At least what's always being said about .666 OIDs... Ciao, Michael.
For 2.5? Read comments
changed notes moved from Incoming to Software Enhancements
Ondrej, can you review?
Commits: • eafcc405 by Ondřej Kuzník at 2021-03-18T17:32:30+00:00 ITS#6830 Enable NO-USER-MODIFICATION on ppolicy attributes