Microsoft has officially deprecated New Technology LAN Manager (NTLM), saying the technology will no longer see active development as of June, and will be phased out in favor of more secure alternatives.

All versions of NTLM, including LANMAN, NTLMv1, and NTLMv2, are no longer under active feature development and are deprecated. Use of NTLM will continue to work in the next release of Windows Server and the next annual release of Windows. Calls to NTLM should be replaced by calls to Negotiate, which will try to authenticate with Kerberos and only fall back to NTLM when necessary.

NTLM is an old authentication protocol which is still in use today, but was long ago superseded by Kerberos, which is a network authentication protocol designed to provide strong authentication for client/server applications by using secret-key cryptography.

Kerberos was initially developed by the Massachusetts Institute of Technology (MIT) in the late 80s, and has since become a default authorization technology in Microsoft Windows and is also implemented in other operating systems like Apple OS, FreeBSD, UNIX, and Linux.

By today’s standards, NTLMv1 is a very weak authentication and even though v2 is much more secure than v1, it’s still not nearly as secure as Kerberos.

Kerberos provides several advantages over NTLM:

• It’s more secure because no passwords are stored locally or sent over the wire.
• It offers improved performance over NTLM authentication.
• Kerberos supports delegation, which means servers can impersonate clients and use the client’s security context to access a resource.
• Trust management is simpler because it avoids the need to have peer-to-peer trust relationships on multiple-domain environments.
• Supports multi-factor authentication (MFA).

Using NTLM authentication is a security risk that’s still being exploited in organizations around the world. For one, it’s abused in cyberattacks known as NTLM Relay attacks, where Windows domain controllers are taken over by forcing them to authenticate against malicious servers.

While we all understand the difficulties and possible setbacks when we replace a protocol which may break legacy applications, it is imperative to do this as soon as possible if you haven’t already.

A first step is to find out which applications are still using NTLM. For example, by using the Group Policy setting Network Security: Restrict NTLM: Audit NTLM authentication in this domain.

From there you can decide whether you want to switch directly to Kerberos or use Negotiate which tries Kerberos first and then switches to NTLM if that fails.

For most applications, replacing NTLM with Negotiate can be achieved by a one-line change in the AcquireCredentialsHandle request to the Security Support Provider Interface (SSPI).