Controlling and restricting NTLM usage. Part I.

NTLM is about 20 years old. And NTLMv2 as well. Believing Wikipedia, it’s available since Windows NT4 SP4, even most experienced administrators don’t remember this already.

And still, every time I’m at a customer, I see that almost nothing has changed for this 20 years. 95% of organizations don’t have or have only minimum control over which versions of NTLM are being used within their environments. A lot of good articles and blog posts have been published during the last ten years, very few things have changed.

Let’s whisk dust off from this topic and try to see what is wrong with this pesky NTLM. How to stop being afraid of NTLM and start controlling it?

Introduction

Due to the existing vulnerabilities in the NTLM protocols many organizations are trying to audit and restrict where it’s possible the extent to which this set of protocols is used. The generic recommendations are to move to Kerberos based authentication where possible, and restrict NTLM usage to NTLMv2 only, in case Kerberos is not available for particular environments. It is important to be aware that other reasons to change to Kerberos, apart from the security ones, is performance issues with NTLM in advanced environments.

Also, it is important to be aware that the recommended procedures, both for auditing and for restriction depends if the aim is to completely restrict NTLM or if the objective is to disable NTLMv1 and LM, and therefore maintaining Kerberos and NTLMv2 as the only available authentication protocols.

In this blog post we will focus on the second scenario only, simultaneous use of Kerberos and NTLMv2 and getting rid of NTLMv1 and LM as completely insecure and obsoleted protocols.

While it’s possible to harden DCs configuration to restrict the usage of LM/NTLMv1, it will cause immediate service outage for company users, as usually at least NTLMv1 is widely used. Therefore, the recommended approach is first audit and identify clients that are using NTLMv1/LM and move them to the more secure NTLMv2. After that it’s possible to restrict the usage of insecure NTLM versions by changing the following policy on domain controllers:

Network security: LAN Manager authentication level.

This policy is going to be switched to the most restrictive and secure “Send NTLMv2 response only. Refuse LM & NTLM”.

Potential impact

Usually enterprise-grade organizations could expect huge business impact and service outage in case of restricting NTLMv1 and LM without taking some preliminary steps.

Based on the data gathered in many companies, at least NTLMv1 is usually widely used. Before enabling changes, a company should be sure that some steps (discussed further) are thoroughly reviewed and carefully implemented, especially steps related to detection.

Continue reading: https://secpfe.com/wordpress/en/2017/03/02/controlling-and-restricting-ntlm-usage-part-ii-audit-and-detection/.

Comments 1

Leave a Reply

Your email address will not be published. Required fields are marked *