Enable Kerberos Authentication for SMTP
[This topic is intended to address a specific issue called out by the Exchange Server Analyzer Tool. You should apply it only to systems that have had the Exchange Server Analyzer Tool run against them and are experiencing that specific issue. The Exchange Server Analyzer Tool, available as a free download, remotely collects configuration data from each server in the topology and automatically analyzes the data. The resulting report details important configuration issues, potential problems, and nondefault product settings. By following these recommendations, you can achieve better performance, scalability, reliability, and uptime. For more information about the tool or to download the latest versions, see "Microsoft Exchange Analyzers" at https://go.microsoft.com/fwlink/?linkid=34707.]
Topic Last Modified: 2006-05-12
The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine whether a Microsoft Exchange Server 2003 server that is installed on a Windows™ Server 2003 Cluster service has the Fully Qualified Domain Name (FQDN) of the server as a value for the SMTPSVC resource on the servicePrincipalName attribute.
If the Exchange Server Analyzer finds that the servicePrincipalName attribute for the SMTPSVC Exchange resource on the Cluster service does not contain the server's FQDN as a value, the Exchange Server Analyzer displays a best practice message.
It is a best practice to enable Kerberos authentication for Simple Mail Transfer Protocol (SMTP) Services on Windows Server 2003 cluster servers that are running Exchange Server 2003. You can enable Kerberos authentication by manually setting a new Service Principal Name (SPN) value for the SMTPSVC Exchange resource.
By default, Windows Server 2003 uses NTLM authentication. The Kerberos protocol is more flexible and efficient than NTLM, and more secure. The benefits gained by using Kerberos authentication are as follows:
Faster connections. With NTLM authentication, an application server must connect to a domain controller in order to authenticate each client. With Kerberos authentication, the server does not have to locate a domain controller. The server can authenticate the client by examining credentials presented by the client. Clients can obtain credentials for a particular server one time and reuse them throughout a network logon session.
Mutual authentication. NTLM enables servers to verify the identities of their clients. NTLM does not enable clients to verify a server's identity, or one server to verify the identity of another. NTLM authentication was designed for a network environment in which servers were assumed to be genuine. The Kerberos protocol makes no such assumption. Parties at both ends of a network connection can know that the party on the other end is who it claims to be.
Delegated authentication. Windows services impersonate clients when they access resources on the clients' behalf. Frequently, a service can complete its work for the client by accessing resources on the local computer. Both NTLM and Kerberos provide the information that a service must have in order to impersonate its client locally. However, some distributed applications are designed so that a front-end service must impersonate clients when it connects to back-end services on other computers. The Kerberos protocol has a proxy mechanism that enables a service to impersonate its client when it connects to other services. No equivalent is available with NTLM.
To resolve this issue, follow these steps to add the missing values for the affected attributes.
Use the SETSPN.exe tool to add an SPN with the missing values
Install the Setspn.exe tool. To obtain the Setspn.exe tool, see "Windows 2000 Resource Kit Tool : Setspn.exe" (https://go.microsoft.com/fwlink/?LinkId=28103).
The Windows Server 2003 version of the Setspn.exe command-line tool is available in the Windows Server 2003 Support Tools that are included on the Windows Server 2003 CD. To install the Server 2003 Support Tools, double-click the Suptools.msi file in the Support/Tools folder.
Follow the guidance in the SETSPN.EXE Setspn_d.txt file to add the missing value to the Active Directory object for your Exchange server. The following example demonstrates adding the FQDN value for a virtual SMTP server SPN:
Start a command prompt, and then change to the directory where you installed Setspn.exe.
At the command prompt, type the following command:
**setspn.exe-a SMTPSVC/**mail.yourdomain.com YOURSERVERNAME
Note
Replace mail.yourdomain.com with your SMTP virtual server FQDN and YOURSERVERNAME with the name of the Exchange server.
Then press Enter.