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.
Register your SPN when the service gets installed. You only have to do it once.
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
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
GINAs Replaced with New Credential Providers
In previous releases, the customization of interactive user logon was done by creating a custom GINA. Despite the name, GINAs were responsible for more than simply gathering authentication information and rendering the UI to collect it. Because of this, custom GINAs were complex to create and usually required Microsoft® Product Support Services (PSS) support for successful implementation. Often, using a custom GINA resulted in unintended side effects such as preventing fast user switching (FUS) and smartcard login. In Windows Vista GINAs are replaced with a new modular Credential Provider model that is easier to program to.
New Credential Security Service Provider, CredSSP
Credential Security Service Provider (CredSSP) is a new security service provider available via the Security Support Provider Interface (SSPI) in Windows. CredSSP enables an application to delegate the user’s credentials from the client (by using the client-side SSP) to the target server (via the server-side SSP). CredSSP is used by Terminal Services to provide SSO.
Stored User Names and Passwords Backup and Restore Wizard
Stored User Names and Passwords in Windows Vista includes a Backup and Restore Wizard, which allows users to back up user names and passwords they have requested Windows to remember for them. This new functionality allows users to restore the user names and passwords on any Windows Vista system. Restoring user names and passwords from a backup file will replace any existing saved user names and passwords the user has on the system.
SSL/TLS Enhancements
Microsoft has added new SSL and TLS extensions, which enable the support of both AES and new ECC cipher suites. The support for AES—not available in Microsoft Windows 2000 or Windows Server 2003—is important as AES has become a National Institute of Standards and Technology (NIST) standard. In order to ease the process of bulk encryption, several cipher suites have been added that support AES.
Schannel ECC Cipher Suite Support
Elliptical curve cryptography, known as ECC is an encryption technique that uses a public key. ECC is based on elliptic curve theory and is used to create more efficient and smaller cryptographic keys. ECC differs from other forms that use the product of very large prime numbers to create keys; ECC instead makes use of an elliptic curve equation to create keys.
In Windows Vista, the Schannel SSP includes new cipher suites that support ECC cryptography. Now, ECC cipher suites can be negotiated as part of the standard TLS handshake.
Schannel Crypto Agility
Windows Vista offers an Open Cryptographic Interface (OCI) and crypto agile capabilities for Schannel. By providing crypto agnostic capability, Microsoft enables government organizations to substitute a higher level of functionality, including advanced combinations of cipher suites. Organizations can now create new cipher suites and then plug them into Schannel.
Kerberos support for AES
This Windows Vista security enhancement will enable the use of AES encryption with Kerberos. This enhancement includes the following changes from Windows XP:
• AES support for the base Kerberos protocol: The base Kerberos protocol in Windows Vista will support AES for encryption of TGTs, Service tickets, and session keys.
• AES support for Generic Security Services (GSS)-Kerberos mechanism: In addition to enabling AES for the base protocol, GSS messages—which make up client/server communications in Windows Vista are protected with AES.
Authentication Support for Branch Domain Controllers
Windows Server code name “Longhorn” includes new authentication feature changes to support the branch office DC feature in Longhorn.
Flexible Smartcard Authentication Support
Although Microsoft Windows Server 2003 included support for smartcards as well, the types of certificates that smartcards could contain were limited by strict requirements. First of all, each certificate needed to have a user principal name (UPN) it was associated with and needed to contain the smartcard logon OID in the extended key usage (EKU) field. In addition, each certificate required that signing was used in conjunction with encryption.
To better support smartcard deployments, Microsoft has made changes to the Windows operating system to enable support for a range of certificates. Now, customers can deploy smartcards with certificates that are not limited by the previous requirements.
Last Login Time
This feature displays the time of the last successful interactive logon, and the number of failed logon attempts since the last successful logon, during a successful interactive logon. This will enable a user to determine if the account was used without his or her knowledge.
- The Windows Authentication Team
The Windows Authentication Team has 4 Program Managers, 8 developers and 8 testers and works on the core Windows authentication components such as the LSA and is responsible for Windows authentication protocols including Kerberos, SSL, NTLM and Digest. We also have one Architect, Paul Leach, who holds the title of Distinguished Engineer (the highest technical title at Microsoft). Paul has been with the team the longest since the early 90s. We also have other Architects who provide advice on the long term architecture and direction including Butler Lampson (another Distinguished Engineer and Turing award winner). Butler is known for his work on Authentication in Distributed Systems including the seminal http://research.microsoft.com/lampson/45-AuthenticationTheoryAndPractice/WebPage.html
I myself am a Program Manager in the team and have been working on authentication for the last 5 years.
JK
