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.
