Certificate-based authentication for Active Directory: Why it matters more as NTLM is deprecated

Microsoft is phasing out NT Lan Manager (NTLM), but replacing it across legacy systems, apps, and third-party integrations isn't simple. To manage internet-facing remote access, certificate-based authentication (CBA), also known as client certificate authentication (CCA), is often the most secure replacement. Here's when CCA can replace NTLM, and how UserLock helps implement it across two distinct use cases: to secure remote access and to extend on-prem authentication to SaaS with Active Directory single sign-on (SSO).

NTLM is the original Windows authentication protocol. Microsoft introduced NTLM in Windows NT in the 1990s as a way of authenticating network users to NT Directory Services, the forerunner of Active Directory (AD).

Security limits quickly became apparent, leading to Microsoft replacing it with the more secure protocol, Kerberos, in 2000. But Kerberos had an important design limitation: to work, it must contact a Domain Controller (DC) for key distribution, which requires "line of sight."

This works on a LAN, or when connecting remotely via a VPN, but not when connecting across the Internet. In that scenario, the DC sits behind a firewall and can't contact the DC directly.

NTLM, in contrast, is a simple challenge-response protocol and can authenticate users connecting via an IIS, RD Gateway, or Exchange server, without the need to reach a DC. This feature means NTLM is still in use for remote users connecting via the Internet where a VPN isn't accessible.

Microsoft has now called time on NTLM. Not surprising given its huge security weaknesses. Microsoft first removed NTLMv1 from Windows 11, version 24H2, and Windows Server 2025. Starting in late 2026, NTLM will be gradually disabled by default. From that point onwards, anyone who wants to keep using NTLM will have to enable it at their own risk.

CCA is a way of fingerprinting devices using a public key encryption. The organization generates a public key and then binds this to a private key for each device allowed to access the network. When a user tries to log in, the first check verifies the device's X.509 certificate, or public key identity.

CCA authentication gets a lot less attention than password credentials and MFA, but it has risen in popularity among enterprises and cloud providers because it offers a way to improve phishing resistance while implementing zero trust.

The short answer is that because every device must have its own CCA certificate, it can be complex and expensive to manage the certificate infrastructure on which it depends. Historically, this has limited CCA to larger companies able to afford this kind of investment.

Initiated using a desktop agent, UserLock Anywhere offers a way to bridge on-premises AD authentication to users connecting via the Internet where a VPN connection isn't possible.

Through UserLock Anywhere, the same AD policies and multi-factor authentication (MFA) can be applied to remote users that would apply if they were connecting via the LAN or a VPN.

UserLock Anywhere now supports doing this using device-generated client certificate authentication (also known as certificate-based authentication, or CBA), generated and stored on the device's trusted platform module (TPM) or mobile device equivalent.

Despite this, many on-premises networks can today now deploy CCA using native AD tools such as Active Directory Certificate Services (AD CS), the Windows Server role for issuing and managing public key certificates.

The role of UserLock Anywhere and UserLock SSO is to extend this to users connecting via SSO or remotely using an unsecured Internet connection. Importantly, from UserLock 13.0, it does this without relying on insecure NTLM.

• UserLock SSO:  adds an extra layer of identity assurance when signing in to SaaS applications. Certificates issued by your organization’s trusted Certificate Authority (as an alternative to AD CS) are validated automatically during login.

• UserLock Anywhere: replaces NTLM with CCA. This ensures that only domain-trusted computers with valid AD-issued certificates can communicate securely with the UserLock server, future-proofing your environment as NTLM is phased out.

To configure the client certificate authentication in UserLock Anywhere, the agent should be updated to UserLock 13.0. The computer should have a certificate present in the local trusted platform module (TPM).

In addition, SSL must be enabled, and client certificates set to "accept" on the IIS server hosting UserLock Anywhere. This is accessed via the SSL settings of the ulproxy application.

UserLock SSO, meanwhile, offers a way to integrate on-premises AD with cloud applications such as Microsoft 365 where UserLock SSO operates as an organization's identity provider (IdP). CCA can also be enabled for this connectivity.