Hi colinjones,
From reading the original bug report, to me, (but who am I anyway?), it sounds like they are more concerned with network security stuff.
Quote stuff...
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(
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.
... unQuote stuff.
My NAS is inside my little network and not exposed to the outside world. I would hate to assume (ass u me) but probably most everyone else's is too?
Those wanting to expose themselves outside have to know when to keep their overcoats buttoned.
Either that, or you get stuck with adding another check box to the template that say's "Authenticate Using LANMAN password".
How many options do you want to start sticking in templates? Beats me! From my experience I know it's a slippery slope.
How many options do you end up with to make something more flexible, or how many device specific templates do you create?
You guys know the answers and consequences better than I do.
