Password change code

[Andrew Bartlett]

Patrick McCarty wrote:
> 
> > Well, you can't change that function - becouse it is used by other
> > code.  But you can write another (better) wrapper.
> >
> > > How far off base am I?
> >
> > Well, the LM password change code doesn't set the plaintext, the two
> > 'main' password change mechisms are as described.  The SAMR calls wraps
> > the lanman.c RAP call.  That is, they both take a 'blob' containing the
> > obscured old and new passwords (in a sort of challange-response kind of
> > format).  These get authenticated by the check_oem_password() code,
> > which returns the new, plaintext password.
> >
> > The oddball call is api_SetUserPassword() in lanman.c, which can get
> > either a plaintext old and new password (win98, authenticated via the
> > normal code paths) or a LM hash only.
> 
> So then, after the passwords are validated by check_oem_password, we can
> pass the plaintext passwords to this function instead of
> pdb_set_plaintext_password?

The 'final' call should be 'pdb_set_plaintext_password()' becouse some
of the administrative tools call it.

> Since this code will take plaintext or hashed (depending on how you setup
> the bitmasks it is passed) it is fairly versatile.
> 
> Is that the direction you had in mind?

Mostly,

> > Looking at the code:
> >
> > Firstly, when I say that the incoming password is an LM hash, it means
> > that it is already hashed.
> Fixed now.
> 
> > Also, if you change only the LM hash, you should invalidate (set to
> > NULL) the NT hash.
> I believe setting it to NULL will cause issues with some backends such as
> LDAP. I now invalidate it by setting it to all X's, much like I saw done
> somewhere else in the code.

No, you must set it to NULL.  Setting it to all X will just give that
user a fixed, known password.  We don't want that.  The passdb deals
with passwords as binary hashes, the representation in LDAP is up to
pdb_ldap do decide.  Likewise, pdb_smbpasswd choses to represent 'no
password available' as all X, but pdb_ldap uses 'no attribute' for that.

> > If the password is too short, return NT_STATUS_PASSWORD_RESTRICTION, or
> > whatever NT returns for that error.  This ensures we get the right error
> > message on the client.
> I'll need to look at these more closely when it this gets integrated.
> There are a couple that I know need to be changed for sure.
> 
> > Finally, put the 'unix password sync' code inside this function, but
> > don't call it for machine accounts.
> K, did that now.
> 
> > Do this bit inside its own 'wrapper' function, that the RPC-based
> > adminstrative password changes can also use.
> Im not sure what you mean here.. You mean put the password change stuff in
> a seperate function yet? I'm confused... You can turn off Unix sync by
> flipping the appropriate bit in my newly defined PCB (password control
> bit) bitmask.

I like recursive functions.  It is often eaiser to see whats going on -
so put the unix password sync code in its own function, and call that if
the bitmask is set.  Keep functions short, and use function calls for
logicly seperate steps.  The compiler will sort it out, and often put it
back inline, so you don't really pay for it anyway :-).

> A bitmask was the only way I could think of sending multiple sendings to
> the function, if you know of a better way, i'm all for it.
> 
> > We should test if machines are premitted to change their password this
> > way at all.  (They *should* make a netlogon call).
> I'm guessing by this that there is some additional structure I should be
> checking something against?

You should check what NT does, that is what I'm saying.  

> > Did I mention this code is complex?
> 
> =) Complex enough to expose my relative inexperience with samba internals
> and with C in general.
> 
> Guess its a good thing I dont scare easily.
> 
> Tomorrow I'll give it a go at trying to integrate and test this code. I'm
> SURE i'll find some problems. I haven't even tried to compile this yet, I
> simply wrote it up in VIM =) But I think im pretty close nevertheless.

A little way to go yet.

In particular:  We *much* allow silly characters in passwords, becouse
some are randomly generated, and won't be just plain ASCII.  Just don't
allow a unix password sync of them.  

Hmm, we *might* deny the whole password change in that case, (current
behaviour) but I'm not sure thats correct.  I'll think about it.

Andrew Bartlett

> --
> Patrick McCarty
> Video Technician
> Azusa Pacific University
> 
> Logic is a systematic method of coming to the wrong conclusion with confidence.
> 
>   ------------------------------------------------------------------------
>                Name: chgpwd.c
>    chgpwd.c    Type: Plain Text (TEXT/PLAIN)
>            Encoding: BASE64

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net