clearTextPassword attribute

Nadezhda Ivanova nadezhda.ivanova at
Wed Oct 28 10:09:54 MDT 2009

Hi Matthias,
Unfortunately the similarity between clearTextPassword and unicodePwd does not help in this case, because we do not not care whatsoever about syntax or function, only access rights granted. In 99% of the cases we rely on the dfeaultSecurtyDescriptor or inherited ACEs to determine access, and by default we may have rights given to principal self or administrator over unicodePwd, but never on clearTextPassword. I suppose I could, in acl module, handle clearTextPassword explicitly by checking for the rights of unicodePwd instead, but it will be an ugly hack... And the whole idea of being allowed to use an attribute that is not actually in the schema breaks a ground rule...


----- Original Message -----
> From: Matthias Dieter Wallnöfer <mwallnoefer at>
> To: Nadezhda Ivanova <nadezhda.ivanova at>
> Cc: abartlet at <abartlet at>, samba-technical at <samba-technical at>
> Sent: Wednesday, October 28, 2009 5:14:18 PM GMT+0200 Europe;Athens
> Subject: Re: clearTextPassword attribute

> > Hi Nadya,
> yeah this attribute is used only by s4. To handle it properly you will 
> have to do some exception handling regarding it (like it has been done 
> in the schema code). Isn't there a constraint line in the ACL for all 
> password attributes in common? If yes, apply this also for this 
> attribute. If each password attribute has it's own setting do this: 
> use 
> the rights for the "unicodePwd". The two attributes are nearly 
> identical: the first is pure UTF16 cleartext (easier for use by s4 
> calls) and the second one (transportable, since also supported by 
> windows) is UTF16 quoted cleartext.
> Matthias
> Nadezhda Ivanova schrieb:
> > Hi Team,
> > I have been debugging the ACL module modify access checks, and it 
> seems to work, but I still get a lot of errors in make test. I did 
> some investigating and here is what I found. Some tests, for example 
> rpc.schannel, create an object and after that attempt to modify an 
> attribute called clearTextPassword. Now, when performing an access 
> check on a modify operation, the acl module looks for the attribute to 
> be modified in the dsdb_schema, because we need that attribute's GUID 
> or securityGUID to check if the user has write access granted for it. 
> However, this attribute is not found in the schema, and since it is 
> not actually correct to instantiate an attribute that is not in the 
> schema, acl module returns operations error... This attribute does not 
> seem to be supported by MS schema. A quick search suggests that it is 
> used in Samba to set unicode passwords, if I am not mistaken 
> (password_hash.c). However, it still seems incorrect to allow use of 
> an undefined attribute. We could make an exception for this attribute 
> in particular in acl.c, but do we always allow access, or allow access 
> only for administrator? Any ideas?
> >
> > Regards,
> > Nadya
> >
> >

More information about the samba-technical mailing list