[jcifs] Doesn't anyone have a SamOEMChangePassword capture?

Tony Thompson tony.thompson at stone-ware.com
Fri Jun 14 05:24:21 EST 2002

The trace I had sent before was from a Win98 machine changing my password in an NT domain.  It didn't do a SamOemChangePassword.  It did a NetUserPasswordSet2 (115).  I will try to get a packet trace from somewhere and work from that angle.

>>> "Michael B. Allen" <miallen at eskimo.com> 06/13/02 02:00PM >>>
On Thu, 13 Jun 2002 10:59:46 -0500
"Tony Thompson" <tony.thompson at stone-ware.com> wrote:

> From what I can tell by digging around in that code, I won't be able to
> do a straight comparison of the encrypted password data because the Samba
> code adds some random bytes into the new password buffer (I can probably
> do this too after everything works).  Does anyone have any suggestions?

Those  random  bytes  are  not  random.  They  can't be or the whole scheme
wouldn't  work.  That's  the  session  key  returned  in  SMB_COM_NEGOTIATE
response  and  also available from SmbTransport.client.sessionKey where you
can  get  the transport with SmbTransport.getSmbTransport() but you have to
use  the  transport before accessing the session key or the trransport will
not  have negotiated yet. But I don't recall seeing anything in the RAP doc
about  that. If it really is factoring in the sessionKey then that would be
pretty  important!  :~)  Regardless I've said it before and I say it again,
you  should  bother  doing  anything without a pcap. Now go find yourself a
Win98  machine,  tell  it  to  join the domain on your NT 4 server and then
change    your   password.   My   guess   is   that   will   show   you   a

You might try sending a message to the samba users mailing list asking very
nicely  for  someone  to  help you get a pcap. There are probably dozens of
users on there that could grab one in two shakes. 



More information about the jcifs mailing list