#To Avoid CIFS issues as result of patching AD for CVE-2022-38023, Can we change the authentication?

1 messages · Page 1 of 1 (latest)

buoyant halo
#

This vulnerability in Windows only applies to domain authentication using NTLM/Netlogon. Authentication via Kerberos or FIPS is not exposed to this vulnerability and is not impacted by the patches being issued by Microsoft to address CVE-2022-38023.

We are in 9.9.1p3 now, and not ready to upgrade to 9.9.1p16 before 7/11, as the version that can support NTLM/Netlogon after AD patching.

I am not familiar with Domain Authentication, but my question is: Without upgrade ONTAP, is there anyway we can change the domain authentication from NTLM/Netlogon to Kerberos? If yes, what steps we would have to go through?

ruby flint
#

as far as I know, ntlm/Netlogin will not work if your domain controllers are patched with the July version. You will simply need to prioritize the upgrade or suffer outages. Any ntlm authentication from the filer to the DC that isn't signed and sealed will fail.

trim fiber
#

is there anyway we can change the domain authentication from NTLM/Netlogon to Kerberos?
that depends on the reason the client uses NTLM. If the client is not joined to the domain (or joined to another, non-trusted domain), there is no way to use kerberos. If the client uses IP addresses instead of FQDNs to connect to a share, you can enable kerberos (https://learn.microsoft.com/en-us/windows-server/security/kerberos/configuring-kerberos-over-ip) ...

Configuring Kerberos for IP Address

Kerberos support for IP-based SPNs

#

it might be as simple as the SPN having an incorrect hostname, if so, fixing that will enable clients to use Kerberos again

#

I wonder about this though:

we are not ready to upgrade to 9.9.1p16 before 7/11
Upgrading is non-disruptive and can be done during a lunchbreak or in the evening. We have upgraded dozens of systems with thousands of active users and hundreds of VMs on them during working hours

hard root
#

I suggest you upgrade now. Microsoft doesn’t care if you aren’t ready. If there were other viable workarounds, we would have suggested them

robust dagger
#

What is the particular reason we still use NTLM authentication versus Kerberos authentication? Can I say Kerberos is better than NTLM, and should avoid NTLM?

I know if Kerberos auth got failed, then it will fail over to NTLM, but would that be used for just in case Kerberos didn't work?

ruby flint
robust dagger
#

"we" meant "customer". I didn't mean to turn it off. If we should always configure the authentication to use Kerberos as the first try and if it didn't work, failover to NTLM? Any reasons we didn't want to use Kerberos first?

ruby flint
#

i'm guessing there are clients that either aren't on machines that aren't properly added into the domain or there are scripts/applications/samba/linux cifs users that don't have things configured to used Kerberos

robust dagger
#

I don't know details about AD authentication. But, to configure Kerberos as first try instead of NTLM, on high level, I know some configurations
need to be done on AD Controllers and ONTAP, but, are there also relevant things need to be changed with USER account and Window servers that the user account logged into?

trim fiber
#

some scenarios where the client does NOT use Kerberos:

  • the client is not in the same (or a trusted) domain
  • the client connects to the IP address (via \\10.1.2.3\share instead of \\srv.dom.org\share)
  • some or all SPNs in the SVMs AD account are not correct
robust dagger
#

So, upon my understanding, Windows servers are not involved, only SVM's, user accounts and AD are, in order to set up Kerberos authentication. Correct?

trim fiber
#

what do you mean by "set up kerberos authentication"? if you are using AD, you are already using kerberos if the client can negotiate it. Three reasons why it might not are outlined above. So you don't need to "set up kerberos", you need to try and fix your environment to actually use it if they don't already

devout venture
#

I forgot to rename my Active directory Server object to my newly renamed Netapp, will this be a problem if i rename the AD account now..?

#

its been like this for over a year with a differenct AD account not matching Netapp server name

torn pivot
#

@edgy slate ?

edgy slate
#

You should not rename the CIFS server's computer object manually in Active Directory. Note that the CIFS server name does not have to be the same as the Vserver (SVM) name. For Kerberos to work, you really just need to have the proper Service Principal Names (SPNs) in place.