Plan authentication settings for Web applications (Windows SharePoint Services)

Article
05/20/2016

Applies To: Windows SharePoint Services 3.0

Topic Last Modified: 2016-05-08

In this article:

Plan authentication settings
Plan authentication exclusions
Worksheet

This article discusses the authentication configuration settings that need to be planned for individual Web applications in Windows SharePoint Services 3.0. Use this article with the Web application authentication settings worksheet (https://go.microsoft.com/fwlink/?LinkID=798133&clcid=0x409.) Complete a separate worksheet for each of the following elements that are a part of your solution design in Windows SharePoint Services 3.0:

New or extended Web applications in Windows SharePoint Services 3.0.
Additional zones within a Web application (other than the default zone). Include zones that are created for the search account.

Use completed worksheets with Deploy and configure SharePoint sites (Windows SharePoint Services).

Plan authentication settings

This section discusses each of the settings on the Edit Authentication page of the SharePoint Central Administration Web site. To get to this page, on the Application Management page, in the Application Security section, click Authentication providers. Click the zone that you want to modify authentication settings for. The Edit Authentication page opens.

Depending on the authentication options you choose, you might be able to specify your authentication settings directly when you create or extend the Web application in Windows SharePoint Services 3.0. However, not all options are available when you initially create or extend a Web application. If you cannot configure authentication when you create or extend the Web application, you can accept the default authentication settings initially and then edit the settings on the Edit Authentication page.

Authentication type

Select the method that you want to use. If you are planning to allow anonymous access instead of implementing an authentication method listed in this section, select Windows authentication.

If you select Windows, specify the Windows authentication method in the IIS Authentication Settings section of the Edit Authentication page. If you select Forms or Web single sign on, the options on the Edit Authentication page change to allow you to enter the membership provider name and the role manager name.

If you want to use Certificate authentication or Kerberos authentication, review the following table to identify the additional configuration steps required to configure these methods.

Authentication method	Additional configuration	Specialized roles
Certificates	Select Windows authentication in Central Administration. Configure Internet Information Services (IIS) for certificates. Enable Secure Sockets Layer (SSL). Obtain and configure certificates from a certification authority (CA).	Microsoft Windows Server 2003 administrator, to obtain and configure certificates
Kerberos (Integrated Windows)	Select Kerberos authentication in Central Administration. Configure a Service Principal Name (SPN) for the domain user account that is used for the application pool identity (application pool process account). Register the SPN for the domain user account in Active Directory.	IIS administrator

Worksheet action
Record the additional configuration necessary in the Additional Configuration section of the Web application authentication settings worksheet (https://go.microsoft.com/fwlink/?LinkID=798133&clcid=0x409).

Anonymous access

Indicate whether anonymous access is allowed. If you selected Forms or Web single sign-on in the Authentication Type section, select the Enable anonymous access check box.

Client integration

You can disable client integration, which removes features that start client applications. This is the optimal configuration for some scenarios, such as publishing read-only content to the Web for anonymous access. Additionally, if you select ASP.NET forms authentication or Web Single Sign-On (SSO) authentication, client integration is set to No by default.

If you have installed Windows SharePoint Services 3.0 with Service Pack 2 (SP2), client integration is supported, except for Outlook integration. All other client integration is supported, including SharePoint Designer authoring.

Note

If you have not installed Windows SharePoint Services 3.0 with SP2, client integration is disabled by default when you use forms-based authentication. This is because client integration does not natively support forms-based authentication prior to Windows SharePoint Services 3.0 with SP2.

Expected behaviors when client integration is disabled

When client integration is disabled, sites behave in the following ways:

Links that start client applications are not visible.
Documents are opened in the browser. Documents cannot be opened by client applications.
Users cannot edit documents on the site directly from the client applications. However, users can download the document, edit the document locally, and then upload the document.

The following table lists specific menu commands and features that are not available when client integration is disabled.

Category	Command or feature that is unavailable
Toolbars	New document Work in Microsoft Office Outlook Open in Windows Explorer Export to spreadsheet Open with Database Program
Editing documents	Edit in Microsoft Office applications such as Word and Excel.
Views	Explorer view Create an Access view
Picture libraries	Upload multiple Edit picture Download Send to
Slide libraries	Publish slide Send to Microsoft Office PowerPoint
Other	Discuss Connect to Office Outlook

Behaviors of specific authentication methods

In addition to the deployment scenario (such as publishing read-only content), the choice of authentication method might determine how to configure client integration. Some authentication methods behave differently with client applications. In some cases, the behavior depends on whether client browsers are configured to use persistent cookies or session cookies.

The following table summarizes the potential behaviors of client integration when used with specific authentication methods.

Authentication method Behavior

Authentication method	Behavior
Basic	Users are prompted to enter their credentials each time they access a document. Other features might also require that they enter their credentials again.
ASP.NET forms and Web SSO	If the following conditions are true, a persistent cookie is created: The authentication provider supports persistent cookies. The user clicks Sign me in automatically when they log in. The persistent cookie is shared by all applications that use the same cookie store and the user can open documents in the client applications. The persistent cookie is created with a default time-out value of 30 minutes. This value can be changed by adding or updating the time-out parameter in the forms node in the Web.config file. For example: `<forms loginUrl="login.aspx" name=".ASPXFORMSAUTH" timeout="100" />` When the cookie expires, client integration stops working. If users are in a browser, they will be prompted to re-enter credentials. If the authentication provider does not support persistent cookies or the user did not click Sign me in automatically when they logged in, a session cookie is used. A session cookie is only accessible by the browser. The user will not be able to open document directly in the client applications. If the authentication provider does not provide support for persistent cookies or if persistent cookies are not allowed in your environment, turn off client integration. For example, Active Directory Federation Services (AD FS) does not provide support for persistent cookies.
Anonymous	When opening a document, users are repeatedly prompted for their credentials. If they click Cancel in the authentication dialog box 10 times, the site might open the document by using the client application. Because of this poor experience, it is recommended that client integration be turned off for anonymous access scenarios.

Basic

Users are prompted to enter their credentials each time they access a document. Other features might also require that they enter their credentials again.

ASP.NET forms and Web SSO

If the following conditions are true, a persistent cookie is created:

The authentication provider supports persistent cookies.
The user clicks Sign me in automatically when they log in.

The persistent cookie is shared by all applications that use the same cookie store and the user can open documents in the client applications. The persistent cookie is created with a default time-out value of 30 minutes. This value can be changed by adding or updating the time-out parameter in the forms node in the Web.config file. For example:

<forms loginUrl="login.aspx" name=".ASPXFORMSAUTH" timeout="100" />

When the cookie expires, client integration stops working. If users are in a browser, they will be prompted to re-enter credentials.

If the authentication provider does not support persistent cookies or the user did not click Sign me in automatically when they logged in, a session cookie is used. A session cookie is only accessible by the browser. The user will not be able to open document directly in the client applications.

If the authentication provider does not provide support for persistent cookies or if persistent cookies are not allowed in your environment, turn off client integration. For example, Active Directory Federation Services (AD FS) does not provide support for persistent cookies.

Anonymous

When opening a document, users are repeatedly prompted for their credentials. If they click Cancel in the authentication dialog box 10 times, the site might open the document by using the client application. Because of this poor experience, it is recommended that client integration be turned off for anonymous access scenarios.

Using the Windows Vista operating system with Internet Explorer 7

In Windows Vista, Internet Explorer 7 includes an additional security feature called protected mode. By default, protected mode is enabled for the Internet, Intranet, and Restricted Sites zones. Because this feature places persistent cookies in a location that prevents sharing across applications, client integration does not work as intended.

To configure Internet Explorer 7 to work with client integration, do one of the following:

Disable protected mode.
If protected mode is enabled, add SharePoint sites to the Trusted sites zone in Internet Explorer.

For information about disabling protected mode, see "Configuring Protected Mode" in Understanding and Working in Protected Mode Internet Explorer (https://go.microsoft.com/fwlink/?LinkId=78098&clcid=0x409).

Testing client integrations settings

If you are uncertain about how to configure the client integration setting, test the results in a test environment before deploying sites into production. If this setting is changed after it is applied, sites and client applications might behave unusually.

Worksheet action
On the Web application authentication settings worksheet (https://go.microsoft.com/fwlink/?LinkID=798133&clcid=0x409), in the Enable Client Integration section, select Yes or No.

Settings for ASP.NET forms authentication and Web SSO

If you are implementing ASP.NET forms authentication or Web SSO, you must develop the configuration settings to insert into the applicable Web.config files. See Authentication samples (Windows SharePoint Services) to review examples of properly configured strings for several common scenarios.

Worksheet action
On the Web application authentication settings worksheet (https://go.microsoft.com/fwlink/?LinkID=798133&clcid=0x409), enter the following two types of information: Name The name of the membership provider, role manager, and HTTP module (if applicable). These names appear in the Central Administration site. Web.config configuration Paste the appropriate configuration strings into the worksheet. These strings can be copied from the worksheet into the Web.config files when the Web application is deployed.

On the Web application authentication settings worksheet (https://go.microsoft.com/fwlink/?LinkID=798133&clcid=0x409), enter the following two types of information:

Name The name of the membership provider, role manager, and HTTP module (if applicable). These names appear in the Central Administration site.
Web.config configuration Paste the appropriate configuration strings into the worksheet. These strings can be copied from the worksheet into the Web.config files when the Web application is deployed.

Ensure that the MembershipProvider name and RoleManager name you registered in the Web.config file is the same as the name that you entered in the Central Administration authentication.aspx page. If you do not enter the role manager in the Web.config file, the default provider specified in the machine.config file might be used instead.

For example, the following string in a Web.config file specifies a SQL membership provider:

<membership defaultProvider="AspNetSqlMembershipProvider">

For more information about requirements for membership providers and role managers, see "Connect to identity management systems that are not based on Windows or that are external" in Plan authentication methods (Windows SharePoint Services).

Plan authentication exclusions

If you are implementing ASP.NET forms authentication or Web SSO, you need to plan for authentication exclusions. If you are implementing Windows authentication, you do not need to read this section.

When you create or extend a Web application or when you add a zone to a Web application, IIS creates a new Web site. Authentication settings that are registered in the Web.config file for this Web application are inherited by virtual directories below the Web site. Virtual directories that are added below a Web application in Windows SharePoint Services 3.0 are not managed by Windows SharePoint Services 3.0 and are considered to be excluded virtual directories.

If you are implementing ASP.NET forms authentication or Web SSO and you plan to add virtual directories below these Web sites, you need to decide whether you want these excluded virtual directories to inherit the ASP.NET forms authentication or Web SSO settings.

Worksheet action
On the Web application authentication settings worksheet (https://go.microsoft.com/fwlink/?LinkID=798133&clcid=0x409), indicate whether excluded virtual directories will be added in IIS beneath the Web site that corresponds to this Web application in Windows SharePoint Services 3.0. If excluded virtual directories will be added, indicate whether authentication settings should be inherited.

Use the following procedure to configure IIS so authentication settings are not inherited.

Configure IIS so authentication settings are not inherited

Add a new IIS virtual directory beneath the IIS Web site that corresponds to the applicable Web application or zone in Windows SharePoint Services 3.0.
In IIS Manager, right-click the new virtual directory, and then click Properties.
Click the Virtual Directory tab.
Click Create (this makes the virtual directory an application).
Click Configuration.
Select the wildcard application maps, and then click Remove.
Click Yes, and then click OK.

Create a new Web.config file at the root of the new virtual directory file system path, and add the following entries:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<configuration>
 <system.web>
  <httpModules>
   <clear />
  </httpModules>
  <httpHandlers>
   <clear />
  </httpHandlers>
 </system.web>
</configuration>

Worksheet

Use the following worksheet to plan and record configuration settings for each of your Web applications in Windows SharePoint Services 3.0.

Web application authentication settings worksheet (https://go.microsoft.com/fwlink/?LinkID=798133&clcid=0x409)

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 Downloadable books for Windows SharePoint Services.

Share via