Configure authentication (Office SharePoint Server)

  • Article

Applies To: Office SharePoint Server 2007

This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.

 

Topic Last Modified: 2016-11-14

In this chapter:

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.

Office SharePoint Server authentication

To determine the most appropriate Office SharePoint Server 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.

  • You might need to implement an impersonation/delegation model that can pass a user's operating system–level security context across tiers. This enables the operating system to impersonate the user and delegate the user's security context to the next downstream subsystem.

Microsoft Office SharePoint Server is a distributed application that is logically divided into three tiers: the front-end Web server tier, the application server tier, and the back-end database tier. Each tier is a trusted subsystem and authentication can be required for access to each tier. Credential validation requires an authentication provider. Authentication providers are software components that support specific authentication mechanisms. Office SharePoint Server 2007 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. Office SharePoint Server 2007 includes an LDAP v3 membership provider, and ASP.NET 2.0 includes a SQL Server membership provider.

You can also deploy multiple authentication providers to enable, for example, intranet access by using Windows authentication and external access by using forms authentication. Using multiple authentication providers requires the use of multiple Web applications. Each Web application must have a designated zone and a single authentication 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 (https://go.microsoft.com/fwlink/?LinkId=87014&clcid=0x409).

Windows authentication provider

The Windows authentication provider supports the following authentication methods:

  • Anonymous authentication

    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

    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

    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 (https://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

    Integrated Windows authentication can be implemented using either NTLM or constrained Kerberos delegation. Constrained Kerberos delegation is the most secure authentication method. Integrated Windows authentication works well in an intranet environment where users have Windows domain accounts. In Integrated Windows authentication, the browser attempts to use the current user's credentials from a domain logon, and if the attempt is unsuccessful, the user is prompted to enter a user name and password. If you use Integrated Windows authentication, the user's password is not transmitted to the server. If the user has logged on to the local computer as a domain user, the user does not have to authenticate again when the user accesses a network computer in that domain.

  • Kerberos authentication

    This method is for servers that are running Active Directory on Microsoft Windows 2000 Server and more recent versions of Windows. Kerberos is a secure protocol that supports ticketing authentication. A Kerberos authentication server grants a ticket in response to a client computer authentication request that contains valid user credentials. The client computer then uses the ticket to access network resources. To enable Kerberos authentication, the client and server computers must have a trusted connection to the domain Key Distribution Center (KDC). The client and server computers must also be able to access Active Directory. For more information about configuring a virtual server to use Kerberos authentication, see Microsoft Knowledge Base article 832769: How to configure a Windows SharePoint Services virtual server to use Kerberos authentication and how to switch from Kerberos authentication back to NTLM authentication (https://go.microsoft.com/fwlink/?LinkId=115572&clcid=0x409).

  • Constrained Kerberos delegation

    Constrained authentication is the most secure configuration for communication between multiple application tiers. You can use constrained delegation to pass the original caller's identity through multiple application tiers: for example, from a Web server to an application server to a database server. Constrained Kerberos delegation is also the most secure configuration for accessing back-end data sources from application servers. Impersonation enables a thread to run in a security context other than the context of the process that owns the thread. In most server farm deployments in which front-end Web servers and application servers run on different computers, impersonation will require constrained Kerberos delegation.

  • Impersonation and Kerberos delegation

    Kerberos delegation enables an authenticated entity to impersonate the credentials of a user or computer within the same forest. When impersonation is enabled, the impersonating entity is allowed to use credentials for performing tasks on behalf of the impersonated user or computer.

    During impersonation, ASP.NET applications can run by using the credentials of another authenticated entity. By default, ASP.NET impersonation is disabled. If impersonation is enabled for an ASP.NET application, then that application runs using the credentials of the access token IIS passes to ASP.NET. That token can be either an authenticated user token, such as a token for a logged-in Windows user, or the token that IIS provides for anonymous users (typically, the IUSR_computername identity).

    When impersonation is enabled, only your application code runs under the context of the impersonated user. Applications are compiled and configuration information is loaded by using the identity of the ASP.NET process.

    For more information about impersonation, see ASP.NET Impersonation (https://go.microsoft.com/fwlink/?LinkId=115573&clcid=0x409).

  • NTLM authentication

    This method is for Windows servers that are not running Active Directory on a domain controller. NTLM authentication is required for networks that receive authentication requests from client computers that do not support Kerberos authentication. 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 authentication is required in networks where the server receives requests from client computers that do not support Kerberos authentication. 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. When Windows 2000 Server is converted to native mode where no down-level Windows NT domain controllers exist, NTLM is disabled. Kerberos then becomes the default authentication protocol for the enterprise.

Forms authentication provider

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 single sign-on (SSO) authentication provider

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 (Office SharePoint Server). For information about how to perform this procedure using the Stsadm command-line tool, see Authentication: Stsadm operation (Office SharePoint Server).

Download this book

This topic is included in the following downloadable book for easier reading and printing:

See the full list of available books at Office SharePoint Server technical library.