Microsoft plans to kill off NTLM authentication in Windows 11
bleepingcomputer.com
bleepingcomputer.com
The moment Microsoft rolls out a "turn NTLM back on" checkbox, the internet will be flooded with "how to fix printer not working on Windows 11" articles that will linger at least as long as the stupid "just disable SELinux if you run into any kind of error" articles are sticking around.
I still think there was a lot of missed opportunity in Windows 8's implementation of UWP and still wonder what might have happened had it been given more time to iterate and more time to showcase its good sides.
(Also, Fitt's Law suggests that what's good for the touch goose is great for the mouse gander. Carefully thought out "touch screen-first" interfaces can be amazingly friendly to mouse users. Desktop users have become obsessed with reducing things down to the FPS equivalent of a "headshot" target area and have forgotten what early 640x480 Windows was like when even 32x32 pixel targets were the relative size of a barn door and much friendlier to newcomers, tired eyes/arms, and anyone in some state of different ability.)
I used Windows 8 on a laptop and it sucked. Windows 8.1 made the OS usable but it took until Windows 10 until I stopped being annoyed at the random mix between Windows and Windows Mobile UI controls. I still dislike how obviously touch-targeted the Windows applications I'll only ever interact with using a mouse are.
UWP itself was a better model in many ways, but the way they implemented them as a screen filling thing that took away your task bar was a mistake. The design language, which seems to be "make everything flat, make buttons difficult to recognise rectangles, add whitespace wherever you can", is something I'll probably never get over. I use a 1080p screen at 1x scaling, maybe I'm supposed to buy a 4k screen to make UWP feel less bloated?
I think the Windows 7 had perfectly fine mouse targets. I think the design matters too: when I was looking at a fake Windows 7 theme, I saw a picture of the X button independent of the title bar, and it felt weirdly large. Only when I dragged it up to the top right did I notice that the button was much larger than I remembered it being.
The touch targets could've been bigger (the OS was still optimised for stylus based touch screens) but Windows 10's tablet mode shows how that could've been resolved. I'm not suggesting we go back to the tiny buttons featured in Windows 2000, but I'd like to trade some modern whitespace back in for information density.
There are certainly parts of windows desktop apps with absurdly small click targets (have you tried to resize a window recently?) That doesn't mean desktop users are in favor of those.
Desktop users generally favor much more information dense interfaces that you can't achieve in a touch interface because the touch targets would be too small.
Can you design an interface that's great for both? Sure, but it's really difficult.
She might be a little slow to print, she might only speak PCL 5, she might have an external usb jet direct adapter…but she prints every time and never jams.
MSFT will be replacing some of the NTLM functionality with something called IAKERB, which is a GSS-API mechanism (aka, an SSP in Windows terminology) that allows the server application to proxy Kerberos messages between the client and the Kerberos key distribution centers (KDCs), and this will replace two things that NTLM provides:
- support for cases where there is
no direct line of sight between
the client and the KDCs
- support for using username &
password local to the server by
having the server have its own
local KDC
EDIT: I don't mind downvotes, but if I'm trying to provide useful technical information and you disagree with it it, it might be useful to say so because a) I might be wrong, b) you might be wrong, c) others might learn something.
Kerberos has requirements about clocks being synchronized such that clock skew will prevent authentication.
I rather doubt that Microsoft has made Windows any more punctual about setting its damned clock even if you give it a time server and tell it to set its time from the network.
Even if the behavior I observed was somehow rare, there's still the matter of local IT "gurus" needing to punch holes in firewalls sufficient to enable NTP and/or being punctual about setting clocks.
This is going to be fun.
In particular you'll still be able to do the workgroup thing.
This is like someone asking for Linux scripting advice and being told that there is VB Script for Linux now!
- NTLM doesn't sign packets. If you can intercept an NTLM auth request you can forward that authentication attempt to another resource and impersonate the user without needing to know or crack their password. You simply MitM the challenge-response between the client and the server. This is called NTLM relaying and is a core issue of NTLM, though some protocols have additional verification such as SMB signing, which is not enforced by default.
- NTLM has relatively weak hashes, though this is far from the biggest issue with NTLM.
- NTLM (unlike Kerberos), uses a single hash for all authentication. If you can compromise this hash, you can impersonate the user anywhere. With Kerberos, each auth event generates a signed with a narrow validity period that grants access to a tuple of user, device, and resource. Meaning if you compromise a user's Kerberos tickets, you can only impersonate them on services that they already had a ticket for at the time, and for only a few hours in until those tickets expire. The NTLM hash itself is the proof-of-identity for all NTLM auth, and this can be recovered in memory or on disk for local accounts.
- NTLM, combined with older broadcast name resolution protocols (namely LLMNR, NBT-NS mDNS, and WPAD) can be very easily intercepted and abused for NTLM relaying due to the lack of signing. It is trivial in most Windows environments to run Responder.py and get an administrative session on pretty much everything. Unless the enterprise has taken steps to harden against NTLM relaying (which is difficult both for compatibility issues and the sheer number of required changes), they're going to be vulnerable to it. My current environment has top of the line network monitoring, SIEM, and EDR, but it's still very easy to slip under the radar with NTLM relaying if you know what you're doing.
NTLM provides signing and sealing using a session key. It is the responsibility of the protocol using NTLM for auth to use that key to sign or seal. The problem is that this feature is frequently turned off.
So it's actually not accurate to say "NTLM is vulnerable to relay attacks". If someone turns off signing in SMB to improve performance, that is not a problem with NTLM, that is a problem with the operator turning off signing. If a door has a lock but it's left unlocked, is that a problem with the security of the door?
NTLM also calculates a MIC over all of the NTLMSSP tokens which provides integrity protection independent of the protocol using NTLM. That MIC includes the target SPN so even if signing is turned off, it cannot be hacked.
Regarding hashes, there are two types of NTLM hashes. There are the password equivalent hashes which are only accessible through hacking system memory of a compromised machine that has access to them. It suffices to say, this is not the path of least resistance for an attacker. This is also known as "pass the hash".
Then you have what are called NetNTLMv2 hashes within the NTLMSSP tokens exchanged during authentication. These are muxed from the password and challenge using MD4 and MD5 but also RC4 if key exchange is used (session key mentioned above). This is not trivial to break. It could easily take a room full of GPUs months and maybe never depending on the generator and complexity of the password.
The problem with NTLM is not so much with the NTLM protocol itself but with the various implementations that either don't implement the necessary security features or they simply get turned off. Last I checked Windows Server domain members do not require clients to negotiate signing by default. If an acceptor required an SPN and a MIC, that would stop a relay attack even if signing wasn't used (because they would not be able to forge the MIC without the password and the MIC factors in the SPN).
Another issue is that the security community needs to find issues to justify their existence. NTLM being oldest and relatively weak crytographically naturally draws a lot of critisizm. But the facts are obscured and hyperbolized regularly. People largely regurgitate what they hear without really knowing what they're talking about. They need to to make it at least sound like they know what they're talking about. The only way anyone REALLY knows how this stuff works is to studying the documentation ([MS-NLMP].pdf), looking at captures and step through computations in code.
Because the defaults are bad, vendors have the ability to ship products that are insecure but will still work on a default / typical network.
Administrators have to make risky changes with complex monitoring systems in place to tighten the security to a reasonable level.
The larger the network the harder this is, to the point where it becomes impossible because there are too many incompatible devices.
This is the criticism of the protocol: it not only leads to a pit of failure from which each customer has to dig their own way out.
I'm also not going to respond to a non-expert's plea for information with unnecessary minutiae like the differences between LM, NT, and NTLM hashes or the differences between NTLMv1/v2 and NetNTLM. My ommissions were intentional because i'm trying to make my comment approachable.
In a default, non-hardened Windows environment, NTLM is a nightmare. Yes, it can be secured. No, it is not straightforward.
There’s a long history here:
https://en.wikipedia.org/wiki/NTLM
The main problem is that there’s no way to reliably patch old stuff. If you have a large network, leaving NTLM enabled means attackers will continue to exploit it but as long as it’s an option slacker enterprise IT departments and vendors will continue to delay replacing it. Microsoft deprecated the protocol more than a decade ago so now they’re forcing the slackers to actually do it.
To be fair the same can be said for Kerberos. It's just that Kerberos has kept up with the times more.
- insecure and you know it - insecure and you don't know it
until you sneeze and someone's stolen everything.
Microsoft has been actively telling customers to "please stop using this" for over 10 years. Enough time has passed.
NTLM is the Telnet of file sharing. There was a time and place for it and that time has passed.
Most guides for Samba still seem to be written with NTLM in mind. Any Linux/*BSD based consumer NAS may break, as well as many hobbyist NAS setups.
Microsoft is right to get rid of these old, vulnerable protocols, but there may still be an impact.
I have no idea how to set up Kerberos. It looks like I need a Kerberos domain or something? It seems a lot more complicated.
> However, Microsoft is now working on two new Kerberos features: IAKerb (Initial and Pass Through Authentication Using Kerberos) and Local KDC (Local Key Distribution Center).
> "The local KDC for Kerberos is built on top of the local machine's Security Account Manager so remote authentication of local user accounts can be done using Kerberos," Microsoft's Matthew Palko explained.
> "This leverages IAKerb to allow Windows to pass Kerberos messages between remote local machines without having to add support for other enterprise services like DNS, netlogon, or DCLocator. IAKerb also does not require us to open new ports on the remote machine to accept Kerberos messages."
Wonder what’s going to happen there?
My guess is that Windows 11 will disable NTLM out of the box and perhaps Windows 12 will disable it entirely.
Hell, this could be sold as some kind of firewall solution with a $3/mo "enterprise" subscription. Someone can make money with this!
I knew these devices were out there, but not every network printer works as well over USB as it does over the network.
Why not?
But that's all IAKERB does. There's two use cases here: proxying to the local, SAM-backed KDC for workgroup mode authen., and proxying to domain controller KDCs for RDP and RAS and what not where the [K]DCs are not reachable directly by the client.
(There's a third use case that they don't currently seem to intend to support, which is when you try to authenticate to a Windows system by IP instead of by name. In that case they could extend IAKERB to use the Microsoft user-to-user Kerberos protocol to discover the server's name.)
> Strangely it is entirely specific to Windows 11 and by extension Windows clients. There is no mention of Windows Server.
Steve Syfuhs addressed this on twitter: there's only one Windows now, so there's no need to mention "Windows Server" because "Windows Server" == Windows.
The dream is to throw away 100% of my desktops and run with just a MacBook and a decent external monitor. I don't have the patience to manage hardcore/gamer hardware anymore.
* Noted not all activities are applicable to all people some activities may violate our terms of service and result in a closing of your account without these activites include but are not limited to, the production of tools or services that would result in loss of revenue for the Microsoft corporation, developing free or open source (FOSS) software without an authorized Microsoft FOSS developer license, publishing misinformation, false or libelous claims about the Microsoft corporation or products, and other activities as determined by Microsoft.
** Free in this case is exclusive of necessary fees, surcharges, and shipping and handeling related expenses.
Welcome to the Windows future where you get the experience you deserve.
P.S. Please don't create the torment nexus