[jcifs] Question about NT Domains

Tony Thompson tony.thompson at stone-ware.com
Thu Jun 13 06:28:13 EST 2002 

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).

>>> "Michael B. Allen" <miallen at eskimo.com> 06/12/02 01:33PM >>>
On Wed, 12 Jun 2002 08:47:52 -0500
"Tony Thompson" <tony.thompson at stone-ware.com> wrote:

> This document:
> 
> ftp://ftp.microsoft.com/developr/drg/CIFS/cifsrap2.doc 
> 
> says the descriptor string for SamOemChangePassword is "zsT".
> The descriptor string that is in the header file that you pointed me to
> has a descriptor string of "B516B16".  Both sources say the function
> number is 214.  I have tried both descriptors with the same results.
> Any idea which one is the correct one?

B516B16  just  means 516 bytes followed by 16 bytes which apparently is the
same  as a 512 byte string 'z' followed by a pointer to the send buffer 's'
and  a  2  byte  send  buffer length thus "zsT" is ultimately a synonym for
"B516B16" (or something). Another reason to get yourself a pcap.

> 
> I am testing against an NT4.0 (SP6) server.  Is it possible that it
> really doesn't support this function?

No.  NT  4.anything  will  support  it.  You just need a pcap of the passwd
change. A win98 machine against an NT 4 domain sounds like it will generate
a   SamOEMChangePassword.  It  sounds  like  you  have  all  the  necessary
equiptment. So what is the error message you are getting exactly? That last
jcifs_pass.cap  you  sent  me  died  on  the  SessionSetupAndX message with
"Access  denied".  That  has  nothing  to  do with RAP. That's just a wrong
domain\user:pass. But doing anything without a pcap of it is wasting time.

Mike

