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
Previous
Register
