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
Register
