Bug 6682 - Netapp and krb5 failled
Netapp and krb5 failled
Status: RESOLVED FIXED
Product: CifsVFS
Classification: Unclassified
Component: kernel fs
2.6
x86 Linux
: P3 normal
: ---
Assigned To: Steve French
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-01 09:26 UTC by Thomas Sondag
Modified: 2012-04-28 00:40 UTC (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Sondag 2009-09-01 09:26:58 UTC
[ 6924.132239]  /build/buildd/linux-2.6.28/fs/cifs/cifssmb.c: Dialect: 2
[ 6924.132246]  /build/buildd/linux-2.6.28/fs/cifs/cifssmb.c: negprot rc -5
[ 6924.132255]  /build/buildd/linux-2.6.28/fs/cifs/connect.c: CIFS
VFS: leaving cifs_mount (xid = 3402) rc = -5
[ 6924.132260]  CIFS VFS: cifs_mount failed w/return code = -5

With the same setup I managed to mount a Win2003 and samba 3 shares
with kerberos.
Using smbclient -k or gvfs2 smb:// is ok with the Netapp share.
I'm not root, mount.cifs have a correct suid.
The /etc/request-key.conf is ok (and it's working with win2003 and samba 3)
The machine account in the AD is the same as the reverse dns name.
It's working fine with NTLM authentication.

As discuss on the list it's look like an Ontap bug, the network dump show :
Flags2 : 
 - Extended Security Negotiation : Extended security negotiation is not supported
and send mechType KRB5 in the same packet.

Could you please provide a workaround before the Netapp bugfix ?

In the meantime I create my own patch, it's working for me but I'm not really sure of what I'm doing.

--- cifssmb.c.old	2009-09-01 16:16:32.000000000 +0200
+++ cifssmb.c	2009-09-01 14:20:34.000000000 +0200
@@ -647,7 +647,8 @@
 	if (pSMBr->EncryptionKeyLength == CIFS_CRYPTO_KEY_SIZE) {
 		memcpy(server->cryptKey, pSMBr->u.EncryptionKey,
 		       CIFS_CRYPTO_KEY_SIZE);
-	} else if ((pSMBr->hdr.Flags2 & SMBFLG2_EXT_SEC)
+	} else if (((pSMBr->hdr.Flags2 & SMBFLG2_EXT_SEC)
+			|| (server->capabilities & CAP_EXTENDED_SECURITY))
 			&& (pSMBr->EncryptionKeyLength == 0)) {
 		/* decode security blob */
 	} else if (server->secMode & SECMODE_PW_ENCRYPT) {
@@ -657,7 +658,7 @@
 
 	/* BB might be helpful to save off the domain of server here */
 
-	if ((pSMBr->hdr.Flags2 & SMBFLG2_EXT_SEC) &&
+	if ((pSMBr->hdr.Flags2 & SMBFLG2_EXT_SEC) ||
 		(server->capabilities & CAP_EXTENDED_SECURITY)) {
 		count = pSMBr->ByteCount;
 		if (count < 16) {
Comment 1 Jeff Layton 2009-10-28 07:49:13 UTC
That doesn't quite look right...

Just because the server supports extended security we can't assume that we're actually using extended security. I think we'll need to do something different if we want to work around this netapp bug.
Comment 2 Etienne Goyer 2009-11-09 09:10:03 UTC
We are experiencing this bug too.  I understand the proposed patch is imperfect, but we will give it a whirl anyway.  If anybody have a better fix to propose, we might be able to test.
Comment 3 Etienne Goyer 2009-11-11 09:40:55 UTC
We did some test with the patch proposed by Thomas.  It does work, although not with sec=krb5i (we had to specify sec=krb5).  I understand the patch might not be the right way to resolve the problem, but it does point to the problem being where Thomas think it is indeed.

If anybody would have a better patch to test, I would be a taker.  However, I may not have access to the NetApp Filer on a regular basis in the future to test.

I have also reported the bug against Ubuntu in Launchpad:

    https://bugs.launchpad.net/samba/+bug/479272


Many thanks
Comment 4 t.schlichting 2009-11-11 11:04:08 UTC
We are also hit by this and I would like to make some remarks:

1. I think we forget one very important point: windows clients
can mount these shares!
Windows clients ignore the SMBFLG2_EXT_SEC in the SMB_COM_NEGOTIATE response,
Linux clients behave different than Windows clients in this point!

2. If I found the right part in the Microsoft documentation
(http://msdn.microsoft.com/en-us/library/cc246254%28PROT.13%29.aspx)
it says:

2.2.1, scroll down to SMB_FLAGS2_EXTENDED_SECURITY:

"Indicates that the client or server supports SPNEGO authentication,
as specified in section 3.2.4.2.3 for client behavior and sections
3.3.5.2 and 3.3.5.3 for server behavior. This bit field SHOULD be
set to 1 when NTLM 0.12 or later is negotiated for the SMB dialect
dialect and the client or server supports extended security."

The say *SHOULD*, not *MUST*...

I've also looked at 3.3.5.2 and 3.3.5.3 but did not find any MUST's
for the server response about this flag, please correct me if I
got it wrong.

So the behavior of the netapp might be perfectly legal and
not a bug?

3. What are the advantages for the client on insisting that
SMBFLG2_EXT_SEC is set? What could happen in the worst case
if CAP_EXTENDED_SECURITY is set but SMBFLG2_EXT_SEC not?

4. For economical thinking companys it is very good if
Linux clients cannot use cifs. Customers have to buy
CIFS *and* NFS licenses which is very good for
revenue. ;-)
Comment 5 Richard Smits 2011-10-24 12:58:23 UTC
We are having trouble with this too. Is there already a permanent fix available ? We tried samba 3.5.11, but also the same result.
Comment 6 Shirish S. Pargaonkar 2011-11-15 14:35:39 UTC
Is this still a problem with the latest cifs module (such as 1.75)?
Comment 7 Richard Smits 2011-11-16 15:38:23 UTC
The cifs module version 1.61 has this problem. I do not know if 1.75 still has this problem. I will try to test this.
Comment 8 Richard Smits 2011-12-14 07:56:24 UTC
cifs.ko version 1.74 works good with a mount.cifs/krb5 to a netapp filer. So this looks fixed.
Comment 9 Jeff Layton 2012-04-28 00:40:50 UTC
Excellent. Thanks for testing it.