Configure authentication (Windows SharePoint Services)
Updated: May 1, 2008
Applies To: Windows SharePoint Services 3.0
Topic Last Modified: 2008-04-29
In this article:
Authentication is the process of validating client identity, usually by means of a designated authority. Web site authentication helps establish that a user who is trying to access Web site resources can be verified as an authenticated entity. An authentication application obtains credentials from a user who is requesting Web site access. Credentials can be various forms of identification, such as user name and password. The authentication application tries to validate the credentials against an authentication authority. If the credentials are valid, the user who submitted the credentials is considered to be an authenticated identity.
To determine the most appropriate Windows SharePoint Services 3.0 authentication mechanism to use, consider the following issues:
To use a Windows authentication mechanism, you need an environment that supports user accounts that can be authenticated by a trusted authority.
If you use a Windows authentication mechanism, the operating system performs user credential management tasks. If you use an authentication provider other than Windows, such as forms authentication, you must plan and implement a credential management system and determine where to store user credentials.
Windows SharePoint Services 3.0 authentication for is built on the ASP.NET authentication model and includes three authentication providers:
Windows authentication provider
Forms authentication provider
Web SSO authentication provider
You can use the Active Directory directory service for authentication, or you can design your environment to validate user credentials against other data stores, such as a Microsoft SQL Server database, a lightweight directory access protocol (LDAP) directory, or any other directory that has an ASP.NET 2.0 membership provider. The membership provider specifies the type of data store you are going to use. The default ASP.NET 2.0 membership provider uses a SQL Server database. ASP.NET 2.0 includes a SQL Server membership provider.
The authentication providers are used to authenticate against user and group credentials that are stored in Active Directory, in a SQL Server database, or in a Non-Active Directory LDAP directory service (such as NDS). For more information about ASP.NET membership providers, see Configuring an ASP.NET Application to Use Membership (http://go.microsoft.com/fwlink/?LinkId=87014&clcid=0x409).
The Windows authentication provider supports the following authentication methods:
Anonymous authentication enables users to find resources in the public areas of Web sites without having to provide authentication credentials. Internet Information Services (IIS) creates the IUSR_computername account to authenticate anonymous users in response to a request for Web content. The IUSR_computername account, where computername is the name of the server that is running IIS, gives the user access to resources anonymously under the context of the IUSR account. You can reset anonymous user access to use any valid Windows account. In a stand-alone environment, the IUSR_computername account is on the local server. If the server is a domain controller, the IUSR_computername account is defined for the domain. By default, anonymous access is disabled when you create a new Web application. This provides an additional layer of security, because IIS rejects anonymous access requests before they can ever be processed if anonymous access is disabled.
Basic authentication requires previously assigned Windows account credentials for user access. Basic authentication enables a Web browser to provide credentials when making a request during an HTTP transaction. Because user credentials are not encrypted for network transmission, but are sent over the network in plaintext, using basic authentication over an unsecured HTTP connection is not recommended. To use basic authentication, you should enable Secure Sockets Layer (SSL) encryption.
Digest authentication provides the same functionality as basic authentication, but with increased security. User credentials are encrypted instead of being sent over the network in plaintext. User credentials are sent as an MD5 message digest in which the original user name and password cannot be deciphered. Digest authentication uses a challenge/response protocol that requires the authentication requestor to present valid credentials in response to a challenge from the server. To authenticate against the server, the client has to supply an MD5 message digest in a response that contains a shared secret password string. The MD5 Message-Digest Algorithm is described in detail in Internet Engineering Task Force (IETF) RFC 1321 (http://www.ietf.org).
To use digest authentication, note the following requirements:
The user and IIS server must be members of, or trusted by, the same domain.
Users must have a valid Windows user account stored in Active Directory on the domain controller.
The domain must use a Microsoft Windows Server 2003 domain controller.
You must install the IISSuba.dll file on the domain controller. This file is copied automatically during Windows Server 2003 Setup.
Integrated Windows authentication using NTLM
This method is for Windows servers that are not running Active Directory on a domain controller. NTLM is a secure protocol that supports user credential encryption and transmission over a network. NTLM is based on encrypting user names and passwords before sending the user names and passwords over the network. NTLM is the authentication protocol that is used in Windows NT Server and in Windows 2000 Server workgroup environments, and in many Active Directory deployments. NTLM is used in mixed Windows 2000 Active Directory domain environments that must authenticate Windows NT systems.
The forms authentication provider supports authentication against credentials stored in Active Directory, in a database such as a SQL Server database, or in an LDAP data store such as Novell eDirectory, Novell Directory Services (NDS), or Sun ONE. Forms authentication enables user authentication based on validation of credential input from a logon form. Unauthenticated requests are redirected to a logon page, where the user must provide valid credentials and submit the form. If the request can be authenticated, the system issues a cookie that contains a key for reestablishing the identity for subsequent requests.
Web SSO is also referred to as federated authentication or delegate authentication, because it supports secure communication across network boundaries.
SSO is an authentication method that enables access to multiple secure resources after a single successful authentication of user credentials. There are several different implementations of SSO authentication. Web SSO authentication supports secure communication across network boundaries by enabling users who have been authenticated in one organization to access Web applications in another organization. Active Directory Federation Services (ADFS) supports Web SSO. In an ADFS scenario, two organizations can create a federation trust relationship that enables users in one organization to access Web-based applications that are controlled by another organization. For information about using ADFS to configure Web SSO authentication, see Configure Web SSO authentication by using ADFS (Windows SharePoint Services).