Re: [linux-cifs-client] Linux CIFS NTLMSSP mount failing against win2k8
Jeff Layton <[email protected]>
| Newsgroups | gmane.network.samba.internals,gmane.linux.file-systems.cifs |
|---|---|
| Message-ID | <[email protected]> |
On Sat, 17 Apr 2010 15:58:23 +1000 Andrew Bartlett <[email protected]> wrote: > On Fri, 2010-04-16 at 22:44 -0400, Jeff Layton wrote: > > > > - then I read the spec more carefully. The problem is that the existing > > code doesn't try to use NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY > > (aka NTLM2 -- not to be confused with NTLMv2). > > > > Without that, the server expects signatures done using rc4, but cifs > > universally uses md5 signatures. > > This isn't the case. SMB signing is always MD5. NTLM2 simply changes > the 'effective' challenge and the session key, by providing a value in > the 'LM hash' to include with the Negotiate-provided challenge. > Interesting. That seems to be contradictory to what the MS-NLMP document says. If you have a look at section 3.4.4.1, you'll see that the algorithm for computing the signature does not use md5. However if you negotiate extended session security (aka NTLM2) or use NTLMv2, then you're supposed to use md5. Perhaps we should bring that up on the dochelp list? In any case, I think the right solution is just to have CIFS always use extended session security and NTLMv2. > > So we need to negotiate with that flag > > too. At this point, I don't have the time to undertake this project > > (and it does seem to be a project), so I've left this code alone for > > now. It may be quite some time before I can fix this. It would be great > > if someone else could take on this project instead :) > > > > There are a couple of other things that could stand to be fixed too: > > > > - The client uses NTLMv1 auth in the exchange. It seems like it would > > be better to use NTLMv2 instead. Are there any known servers that > > support the NTLMSSP GSSAPI scheme but that don't support NTLMv2 auth? > > There are. The compatibility for NTLMv2 is dependent entirely on the > domain controller, while 'NTLM2 session security' does not need > co-operation from the DC. > > However, all real world DCs now support NTLMv2, as long as you get the > workstation names right etc. > > > - The code uses its own crypto routines. It would be preferable to have > > it use the kernel's crypto API where possible. > > > > - being able to do SPNEGO-wrapped NTLMSSP instead of just "raw" would > > also be great. > > > > Anyway, hopefully these notes will be helpful to whomever ends up > > fixing this code. > > I'm happy to help confuse you further if required ;-) > Thanks. This protocol is INSANE. I think we're going to have to overhaul a lot of the CIFS crypto from the ground up in order to do this right. -- Jeff Layton <[email protected]>
signature.asc
(application/pgp-signature, 198 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAkvJjXAACgkQyP0gxQMdzIAwmgCfWTmk+GAZwyVj6HvP9eQRfSzN 99sAn1ywlGDJU6nnJrLxvQA3FLa1vX7p =Cwov -----END PGP SIGNATURE-----