Datasheet

CHAPTER 1 SharePoint Foundation 2010 under the hood

Authentication Types

In conjunction with IIS, SharePoint supports several ways to allow users to authenticate. They

are not exclusive; you can apply multiple types of authentication to a web application. IIS

will apply the most restrictive method ﬁrst. If that fails, it will try the second most-restrictive

method, and so on, until it ﬁnally refuses the client or lets them log in.

ASP.NET Impersonation Authentication This authentication type allows an ASP.NET

application to use a speciﬁed account to act as its identity or run as a user authenticated by

IIS (such as IUSR if Anonymous Access were enabled).

Windows Integrated Authentication This authentication type requires the user to have

a domain account or a local account on the SharePoint server. This, of course, is the method

that Microsoft prefers and is the one used throughout this book.

Digest This also works with Active Directory, but it sends the username and password as

hashed values. It can be used if Windows Integrated Authentication is blocked by a ﬁrewall

or not being passed by a proxy server. It is also available on WebDAV servers.

Basic This type will send authentication information across a network as clear text, which

is obviously not a great idea. It is sometimes required by mobile devices.

Anonymous Access This type allows users to establish an anonymous connection with IIS

by using an anonymous or guest account.

Usually ASP.NET Impersonation and Windows Integrated Authentication are enabled by

default for SharePoint web applications.

Authentication Methods

In addition to those authentication types, SharePoint offers two Windows authentication meth-

ods during installation. These protocols don’t just govern how authentication data is passed on

the network for users trying to access SharePoint; they govern how SharePoint service accounts

themselves access resources.

NTLM This secure protocol encrypts usernames and passwords over the network. It sim-

ply sends data to the authenticating authority and back. This protocol does not require addi-

tional conﬁguration, and is the simplest to use.

Kerberos This secure protocol encrypts data but handles authentication differently than

NTLM. Kerberos is based on ticketing. A username and password are passed to an authen-

tication server, which sends back a ticket to allow the authenticated user to access network

resources. The user and the authentication server (or Key Distribution Center) must trust each

other. This means that service principal names must be set for the SharePoint servers and data-

base access accounts so resources on the network can be accessed by SharePoint on behalf of the

user. The account and the servers must be trusted for delegation in some circumstances.

Although Kerberos can be the best option for authentication, NTLM is still suggested in

many cases, because using Kerberos requires the database access account to have a service

principal name, which could be a greater danger to the network if that account is compro-

mised. And even though outside the network, authentication is tighter with the mutual

626382c01.indd 22 1/27/11 10:47:24 AM