The Samba-Bugzilla – Bug 1013
smbclient can't use null password with OS X (2.2.8a has no problem)
Last modified: 2005-02-07 11:19:44 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 192.168.5.90 -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
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
This has nothing to do with libsmbclient ...
current behavior is by design.
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?