What would be nice would be if they could allow it only for RFC 1918 addresses with a IP TTL of one – allow the local doughnut shop to keep their old printer a bit longer with a warning but force slacker corp not to keeping procrastinating.
If this does happen, I wouldn't be surprised if someone would start selling dirt cheap "printer upgrade boxes" in the form of small Linux computers with two ethernet ports (or maybe a USB port and an ethernet port, and a WiFi access point especially for the printer) that just run Samba. If the printer is directly attached to the box, they wouldn't even introduce severe security vulnerabilities.
Hell, this could be sold as some kind of firewall solution with a $3/mo "enterprise" subscription. Someone can make money with this!
Yes, but more modern. This thing features operating systems old enough that I doubt the protocols it speaks to computers is modern enough to be secure.
I knew these devices were out there, but not every network printer works as well over USB as it does over the network.
I'm wondering more about Workgroup networking. I can understand dumping it for domain controllers, but what authentication is used on domain-less networks?
It's in the article: (and the whole reason for finally killing off NTLM)
> 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."
AFAIK there aren't, and that's the reason for that huge chasm between proper Kerberos and NTLM. I think the old Windows 7-era Home Group was somewhat of a mashup between the two with account syncing, but might've been on top of NTLM anyway.
Samba has supported Kerberos for a while. I'm sure there's some IoT shit that will break with NTLM disabled, but I believe maintained servers shouldn't be impacted.
Doesn't Samba only support Kerberos as part of a full Active Directory deployment? Switching to Kerberos authentication is not just a matter of flipping a switch, it drastically raises the minimum required infrastructure.
From what I've been able to dig up, the situation has been getting worse over time so workarounds that worked circa Samba 4.8 or 4.9 are not effective on current distros.
Many of them probably shouldn't, but if customers buy a new computer and their old workflow doesn't work on the new one, they're going to blame and "fix" the new computer rather than replace additional hardware.
Isn't SMB2 meant to be the "mostly good" one introduced in Vista? SMBv1 was an absolute shit-show. A lot of early devices only supported it using hacked up ancient GPL violating Samba builds
I'm wondering about Sonos v1 systems. They require some ancient login protocol from the server (NTLM v1?) that breaks every year or two. Sonos will never update their system to modernize it. The dumbest thing is it's just read only access for effectively a public account.
Welcome to the new Windows virtual experience, where you can connect all of your Windows devices in a joined ecosystem, and here's the best part you no longer have to worry about paying the full price of a computer, instead you'll be able to pay a small monthly subscription to get a premium Windows Connected Computing Experience(TM). You'll be able to do all the things you normally do* at a fraction of the price of buying a full machine, and best of all if there are any issues the Microsoft Experience Team will ship you a new device absolutely free of charge.** Welcome to the Windows future where you get the experience you deserve.
* 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.
Windows 365 (enterprise) is actually really nice. I started using it to manage an org transition @ work, but I am thinking I might also set up a personal instance at this point.
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.
I felt a great disturbance in the force as if thousands of pen-testers and grey hats cried out in agony as their go to means of breaking enterprise networks was lost.
Don't worry, that printer from 2003 the CEO has an emotional connection to probably requires the entire network to keep NTLM enabled.
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.
To be fair, finding a good printer is hard. Mid-range enterprise printers manufactured before 2006 are in great demand, because of the progress of enshittification by the industry.
They're not killing off printer drivers entirely, but they are moving them to userspace. A good idea that should've been implemented a long time ago, in my opinion, though I suspect printer driver manufacturers would've thrown a hissy fit if they actually did so back in the day.
They tried in Windows 8 and printer driver manufacturers did throw a hissy fit. It was one of the big propaganda sources for "UWP is terrible" discourse because UWP gave the best printer experience for userspace printer drivers and that was Windows 8's carrot incentive to try to get the driver writers to upgrade. Rather than accept the carrot most of the driver writers jumped straight into "UWP is bad and no one wants it and please, please users should ignore the nice parts like the new print driver stack" bandwagon.
I greatly disagree, personally. I don't think enough desktop users gave it a chance. It certainly didn't help that good differentiating features like the better printer stack were just about murdered in their crib.
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 disagree there are many UI patterns that make an exquisite touch interface and a horrible KB&M interface (and vice versa).
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.
I used Windows RT on a tablet and it was great. Easily beat iOS and Android at the time, and I still don't get why professionals went for iPads for so long when there were great Windows tablets that did so much more so much more easily.
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.
I jest…but I have an emotional attachment to my HP 4000 LaserJet.
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.
What is the replacement for single sign-on? NTLM was kind of useful because some web browsers supported pass-through NTLM authentication, making website login process a breathe.
For the line of sight issues that Kerberos doesn't normally deal with MSFT is adding an implementation of IAKERB, which is a Kerberos-related protocol by which an application server can proxy messages between the client and the Kerberos KDCs on behalf of the client.
The blog article doesn't actually say the IAKERB impl will proxy to KDCs. Strangely it is entirely specific to Windows 11 and by extension Windows clients. There is no mention of Windows Server. So it's not crystal clear to me that the implementation will be able to authenticate domain accounts. Maybe it will only authenticate against the "LocalKDC" on top of the local SAM just to work around the issue of being able to log into a machine without line-of-site to a KDC (or NTLM or VM console) and nothing more.
> The blog article doesn't actually say the IAKERB impl will proxy to KDCs.
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.
Every server runs a local KDC backed by the local SAM, so when you authenticate to a server in workgroup mode you'll be using Kerberos over IAKERB to do an AS exchange (think `kinit`) followed by the AP exchange. So you still get standalone username & password authentication.
I'm a Security Architect dealing with the pain of an old environment with a default NTLM configuration so i'll chime in:
- 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.
This is exactly the point i was trying to make and why i opened my comment with "default configuration environment".
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.
It’s an old, old protocol full of 90s crypto mistakes - passwords could be brute-forced in hours over a decade ago, it still uses things like MD-5, etc. and there are attacks which cannot be solved within that protocol such as “pass the hash” where you can obtain a hash from a compromised system and use it to authenticate elsewhere even though you don’t have the original password.
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.
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.
I've always loved that the time set by time.windows.com (I think that's the default that comes with Windows) always seems to be 2 to 3 minutes off the time set by the NTP.org pools. Really easy to get outside of the Kerberos 300 second allowance.
I'm late to this party so this comment will be buried, but I hope it's useful to someone.
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
The only NTLM feature not provided by the new thing is the ability to InitializeSecurityContext() without naming the target service. This is why it's not entirely a drop-in replacement, and NTLM-using applications do need remediation for this (and, along the way, to replace uses of the NTLM SSP with the Negotiate SSP). Because the apps always know a name for the target, there is no reason that this remediation should be hard. Therefore you can consider all the NTLM functionality replaced by IAKERB.
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.
85 comments
[ 2.8 ms ] story [ 126 ms ] threadWonder 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.
> 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."
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.
Why not?
* 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
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.
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.)
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.
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.
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.
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.
This is like someone asking for Linux scripting advice and being told that there is VB Script for Linux now!
In particular you'll still be able to do the workgroup thing.
- insecure and you know it - insecure and you don't know it
until you sneeze and someone's stolen everything.
- 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.
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.
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:
The only NTLM feature not provided by the new thing is the ability to InitializeSecurityContext() without naming the target service. This is why it's not entirely a drop-in replacement, and NTLM-using applications do need remediation for this (and, along the way, to replace uses of the NTLM SSP with the Negotiate SSP). Because the apps always know a name for the target, there is no reason that this remediation should be hard. Therefore you can consider all the NTLM functionality replaced by IAKERB.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.