[jcifs] jCIFS, non encrypted password and Samba 3 failure
Christopher R. Hertel
crh at ubiqx.mn.org
Thu Jun 30 17:17:06 GMT 2005
There are some oddities that are encountered when sending plaintext
passwords in Unicode format.
Windows doesn't seem to understand this mode at all. There is, as far as
I know, no way to tell Windows to use plaintext Unicode passwords. Samba
does support this mode, but I think it may be an accident. As far as I
know, however, Samba's the only server that supports plaintext+Unicode.
There are three options here:
1) If plaintext passwords are in use, don't negotiate Unicode.
That'd be annoying, since Unicode is useful for other things.
2) If plaintext and Unicode are in use, send OEM Charset (extended ASCII)
in the CaseInsensitivePassword field and see if that works. It may
not. Dunno.
3) Modify jCIFS to send the Unicode password in the (possibly broken)
format expected by Samba. (If that format is broken, as I suspect,
then we'd want to know why & how before trying to fix it in Samba.)
There are some notes about all of this near the end of the plaintext
password discussion in my book: http://www.ubiqx.org/cifs/SMB.html#SMB.8.2.1
I wrote:
In addition to the CaseInsensitivePassword field there is also a
CaseSensitivePassword field in the data block, and we haven't even
touched on that yet. This latter field is only used if Unicode has been
negotiated, and it is rare that both Unicode and plaintext will be used
simultaneously. It can happen, though. As mentioned earlier, Samba can
be easily configured to provide support for Unicode plaintext
passwords40. In theory, this should be a simple switch from ASCII to
Unicode. In practice, no client really supports it yet--and weird things
have been seen on the wire. For example:
* Clients disagree on the length of the Unicode password string in
CaseSensitivePassword. Some count the pair of nul bytes that
terminate the string, others do not. (For comparison, the length of
the ASCII CaseInsensitivePassword string does include the
terminating nul, so it seems there is precedent.)
* In testing, more than one client stored the length of the Unicode
password in the CaseInsensitivePasswordLength field... but that's
where the ASCII password length is supposed to go. The Unicode
password length should be in the CaseSensitivePasswordLength field.
How should the server interpret the password in this situation--as
ASCII or Unicode?
* One client added a nul byte at the beginning of the Unicode password
string, probably intended as a padding byte to force word alignment.
The extra nul byte was being read as the first byte of the
CaseSensitivePassword, thus misaligning the Unicode string. Another
client went further and counted the extra byte in the total length
of the Unicode password string. As a result, the password length was
given as an odd number of bytes (which should never happen).
Empirically, it would seem that Unicode plaintext passwords were never
meant to be.
An interesting fact-ette that can be gleaned from this discussion is
that there is a linkage between the password fields and the negotiation
of Unicode. Simply put:
ASCII (OEM character set) <==> CaseInsensitivePassword
Unicode <==> CaseSensitivePassword
That is, ASCII plaintext passwords are stored in the
CaseInsensitivePassword field, and Unicode plaintext passwords should be
placed into the CaseSensitivePassword field. Indeed, Ethereal names
these two fields, respectively, as "ANSI Password" and "Unicode
Password" instead of using the longer names shown above. This
relationship carries over to the challenge/response passwords as well,
as we shall soon see.
Chris -)-----
On Thu, Jun 30, 2005 at 02:25:28PM +0200, Fabrice Jammes wrote:
> jCIFS doesn't seem to work with Samba 3 with option :
> encrypt password = no
> : the problem add already been reported here
>
> http://article.gmane.org/gmane.network.samba.java/4345/match=++authenticate
>
> For next tests i use jcifs-1.2.0.jar (prior versions give same results).
>
> I capture network packets from jCIFS client and i compare them to the
> ones generated by smbclient during an authentication :
>
> With smbclient (authentication successfull)
>
> 0000 00 00 00 01 00 06 00 03 47 25 f9 8b 00 00 08 00 ........ G%......
> 0010 45 00 00 d0 ec af 40 00 40 06 0a 91 c1 37 60 2e E..... at . @....7`.
> 0020 c1 37 60 4a 0c e8 01 bd bf fd 37 f4 b0 7f f1 92 .7`J.... ..7.....
> 0030 80 18 05 b4 89 ce 00 00 01 01 08 0a 57 ae e6 d0 ........ ....W...
> 0040 00 5f 29 b8 00 00 00 98 ff 53 4d 42 73 00 00 00 ._)..... .SMBs...
> 0050 00 08 01 c8 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
> 0060 00 00 ce 16 00 00 02 00 0d ff 00 00 00 ff ff 02 ........ ........
> 0070 00 ce 16 b1 1f 00 00 00 00 15 00 00 00 00 00 5c ........ .......\
> 0080 c0 00 00 5b 00 00 50 00 63 00 65 00 63 00 37 00 ...[..M. o.t.d.e.
> 0090 35 00 30 00 31 00 33 00 00 00 66 00 6a 00 61 00 p.a.s.s. ..f.j.a.
> 00a0 6d 00 6d 00 65 00 73 00 00 00 00 00 55 00 6e 00 m.m.e.s. ....U.n.
> 00b0 69 00 78 00 00 00 53 00 61 00 6d 00 62 00 61 00 i.x...S. a.m.b.a.
> 00c0 20 00 33 00 2e 00 30 00 2e 00 31 00 34 00 61 00 .3...0. ..1.4.a.
> 00d0 2d 00 44 00 65 00 62 00 69 00 61 00 6e 00 00 00 -.D.e.b. i.a.n...
>
> With jCIFS
>
> 0000 00 00 00 01 00 06 00 03 47 25 f9 8b 00 00 08 00 ........ G%......
> 0010 45 00 01 0e b3 42 40 00 40 06 43 c0 c1 37 60 2e E....B at . @.C..7`.
> 0020 c1 37 60 4a 0a 83 01 bd cb 08 2b 4d bd 02 21 6a .7`J.... ..+M..!j
> 0030 80 18 05 b4 27 7c 00 00 01 01 08 0a 57 b1 98 5b ....'|.. ....W..[
> 0040 00 61 e6 46 00 00 00 d6 ff 53 4d 42 73 00 00 00 .a.F.... .SMBs...
> 0050 00 18 03 c0 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
> 0060 00 00 67 c2 00 00 02 00 0d 75 00 7e 00 04 41 0a ..g..... .u.~..A.
> 0070 00 01 00 00 00 00 00 00 00 14 00 00 00 00 00 54 ........ .......T
> 0080 00 00 00 41 00 50 00 63 00 65 00 63 00 37 00 35 ...A.M.o .t.d.e.p
> 0090 00 30 00 31 00 33 00 00 00 00 66 00 6a 00 61 00 .a.s.s.. ..f.j.a.
> 00a0 6d 00 6d 00 65 00 73 00 00 00 3f 00 00 00 4c 00 m.m.e.s. ..?...L.
> 00b0 69 00 6e 00 75 00 78 00 00 00 6a 00 43 00 49 00 i.n.u.x. ..j.C.I.
> 00c0 46 00 53 00 00 00 04 ff 00 00 00 00 00 01 00 4d F.S..... .......M
> 00d0 00 00 5c 00 5c 00 6a 00 6f 00 65 00 64 00 61 00 ..\.\.j. o.e.d.a.
> 00e0 6c 00 74 00 6f 00 6e 00 2e 00 75 00 6e 00 69 00 l.t.o.n. ..u.n.i.
> 00f0 76 00 2d 00 70 00 61 00 72 00 69 00 73 00 31 00 v.-.p.a. r.i.s.1.
> 0100 2e 00 66 00 72 00 5c 00 46 00 4a 00 41 00 4d 00 ..f.r.\. F.J.A.M.
> 0110 4d 00 45 00 53 00 00 00 3f 3f 3f 3f 3f 00 M.E.S... ?????.
>
> There is a space in my password "Mo tdepass" (my good password is
> "Motdepass")
>
> I try to use different values for jcifs.smb.lmCompatibility (from 0
> to 4) without success.
>
> Here are Samba logs for a jCIFS authentication :
>
> Get_Pwnam_internals did find user [fjammes]!
> [2005/06/30 10:54:26, 4] auth/pass_check.c:pass_check(621)
> pass_check: Checking (PAM) password for user fjammes (l=24)
> [2005/06/30 10:54:26, 4] auth/pampass.c:smb_pam_start(459)
> smb_pam_start: PAM: Init user: fjammes
> [2005/06/30 10:54:26, 4] auth/pampass.c:smb_pam_start(476)
> smb_pam_start: PAM: setting rhost to: 193.55.96.46
> [2005/06/30 10:54:26, 4] auth/pampass.c:smb_pam_start(485)
> smb_pam_start: PAM: setting tty
> [2005/06/30 10:54:26, 4] auth/pampass.c:smb_pam_start(493)
> smb_pam_start: PAM: Init passed for user: fjammes
> [2005/06/30 10:54:26, 4] auth/pampass.c:smb_pam_auth(510)
> smb_pam_auth: PAM: Authenticate User: fjammes
> [2005/06/30 10:54:28, 2] auth/pampass.c:smb_pam_auth(514)
> smb_pam_auth: PAM: Athentication Error for user fjammes
> [2005/06/30 10:54:28, 2] auth/pampass.c:smb_pam_error_handler(73)
> smb_pam_error_handler: PAM: Authentication Failure : Authentication failure
> [2005/06/30 10:54:28, 0] auth/pampass.c:smb_pam_passcheck(810)
> smb_pam_passcheck: PAM: smb_pam_auth failed - Rejecting User fjammes !
> [2005/06/30 10:54:28, 4] auth/pampass.c:smb_pam_end(440)
> smb_pam_end: PAM: PAM_END OK.
> [2005/06/30 10:54:28, 3] smbd/sec_ctx.c:pop_sec_ctx(386)
> pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0
> [2005/06/30 10:54:28, 5] auth/auth.c:check_ntlm_password(271)
> check_ntlm_password: unix authentication for user [fjammes] FAILED with
> error NT_STATUS_WRONG_PASSWORD
> [2005/06/30 10:54:28, 2] auth/auth.c:check_ntlm_password(312)
> check_ntlm_password: Authentication for user [fjammes] -> [fjammes]
> FAILED with error NT_STATUS_WRONG_PASSWORD
> [2005/06/30 10:54:28, 5] auth/auth_util.c:free_user_info(1380)
> attempting to free (and zero) a user_info structure
> [2005/06/30 10:54:28, 10] auth/auth_util.c:free_user_info(1383)
> structure was created for fjammes
> [2005/06/30 10:54:28, 3] smbd/error.c:error_packet(105)
> error string = Inappropriate ioctl for device
> [2005/06/30 10:54:28, 3] smbd/error.c:error_packet(129)
> error packet at smbd/sesssetup.c(899) cmd=115 (SMBsesssetupX)
> NT_STATUS_LOGON_FAILURE
> [2005/06/30 10:54:28, 0] smbd/process.c:smb_dump(841)
> created /tmp/SMBsesssetupX.9.resp len 39
> [2005/06/30 10:54:28, 5] lib/util.c:show_msg(464)
> [2005/06/30 10:54:28, 5] lib/util.c:show_msg(474)
>
> With next file :
>
> File /tmp/SMBsesssetupX.9.req
> u~AMBs▒ÀgÂ
> TAMotdepassfjammes?LinuxjCIFSÿM\\joedalton.univ-paris1.fr\FJAMMES?????
>
> Former file becomes this with a successfull smbclient authentication :
>
> ÿÿÿà¾\À[MotdepassfjammesUnixSamba 3.0.14a-Debian
>
> I didn't test with Samba 2 (we don't use it no more)
>
> Could somebody help me ?? jCIFS does not seem to work
> with Samba 3 and next setting :
>
> encrypt password = false
>
> Unfortunately we need this setting ;-)
>
> Thanks for your help.
>
--
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/ -)----- crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/ -)----- crh at ubiqx.org
More information about the jcifs
mailing list