FW: encrypt passwords = no, security=user, samba 3.0a22

[Christopher R. Hertel]

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.

I am making a lot of assumptions about your setup, and what I am describing
may not be the actual problem (as aways, a capture would prove it), but here
is what I have seen (thanks to others on this list for supplying packet
captures):

- With plaintext ANSI passwords (OEM eight-bit character set (extended
  ASCII)) the terminating nul byte is counted when indicating the password
  length.  So, with ANSI passwords, a NULL password has a length of 1.

- When Unicode plaintext passwords are requested by the server (something
  I've only seen Samba do), Windows2000 and WindowsXP will give the ANSI
  password length as zero (0), but...
  + WindowsXP *still includes the single nul terminating byte for the ANSI
    password*.  That has the effect (as seen in Ethereal) of shifting the
    Unicode password string off by one.  Eg.:

        ANSI Password Length: 0
        Unicode Password Length: 16
        Reserved: 00000000
        Capabilities: 0x000000d4
        Byte Count (BCC): 143
        Unicode Password: 007700650061007A006C006500730000
        Account: phrep
        Primary Domain: WINXP
        Native OS: Windows 2002 2600 Service Pack 1
        Native LAN Manager: Windows 2002 5.1

    The correct Unicode password should be 7700650061007A006C00650073000000
    Ethereal (smartly) skips the extra nul byte preceeding the username
    (which is "phrep").

    Note that the password length is given as 16 bytes, which includes the
    two nul bytes required to termintate the string (or it would, if the
    Unicode string alignment were correct).

  + Windows 2000 behaves differently (this looks more like what you're
    seeing).  W2K also sets the ANSI Password Length to zero (0), but it
    doesn't add the nul byte, so the Unicode password is aligned correctly.
    Unfortunately, W2K forgets to count the terminating nul bytes in the
    Unicode Password Length:

        ANSI Password Length: 0
        Unicode Password Length: 12
        Reserved: 00000000
        Capabilities: 0x000000d4
        Byte Count (BCC): 109
        Unicode Password: 67006F006F00620065007200
        Account:
        Primary Domain: crh
        Native OS: WIGGLY
        Native LAN Manager: Windows 2000 2195
        Extra byte parameters

    The Unicode Password Length should be 14 to include the two nul bytes,
    but since the length is given as 12 Ethereal sees the Account field as
    being empty and all of the remaining strings are shifted down.  (That
    is, in this capture Account is "crh", Primary Domain is "WIGGLY", etc.)

So, there you have it.

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 0x0000 )
  Add two to the password length before processing

Someone care to look into providing a patch?

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/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org