SetPassword internals (fwd)

[Luke Kenneth Casson Leighton]

for archives / records.  bug: samba must return NT status codes not DOS
ones, else password changes will use SMBtrans pw chg (which only contains
LM#).  if 32-bit status codes are returned, password change sent will be a
\PIPE\samr call.

thx to kalele for doing the netmon traces and changing SMBsesssetupX to
send 32-bit status codes to check this.

<a href="mailto:lkcl at samba.org"   > Luke Kenneth Casson Leighton    </a>
<a href="http://www.cb1.com/~lkcl"> Samba and Network Development   </a>
<a href="http://samba.org"        > Samba Web site                  </a>
<a href="http://www.iss.net"      > Internet Security Systems, Inc. </a>


> _your_ workstation has already been talking with prithvi and has
> determined (to its own satisfaction, not ours) that it is not capable of
> supporting \PIPE\samr password changes.
>
> it _may_ be that the state information is stored on a per-reboot basis,
> instead of somewhere permanent, like in the registry.
>

I don't think it saves such state information, because as you can see from
samrchange.cap, my workstation *does* do \pipe\samr password changes on
prithvi when the write&X command to the \pipe\samr succeeds.
Which happens when the user's NT password and his smbpasswd are in sync
before the password change.

Anyway, the problem of remote API requests has been eliminated. I've
discovered that the NT wkstation falls back to Remote API requests because
samba sends it an SMB status code instead of an NT error status. Modifying
smbd/error.c to send an NT error on session setup failure corrects this and
the NT wkstation then does a normal NTcreate&X to \pipe\samr.

However, the problem seems to be in the RPC bind or write&X requests where
ntlm authentication fails in the samba server for the user when his NT
password doesn't match his smbpasswd password. This write&X succeeds in the
case of an NT server (such as virgo). I'm attaching a netmon dump of this to
compare against virgo.cap.