Microsoft Exchange Server and SPNs, Part 1

Exchange Server 2007 introduced many changes to the way we manage and configure Exchange servers and services. Some of these changes are obvious because we see or interact with them every day. Other changes lurk in the shadows of some of the lesser-known parts of Exchange and Windows, either because the features are infrequently used or because they're designed to do their work automatically.

One notable example of a lurking feature is Exchange 2007's expanded support for Kerberos authentication, which extends the Kerberos support in Exchange Server 2003 by using it for more services. You probably know that Kerberos is the native authentication protocol for Windows Server 2003, Windows XP, and later Windows versions, and that it was originally designed at MIT to provide trustworthy authentication on nonsecure networks. The reason that Kerberos support is so significant in Exchange is that it lets servers identify and authenticate each other so that all server-to-server communications inside your Exchange organization can be secured. This ability is a big win from a security standpoint because it helps ensure that unauthorized servers (or users) can't impersonate legitimate users, services, or servers.

For service-level Kerberos authentication to work, each service needs to have a correctly registered Service Principal Name, or SPN. The SPN is essentially the Kerberos equivalent of a globally unique identifier (GUID): a unique identifier that lets the Kerberos subsystem, and other services and servers, pinpoint the service they want to authenticate against and communicate with. SPNs are registered in Active Directory (AD) using the Service-Principal-Name attribute associated with an account object.

Let's say that the Microsoft Exchange Transport service on server01.company.com wants to exchange mail with the transport service on server02.company.com. On each machine, the SMTP service is running under a designated account, in this case NetworkService. Server01 looks up the SPN for the transport service on server02, then uses the resulting SPN to request authentication. If the SPN is missing or wrong, authentication fails.

Microsoft provides a list of Exchange-related SPNs that must be registered in AD (see http://technet.microsoft.com/en-us/library/aa996905.aspx), but I'll wager that most Exchange administrators haven't ever looked at it. The key thing to remember is that for each of these SPNs, there should be two, and only two, names registered: one for the NetBIOS name of the server and one for its Fully Qualified Domain Name (FQDN). You can use the Setspn tool to inspect the SPNs registered in AD; usually you won't need to do this, but there are a few specific cases where you might. I'll discuss those cases, and explain how to fix SPN-related problems, in next week's UPDATE.

Meanwhile, don't forget that this is your last chance to submit entries for our "worst Exchange design" contest—get them in by January 7, 2008. Submit your entries via email to [email protected]; the judges will announce their decision the first week in February. For more information about the contest, see "Inexpensive Unified Communications Deployment, Part 2," November 15, 2007.