[Date Prev][Date Next]
Re: (ITS#6250) Password modify ext.op. - automagically add simpleSecurityObject
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#6250) Password modify ext.op. - automagically add simpleSecurityObject
- From: email@example.com
- Date: Tue, 11 Aug 2009 20:27:12 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
> 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/