NTLM was deprecated in 1999, when Windows 2000 came out. You have been supposed to use krb5 since then, and disabled the NTLM. Why is anything about NTLM still news? You have to specifically enable it on newest Windows platforms, because afaik it has been disabled by default for some 5+ years now.
I get the feeling that the author doesn't actually have much experience with production enterprise networks (where this issue occurs and is relevant).<p>It really isn't as simple as just flipping a switch and disabling NTLM:<p>> Microsoft made it very clear that they strongly recommended against disabling NTLM due to incompatibility issues. Instead, they created a system called NTLM Blocking, which requires users to edit their Windows security policies, track event logs, and whitelist applications that need access. This system, while effective if used correctly, is very complicated for normal users to configure and difficult to understand.<p>It <i>is</i> a complicated affair to fully get your network into 100% Kerberos mode. It will require prior auditing and fixing unless you want to suddenly break things in production (because this configuration is binary).<p>As a sysadmin myself, I can confidently say that most IT people (I really would say the majority) do not fully understand the authentication mechanisms on an AD network and how authentication happens in the background because Microsoft has actually succeeded in making it very transparent (except when things really break).<p>Many times Kerberos is not configured correctly in which case thanks to the NTLM fallback things still work and people will be none the wiser (which can be a bad thing precisely because people don't realize it). If you were to suddenly just disable that NTLM altogether, many things will suddenly just stop working.<p>Kerberos requires manual configuration in many cases (Service Principal Names) and its reliance on working DNS is absolute.<p>Some examples:<p>1) Need to connect to a system via IP address for whatever reason? Too bad, without NTLM it's impossible.<p>2) re: above, what if someone configured a connection string (database connection etc.) somewhere with an IP address? It won't be using Kerberos. Disable NTLM and the connection will just stop working.<p>3) Want to connect to a laptop that moves around often? Your dynamic DNS entries better be up to date. If the DNS name leads to a different device, you will get an authentication failure regardless of access because you're trying to authenticate with a Kerberos ticket for the wrong machine. See 1.<p>4) Set up a DNS CNAME (or anything that's not the server's actual hostname where configuration is mostly automatic)? Did you remember to add a Kerberos Service Principal Name for that name in AD? If not, you won't be using Kerberos with those names.<p>5) Set up a server service (SQL, IIS, etc.)? Is it running under the computer identity or a domain user account? That identity will need the proper Service Principal Name. Did you add one? If not, it won't be using Kerberos. Disable NTLM and the service will simply stop working.<p>6) Need to connect to a machine not on the domain? Need to connect to a machine on another domain with which you don't have an AD trust in place? You won't be using Kerberos.<p>To summarize, simply disabling NTLM willy-nilly on an enterprise network is going to be an RGE (resumé generating event).
>However, even when this attack is blocked over the internet, it is very rarely blocked over LAN, meaning it could be used as a method of pivoting within networks.<p>That's frightening, and I wonder if there are any exploits in the wild which do just that?
ntlm is still used every day in WiFi authentication. PEAP authentication is MS-CHAP over TLS over EAP. And the only way for non-MS products to authenticate to Active Directory is via Samba and ntlm.<p>Things would arguably be <i>more secure</i> if MS allowed for AD to export the password hashes to other systems. Querying for an NT hash via LDAP over TLS has essentially zero security problems. (Other than the NT hash itself)