Microsoft to depreciate NTLM

[Computernaut]

Summary

Microsoft have announced their intention to disable NTLM, mainly for security reasons. NTLM is used by many services as a way to integrate Windows/Microsoft-based authentication rather than a separate authentication systems (this is my understanding).

They had this to say in an article from October 11:

Quote

Future disablement of NTLM

Reducing the use of NTLM will ultimately culminate in it being disabled in Windows 11. We are taking a data-driven approach and monitoring reductions in NTLM usage to determine when it will be safe to disable. In the meantime, you can use the enhanced controls we are providing to get a head start. Once disabled by default, customers will also be able to use these controls to reenable NTLM for compatibility reasons.

 

This topic grew into quite a spirited discussion on the r/sysadmin sub-reddit, with a number of amusing comments, a well as a whole load of very legitimate concerns (link in sources). In as much as Microsoft likes to change things seemingly arbitrarily, this shift (obtrusive though it is) does make sense, since NTLM is essentially a Protocol of Theseus at this point with how many patches on top of patches on top of patches just to make it secure enough for the modern IT world.

 

Sources

Microsoft Article

Reddit thread

Edited December 2, 2023 by Computernaut
Spelling

[bcredeur97]

This is going to break so much stuff, but hopefully it goes well lol

[leadeater]

I have a feeling you'll be able to turn back on NTLM for a very long time after it is 'deprecated', like 10 years after easily. Kerberos and SPN's have been around for sooooo long but few really know how to set that up, so while they could not be using NTLM they are. Even then a lot of stuff is moving over to SAML/OAuth.

 

The reason people like NTLM, aware they are using it or not, is because it's invisible and just works with no configuration effort.

[Needfuldoer]

1 hour ago, leadeater said:

I have a feeling you'll be able to turn back on NTLM for a very long time after it is 'deprecated', like 10 years after easily.

Probably, yeah. It's been 10 years since SMB v1 was deprecated, and you can still install it on Windows 11 relatively easily.

 

https://learn.microsoft.com/en-us/windows-server/storage/file-server/troubleshoot/detect-enable-and-disable-smbv1-v2-v3?tabs=server

[StDragon]

8 hours ago, leadeater said:

I have a feeling you'll be able to turn back on NTLM for a very long time after it is 'deprecated', like 10 years after easily. Kerberos and SPN's have been around for sooooo long but few really know how to set that up, so while they could not be using NTLM they are. Even then a lot of stuff is moving over to SAML/OAuth.

 

The reason people like NTLM, aware they are using it or not, is because it's invisible and just works with no configuration effort.

It's the PKI. Maintaining the CA involves certain best-practices with keeping the root offline until needed to mint a cert again. Simple in concept, a major point of fucking up if not planned with a lifecycle in mind to the underlaying HA or VM minting the certs.

[leadeater]

7 hours ago, StDragon said:

It's the PKI. Maintaining the CA involves certain best-practices with keeping the root offline until needed to mint a cert again. Simple in concept, a major point of fucking up if not planned with a lifecycle in mind to the underlaying HA or VM minting the certs.

I think you misunderstand, there is no PKI involved with Kerberos. Or do you mean SAML/OAuth?

[StDragon]

1 hour ago, leadeater said:

I think you misunderstand, there is no PKI involved with Kerberos. Or do you mean SAML/OAuth?

Not required, but PKI is recommended for AD environments.

Configure and validate the Public Key Infrastructure in an on-premises certificate trust model - Windows Security | Microsoft Learn

[leadeater]

6 minutes ago, StDragon said:

Not required, but PKI is recommended for AD environments.

Configure and validate the Public Key Infrastructure in an on-premises certificate trust model - Windows Security | Microsoft Learn

True, it's just that Kerberos doesn't use it at all. Different things entirely, symmetric vs asymmetric encryption along with other differences like passwords and hashes.

 

The main pains points around Kerberos is the need to define SPN's for services like SQL which if you don't do or isn't done right Kerberos authentication cannot be used and it has to fall back to NTLM. Then there is Delegation/Constrained Delegation so a service is allowed to act on behalf of a user which happens with certain SQL and IIS use cases so you might have successful Kerberos authentication to the primary server endpoint connection (client to server) but then the service needs to act on behalf of the user to access another resource and it's not allowed and fails or falls back to NTLM (client to server to server) i.e. IIS accessing a SQL database with authentication impersonation so you maintain user rights access controls if you need it. You don't always want to access an SQL database like that from a website but sometimes you do.

[StDragon]

9 minutes ago, leadeater said:

The main pains points around Kerberos is the need to define SPN's for services like SQL which if you don't do or isn't done right Kerberos authentication cannot be used and it has to fall back to NTLM. 

It shouldn't be so much of a pain though (however it is in fact). Kerberos has been the default since Windows 2000, so why are we having to deal with this crap now??

I blame Microsoft. They deserve to be shit upon for this.

[leadeater]

1 minute ago, StDragon said:

It shouldn't be so much of a pain though (however it is in fact). Kerberos has been the default since Windows 2000, so why are we having to deal with this crap now??

I blame Microsoft. They deserve to be shit upon for this.

Yep, while I understand why it can be a problem there are ways to make it better. If you alter the special account permissions of the SQL service account (use an AD account damn it everyone) you can actually give the account rights to register it's own SPN's and it'll do that every time the SQL service starts and for most use cases it'll self register what you need and it'll just work.

 

Problem is it doesn't do this as part of the SQL install when you specify the service account to use, in my opinion it should but that would require the account running the install to be able to change AD user account permissions.

[StDragon]

14 minutes ago, leadeater said:

Problem is it doesn't do this as part of the SQL install when you specify the service account to use, in my opinion it should but that would require the account running the install to be able to change AD user account permissions.

Not sure how to get around that when service accounts aren't administrative in nature. In fact, you have to explicitly specify which AD accounts to run as a service within a GPO. But if you wanted to use that AD account the ability to install SQL, it would need effectively membership to the Local Administrative group on the server in which SQL would be installed. Also, for other servers as well for clustering. I suppose you could then later revoke access from the local group, but what's the point in going through all that trouble....

Anyways, MS should have set a proper path in doing this in MS SQL versions long ago. But I digress.

 

[leadeater]

28 minutes ago, StDragon said:

Not sure how to get around that when service accounts aren't administrative in nature.

Ideally when the service account is created you make this special permission change to the account but extremely few even know this is a thing, even within Microsoft. That's why the install should try and do it and if it can't flag it as a warning to tell you to make the change to the account.

 

28 minutes ago, StDragon said:

But if you wanted to use that AD account the ability to install SQL, it would need effectively membership to the Local Administrative group on the server in which SQL

No, it's not to do with the local server it's a permission change required on the AD account itself in AD.

 

You can only do this using ADSIEdit or with CLI (cmd or PowerShell), not DSA

 

 

Whenever SQL Server service starts the account svcSCCMSQLService will write in to AD the SPNs it thinks it needs against it's AD account. Permissions to create/write SPNs even against your own account is a restricted permission because it effects the entire AD environment.

[BrandonLatzig]

Ok so
I am dumb. how does this effect me

[tkitch]

2 minutes ago, BrandonLatzig said:

Ok so
I am dumb. how does this effect me

as a home user? absolutely 0.

 

It'd only affect business / enterprise customers with software that relies on NTLM.

[BrandonLatzig]

Just now, tkitch said:

as a home user? absolutely 0.

 

It'd only affect business / enterprise customers with software that relies on NTLM.

ah ok, thank you.