RE: FW: encrypt passwords = no, security=user, samba 3.0a22
Here you go. Enjoy :) N. -- Nir Soffer -=- Exanet Inc. -=- http://www.evilpuppy.org Father, why are all the children weeping? / They are merely crying son O, are they merely crying, father? / Yes, true weeping is yet to come -- Nick Cave and the Bad Seeds, The Weeping Song -Original Message- From: Richard Sharpe [mailto:[EMAIL PROTECTED] Sent: Saturday, March 15, 2003 2:30 AM To: Nir Soffer Cc: Christopher R. Hertel; [EMAIL PROTECTED] Subject: RE: FW: encrypt passwords = no, security=user, samba 3.0a22 On Tue, 11 Mar 2003, Nir Soffer wrote: FWIW turning off unicode with unicode=no helps somewhat, and both ethereal and Samba parse the session request correctly: Hmmm, I fixed a problem in Ethereal around Unicode handling last week at Connectathon. I would be very interested in a trace that shows the problem. Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com badpass.cap Description: badpass.cap aftersp.cap Description: aftersp.cap nounicode.cap Description: nounicode.cap
RE: FW: encrypt passwords = no, security=user, samba 3.0a22
On Tue, 11 Mar 2003, Nir Soffer wrote: FWIW turning off unicode with unicode=no helps somewhat, and both ethereal and Samba parse the session request correctly: Hmmm, I fixed a problem in Ethereal around Unicode handling last week at Connectathon. I would be very interested in a trace that shows the problem. Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
Re: FW: encrypt passwords = no, security=user, samba 3.0a22
Richard Sharpe wrote: On Tue, 11 Mar 2003, Nir Soffer wrote: FWIW turning off unicode with unicode=no helps somewhat, and both ethereal and Samba parse the session request correctly: Hmmm, I fixed a problem in Ethereal around Unicode handling last week at Connectathon. I would be very interested in a trace that shows the problem. Run Samba 3.0 with plaintext passwords. Then log on from both a W2K and a W/XP system. Make sure the Windows clients have been registry-hacked to allow plaintext. Piece of cake. I'm pretty sure I've sent you a capture on this before. I also sent one that showed that WindowsNT4SP3 adds extra nul bytes following some Unicode strings, and that Window2000 will sometime drop one nul byte at the end of the PrimaryDomain field (such that the PrimaryDomain Unicode string isn't properly terminated). See also the !Alert box in section 2.7.2 of my book. ;l file:///home/crh/work/docs/cifsdocs/SMB.html#SMB.7.2 Chris -)- -- Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
RE: FW: encrypt passwords = no, security=user, samba 3.0a22
Nir Soffer wrote: Something our QA department stumbled on: I try to log on to my Samba 3.0a22 installation (make, make install, the usual shebang). The client name is CACOMISTLE (not the NativeOS), the user name is nirs, (not the domain). Any ideas or thoughts, or are we doing something incredibly stupid? At a guess, you are using plaintext passwords with Unicode. If my guess is correct (a simple capture of the SMB SESSION SETUP ANDX exchange would prove it) then read on... I do not know how to convince a Windows *server* to request plaintext passwords. As you are probably aware, it is easy to get Samba to request plaintext if that's really what you want to do. What that means is that the combination of Unicode and plaintext passwords is unusual. I have seen that W2K and W/XP clients will send Unicode plaintext passwords if Samba requests it. Unfortunately, they get the field values wrong--in different ways--and it breaks the existing parsing in Samba. [ snip wonderful explanation ] The Windows systems that I've been able to check do not send Plaintext Unicode passwords correctly. My *guess* is that Microsoft never tested this because their servers don't set up the situation that would require testing. I believe that Samba can compensate, but I have not had time to look at the code (let alone fix it). It should be an easy fix. Eg.: if( Unicode Password begins with 0x00 ) skip a byte if( Unicode Password does not end in 0x ) Add two to the password length before processing Someone care to look into providing a patch? It seems to me that a more correct fix would be, in the case of encrypt passwords = no, to request a normal password and not a UNICODE one. Is this even possible in the protocol? (e.g - request non-unicode passwords, but still support non-unicode filenames?) This is definitely broken now if this the case, regardless where the bug is... Nir. -- Nir Soffer -=- Software Engineer, Exanet Inc. -=- The poor little kittens; They lost their mittens; And now you all must die. Mew, Mew, Mew, Mew, And now you all must die. www.sluggy.com, 24/10/02
Re: FW: encrypt passwords = no, security=user, samba 3.0a22
Nir Soffer wrote: : : It seems to me that a more correct fix would be, in the case of encrypt passwords = no, to request a normal password and not a UNICODE one. Is this even possible in the protocol? (e.g - request non-unicode passwords, but still support non-unicode filenames?) Unicode is either ON or OFF. If Unicode is negotiated, then the Windows clients will try to send a Unicode password. This is definitely broken now if this the case, regardless where the bug is... There are bugs in the Windows clients, clearly, but I think that we can work around them. I also think that smbclient needs to be tested in this regard. Chris -)- PS. It would also be nice (hint to others on this list) if Ethereal were patched to read these messed-up packets correctly. :) -- Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
RE: FW: encrypt passwords = no, security=user, samba 3.0a22
Nir Soffer wrote: : : It seems to me that a more correct fix would be, in the case of encrypt passwords = no, to request a normal password and not a UNICODE one. Is this even possible in the protocol? (e.g - request non-unicode passwords, but still support non-unicode filenames?) Unicode is either ON or OFF. If Unicode is negotiated, then the Windows clients will try to send a Unicode password. This is definitely broken now if this the case, regardless where the bug is... There are bugs in the Windows clients, clearly, but I think that we can work around them. I also think that smbclient needs to be tested in this regard. FWIW turning off unicode with unicode=no helps somewhat, and both ethereal and Samba parse the session request correctly: [2003/03/11 20:11:30, 3] smbd/sesssetup.c:reply_sesssetup_and_X(732) Domain=[CACOMISTLE] NativeOS=[Windows 2000 2195] NativeLanMan=[Windows 2000 5 .0] [2003/03/11 20:11:30, 3] smbd/sesssetup.c:reply_sesssetup_and_X(742) sesssetupX:[EMAIL PROTECTED] So it seems you hit the mark. Now it's time to figure out how to fix it :) Thanks again! Nir. -- Nir Soffer -=- Software Engineer, Exanet Inc. -=- The poor little kittens; They lost their mittens; And now you all must die. Mew, Mew, Mew, Mew, And now you all must die. www.sluggy.com, 24/10/02
Re: FW: encrypt passwords = no, security=user, samba 3.0a22
Nir Soffer wrote: : FWIW turning off unicode with unicode=no helps somewhat, and both ethereal and Samba parse the session request correctly: [2003/03/11 20:11:30, 3] smbd/sesssetup.c:reply_sesssetup_and_X(732) Domain=[CACOMISTLE] NativeOS=[Windows 2000 2195] NativeLanMan=[Windows 2000 5 .0] [2003/03/11 20:11:30, 3] smbd/sesssetup.c:reply_sesssetup_and_X(742) sesssetupX:[EMAIL PROTECTED] So it seems you hit the mark. Now it's time to figure out how to fix it :) It's something I would do if I had time right now, but I am trying to finish up several projects all at once. Thanks again! We aims to please. :) Chris -)- -- Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
