[jcifs] Question about NT Domains

[Tony Thompson]

OK, after following Mike's suggestions, a little help from here (http://samba.org/doxygen/samba/head/clirap_8c-source.html) and some guessing, I now have a good packet being sent to the server.  I am actually getting a status back from the server, although not the one I had hoped for.  The status I get back is 86 (ERROR_INVALID_PASSWORD).  So, I am guessing that this means the password hashing that I am doing is not correct.

In the source file I mentioned above, there is a function named cli_oem_change_password().  That appears to be in the Samba code somewhere.  Is there a utility that I can run that will invoke that function so that I can get a packet trace of the call?  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?

I am attaching my revised source code in case anyone who has done this before (in Samba) feels adventurous enough to help me out a bit.

BTW, the packet corruption that I mentioned before was my fault (big surprise).  I had what amounted to a pointer issue when writing the data into the packet.

Tony

>>> "Allen, Michael B (RSCH)" <Michael_B_Allen at ml.com> 06/12/02 08:18PM >>>


> -----Original Message-----
> From:	Tony Thompson [SMTP:tony.thompson at stone-ware.com] 
> Sent:	Wednesday, June 12, 2002 4:28 PM
> To:	miallen at eskimo.com 
> Cc:	Michael_B_Allen at ml.com; jcifs at samba.org; sfrench at us.ibm.com 
> Subject:	Re: [jcifs] Question about NT Domains
> 
> Well, I figured out part of my problem.  In SmbFile, my changePassword() method was using send() instead
> of sendTransaction() to send the SamOemChangePassword request.  Once I got past that, the request is
> actually showing up on the wire but looks like it is corrupt.  That is probably my lack of knowledge of the
> jCIFS internals.  Here is what my method currently looks like:
> 
> public void changePassword( String newPassword ) throws SmbException {
>    sendTransaction( new SamOemChangePassword( authInfo.username, authInfo.password, newPassword
> ), new SamOemChangePasswordResponse() );
> }
> 
> Attached is a trace of the attempt to change the password.  The packet, according to the decode, seems
> to have an invalid function number (41791) and descriptor string (i.e. it was corrupted somehow).
> 
	Hi Tony,

	I took a look at your code a little more carefully. I can see a few problems.

	Everything is being written into the Parameters section of the message. If you look at the doc on RAP on
	SamOemChangePassword, there are a few things written in the "Transaction Parameters Request
	Section" but it says the 532 byte databuffer is supposed to go in the "Transaction Request Data Section".
	So you just need to arraycopy that in the writeDataWireFormat (emphesis on "Data") method as opposed
	to the writeParameterWordsWireFormat (emphisis on "ParameterWords") method. The NetServerEnum2
	and NetServerEnum RAP calls from which you are basing your code just happen to not have anything in
	the Data section. Notice how the SamOemChangePassword response does not contain any Data whereas
	NetServerEnum2 and NetShareEnum do.

	The writeString method writes a string in a UCS2-LE encoding. On the wire this looks like a regular string
	but with zeros in between each character. You would not use this method unless you know
	that a string should be written in Unicode. For copying parameter descriptor strings and chunks of data use
	the System.arraycopy method. Just handle the parameter descriptor strings like they are in the
	NetServerEnum2 and NetShareEnum code.

	Looking at your latest pcap, there's nothing but total garbage after the pipe name. I'm not sure why this is
	happening but you definately don't want to set the subCommand to NET_SERVER_ENUM2 like you have.
	You should add static final int SAM_OEM_CHANGE_PASSWORD = 0x00D6;(d6 is hex for 214) to
	SmbComTransaction.java and then writeInt2 it and not 214 directly.

	You will also need to adjust maxParameterCount see:

	  http://ubiqx.org/cifs/rfc-draft/draft-leach-cifs-v1-spec-02.html#s3.13 

	for a description of what MaxParameterCount means but a packet capture would make all of this much
	easier.

	Mike



-------------- next part --------------
A non-text attachment was scrubbed...
Name: SamOemChangePassword.java
Type: application/octet-stream
Size: 6745 bytes
Desc: not available
Url : http://lists.samba.org/archive/jcifs/attachments/20020613/b31918f7/SamOemChangePassword.obj