CIFS and Kerberos

rmharwood · ‎2010-07-22

Has anyone successfully worked with Kerberos authentication and CIFS shares on non-Windows clients - particularly OSX and Linux?

ONTAP 7.3.3. CIFS works perfectly fine from Windows clients and non-Windows clients using NTLM authentication but does not work with Kerberos. I've trolled every web article posting I can find but none of them seem to offer any solution. OSX falls back to asking for a password and using NTLM and smbclient on Linux always gives "SPNEGO login failed: NT_STATUS_MORE_PROCESSING_REQUIRED". I switched on the option cifs.trace_login but it does not log anything on the Netapp side for those clients.

Any ideas would be appreciated!

Cheers,

Richard

rsmits1074 · ‎2011-10-19

We have the same problem. Is there any more information about this problem ? I am going to open a support call about this.

Greetings ... Richard Smits

rmharwood · ‎2011-10-19

This was a while back, so I may be mistaken here.

I think there were two factors involved: one was to make sure that the DNS name of the filer was identical to the Kerberos principal name. We had to check the filer's entry in Active Directory for that. If it doesn't match then you have to change the DNS domain of the filer, remove the AD entry and reconfigure cifs by doing "cifs setup".

The second issue was that there is a version of OSX (although I can't remember which one) that did not successfully connect if share browsing was disabled. As long as it could successfully browse one share, it was ok. So, what we ended up doing was enabling share browsing at a filer level and then disabling share browsing on each of the shares.

Let me know if these are applicable to you and how it works out.

Cheers,

Richard

ben_fenstermaker · ‎2011-10-19

I can say that CIFS and Kerberos are working just fine for us. We are running 7.3.3 and all of our user home folders and profiles live on CIFS shares from our NetApp. We are running mostly 10.6 with a little bit of 10.5 and 10.7 mixed in on the MacOSX client side. All of the clients are bound to Active Directory and Open Directory in the normal golden triangle setup. We have no issues with the Mac clients falling back to password prompts when accessing a CIFS share.

rsmits1074 · ‎2011-10-24

Hello,

No, our Linux clients are having trouble accessing CIFS shares on our 8.01 filer. NTLM works good, krb5 nfs works also good, but krb5 to a cifs share does not work.

I am trying to get a good wireshark trace to see the raw reply from the filer. I was told it has to do with 'extended security negotiation' support' ?

I am trying to get more information from support about this.

BWAGNER_SEEDS · ‎2011-10-31

This is something I've been struggling with recently. I'm glad to find I'm not the only one with this issue. I manage the cifs client in question, not the filer, but here is what I have found out thus far:

Client: CentOS 6 with cifs-utils-4.8.1-2 installed (due to https://bugzilla.redhat.com/show_bug.cgi?id=667382)

Server A: Solaris 10 u8 x86 with kernel patch 144501-19 and samba patch 119758-20 installed.

Server B: A NetApp device (details unknown).

On the client I added printk.time=1 to add timestamps to the dmesg output. Then I loaded the cifs module, set Kerberos to be the only allowed authentication mechanism (using the SecurityFlags defined here: http://www.kernel.org/doc/readme/fs-cifs-README )and increased the cifs module debug level

# modprobe cifs

# echo 0x08008 > /proc/fs/cifs/SecurityFlags

# echo 3 > /proc/fs/cifs/cifsFYI

I also prepared /etc/request-key.conf as follows

create cifs.spnetgo * * /usr/sbin/cifs.upcall -l %k %d

create dns_resolver * * /usr/sbin/cifs.upcall -l %k %d

I then used a logon script to run the mount using the cached kerberos credentials of whoever just logged on:

/usr/bin/sudo /sbin/mount.cifs //serverA/share1 ~/mountpoint -o user=$(/usr/bin/who -m | awk '{print $1}'),uid=$(/usr/bin/id -u),gid=1406,dir_mod=0770,file_mod=0660,dynperms,domain=DOMAIN1,sec=krb5

/etc/sudoers

%DOMAIN1_group1 ALL = NOPASSWD: /sbin/mount.cifs

When a user logs on, dmesg shows the following (abridged and hand-typed, as I cannot copy/paste it easily at the moment):

fs/cifs/cifssmb.c: secFlags 0x8

fs/cifs/cifssmb.c: Kerberos only mechanism, enable extended security

[output omitted]

fs/cifs/connect.c: Security Mode: 0x3 Capabilities: 0x8080f3fd TimeAdjust: 14400

fs/cifs/sess.c: sess setup type 4

fs/cifs/cifs_spnego.c: key description =

and it goes on to succeed from there. The cifs code shows session setup type 4 is Kerberos (http://lxr.free-electrons.com/source/fs/cifs/cifsglob.h).

cifsglob.h

98 enum securityEnum {

99 LANMAN = 0, /* Legacy LANMAN auth */

100 NTLM, /* Legacy NTLM012 auth with NTLM hash */

101 NTLMv2, /* Legacy NTLM auth with NTLMv2 hash */

102 RawNTLMSSP, /* NTLMSSP without SPNEGO, NTLMv2 hash */

103 /* NTLMSSP, */ /* can use rawNTLMSSP instead of NTLMSSP via SPNEGO */

104 Kerberos, /* Kerberos via SPNEGO */

105 };

and

If I connect to the NetApp filer, which I don't manage so I know nothing about, I get this:

fs/cifs/cifssmb.c: secFlags 0x8

fs/cifs/cifssmb.c: Kerberos only mechanism, enable extended security

[output omitted]

fs/cifs/connect.c: Security Mode: 0x3 Capabilities: 0x8000e3fd TimeAdjust: 14400

fs/cifs/sess.c: sess setup type 3

fs/cifs/sess.c: ntlmssp session setup phase 1

...and it goes on to say NT_STATUS_MORE_PROCESSING_REQUIRED and eventually returns permission denied because it's using RawNTMLSSP (type 3, again from the above enum) without ever requesting a password.

The only significant difference that I can detect is in the server capabilities flag: 0x8080f3fd (working) vs 0x8000e3fd (not working). Most of these are defined here: http://lxr.free-electrons.com/source/fs/cifs/cifspdu.h

569 /* Negotiate response Capabilities */

570 #define CAP_RAW_MODE 0x00000001

571 #define CAP_MPX_MODE 0x00000002

572 #define CAP_UNICODE 0x00000004

573 #define CAP_LARGE_FILES 0x00000008

574 #define CAP_NT_SMBS 0x00000010 /* implies CAP_NT_FIND */

575 #define CAP_RPC_REMOTE_APIS 0x00000020

576 #define CAP_STATUS32 0x00000040

577 #define CAP_LEVEL_II_OPLOCKS 0x00000080

578 #define CAP_LOCK_AND_READ 0x00000100

579 #define CAP_NT_FIND 0x00000200

580 #define CAP_DFS 0x00001000

581 #define CAP_INFOLEVEL_PASSTHRU 0x00002000

582 #define CAP_LARGE_READ_X 0x00004000

583 #define CAP_LARGE_WRITE_X 0x00008000

584 #define CAP_LWIO 0x00010000 /* support fctl_srv_req_resume_key */

585 #define CAP_UNIX 0x00800000

586 #define CAP_COMPRESSED_DATA 0x02000000

587 #define CAP_DYNAMIC_REAUTH 0x20000000

588 #define CAP_PERSISTENT_HANDLES 0x40000000

589 #define CAP_EXTENDED_SECURITY 0x80000000

From this, I can see that both servers have extended security capabilities, but that the NetApp device doesn't have Unix capabilities enabled (0x00800000). However, this should not be a requirement, since I am using dynperms to let the server handle all of the permissions. The other difference is 0x0000f000 (working) vs 0x0000e000 (non working). I have not been able to find out what capability (or set of capabilities) this flag represents. Hopefully someone else can make use of this info. Ideally, the NetApp filer can be configured with CAP_UNIX or whatever 0x0000f000 is in order to resolve this issue.