On Sat, 24 Mar 2012 05:31:09 +0100
Günter Kukkukk <linux@xxxxxxxxxxx> wrote:
> some background:
>
> cifs tried to connect to a XP box, which was joined to a domain.
> smbclient (and Mac) were working - cifs not.
>
> On that XP box GPOs (or others) were set in that way, that _only_
> NTLMSSP connections were allowed at all.
>
> During the "negotiate protocol" request, cifs does _not_ set the
> "extended security negotiation" bit in flags2.
> in cifs terms: #define SMBFLG2_EXT_SEC cpu_to_le16(0x800)
> Cifs supports that - but does not offer that capability to the server.
>
> So the XP server did response to _not_ support extended security in
> the capabilities field...
> Cifs tried default ntlm - and failed to connect.
> Any mount options regarding "sec=....." don't help here!
>
> So shouldn't cifs _always_ set the "extended security negotiation" bit in flags2
> during negprot (to get proper server caps)?
>
> Atm one can workaround with:
>
> echo 0x80080 > /proc/fs/cifs/SecurityFlags or
> echo 0x80 > /proc/fs/cifs/SecurityFlags
>
> to force NTLMSSP.
>
> Cheers, Günter
FWIW, specifying sec=ntlmssp should also work w/o mucking with the
entirely unintuitive SecurityFlags interface.
Now, *should* it set extsec bit unconditionally? Yes.
*Does* it? No.
The reasons for this are more or less an implementation detail in
cifs.ko. The problem is that cifs makes the decision about what
security mode to use far too early and doesn't have a mechanism to fall
back to select one properly based on what the server supports.
I proposed a set of patches to fix this a couple of years ago, but only
some were merged:
[PATCH 00/11] cifs: overhaul of auth selection code
At the time, Steve insisted that the patchset allow users to specify
multiple sec= options at mount time and somehow respect them. I didn't
see a way to do this cleanly and gave up in frustration.
The discussion surrounding that is here:
http://lists.samba.org/archive/linux-cifs-client/2010-May/005972.html
A new effort to clean up this mess would certainly be welcome from me,
but I found Steve's idea of how this should work to be unnecessarily
complicated. If someone does want to do this then I suggest the
scheme be fully written out beforehand so we can understand what the
expected behavior should be.
Personally, I think being able to specify multiple sec= options is not
worth the trouble. At mount time, users can try a different one if the
specified one fails.
--
Jeff Layton <jlayton@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
