smbclient null-password behavior differs between 3.0 and 2.2.8a

David Wuertele dave-gnus at
Wed Dec 17 01:32:38 GMT 2003

When I made the move to 3.0, I noticed that smbclient no longer works
with null passwords.  Am I missing something?  I read the FAQ, which
suggests that the server is rejecting the null password.  But I know
that null passwords work fine for the 2.2.8a client, so the server is
not the issue.  The FAQ recommends "smbclient -L host -U%", but I
don't want to set the username to null.  I want a non-null username
with a null password.

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

Any suggestions how to get 3.0 to work with null passwords?


More information about the samba-technical mailing list