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
You can also include a port value if you want to limit the SPN to a specific port or you are using non-standard ports for a particular Web application. For example, if your central administration site is hosted on port 35000, you might want to include this specification in your SPN registrations for the SharePoint Central Administration site. To offer a more detailed example, if you host Central Administration on a computer named CA01 in the fabrikam .com domain on port 35000, your SPNs for this site would be HTTP/CA01.fabrikam.com:35000 and HTTP/CA01:35000.
Finally, the name part of the SPN is rarely used except for services that are replicated. You can safely omit the name part of an SPN for your MOSS-related SPN registrations.
In terms of AD, the SPNs are values automatically written to the servicePrincipalName multivalued attribute of a computer account when it’s registered in an AD domain. For example, workstation01 in the fabrikam.com domain will have the following two SPNs automatically registered: HOST/WORKSTATION01 and HOST/workstation01.fabrikam.com. Servers registered in the domain will also have the HOST SPN entries and are likely to have some symbolic class as well, such as SMTPSVC. Because of this automatic registration, your AD client can use Kerberos authentication to authenticate you to a domain. In addition, the NT AUTHORITY\NETWORK SERVICE (aka Network Service) acts as the computer on the network and therefore inherits the SPN settings of the computer.
You might ask then, if Network Service has an SPN on it already, why bother having to set the SPN if an IIS application pool can use this account for its identity? To that we would say, great question! Microsoft recommends that you use an AD user account for each application pool supporting a MOSS Web application. Although we don’t have specific information about this, we believe Microsoft discourages the use of Network Service for this purpose because it would require that you assign several permissions to this ubiquitous and typically low-privilege account. Therefore, when you assign a user account to an Application Pool’s identity that will provide Kerberos authentication, you must then assign an SPN to that account. During the authentication handshake between the client browser and the Web application, IIS uses the SPN to retrieve a Kerberos ticket from the KDC and a session key on behalf of the logged-on user.
Setting SPNs
With the aptly named setspn command-line tool that’s part of Windows Server 2003 SP1 and later (and included as a support tool for Windows 2000 Server), you can perform SPN create, read, update, and delete operations. The create operation is referred to as registering an SPN. Figure 2 shows the registration process.
Because registering an SPN is a securitysensitive operation, you must have administrative permissions in the domain to create, update or delete an SPN. Any authenticated user can read SPNs created for a user account or computer. Being able to read an SPN is important, especially if you work in an organization where you don’t have administrative permission in the domain to set it yourself, so you can check for configuration accuracy and troubleshoot errors.
In the example of a host named corpweb and corpweb.fabrikam.com, if the application user account assigned to the MOSS Application Pool identity is fabrikam\PortalAppPool, the following SetSPN commands prepare the account for Kerberos authentication:
setspn -A HTTP/corpweb fabrikam\
PortalAppPool
setspn -A HTTP/corpweb.fabrikam .
com fabrikam\PortalAppPool
The first command sets the HTTP class and the NetBIOS name of the Web server on the fabrikam\PortalAppPool user account. The second command sets the HTTP class and fully qualified host name (DNS name) for the portal on the same user account. After registering the user account with the required SPNs, running the following command:
setspn -L portalapppol
returns the following output:
Registered ServicePrincipalNames for CN=
PORTALAPPPOOL,OU=SVCACCOUNTS,
DC=FABRIKAM,DC=COM:
HTTP/corpweb
HTTP/corpweb.fabrikam.com
The -L parameter shows the distinguished name of the PortalAppPool account and the SPNs registered on that account. Note the command parameter syntax suggests that you can run setspn commands only against computer names. However, it also works for user accounts, as the previous example demonstrates.
Continued on Page 3
SPNs to Set for MOSS
To support Kerberos authentication for MOSS, run the setspn command against the application pool accounts you have created for your MOSS Web applications to register the published names. In a typical MOSS installation, the Web applications that require SPN registrations on their associated application pool accounts are SharePoint 3.0 Central Administration, SSP, MySite, and the portal. Published names include the FQDN as it appears in your DNS (i.e., corpweb.fabrikam.com), the NetBIOS name (i.e., corpweb) and any other FQDNs that might be associated with a portal site (i.e., a DNS CNAME entry of portal.fabrikam.com that resolves to corpweb.fabrikam.com or host header addresses).
Use the port designation in the SPN host name for Web applications that are published over non-standard ports. If a particular Web application is using port 80 or 443, you don’t need to specify the port.
We have provided a simple example in the previous section for registering two SPNs and you can refer to the article “Configuring Kerberos for SharePoint 2007: Part 1 - Base Configuration for SharePoint,” (blogs.msdn.com/martinkearn/archive/2007/04/23/configuring-kerberos-for-sharepoint-2007-part-1-base-configuration-for-sharepoint.aspx) to see other example SPN commands for a MOSS instance. The author, Martin Kearn, also suggests that you configure an SPN against the SharePoint Farm Service account. However, we haven’t been able to confirm why this is necessary for this initial configuration to support Kerberos authentication.
Preparing Your Web Applications
Now that your SPNs are set, the next step is to configure the default Windows membership provider for each Web application to use Kerberos. You can complete this task from SharePoint Central Administration by following this path: Central Administration, Application Management, Authentication Providers. From the Web Application drop-down menu in the tool bar, select each Web application, then click the Default zone for the Windows membership provider.
From the Edit Authentication Web page, verify that Integrated Windows Authentication (which is synonymous with Windows Integrated Authentication) is checked, then select Negotiate (Kerberos). This option means that the Web application will attempt Kerberos authentication with the client. If this authentication fails, the Web application will downgrade to NTLM authentication. If non-Windows Integrated Authentication protocols are enabled, such as basic and digest authentication, and the client browser can’t support Kerberos or NTLM, the server will let the browser attempt basic and then digest authentication.
If you’re supporting Kerberos authentication on the Web application hosting the shared service provider, you also have to run the following stsadm command to enable Kerberos authentication:
STSADM.exe -o SetSharedWebService
Authn -negotiate
This is Step 4 in the Martin Kearn blog article we mentioned in the previous section. Note that Martin mentions additional steps required for configuring Kerberos delegation (Step 2 and part of Step 5). However, neither of these steps is necessary for the initial MOSS configuration to support Kerberos authentication.
When Kerberos Delegation Is Essential
A deciding factor for using Kerberos is whether you need to support the delegation feature. Web Figure 1 (www.windowsitpro.com, InstantDoc ID 97376), shows the process delegation and constrained delegation go through.
To understand delegation, consider impersonation. Impersonation is the process of acting as the logged-on user account to access resources. Impersonation is necessary when a service account (i.e., a MOSS application pool identity) is accessing back-end systems on behalf of a user and there is a security requirement that users must use their identity to connect to the back-end resource. Delegation simply extends impersonation across machine boundaries.
To decide whether you need this feature, you must evaluate the type of application that will serve as the front end to the authentication process, what back-end applications are involved in the authentication process, and how secure the authentication process needs to be. The following three scenarios illustrate the issues involved:
Scenario 1: A user logs on to a Windows network. The user can run Microsoft Word and open a Word document located on a network file share. The client computer contains a Kerberos ticket generated upon each user’s logon (called a Ticket-granting ticket-TGT). When a logged-on user wants to access a Word document on a file share, the user (via the client computer’s local security authority) communicates with a ticket-granting service-i.e., a KDC server. The KDC uses additional Kerberos tickets to facilitate the mutual authentication between the client and the file server containing the Word document. Each DC in an AD domain acts as a KDC. Although this explanation about how the interaction between the client and the file server occurs is significantly oversimplified, it demonstrates that base Kerberos services, not delegation, are needed in this case.
Continued on Page 4
Scenario 2: A client application authenticates with a middle-tier application and the middle-tier application then serves data from one or more back-end applications. In this case, the client application is a Web browser or Office application, the middle-tier application is the MOSS portal, and the back-end application can be a point solution (i.e., Project Server) or an integration services layer that accesses the back-end system.
Scenario 3: A service account accesses resources on behalf of a user. This process is referred to as the trusted sub-system model. The sub-system (or back-end application) trusts the middle-tier application service account so that the service account can retrieve data for a user by using the service account’s identity and hand that data to the user. This scenario scales well, but should only be used to retrieve data that doesn’t have to be secured by the user account or that requires per-user auditing.
So where is delegation necessary? The first scenario, in which a single application accesses a file share, doesn’t involve delegation. The user logs on to the system and there is no service running on another computer acting on behalf of the user to authenticate to a file share containing the Word document. In the second scenario, delegation is essential for supporting a single sign-on (SSO) experience and for authenticating to remote resources as the logged-on user. In the third scenario, the trusted sub-system model, delegation isn’t necessary because, by design, the service account isn’t impersonating users.
How to Configure Kerberos Delegation
Configuring delegation to a user account assigned as an application pool identity for a SharePoint Web application is relatively straightforward. The simplest way to enable this delegation is to navigate to the properties of a user account in the Active Directory Users and Computers snap-in.
Once there, take one of two paths depending on your domain functional level. If you’re running a Win2K domain or your Windows 2003 domain is running in Win2K domain functional level, click the Account tab and under Account Options select the Account is trusted for delegation check box. If you’re running in Windows 2003 domain functional level, select the Delegation tab in the user properties dialog box, which Figure 3 shows. (If the Delegation tab isn’t present and the domain is set to a Windows 2003 functional level, you need to go back and set an SPN on the service account.) In the Delegation tab, select one of the following three options:
Do not trust this user for delegation. This option is the default selection and doesn’t let the user account impersonate another user to any back-end system.
Trust this user for delegation to any service (Kerberos only). This option lets the user account impersonate another user to any backend system that supports Kerberos authentication. It’s time constrained because a Kerberos session key’s default expiration lifetime is 10 hours. However, it’s not constrained to a specific target. The application pool account will attempt to access any Kerberos-enabled backend target as an impersonated user.
Trust this user for delegation to specified services only. This option constrains the application pool account to a specific target or targets. As Keith Brown describes in The .NET Developer’s Guide to Windows Security (Addison Wesley, 2005), this option constrains delegation not only in time, but also in space. We specifically say “target” and not “back-end system” because the only valid target for constrained delegation is an SPN. The two typical targets are either SPN-enabled computers or user accounts. If your goal is to limit delegation to a back-end system that uses an application pool user account, you have two choices: You can either register an SPN for a target user account, as we described earlier in this article, or you can choose one of the existing SPNs assigned to the target back-end computer.
Typically, using an existing SPN assigned to the computer is adequate. Some reasons why you might want to register additional SPNs include the following:
• Users access the back-end system by a custom FQDN.
• You want to further constrain delegation by designating a specific port to which the backend service listens.
• The back-end service uses a custom service name (SPN class field) that isn't registered in the default set of SPNs on a target system.
• You choose to constrain delegation to specific user accounts rather than to specific target computers.
Figure 3 shows constrained delegation (i.e., the check box Trust this user for delegation to specified services only is selected) to a back-end system with a custom FQDN of BackEnd01. Server.Sys, two ports designated for two SPNs, one service on usahsvulm268 that’s listening on port 4000, and another service on BackEnd01 .Server.Sys that’s listening on port 45000.
When and How to Configure Protocol Transition
When one or more users accessing your portal Web applications can’t use Kerberos from their client computers or when your front-end Web servers don’t provide Windows Integrated Authentication, you can use the Kerberos Protocol Transition feature. The former case is relatively rare. However, in the latter case, some routers or firewalls won’t let you negotiate to Kerberos or even NTLM authentication. In these situations, configuring IIS to use Basic authentication over SSL is the best you can do. After IIS authenticates a user by using Basic authentication, the Kerberos Protocol Transition feature lets the front-end Web servers negotiate up to Kerberos authentication on behalf of the user.
Continued on Page 5
Configuring protocol transition is straightforward. In Figure 3, beneath the Trust this user for delegation to specified services only option are two radio buttons that let you select either Use Kerberos only or Use any authentication protocol. If you select Use Kerberos only, then constrained delegation will work only with inbound Kerberos authentication of the user. Selecting Use any authentication protocol, which Figure 3 shows, lets you use protocol transition so that the middle-tier application (MOSS, in this case) changes the incoming authentication to Kerberos from some other authentication protocol, such as Basic authentication or NTLM.
For the service to obtain an impersonation token, its service account must have the “act as part of the operating system” privilege. If it doesn’t, the service will get only an identification token.
Getting an impersonation token is essential if your goal is to allow both protocol transition and delegation. However, the impersonation token does expose your system to attacks where a user logs on as the application pool account to compromise a system. Therefore, use this feature with caution.
An identity token, however, is usually adequate if all you need is to allow protocol transition. See Web Figure 2 to get a picture of what it takes to support protocol transition. The Learning Path that appears with this article online directs you to more resources about protocol transition and Kerberos. After you configure Kerberos, you’ll need to check out the Web sidebar “Testing and Troubleshooting Kerberos,” InstantDoc ID 97378, to ensure you’ve done it correctly.
Get to Know the Three-Headed Watchdog
As you can see, Kerberos authentication in a MOSS environment is a significant and sometimes challenging topic. Small wonder that it’s named for the three-headed dog in Greek mythology that guarded the gates of the underworld. But, with a little research, perseverance, and some testing in your lab environment, you’ll soon gain experience with the threeheaded dog and hopefully let it loose on your MOSS portal. We recommend you try it!
