It’s a no-brainer to use Kerberos authentication to access SharePoint when Active Directory (AD) is your identity store. The Kerberos authentication protocol is the highest performance Windows Server authentication mechanism out of the box, and Kerberos is currently the most secure authentication mechanism supported by AD. (For more information about Kerberos, check out the sidebar, “10 Important Kerberos Facts,” page 78.)
In the Windows SharePoint 3.0 (WSS 3.0) Central Administration interface, Microsoft recommends that you use Kerberos authentication. Unfortunately, when you choose Kerberos authentication, Microsoft displays an ambiguous message that says an administrator might have to configure an application pool account to allow for Kerberos authentication if the application pool account is not Network Service. Further, there’s no reference to any documentation where you can figure out what the heck to do to make Kerberos authentication work. To complicate matters, Microsoft’s article explaining how to configure Microsoft Office SharePoint Server 2007 (MOSS) to use Kerberos authentication (see support.microsoft.com/?kbid=832769) actually contains the following quote: “Most of the time, you should choose NTLM [NT LAN Manager] authentication.” How’s that for an inconsistent message?
But we’ve found that Kerberos is truly the best authentication method, especially for such uses as authentication over a slow link or a public network and with smart cards. And when you have finished reading our article, you will know which Kerberos authentication features you need, what to do to configure these features in a SharePoint environment, and how to verify that Kerberos authentication is working.
System Requirements
To run in a Windows network, Kerberos authentication requires several components, which Figure 1 shows. If you’re running AD, you probably have most of the pieces in place already: a trusted authority called the Key Distribution Center (KDC-for details on exactly what the KDC does, see the Microsoft article “How the Kerberos Version 5 Authentication Protocol Works,” at technet2.microsoft.com/ windowsserver/en/library/4a1daa3e-b45c- 44ea-a0b6-fe8910f92f281033.mspx?pf=true), clients that support Kerberos authentication, a time service, TCP/IP, AD-integrated DNS, and the ability to configure Service Principal Names (SPNs).
The KDC arbitrates secure communication between two clients. Each AD domain controller (DC) is already a KDC. The KDC uses timestamps in the authentication process. Because AD relies on a time service for directory service activities such as replication, if you’re already using AD the time service will be configured for a properly functioning AD implementation. In addition, it’s likely that you have AD-integrated DNS already operating in your network. Of course, you can also support BIND DNS servers in an AD implementation. If you do use BIND DNS, all you have to do to implement Kerberos is add SRV records for each AD domain specifically to support the LDAP and Kerberos protocols. (For information on how to configure your BIND DNS server to support Kerberos, see the article “Configure BIND DNS to Answer Active Directory Queries” at www.linuxquestions.org/linux/answers/Networking/Configure_BIND_DNS_to_Answer_Active_Directory_Queries.)
Finally, all Windows 2000 clients and beyond support Kerberos authentication. Kerberos is an open standard so, as you might expect, additional clients such as Mac OS X, Sun Microsystems Solaris, and Red Hat Linux also support Kerberos authentication. After you verify that your network meets the basic requirements, the next step is configuration.
Initial Steps to Support Kerberos Authentication
The first steps in configuring Kerberos authentication, namely setting one or more SPNs and configuring each SharePoint Web application to use Kerberos authentication, apply to all MOSS/ WSS 3.0 implementations. Before diving too deeply into how you accomplish these two configuration steps, it’s important to understand the underlying MOSS/WSS Web application architecture and how it maps to the Internet Information Services (IIS) Web site architecture on which it runs.
A typical MOSS instance contains multiple Web applications. For example, a Web application is assigned to host SharePoint Central Administration and another hosts the Share- Point Shared Service Provider (SSP). You create these two Web applications when you install and initially configure MOSS. To let users interact with MOSS, you then create one or more Web applications to host your portal. Users log on to this Web application. In addition, you create another Web application if you want to implement the MySite feature. Each Web application is an IIS 6.0 Web site. Although the MOSS/WSS 3.0 interface lets you create the MySite feature in the SSP, the setup procedure advises you to create a separate Web Application. This is a good idea, especially for simplifying disaster recovery.
An essential part of an IIS 6.0 or later Web site is its application pool. Each IIS 6.0 Web site is assigned to an application pool. For security and stability, the application pool separates the worker process for one or more Web sites from the content and configuration settings for those Web sites. Although you can assign more than one IIS Web application to the same application pool, you should configure each MOSS Web application to use its own application pool. Within the application pool you specify the identity of a user account for running the Web site process. By default, IIS assigns the built-in Network Service identity to an application pool. However, Microsoft doesn’t recommend this configuration for MOSS/WSS 3.0 Web applications. Instead, each application pool should use a unique domain user account and be assigned to a single Web application. See the Microsoft article “Plan for administrative and service accounts (Office SharePoint Server),” (technet2.microsoft.com/Office/en-us/library/f07768d4-ca37-447a-a056-1a67d93ef5401033.mspx?mfr=true).
What’s a Service Principal Name?
Each user account that is used by an application pool requires that an SPN be set against it to allow Kerberos authentication to work. An SPN uniquely identifies a user account or computer account as a service host at a specific target address. This distinction is essential for helping to prevent service (daemon) spoofing, which occurs when a system accidentally connects to a malicious daemon of the same name running on a different machine or operating with a different user account. In addition, the SPN is critical to the proper operation of the KDC ticket-granting process. To learn more about the Kerberos authentication protocol architecture, review the resources listed in the Web Learning Path at www.windowsitpro.com/Article/ArticleID/97376/Windows_97376.html.
In Kerberos 5, the different parts of the SPN are delimited with a forward slash: class/host: port/name. The class name is a value such as HOST, HTTP, or LDAP. HOST is a special name and always represents the builtin services running on a computer registered in AD. Any other class name acts as an alias of a HOST name. It’s useful to assign a symbolic class name to differentiate specific types of services you might be providing, such as http services. For example, Microsoft Internet Explorer (IE) and IIS use the HTTP class name for Kerberos authentication. Note that the HTTP class name is not the same as the http protocol, so you can use the HTTP class name for both http and https services.
The next part of the SPN is the host name, not to be confused with the HOST class name; the host name can include a port value. The two types of host names you should register for an SPN are the NetBIOS name (computer name) and the Fully Qualified Domain Name (FQDN). By registering both, you can be sure that a user who browses to either name will authenticate using Kerberos.
Continued on Page 2