After a bunch of noodling we're still showing about 15% of our cifs sessions to be using NTLMv2 and I suspect it has to to with our DNS and the Service Principal Names of the Computer Object for the SVM in our AD.

I've pretty much established that whether a connection gets Kerberos or NTLMv2 depends on what hostname the mapping is made to, and whether Kerberos is happy with the reverse lookup of that hostname and whether AD says there's a Service Principal Name for that hostname.

How's this for muddy waters. Our SVM sits in a different DNS domain than the AD domain its CIFS server is in. Worse, users might access it from yet another DNS domain via CNAME. And its IP is in a private IP space so it can't get a PTR record in that other DNS domain. And some number of our users are still mapping Windows network drives to yet another CNAME leftover from the last time we migrated to a new cluster and SVM. Good times. Oh, and we don't manage the Windows clients that connect to these shares, so we have limited access to what hostnames they're even mapping to. We also don't manage the Active Directory the SVM sits in except for the Computers OU where it actually sits.

I've gotten as far as 85% Kerberos by:

• moving the primary DNS entry and PTR record to our on-premise-only DNS zone, with a CNAME in the second DNS domain
• removing the SPN with the AD domain from the Attributes of the Computer Object (no one should ever be trying to reach it at the AD domain, in fact that name wouldn't even resolve in DNS).
• adding SPNs for the other two DNS domains
• despite trying yet another SPN for the short name of the old CNAME, I can not get a Kerberos connection to that legacy shortname.

I do still see new NTLMv2 connections being made but I think we're on the right track:

• I've asked the different IT shop that manages the Windows clients to update their drive mappings to our direct DNS entry for the SVM.
• I've asked the different IT shop that manages the AD to hold off on patching their DCs until we know more about this. Yet another division (with another AD and their own NetApp cluster) will be patching their DCs on 8/5.

I'll keep you posted.

"Randy" == Randy Rue <randyrue@gmail.com> writes:

Hello All,
We've upgraded our AFF-A220 to 9.13.1 as per 
https://kb.netapp.com/Support_Bulletins/Customer_Bulletins/SU530

and should be all good to go for next Tuesday's closing of the door on NTLMv2 authentication.

However,

scrb::> vserver cifs session show -vserver sdata -fields auth-mechanism,address,windows-user
node     vserver    session-id           connection-id address         auth-mechanism windows-user
-------- ---------- -------------------- ------------- --------------- -------------- ------------
scrb-a sdata      12223613813613660030 4271015427    10.6.154.156    NTLMv2         FHC\rgrasdue

still shows all of our CIFS connections using NTLMv2 to authenticate (one line is shown of
hundreds of connections)

Are we ready for next week's update? Will the auth-mechanism change
after we patch our DCs? Or will all our CIFS connections break?

I'm in the same boat, we have a 9.5P5 cluster which just shows NTLMv1
and NTLMv2 logins.  Can't seem to get it to do kerberos.  I suspect
it's something on the DC side of things, but our admins there haven't
found anything.

My other system, running 9.3P17 (so definitely affected) is only
showing kerberos logins, so we should be ok there no matter what.  

John