> 
> Tony
> 
> >>> "Steven French" <sfrench at us.ibm.com> 06/12/02 12:25AM >>>
> There are four set password calls for SMB/CIFS (not counting the Kerberos
> change password):
> NetUserPasswordSet    (plain text)  which is RAP ordinal 58
> NetUserPasswordSet2 (one way lanman hash of password)  115
> NetUserPasswordSet3 (reversibly encrypted ie secure decryptable change
> password) done by IBM       275
> SAM_OEMChangePassword (same idea as above but done a few years later by
> Microsoft)                      214
> 
> See
> http://cvs.samba.org/cgi-bin/cvsweb/samba/source/include/rap.h?rev=1.4.2.1&content-type=text/x-cvsweb-markup 
> 
> for a fairly complete list based on Microsoft's postings and documentation
> (as well as IBM documentation on the IBM specific ones).    Jim and I added
> this when we added the "net" utility to Samba last year and with it a lot
> of RAP support.    There once was NetUserPassswordSet2 support in Samba
> don't know if it is still there.   It may have been in the old PAM_SMB as
> well.
> 
> Although the current Microsoft clients preferentially send
> SAM_OEMChangePassword, they (and many others too)  will send
> NetUserPasswordSet2 if the server doesn't support SAM_OEM and then some
> will even fall back to the ancient plain text NetUserPasswordSet RAP call
> 
> 
> 
> Steve French
> Senior Software Engineer
> Linux Technology Center - IBM Austin
> phone: 512-838-2294
> email: sfrench at us.ibm.com 
> 
> 
> "Allen, Michael B (RSCH)" <Michael_B_Allen at ml.com> on 06/11/2002 10:16:22
> PM
> 
> To:    "'Tony Thompson'" <tony.thompson at stone-ware.com>,
>        "'jcifs at samba.org'" <jcifs at samba.org>, Steven
>        French/Austin/IBM at IBMUS
> cc:
> Subject:    RE: [jcifs] Question about NT Domains
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From:     Tony Thompson [SMTP:tony.thompson at stone-ware.com] 
> > Sent:     Tuesday, June 11, 2002 10:51 PM
> > To: Michael_B_Allen at ml.com 
> > Subject:  RE: [jcifs] Question about NT Domains
> >
> > OK, here is a trace from a Win98 machine.  It still looks different.  If
> you look at packet #13,
> > I am guessing that is where the password is set but, it looks completely
> different from what
> > I would expect.  According to the document you clued me in on, the
> parameter descriptor
> > string should be "zsT".  The descriptor in that packet is "zb16b16WW" (I
> think).  I couldn't
> > even find that in the cifsrap2.doc.
> >
>  Opps, that appears to be a another RAP call for changing your password. I
>  have not heard of
>  SetUserPassword (115). There are hundreds of RAP calls. I seem to be at a
>  loss as to how
>  to capture a SamOEMChangePassword call. I suppose an early version of
>  smbclient might
>  do it. You could probably get Win98 to do it too you just need to provoke
>  it in the right way.
>  Does anyone have an Ethereal pcap of SamOEMChangePassword or know exactly
>  how Tony
>  can get one?
> 
> > I am not sending the wrong password so, I must be building the request
> incorrectly.
> >
>  You really need a pcap. You'll never get it right without one. At least I
>  never could.
> 
>  Otherwise, your code looks really close,
>  Mike
> 
> > I am attaching my source code as well.  I don't know if you can see
> anything obviously wrong with that.
> >
> > Thanks for your help.
> > Tony
> >
> > >>> "Allen, Michael B (RSCH)" <Michael_B_Allen at ml.com> 06/11/02 08:56PM
> >>>
> > Your password changing utility is using DCE/RPC which is why it looks
> nothing like your other trace. The
> > jcifs trace looks like a strait forward wrong password to me. Try
> capturing a Win98 machine. It' can't do
> > DCE/RPC.
> >
> > Mike
> >
> > > -----Original Message-----
> > > From:   Tony Thompson [SMTP:tony.thompson at stone-ware.com] 
> > > Sent:   Tuesday, June 11, 2002 9:43 PM
> > > To:     Michael_B_Allen at ml.com 
> > > Subject:      RE: [jcifs] Question about NT Domains
> > >
> > > I grabbed the BouncyCastle code.  There is an RC4 engine in there that
> I can use.
> > >
> > > I am having an issue with trying to get this thing working.  Here is
> the exception that I am getting:
> > >
> > > jcifs.smb.SmbException: Invalid operation for IPC service
> > >         at jcifs.smb.SmbTree.send(SmbTree.java:86)
> > >         at jcifs.smb.SmbFile.send(SmbFile.java:499)
> > >         at jcifs.smb.SmbFile.changePassword(SmbFile.java:1420)
> > >         at Test.main(Test.java:137)
> > >
> > > Attached are two Sniffer trace files.
> > >
> > > passwd.cap - is a trace of a command line utility that I grabbed off
> the net to change my password (it works).
> > >
> > > jcifs_pass.cap - is a trace of the code I added to jCIFS.
> > >
> > > Can you point me to something specific in the trace (i.e. a packet #,
> etc.) that I can use to compare the two traces to try and figure out what I
> am doing wrong?  I haven't really dug into this
> > > stuff at the wire level before so I am not quite sure what I am looking
> for just yet.
> > >
> > > Thanks.
> > > Tony
> > >
> > > >>> "Allen, Michael B (RSCH)" <Michael_B_Allen at ml.com> 06/10/02 07:52PM
> >>>
> > > RC4 is a very simple algorithm. A very simple search on google turned
> up numerous RC4.java classes.
> > >
> > > > -----Original Message-----
> > > > From: Tony Thompson [SMTP:tony.thompson at stone-ware.com] 
> > > > Sent: Monday, June 10, 2002 8:07 PM
> > > > To:   miallen at eskimo.com 
> > > > Cc:   jcifs at samba.org 
> > > > Subject:    Re: [jcifs] Question about NT Domains
> > > >
> > > > It looks like the E() is what I need to do the one way transformation
> (partially).  If the old password is longer than 8 bytes, I have to
> concatenate several results from E().
> > > >
> > > > But, I still need to do RC4 encryption on the two passwords.  I don't
> think that RC4 encryption is part of the JCE or, even if it was, that you
> would want jCIFS dependent on the JCE.  What do
> > the
> > > > Samba "guys" do?  Is there anything that we can use to do this?
> > > >
> > > > >>> "Michael B. Allen" <miallen at eskimo.com> 06/07/02 08:10PM >>>
> > > > On Fri, 07 Jun 2002 15:12:30 -0500
> > > > "Tony Thompson" <tony.thompson at stone-ware.com> wrote:
> > > >
> > > > > I decided to try and tackle this but, I am having a couple of
> issues.  According to the cifsrap2.doc, an RC4 encryption must be performed
> on the old password before it is sent.  I didn't see
> > > > anything hanging around in jCIFS that would do this.  Any
> suggestions?
> > > > >
> > > > > A one way transformation must also be performed on the old
> password.  The document describes the gyrations required to do this but,
> one of the elements of the transformation is "an 8 byte
> > string
> > > > whose value is available from Microsoft upon request".  Any idea what
> this string might be or how to get it?
> > > > >
> > > > > Is there something already in jCIFS that would do all of the above
> for me (i.e. is this same type of thing used anywhere else)?  I know it is
> a long shot but, I had to ask.
> > > >
> > > > Look  at  the  top  of jcifs/smb/SmbSession.java. You can in all
> likelyhood
> > > > just  use  the  E()  method.  It's  probably  very similar but i
> don't know
> > > > really.  It will take some fiddling and reasoning. You don't really
> need to
> > > > know much about encryption to do it but you might want to get a
> capture and
> > > > copy  out  the  encrypted  value  of  a known password so you can
> test your
> > > > encryption method.
> > > >
> > > > Mike
> > > >
> > > > --
> > > > http://www.eskimo.com/~miallen/c/jus.c 
> > > >
> > > >
> > > >
> > >
> > >  << File: passwd.cap >>  << File: jcifs_pass.cap >>
> >  << File: 98_pass.cap >>  << File: SamOemChangePasswordResponse.java >>
> << File: SamOemChangePassword.java >>
> 
> 
> 
> 


-- 
http://www.eskimo.com/~miallen/c/jus.c 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: jcifs_pass2.cap
Type: application/octet-stream
Size: 2671 bytes
Desc: not available
Url : http://lists.samba.org/archive/jcifs/attachments/20020612/af2ab647/jcifs_pass2.obj

More information about the jcifs mailing list