Full_Name: Eric Clements Version: 2.4.26 OS: MacOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (17.193.15.131) RFC 3062 Section 2.1 (authored by OpenLDAP) states that a password modify request may or may not be an LDAP DN, yet OpenLDAP backend requires a DN.
eclements@apple.com wrote: > Full_Name: Eric Clements > Version: 2.4.26 > OS: MacOS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (17.193.15.131) > > > RFC 3062 Section 2.1 (authored by OpenLDAP) states that a password modify > request may or may not be an LDAP DN, yet OpenLDAP backend requires a DN. I'm not sure I understand why you've filed this ITS. The RFC doesn't specify that a server MUST support non-DN valued identities. It in fact says in Section 3: If the server does not recognize provided fields or does not support the combination of fields provided, it SHALL NOT change the user password. Clearly it is allowed for a server to reject identities if it doesn't recognize them. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
I filed it in response to a posting I saw on AFP548 regarding OS X. Some users have patched OpenLDAP to work around the issue. Though your statement is true, many SASL methods do not use DNs either. I do not see why it is not allowed for passwordModify in the same way. If it behaves as designed then feel free to close. Thank you, --------------------------- Eric Clements On Aug 1, 2012, at 2:26 PM, Howard Chu <hyc@symas.com> wrote: > eclements@apple.com wrote: >> Full_Name: Eric Clements >> Version: 2.4.26 >> OS: MacOS >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (17.193.15.131) >> >> >> RFC 3062 Section 2.1 (authored by OpenLDAP) states that a password modify >> request may or may not be an LDAP DN, yet OpenLDAP backend requires a DN. > > I'm not sure I understand why you've filed this ITS. The RFC doesn't specify > that a server MUST support non-DN valued identities. It in fact says in Section 3: > > If the server does not recognize provided fields or does not support > the combination of fields provided, it SHALL NOT change the user > password. > > Clearly it is allowed for a server to reject identities if it doesn't > recognize them. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/
Eric Clements wrote: > I filed it in response to a posting I saw on AFP548 regarding OS X. Some users have patched OpenLDAP to work around the issue. If you have a working patch that behaves as you think it should, you're welcome to submit it. Unfortunately, the RFC is explicitly silent on how other identity formats are represented. I.e., it doesn't even specify that SASL identities (such as used in SASL Bind) are valid here. > Though your statement is true, many SASL methods do not use DNs either. I > do not see why it is not allowed for passwordModify in the same way. If it behaves as designed then feel free to close. > > Thank you, > --------------------------- > Eric Clements > > On Aug 1, 2012, at 2:26 PM, Howard Chu <hyc@symas.com> wrote: > >> eclements@apple.com wrote: >>> Full_Name: Eric Clements >>> Version: 2.4.26 >>> OS: MacOS >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (17.193.15.131) >>> >>> >>> RFC 3062 Section 2.1 (authored by OpenLDAP) states that a password modify >>> request may or may not be an LDAP DN, yet OpenLDAP backend requires a DN. >> >> I'm not sure I understand why you've filed this ITS. The RFC doesn't specify >> that a server MUST support non-DN valued identities. It in fact says in Section 3: >> >> If the server does not recognize provided fields or does not support >> the combination of fields provided, it SHALL NOT change the user >> password. >> >> Clearly it is allowed for a server to reject identities if it doesn't >> recognize them. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Definitely not a bug... at best a feature enhancement, but zero follow up from Apple. RFC lacking description of behavior in SASL case.
changed notes changed state Open to Closed moved from Incoming to Software Enhancements