Windows Authentication Blog : NTLM

Migrating from NTLM to Negotiate in a nutshell

Authentication — Fri, 28 Apr 2006 03:51:00 GMT

Migrating to Negotiate from NTLM is quite simple in most cases. It breaks down into these four simple steps:

First, build an SPN for your Service

When I talk to people about using Negotiate, there’s often this moment of terror when they realize they’re going to have to build an SPN. I’ve got my theories about why that might be, but suffice it to say you can hold back the terrors. It’s not difficult, and it corresponds to about 90% of the work here.

The first thing you have to do is pick an SPN prefix. This should be something unique to your application protocol. For example, if I have an application called “Flying Authentication Thing”, then FlyingAuthenticationThing would be a useful (if not particularly short) SPN prefix.

The prefix is half the work of building an SPN. The other half is literally putting that prefix in front of your server’s hostname (DNS preferred, netbios if necessary).

For example,

FlyingAuthenticationThing/my-dev-machine.ntdev.corp.microsoft.com

would denote the FlyingAuthenticationThing service on my current development machine. You can do this with the explicitly-blessed DsMakeSpn (see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ad/ad/dsmakespn.asp), or a simple sprintf.

Second, have your Service register the SPN

The SPN needs to be associated with the account your server is running as. If this is NetworkService or LocalSystem, that would be the host computer’s account (usually netbios computername$) in the Directory.

You can use DsWriteAccountSpn (see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ad/ad/dswriteaccountspn.asp?frame=true) to register that SPN. There should already be SPNs on the machine account already. Don’t disturb them… just add yours to the mix.

The cool thing about registering your SPN is that it’s generally fire-and-forget. If your computer changes names for some reason, most of the SPNs will automatically change with it.

Alternatively, you can use setspn (a reskit tool, see http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/setspn-o.asp) to write the SPN manually, since you only have to do it at installation time.

Third, have your client use the Service’s SPN.

This may seem obvious, but to get Mutual Auth, you have to actually provide the server name to the client authentication mechanism. It can’t just guess J

So, when you’re going to connect to a server (netbios name or dns name), build an SPN out of it the same way your server did above. That is, slap your SPN prefix onto the front of it with a slash in the middle.

Pass the newly-built SPN to your authentication function. In SSPI terms, this would be InitializeSecurityContext’s pszTargetName parameter. Wrappers around SSPI have their own parameters—consult your API documentation.

Fourth, have your Client and Server call Negotiate instead of NTLM

Whatever your client or server calls with NTLM, have it call it with Negotiate instead.

In SSPI terms, this means changing the call to AcquireCredentialsHandle to have “Negotiate” instead of “NTLM”. For RPC, DCOM, or other callers, it will be different, but usually just as simple – swapping, say, RPC_C_AUTHN_WINNT with RPC_C_AUTHN_GSS_SPNEGO.

Consult your API documentation for more on this if you don't use SSPI directly, since there are lots of functions that wrap SSPI in some way.

…and that’s it! You’re done!

