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.
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:
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
...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.
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.
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.
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.