Full_Name: Michael Str�der Version: HEAD OS: openSUSE Linux 11.1 URL: Submission from: (NULL) (84.163.50.194) If one trys to set the userPassword with a Password Modify ext. op. request but the object classes of the entry does not allow userPassword slapd could add automagically AUXILIARY object class simpleSecurityObject to the entry. (I'm doing this in web2ldap since years when changing the userPassword with a normal modify operation which client-side hashing.)
michael@stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: openSUSE Linux 11.1 > URL: > Submission from: (NULL) (84.163.50.194) > > > If one trys to set the userPassword with a Password Modify ext. op. request but > the object classes of the entry does not allow userPassword slapd could add > automagically AUXILIARY object class simpleSecurityObject to the entry. > > (I'm doing this in web2ldap since years when changing the userPassword with a > normal modify operation which client-side hashing.) This request sounds like a mistake to me. The DSA is supposed to enforce the data model, not automagically enable you to bypass the model. What clients do is a completely separate matter... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
hyc@symas.com writes: > This request sounds like a mistake to me. The DSA is supposed to > enforce the data model, not automagically enable you to bypass the > model. What clients do is a completely separate matter... It makes sense if you add a config parameter with an LDAP URL or something describing entries which can be so modified (subject to ordinary access controls). -- Hallvard
Sorry, sent too early. > It makes sense if you add a config parameter with an LDAP URL or > something describing entries which can be so modified (subject to > ordinary access controls). I imagine one would typically filter for objectClass, e.g. ldap:///???(objectClass=person)
hyc@symas.com wrote: > michael@stroeder.com wrote: >> Full_Name: Michael Ströder >> Version: HEAD >> OS: openSUSE Linux 11.1 >> URL: >> Submission from: (NULL) (84.163.50.194) >> >> >> If one trys to set the userPassword with a Password Modify ext. op. request but >> the object classes of the entry does not allow userPassword slapd could add >> automagically AUXILIARY object class simpleSecurityObject to the entry. >> >> (I'm doing this in web2ldap since years when changing the userPassword with a >> normal modify operation which client-side hashing.) > > This request sounds like a mistake to me. The DSA is supposed to enforce the > data model, not automagically enable you to bypass the model. What clients do > is a completely separate matter... Let's assume the policy for a deployment is that password changes MUST be applied by using password modify ext. op. (e.g. because smbk5pwd is used or similar) and you want to use object class 'account' for user entries. How could the attribute 'userPassword' be added to the user entry then? It's kind of a dead-lock situation. Ciao, Michael.
Michael Ströder wrote: > hyc@symas.com wrote: >> michael@stroeder.com wrote: >>> Full_Name: Michael Ströder >>> Version: HEAD >>> OS: openSUSE Linux 11.1 >>> URL: >>> Submission from: (NULL) (84.163.50.194) >>> >>> >>> If one trys to set the userPassword with a Password Modify ext. op. request but >>> the object classes of the entry does not allow userPassword slapd could add >>> automagically AUXILIARY object class simpleSecurityObject to the entry. >>> >>> (I'm doing this in web2ldap since years when changing the userPassword with a >>> normal modify operation which client-side hashing.) >> >> This request sounds like a mistake to me. The DSA is supposed to enforce the >> data model, not automagically enable you to bypass the model. What clients do >> is a completely separate matter... > > Let's assume the policy for a deployment is that password changes MUST be > applied by using password modify ext. op. (e.g. because smbk5pwd is used or > similar) and you want to use object class 'account' for user entries. How > could the attribute 'userPassword' be added to the user entry then? It's kind > of a dead-lock situation. Then you made a mistake in your data design. You should have chosen an objectclass (or set of objectclasses) that supports authentication from the outset. To me this is analogous to the usual prohibition against changing an object's structural class - you cannot change a car into a pencil. You cannot change a non-user into a user. -- -- 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 wrote: > Michael Ströder wrote: >> Let's assume the policy for a deployment is that password changes MUST be >> applied by using password modify ext. op. (e.g. because smbk5pwd is >> used or >> similar) and you want to use object class 'account' for user entries. How >> could the attribute 'userPassword' be added to the user entry then? >> It's kind >> of a dead-lock situation. > > Then you made a mistake in your data design. Nope. Since with a modify request I can achieve the goal by adding object class 'simpleSecurityObject'. IMO password modify ext.op. should result in userPassword being added. One could view it as a hen-and-egg problem because 'simpleSecurityObject' is mandating 'userPassword'. > You should have chosen an > objectclass (or set of objectclasses) that supports authentication from > the outset. To me this is analogous to the usual prohibition against > changing an object's structural class - you cannot change a car into a > pencil. You cannot change a non-user into a user. Please don't compare apples with pies. 'account' is STRUCTURAL so the user entry represents already a user. 'simpleSecurityObject' is AUXILIARY (not STRUCTURAL) which adds another attribute. The STRUCTURAL object class of the entry is not altered, so no magic change from a car into a pencil here. Ciao, Michael.
michael@stroeder.com wrote: > Howard Chu wrote: >> Michael Ströder wrote: >>> Let's assume the policy for a deployment is that password changes MUST be >>> applied by using password modify ext. op. (e.g. because smbk5pwd is >>> used or >>> similar) and you want to use object class 'account' for user entries. How >>> could the attribute 'userPassword' be added to the user entry then? >>> It's kind >>> of a dead-lock situation. >> Then you made a mistake in your data design. > > Nope. Since with a modify request I can achieve the goal by adding object > class 'simpleSecurityObject'. IMO password modify ext.op. should result in > userPassword being added. One could view it as a hen-and-egg problem because > 'simpleSecurityObject' is mandating 'userPassword'. I agree with Hallvard that this should be made configurable. So the admin could specify whether and which AUXILIARY object class is added. Ciao, Michael.
michael@stroeder.com wrote: > Howard Chu wrote: >> Michael Ströder wrote: >>> Let's assume the policy for a deployment is that password changes MUST be >>> applied by using password modify ext. op. (e.g. because smbk5pwd is >>> used or >>> similar) and you want to use object class 'account' for user entries. How >>> could the attribute 'userPassword' be added to the user entry then? >>> It's kind >>> of a dead-lock situation. >> >> Then you made a mistake in your data design. > > Nope. Since with a modify request I can achieve the goal by adding object > class 'simpleSecurityObject'. IMO password modify ext.op. should result in > userPassword being added. One could view it as a hen-and-egg problem because > 'simpleSecurityObject' is mandating 'userPassword'. Since the ppolicy overlay already provides the facility for hashing plaintext passwords on Add and Modify, there's no reason you couldn't have just created the objects correctly in the first place. >> You should have chosen an >> objectclass (or set of objectclasses) that supports authentication from >> the outset. To me this is analogous to the usual prohibition against >> changing an object's structural class - you cannot change a car into a >> pencil. You cannot change a non-user into a user. > > Please don't compare apples with pies. It was an analogy, not a literal comparison. Don't lose the main point, which is that changing a non-user into a user is a significant change in the purpose of an object. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
moved from Incoming to Software Enhancements
Why is this ITS in software development, and open? Anyone intends to develop that feature, despite the discussion? p.
No.
changed notes changed state Open to Closed