One of the cool things about Negotiate is that it tends to know when it's necessary (and safe) to downgrade to NTLM. One of those cases is when no SPN is registered on a server's account. In those cases, the server is obviously downlevel (that is, it hasn't registered an SPN yet), so NTLM will be used. So uplevel clients can talk to downlevel servers.

Also, because Negotiate is smart enough to accept raw (non-gss-framed) NTLM, the reverse is also true: a downlevel client can talk to an uplevel server. This makes migration far less painful than one might expect from changing authentication protocols.

-Dave Christiansen

NTLM’s time has passed

Authentication — Fri, 07 Apr 2006 12:45:00 GMT

IMHO, Microsoft’s NTLM authentication protocol is getting a bit long on the tooth. Although we still support it for various reasons (many of which are obvious), you should look very sternly upon it if your application uses it.

In case you’re not familiar with the NTLM protocol, there’s a great write-up at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthn/security/microsoft_ntlm.asp.

There’s really very little reason not to migrate to the Negotiate SSP. If you haven’t considered migrating, you should do so sooner rather than later. The chief benefit of Negotiate is that it will use Kerberos if possible, and can securely downgrade to NTLM if it becomes necessary.

The benefits of Kerberos over NTLM are many—these are just a few:

Huge performance improvement, mostly for server applications
Kerberos is an open standard with a thriving community. NTLM is a proprietary protocol, and we’re looking for ways to deprecate it.
NTLM is a four-letter word. Kerberos has twice as many letters.
Kerberos in Vista will support the AES encryption type. NTLM won’t.
Kerberos supports several modes of delegation. NTLM doesn’t support any.

But if these weren’t enough, there’s always the general security factor. Of the three flavors of NTLM (LM, NTLM, and NTLMv2), only v2 holds a candle to Kerberos in terms of security. Unfortunately, you can’t actually rely on people deploying NTLMv2 correctly, and even if you could, you still wouldn’t be as safe as you were if you were using Kerberos.

Let’s look a little closer at those last two assertions, shall we?

You can’t rely on NTLMv2 being deployed correctly

I’ve heard talk that NTLMv2 is cryptographically equivalent to Win2003 Kerberos (because both use RC4/HMAC). This is more or less true. However, if your application’s security depends on this strength of crypto being used, you are pinning lots of hope on a very sick donkey.

First off, in order to use RC4 with NTLM, you need NTLMv2. NTLMv2 will only be negotiated if your LmCompatibilityLevel is set correctly (see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gp/576.asp for what this means). This is an extra step that many system administrators may or may not actually do depending on what Operating Systems are present in the deployment.

As if this weren’t enough, setting this key to ensure NTLMv2 (since v1 and LM are Right Out) is negotiated effectively cuts off a machine (or a domain) from authentication using older versions of Windows. Obviously, MS does not support those, but let’s be honest: some deployments still use them.

So, a deployment that contains, say, Windows NT 3.51, would be unable to deploy NTLMv2. For this reason, you can’t count on system administrators requiring NTLMv2 and thus cannot rely on it to secure your application protocol.

Note that it’s safe to use Negotiate in these environments, even though NTLMv2 may not be available, because Negotiate can determine that Kerberos can’t be used to a target server and will drop down to whatever version of NTLM the deployment is configured for. This allows you to actually get Kerberos in situations where it is possible to use without forsaking NTLM for the situations where it is necessary.

Mutual Authentication

The biggest problem with NTLM, in my opinion, is that all flavors of it lack support for server auth. Some have claimed that NTLM has mutual auth because the server produces a challenge after contacting its DC over the netlogon secure channel so the “server” is really the DC you contacted, but this isn’t mutual auth. It would be server auth if you were sending messages to the DC, but you’re not—you’re sending them to a file server or a mail server, or whatnot.

So: all NTLM can actually guarantee a client application is that it’s talking to someone with a secure channel. Yeah, it’s better than nothing, but it may not be enough.

Consider a file server. If I want to hit a central install-point for my domain software (\\foo\bar\baz\InstallStuff.exe), then I want to authenticate to \\foo, and then ask it to start sending bits for InstallStuff.exe to me. In this scenario, I don’t know whether \\foo is really \\foo, or whether it might be some rogue server that happens to be joined to the same domain, or some other server somewhere in my domain that’s been penetrated.

Call to Action: Migrate to Negotiate!

If your application is currently using NTLM, you should migrate to Negotiate sooner, rather than later. Negotiate is smart enough today to know when Kerberos should be used, and when using NTLM is safe. Negotiate also gives applications a chance of using new authentication protocols when they come out.

I’ll write again on the specifics of how to migrate later, but hopefully this entry will get people started thinking about whether they really need NTLM, and keep developers from writing new code that uses it.

- David Christiansen