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

$ smbclient //borges/pub
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

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

Reply via email to