Bug 1013 - smbclient can't use null password with OS X (2.2.8a has no problem)
Summary: smbclient can't use null password with OS X (2.2.8a has no problem)
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: smbclient (show other bugs)
Version: 3.0.1
Hardware: Other other
: P3 normal
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact:
Depends on:
Reported: 2004-01-28 09:32 UTC by David Wuertele
Modified: 2005-02-07 11:19 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description David Wuertele 2004-01-28 09:32:21 UTC
smbclient no longer works with null passwords.  Null passwords work fine for the
2.2.8a client, so the server is not the issue.

I traced the packets on the two smbclients, and I see several
differences.  The command I ran was:

  smbclient //g4-box-1/dood  -I -U dood

I used the same command on both 2.2.8a and 3.0 systems.  Here are the
differences I saw in the packets:

1.  client sends "Extended Security Negotiation: Extended security
    negotiation is supported" on 3.0, but not on 2.2.8a

2.  2.2.8a client sends ANSI Password, Unicode Password, and
    uppercased-account name.  Meanwhile, 3.0 client doesn't send
    either passwords, and sends a lowercased-account name.  I think
    this is actually the key here.

3.  the "primary domain" sent by 2.2.8a is the client's default
    domain, while the "primary domain" sent by 3.0 is the domain of
    the share being accessed

4.  2.2.8a sends "SMB Command: Session Setup AndX (0x73)" and gets
        response "NT Status: STATUS_SUCCESS (0x00000000)"
    3.0 sends same command and gets response
           "NT Status: STATUS_LOGON_FAILURE (0xc000006d)"

The server's smb.conf file includes the following three lines:

  security = user
  encrypt passwords = yes
  null passwords = yes

If I change the 'encrypt passwords' to '= no', smbclient-3.0 works
fine.  The problem is that I have the exact same problem on hosts over
which I have no control of the smb.conf file, for example Mac OS X
10.3.  10.3 appears to have the same behavior as my linux samba host
with the above three lines in the smb.conf.

When I analyze the packets sent between the client and the server, I
see the following difference in the frames (see attatchments for full
frame decode):

  samba-2.2.8a sending encrypted null password:

<        Byte Count (BCC): 69
<        ANSI Password: 4C0154EFEF076CCBAE3A6256E351DF5A...
<        Unicode Password: B30B73818904C5A7111948521702F985...
<        Account: DOOD
<        Primary Domain: ABCD

  samba-3.0 sending no password:

>        Byte Count (BCC): 26
>        Account: dood
>        Primary Domain: WORKGROUP

Note that the primary domain is also different: 3.0 uses the default
domain WORKGROUP, while 2.2.8a uses the default domain of the client
Comment 1 Richard Sharpe 2004-05-08 17:58:57 UTC
This has nothing to do with libsmbclient ...
Comment 2 Gerald (Jerry) Carter (dead mail address) 2005-02-07 10:22:35 UTC
current behavior is by design.
Comment 3 David Wuertele 2005-02-07 11:19:44 UTC
Well then I guess I'm out of luck with v3.x.  I'll have to stick to using 2.2.8a.

May I ask what was the design goal that conflicts with the feature of having
NULL passwords?  Why is that goal important for v3 and not v2.2.8a?