Using the NTLM Application Verifier Plug-in

Updated: November 21, 2012

Applies To: Windows 7, Windows 8, Windows Server 2008 R2, Windows Server 2012

This topic describes the NTLM Application Verifier plug-in and how to use it to identify NTLM traffic throughout your Windows environment.

In this topic

• What is the NTLM Application Verifier plug-in?

• How the NTLM Application Verifier plug-in works

• Additional resources

What is the NTLM Application Verifier plug-in?

The NTLM Application Verifier plug-in monitors an application’s individual process calls to the authentication APIs AcquireCredentialsHandle and InitializeSecurityContext to detect uses of the NTLM protocol.

Why is the plug-in useful when analyzing NTLM usage?

NTLM v1 and v2 are based on the challenge/response authentication architecture that inherently lacks server authentication thereby exposing flaws that potentially compromise the security of applications and the operating system. Two types of attacks are possible on the challenge/response authentication architecture: reflection and relay. Both of these types have been mitigated through updates over the years to the operating system, whether through design changes to applications or actual updates to the operating system.

Although Kerberos has been available for a number of years many applications are still written to use NTLM only, which reduces the security level of those applications. Kerberos cannot replace NTLM in all scenarios—principally those where a client needs to authenticate to systems that are not joined to a domain (a home network perhaps being the most common of these).

The Negotiate security service provider (authentication package) allows a backwards-compatible compromise that uses Kerberos whenever possible and only reverts to NTLM when there is no other option. Switching an application’s authentication code to use Negotiate instead of NTLM will significantly increase the security effectiveness while introducing few or no application compatibilities.

What factors cause NTLM to be “hard-coded” in an application?

In many currently deployed applications, the following two factors may cause a dependency on NTLM:

• The application explicitly selects NTLM as the authentication package

  Sometimes the use of NTLM is obvious, such as in the call to the API AcquireCredentialsHandle by using the NTLM function. In other protocol usage, the usage of NTLM might not be so obvious. For example, the RPC default authentication package (RPC_C_AUTHN_DEFAULT) is actually an alias to NTLM when RPC is used over the network. In addition, the explicit flag to select NTLM doesn’t have the NTLM abbreviation anywhere in it (RPC_C_AUTH_WINNT). By using this construct, it is easier to select NTLM without necessarily knowing you have done so.

  In place of NTLM, developers should use the Negotiate package (also known as the SPNEGO or SNEGO package). Package selection needs to match on both client and server components to allow Negotiate to attempt to use Kerberos. In other words, both client and server parts of the application need to use Negotiate. If either side uses NTLM (as might be the case with legacy versions), Negotiate will still work but will always revert to NTLM.

• The client fails to supply a valid server target name to the authentication process

  In protocols that support or require mutual authentication, such as Kerberos, the target name is used to achieve mutual authentication. Authentication APIs, such as InitializeSecurityContext, take an optional parameter, usually called something like “TargetName,” “PrincipalName,” or “ServerPrincipalName.”. This is the identifier used by domain controllers to select the correct domain account for obtaining credentials for the target service. Because NTLM architecture does not use server authentication, this parameter is not required for native NTLM to successfully authenticate. However, this requirement is enforced when Extended Protection for Authentication has been applied.

Failed Kerberos authentication attempts

Mutual authentication depends on a central authority attesting to the binding between the target name and the target itself. Kerberos, which uses this architecture, requires that a client computer obtains a service ticket that is valid for the service that the client computer is authenticating to. This is achieved by the domain controller issuing to the client computer a ticket corresponding to the target name. This ticket is encrypted with a key that only the target server can decrypt. When the client computer presents the ticket to the server the fact that the latter demonstrates to the client computer that it can decrypt the ticket proves to the client computer that the server is really the possessor of the target name.

Kerberos authentication will always fail if no target name or an invalid target name is specified. When Negotiate is selected as the authentication package, the absence of a target name or supplying an invalid target name will cause NTLM to be used. Most authentication APIs that have the target name as an optional parameter will accept NULL without error—unless the developer overrides this and provides an explicit target name NTLM.

How the NTLM Application Verifier plug-in works

The plug-in detects the following errors:

• The NTLM package is directly specified in the call to AcquireCredentialsHandle (or a higher-level wrapper API).

• The target name in the call to InitializeSecurityContext is NULL.

• The target name in the call to InitializeSecurityContext is not a properly formed service principal name (SPN), user principal name (UPN), or NetBIOS-style domain name.

The following table describes several different events that the NTLM plug-in can detect.

The plug-in also logs warnings when it detects downgrades to NTLM, for example, when an SPN is not found by the domain controller. These are only logged as warnings since they are often legitimate cases, such as authenticating to a system that is not joined to a domain.

Additional resources

• Using Application Verifier Within Your Software Development Lifecycle

• Extended Protection for Authentication

See Also

Concepts

Assessing NTLM usage