Microsoft Office Tutorials and References
In Depth Information
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 first. If that fails, it will try the second most-restrictive
method, and so on, until it finally refuses the client or lets them log in.
ASP.NET Impersonation Authentication This authentication type allows an ASP.NET
application to use a specified 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 topic.
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 firewall
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
methods 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
simply sends data to the authenticating authority and back. This protocol does not require
additional configuration, 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
authentication 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
database 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
compromised. And even though outside the network, authentication is tighter with the mutual
Search JabSto ::

Custom Search