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.
On 7/11/23 14:23, John Stoffel wrote:
>>>>>> "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
>