In the end, the explanation for being unable to connect to servers using
share-level security is very straightforward. If I configure a samba
server here for security=share and connect with smbclient, I see the
following:
$ smbclient //borges/pub
Password:
Domain=[DNSG] OS=[Unix] Server=[Samba 3.0.30]
Server not using user level security and no password supplied.
Server requested LANMAN password (share-level security) but 'client use lanman
auth' is disabled
tree connect failed: SUCCESS - 0
$
The use of lanman authentication has been disabled on both client and
server in Ubuntu 8.04 because it's substantially weaker that NTLM
passwords, and therefore more vulnerable to decryption attacks of the
network traffic. To be precise, the man page for smb.conf says:
This parameter determines whether or not smbclient(8) and other
samba client tools will attempt to authenticate itself to servers
using the weaker LANMAN password hash. If disabled, only server
which support NT password hashes (e.g. Windows NT/2000, Samba,
etc... but not Windows 95/98) will be able to be connected from the
Samba client.
The LANMAN encrypted response is easily broken, due to it’s case-
insensitive nature, and the choice of algorithm. Clients without
Windows 95/98 servers are advised to disable this option.
Disabling this option will also disable the client plaintext auth
option
I didn't remember that share-level security was restricted to lanman
password authentication, but now that I see that, this failure to
connect makes sense. It is not accidental that the client refuses to
negotiate security in such a situation; I still believe this is the
correct default for libsmbclient to use in hardy, because enabling weak
authentication in the client doesn't just make it possible to use older
servers, it also makes it possible for a man-in-the-middle attacker to
trick your client into using weak authentication when trying to talk to
a newer server, compromising other passwords in the process.
As a workaround, users who need to access security=share servers can add
'client lanman auth = yes' to the [global] section of
/etc/samba/smb.conf on their hardy client systems, to enable negotiation
of this weak authentication protocol.
For nautilus/gvfs, there definitely should be a better feedback
mechanism about this problem, so that users get some indication of why
the connection has failed.
** Changed in: gvfs (Ubuntu Hardy)
Status: New => Triaged
--
SMB error: Unable to mount location when server configured with security=share
https://bugs.launchpad.net/bugs/209520
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to nautilus in ubuntu.
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
