Re: Microsoft CVE-2022-38023 and NTLMv2
Randy Rue <[email protected]> Mon, 17 Jul 2023 13:49:38 -0700
| Newsgroups | gmane.comp.hardware.netapp |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============6629930842709679606==
Content-Type: multipart/alternative;
boundary="------------0WhZ8Q8cxoF2TrAOQYkmOWco"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------0WhZ8Q8cxoF2TrAOQYkmOWco
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
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<[email protected]> 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
>
--------------0WhZ8Q8cxoF2TrAOQYkmOWco
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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.</p>
<p>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.<br>
</p>
<p>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.<br>
</p>
<p>I've gotten as far as 85% Kerberos by:</p>
<ul>
<li>moving the primary DNS entry and PTR record to our
on-premise-only DNS zone, with a CNAME in the second DNS domain</li>
<li>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).</li>
<li>adding SPNs for the other two DNS domains</li>
<li>despite trying yet another SPN for the short name of the old
CNAME, I can not get a Kerberos connection to that legacy
shortname.</li>
</ul>
<p>I do still see new NTLMv2 connections being made but I think
we're on the right track:</p>
<ul>
<li>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.</li>
<li>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.</li>
</ul>
<p>I'll keep you posted.<br>
</p>
<div class="moz-cite-prefix">On 7/11/23 14:23, John Stoffel wrote:<br>
</div>
<blockquote type="cite"
cite="mid:[email protected]">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">"Randy" == Randy Rue <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a> writes:
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Hello All,
We've upgraded our AFF-A220 to 9.13.1 as per
<a class="moz-txt-link-freetext" href="https://kb.netapp.com/Support_Bulletins/Customer_Bulletins/SU530">https://kb.netapp.com/Support_Bulletins/Customer_Bulletins/SU530</a>
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">and should be all good to go for next Tuesday's closing of the door on NTLMv2 authentication.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">However,
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">still shows all of our CIFS connections using NTLMv2 to authenticate (one line is shown of
hundreds of connections)
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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
</pre>
</blockquote>
</body>
</html>
--------------0WhZ8Q8cxoF2TrAOQYkmOWco--
--===============6629930842709679606==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Toasters mailing list
[email protected]
https://www.teaparty.net/mailman/listinfo/toasters
--===============6629930842709679606==--