[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
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: hyc@symas.com
- Date: Tue, 11 Aug 2009 20:11:59 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
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/