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.