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.