Plan authentication settings for Web applications (Search Server 2008)
Updated: April 16, 2009
Applies To: Microsoft Search Server 2008
Topic Last Modified: 2009-05-26
Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.
In this article:
This article discusses the authentication configuration settings that need to be planned for individual Web applications in Search Server 2008. Use this article with the Web application authentication settings worksheet (http://go.microsoft.com/fwlink/?LinkID=73334&clcid=0x409). Complete a separate worksheet for each of the following elements that are a part of your solution design in Search Server 2008:
New or extended Web applications in Search Server 2008.
Additional zones within a Web application (other than the default zone). Include zones that are created for the search account.
This section discusses each of the settings on the Edit Authentication page of the 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 Search Server 2008. 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.
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|
| || |
Microsoft Windows Server 2003 administrator, to obtain and configure certificates
Kerberos (Integrated Windows)
| || |
Record the additional configuration necessary in the Additional Configuration section of the Web application authentication settings worksheet (http://go.microsoft.com/fwlink/?LinkID=73334&clcid=0x409).
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.
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 forms authentication or Web Single Sign-On (SSO) authentication, client integration is set to No by default.
If you have installed Microsoft Office SharePoint Server 2007 with Service Pack 2 (SP2), client integration is supported except for Outlook Integration. All other client integration is supported including SharePoint Designer authoring.
If you have not installed Search Server 2008 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 Search Server 2008 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. You might be able to use many client integration features with forms-based authentication, and there are workarounds available to implement varying levels of client integration functionality with forms-based authentication. However, if published workarounds are inadequate, or if you find unexpected issues using workarounds, we do not provide support and there are no product changes to address these issues. If you plan to use client integration with forms-based authentication, you must fully test any available solutions or workarounds to determine if the performance and functionality are acceptable in your environment.|
Product Support can provide commercially reasonable support to help you troubleshoot published workarounds.
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|
Work in Microsoft Office Outlook
Open in Windows Explorer
Export to spreadsheet
Open with Database Program
Edit in Microsoft Office applications such as Word and Excel.
Create an Access view
Send to Microsoft Office PowerPoint
Connect to Office Outlook
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.
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 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:
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.
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.
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 (http://go.microsoft.com/fwlink/?LinkId=78098&clcid=0x409).
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.
On the Web application authentication settings worksheet (http://go.microsoft.com/fwlink/?LinkID=73334&clcid=0x409), in the Enable Client Integration section, select Yes or No.
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 (Search Server 2008) to review examples of properly configured strings for several common scenarios.
On the Web application authentication settings worksheet (http://go.microsoft.com/fwlink/?LinkID=73334&clcid=0x409), enter the following two types of information:
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:
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 (Search Server 2008).
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 Search Server 2008 are not managed by Search Server 2008 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.
On the Web application authentication settings worksheet (http://go.microsoft.com/fwlink/?LinkID=73334&clcid=0x409), indicate whether excluded virtual directories will be added in IIS beneath the Web site that corresponds to this Web application in Search Server 2008. 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 Search Server 2008.
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).
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>