Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft plans to kill off NTLM authentication in Windows 11

bleepingcomputer.com

Post reply on HN
Print view View original

81–86 of 86 posts

Re: Microsoft plans to kill off NTLM authentication in Windows 11

#81

Post by jeroenhd »

woleium wrote: post #76
jeroenhd wrote: post #47

Earlier quoted context omitted.

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 so…

Like this? https://www.aliexpress.com/item/1005002604130322.html

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.

Re: Microsoft plans to kill off NTLM authentication in Windows 11

#82

Post by tg16 »

jiggawatts wrote: post #63
bodeadly wrote: post #52

Earlier quoted context omitted.

This is not accurate. 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 wit…

You admit yourself that the defaults are bad. 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…

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.

Re: Microsoft plans to kill off NTLM authentication in Windows 11

#83

Post by woleium »

jeroenhd wrote: post #81
woleium wrote: post #76

Earlier quoted context omitted.

Like this? https://www.aliexpress.com/item/1005002604130322.html

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’ve done one of these recently, and I ended up using an old raspberry pi 3b. It was less costly than any of the alternatives I could find.

Re: Microsoft plans to kill off NTLM authentication in Windows 11

#84

Post by NelsonMinar »

TedDoesntTalk wrote: post #26
NelsonMinar wrote: post #13

Earlier quoted context omitted.

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.

> Sonos will never update their system to modernize it Why not?

You'd have to ask them, but the Sonos v1 systems are abandoned. We're all supposed to buy new hardware.

Re: Microsoft plans to kill off NTLM authentication in Windows 11

#85

Post by bodeadly »

cryptonector wrote: post #73
folmar wrote: post #17

Earlier quoted context omitted.

Normal Kerberos. For SSO NTLM was a fallback with no SSO power only.

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.

Re: Microsoft plans to kill off NTLM authentication in Windows 11

#86

Post by cryptonector »

bodeadly wrote: post #85
cryptonector wrote: post #73

Earlier quoted context omitted.

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…

> 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.

Post reply on HN