[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
SamOEMChangePassword.
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.
Mike
--
http://www.eskimo.com/~miallen/c/jus.c
More information about the jcifs
mailing list