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?
Let u s know,
Randy Rue
Randy, As far as I know, the MS patch will just require sealing on Netlogon connections. They will still be allowed. I had opened a case with Netapp support, and this is not a tunable parameter, it's just build into the patch. So you should be good. There is another tunable parameter, "cifs security modify -vserver vserver -aes-enabled-for-netlogon-channel" You may want to set this to true. Our windows engineers warned us that this will be a "next step" in MS's lockdown of auth security. FWIW, almost all of our clients are <=SMBv3 with kerberos auth, but we do notice the SVMs themselves make NTLMv2 auth to the domain controllers from time to time (on 9.10.1P12)
Fred On Friday, July 7, 2023 at 10:58:43 AM EDT, Randy Rue randyrue@gmail.com wrote:
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? Let u s know, Randy Rue_______________________________________________ Toasters mailing list Toasters@teaparty.net https://www.teaparty.net/mailman/listinfo/toasters
"Randy" == Randy Rue randyrue@gmail.com writes:
and should be all good to go for next Tuesday's closing of the door on NTLMv2 authentication.
However,
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
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:
-
Fred Grieco -
John Stoffel -
Randy Rue