Share via

Plan authentication methods (Search Server 2008)

  • Article

Applies To: Microsoft Search Server 2008

 

Topic Last Modified: 2009-04-03

The information in this section does not apply to Microsoft Search Server 2008 Express. It applies to the full version of Microsoft Search Server 2008 only.

This article describes the authentication methods that are supported by Search Server 2008. After reading this article, you will be able to:

  • Understand how authentication is implemented in Search Server 2008.

  • Identify the authentication methods that are appropriate for your environment.

In this article:

  • About authentication

  • Supported authentication methods

  • Configure authentication

  • Plan authentication for crawling content

  • Planning zones for your authentication design

  • Choose methods of authentication allowed in your environment

  • Worksheet

About authentication

Authentication is the process of validating a user's identity. In Search Server 2008, Internet Information Services (IIS) performs the authentication of users. After a user's identity is validated, Search Server 2008 performs the authorization process to determine which sites, content, and other features the user can access. Part of this process begins when the content items are crawled. As the crawler opens each content item to extract the content, it also retrieves content item metadata including the access control list (ACL) for each content item. After the content from each content item is parsed and processed, it is then added to the full-text index, also called the content index. The metadata and ACL information is added to a separate index called the search database.

When a user submits a query, the Web server obtains both the search results from the content index and each content item’s metadata, including ACLs, from the search database. The Web server compares the credentials of the user who submitted the query to the ACLs of the content items included in the search results. Any content items that the user does not have permission to access are not included in the search results. This process is known as security trimming.

Supported authentication methods

Search Server 2008 provides a flexible and extensible authentication system, which supports authentication for identity management systems that are based or are not based on the Windows operating system. By integrating with ASP.NET pluggable authentication, Search Server 2008 supports various forms-based authentication schemes. Authentication support in Search Server 2008 enables various authentication scenarios. They include the following:

  • Using standard Windows authentication methods.

  • Using a simple database of user names and passwords.

  • Connecting directly to an organization's identity management system.

  • Using two or more methods of authentication for accessing partner applications (for example, connecting to your partner company's identity management system for authenticating partner employees while you are using Windows authentication methods to authenticate your internal employees).

  • Participating in federated identity management systems.

The following table lists the supported authentication methods:

Authentication method Description Examples

Windows

The standard IIS Windows authentication methods are supported.

  • Anonymous

  • Basic

  • Digest

  • Certificates

  • Kerberos (Integrated Windows)

  • NTLM (Integrated Windows)

ASP.NET forms

Search Server 2008 adds support for identity management systems that are not based on Windows by integrating with the ASP.NET forms authentication system. ASP.NET authentication enables Search Server 2008 to work with identity management systems that implement the MembershipProvider interface. You do not have to rewrite the security administration pages or manage shadow Active Directory directory service accounts.

  • Lightweight Directory Access Protocol (LDAP)

  • SQL database or other database

  • Other ASP.NET-based forms authentication solutions

Web Single Sign-On (SSO)

Search Server 2008 supports federated authentication through Web SSO vendors. Web SSO enables SSO in environments that include services that are running on different platforms. You do not have to manage separate Active Directory accounts.

  • Active Directory Federation Services (AD FS)

  • Other identity management systems

Authentication of system accounts

ASP.NET forms authentication and Web SSO can be used to authenticate only user accounts. The process accounts that are used to connect to Microsoft SQL Server database software and run the scale-out deployment must be Windows accounts, even when you use alternative methods of authentication to authenticate users.

Search Server 2008 supports SQL Server authentication and local computer process accounts for farms that are not running Active Directory. For example, you can implement local accounts by using identical user names and passwords across all servers in a farm.

Configure authentication

Although configuring Windows authentication is straightforward, configuring authentication to use ASP.NET forms or Web SSO requires more planning. This section provides a summary of how authentication is configured in Search Server 2008. This information will help you understand how to design an authentication strategy for your solution and determine who in your organization has to be involved in planning for authentication.

Connect to identity management systems that are external or not based on Windows

To use ASP.NET forms or Web SSO to authenticate users against an identity management system that is not based on Windows or that is external, you must register the membership provider in the Web.config file. In addition to registering a membership provider, you can register a role manager also. Search Server 2008 uses the standard ASP.NET role manager interface to gather group information about the current user. Each ASP.NET role is treated like a domain group by the authorization process in Search Server 2008. You register role managers in the Web.config file the same way that you register membership providers for authentication.

If you want to manage membership user or roles from the Central Administration site, you can optionally register the membership provider and the role manager in the Web.config file for the Central Administration site (in addition to registering these in the Web.config file for the Web application that hosts the content).

Ensure that the membership provider name and role manager name that 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 additional information about how to use ASP.NET forms authentication to connect to a SQL Server authentication provider, see Authentication samples (Search Server 2008).

Finally, if you are using Web SSO to connect to an external identity management system, you must also register an HTTP module for the Web SSO. An HTTP module is an assembly that is called on every request made to your application. HTTP modules are called as part of the ASP.NET request pipeline. For more information, see Introduction to HTTP Modules (https://go.microsoft.com/fwlink/?LinkId=77954&clcid=0x409).

Integrating with ASP.NET forms authentication puts additional requirements on the authentication provider. In addition to registering the various elements in the Web.config file, the membership provider, role manager, and HTTP module must be programmed to interact with Search Server 2008 and ASP.NET methods, as indicated in the following table:

Category Description

Membership provider

To work with Search Server 2008, the membership provider must implement the following methods:

  • GetUser (String)   Search Server 2008 calls this method to resolve user names during invitations and to get the user's display name.

  • GetUserNameByEmail   Search Server 2008 calls this method to resolve user names in invitations.

  • FindUsersByName, FindUsersByEmail   Search Server 2008 calls these methods to populate the user picker control on the Add Users page. If the membership provider returns no users, the picker will not function and administrators will have to type the user name or e-mail address in the Add User text box.

Role manager

The role manager must implement the following methods:

  • RoleExists   Search Server 2008 calls this method during invitations to verify that a role name exists.

  • GetRolesForUser   Search Server 2008 calls this method at access check to gather the roles for the current user.

  • GetAllRoles   Search Server 2008 calls this method to populate the group and role picker. If the role provider returns no groups or roles, the Search Server 2008 picker will not function and the administrator will have to type the name of the role in the Add User text box.

HTTP module

The HTTP module must handle the following events:

  • AuthenticateRequest   This event is called when ASP.NET is ready to authenticate the user. The Web SSO module must unpack the user's authentication cookie and set the HttpContext.User object with the identity of the current user.

  • EndRequest   This is the last event in the ASP.NET pipeline. This event is called just before it returns the code to the client. The Web SSO module must capture 401 responses coming from Search Server 2008 and turn these into an appropriate 302 redirect for authentication to the Web SSO logon server.

Enabling Anonymous Access

You can enable anonymous access for a Web application in addition to configuring a more secure authentication method. By using this configuration, administrators of sites within the Web application can choose to allow anonymous access. If anonymous users want to gain access to secured resources and capabilities, they can click a logon button to submit their credentials.

Plan authentication for crawling content

To perform successful crawls of content in a Web application, you must understand the authentication requirements of the index component of the index server (also known as the crawler). This section describes how to configure authentication for Web applications to ensure that content in the Web applications can be successfully crawled.

When a farm administrator creates a Web application by using all default settings, the default zone for that Web application is configured to use NTLM. The farm administrator can change the authentication method for the default zone to any authentication method supported by Search Server 2008.

The farm administrator can also extend a Web application one or more times to enable additional zones. Up to five zones can be associated with a particular Web application, and each zone can be configured to use any authentication method supported by Search Server 2008.

By default, the crawler uses NTLM when crawling content. A search service administrator can also create a crawl rule to configure the crawler to use a different authentication method, such as basic authentication or a client certificate, instead of NTLM, when crawling a particular range of URLs. For more information about crawl rules, see Plan to crawl content (Search Server 2008).

Order in which the crawler accesses zones

When planning the zones for a Web application, consider the polling order in which the crawler accesses zones when it is trying to authenticate. The polling order is important, because if the crawler encounters a zone configured to use digest authentication or Kerberos authentication that does not use a standard port (80 or 443), authentication fails and the crawler does not attempt to access the next zone in the polling order. If this occurs, the crawler will not crawl content on that Web application.

Tip

Ensure that the authentication method configured for the crawler is earlier in the polling order than a zone configured for Kerberos that uses a non-standard port or digest authentication.

The crawler polls the zones in the following order:

  • Default zone

  • Intranet zone

  • Internet zone

  • Custom zone

  • Extranet zone

The following figure shows the decisions that are made by the authentication system when the crawler attempts to authenticate:

How the crawler polls zones

Polling order used by the crawler

The following table describes the actions associated with each callout in the figure.

Callout Action

1

Crawler attempts to authenticate by using the default zone.

Note

The crawler always attempts to use the default zone first when it is trying to authenticate.

2

If the authentication methods configured for the crawler and the zone are the same, the crawler is authenticated and continues to the authorization phase. Otherwise, proceed to step 3.

3

If the zone is configured for Kerberos authentication, proceed to step 4. Otherwise, proceed to step 5.

4

If the zone is configured to use either port 80 or port 443, the crawler is authenticated and continues to the authorization phase. Otherwise, authentication fails and the crawler does not attempt to authenticate by using another zone. This means the content is not crawled.

5

If there are no more zones in the polling order, authentication fails and the content is not crawled. Otherwise, proceed to step 6.

6

Crawler attempts to authenticate by using the next zone in the polling order. Return to step 2.

If you configure the default zone to use an authentication method that the crawler does not support — for example, Web SSO — you must create at least one additional zone and configure this zone to use certificates, basic authentication, Kerberos protocol using a standard port, or NTLM. If certificates or basic authentication is used to crawl the Web application, the search service administrator must create a crawl rule to configure the crawler to use the appropriate authentication method when crawling that Web application. Consider the following scenario.

Authentication scenario

The farm administrator creates a Web application and configures it to use forms authentication. Because the farm administrator wants the content in the Web application to be crawled and indexed, and because she knows that the crawler requires a zone configured with NTLM, basic authentication, or certificates, the farm administrator extends the Web application and configures the intranet zone to use NTLM.

When the crawler attempts to authenticate by using the default zone, the authentication system discovers that the crawler and the zone are not configured to use the same authentication method. Because the zone is not configured for Kerberos authentication using a non-standard port or digest authentication and there is at least one additional zone in the polling order, the crawler attempts to authenticate by using the intranet zone. Because the intranet zone is configured to use NTLM and the crawler also uses NTLM, then by default authentication succeeds.

Note that, if the farm administrator had configured the intranet zone for basic authentication instead of NTLM, the search service administrator would have to create a crawl rule to configure the crawler to use basic authentication when crawling that particular Web application. Otherwise, authentication would fail and the content would not be crawled. Likewise, if the farm administrator had configured the intranet zone to use a client certificate, the search service administrator would have to create a crawl rule to configure the crawler to use a client certificate when crawling that particular Web application. Additionally, a server administrator must register the client certificate with the index server; otherwise, authentication would fail and the content would not be crawled.

Tip

Effective planning of authentication for Web applications, and planning to crawl the content that is contained by those Web applications, requires collaboration between farm administrators who create the Web applications and search service administrators who configure the crawler.

Remember that, if you configure a zone to use either basic authentication or certificates and you want the crawler to authenticate by using that zone, the search service administrator must create a crawl rule to configure the crawler to use the same authentication method as the zone that you intend it to authenticate with. Otherwise, the crawler attempts to use the next available zone.

In addition to appropriately configuring the authentication method, you must ensure that the crawler is authorized to crawl content within the Web application. The search service administrator must ensure that the content access account has the Read permission level to content accessed through this zone. Farm administrators can do this by creating a policy that gives the content access account the Read permission level on a particular Web application.

Planning zones for your authentication design

If you plan to implement more than one authentication method for a Web application by using zones, use the following guidelines:

  • Use the default zone to implement your most secure authentication settings. If a request cannot be associated with a specific zone, the authentication settings and other security policies of the default zone are applied. The default zone is the zone that is created when you create a Web application. Typically, the most secure authentication settings are designed for end-user access. Consequently, the default zone will likely be the zone that is accessed by end-users.

  • Use the minimum number of zones that is required by the application. Each zone is associated with a new IIS site and domain for accessing the Web application. Only add new access points when these are required.

  • If you want content within the Web application to be included in search results, ensure that at least one zone is configured to use NTLM, basic, or forms-based authentication. One of these authentication methods is required by the index component to crawl content. Do not create a dedicated zone for the index component unless it is necessary.

Choose methods of authentication allowed in your environment

In addition to understanding how authentication is configured, planning for authentication includes the following:

  • Considering the security context or environment of your Web application in Search Server 2008.

  • Evaluating the recommendations and tradeoffs for each method.

  • Understanding how user credentials and related identity data are cached and consumed by Search Server 2008.

  • Understanding how user accounts are managed.

  • Ensuring that authentication methods are compatible with browsers that are used by users.

Worksheet action

Use the Authentication methods worksheet (https://go.microsoft.com/fwlink/?LinkId=77970&clcid=0x409) to identify which authentication methods you are willing to support in your environment and to record your decisions and recommendations for each. This worksheet will be used when planning authentication methods for individual Web applications in Search Server 2008.

Recommendations for specific security environments

Your choice of authentication methods will be primarily driven by the security context of your application. The following table provides recommendations based on the most common security environments:

Environment Considerations

Internal intranet

At a minimum, protect user credentials from plain view. Integrate with the user management system that is implemented in your environment. If Active Directory is implemented, use the Windows authentication methods built into IIS.

External secure collaboration

Configure a separate zone for each partner company that connects to the site. Use Web SSO to authenticate against each partner’s own identity management system. This eliminates the requirement to create accounts in your own identity management system and also ensures that contributor identities continue to be maintained and validated by partner employers. If a contributor is no longer employed by a partner company, the contributor cannot continue to gain access to your partner application.

External anonymous

Enable anonymous access (no authentication) and allow Read-Only permissions for users who connect from the Internet. If you want to provide targeted or role-based content, you can use ASP.NET forms authentication to register users by using a simple database of user names and roles. Use the registration process to identify users by role (such as doctor, patient, or pharmacist). When users log on, your site can present content that is specific to the user role. In this scenario, authentication is not used to validate credentials or to limit who can access the content. The authentication process merely provides a method of targeting content.

Recommendations and tradeoffs for authentication methods

Understanding the advantages, recommendations, and tradeoffs for each specific authentication method can help you determine which methods to use in your environment. The following table highlights the recommendations and tradeoffs for each authentication method. For more information about each of the Windows authentication methods supported by IIS, see IIS Authentication (https://go.microsoft.com/fwlink/?LinkId=78066&clcid=0x409).

Authentication method Advantages and recommendations Tradeoffs

Windows

  • Authenticate by using existing Active Directory accounts.

  • Simplify user management.

  • Take advantage of Active Directory groups when you configure Search Server 2008 authorization.

  • Avoid writing custom code.

  • Each of the methods has its own associated pros and cons.

  • Some IIS authentication protocols are not supported by all Web browsers.

ASP.NET forms

  • Set up Search Server 2008 in an environment that does not use Active Directory (does not require Windows accounts).

  • Authenticate against two or more different identity management systems when you are creating partner applications.

  • Implement a custom authentication scheme by using arbitrary criteria.

  • Authenticate users coming from the Internet.

  • Requires customization of the Web.config file.

  • Subject to replay attacks for the lifetime of the cookie, unless using SSL Transport Layer Security (TLS).

Web SSO

  • Implement Search Server 2008 in an environment that uses federated authentication to secure digital identities across organizations and security environments.

  • Implement Search Server 2008 in an environment that provides SSO to services that are running on different platforms, including environments that do not use Active Directory.

  • Take advantage of AD FS.

  • Authenticate against two or more different identity management systems when you create partner applications.

  • Requires an existing federated authentication system.

  • Requires customization of the Web.config file.

  • AD FS requires SSL. Other SSO systems might have other requirements.

Management of user identity information

How user credentials and other identity information is processed and used by Search Server 2008 can influence your decision about which of the authentication options is best for your intended purpose. This section details how user identity information is processed in the following categories:

  • Binary IDs   How user binary identifiers (IDs) are created or used by Search Server 2008.

  • Caching   The process of retaining a user's identity for a while to avoid repeating the authentication process for each request.

  • Role and group membership   In addition to determining who users are, the authentication process also determines which groups or roles a user belongs to. This information is used during the authorization process to determine which actions a user has permissions to perform. For the purpose of authorization, Search Server 2008 treats Active Directory groups and ASP.NET roles as the same kind of entity.

The following table details how Search Server 2008 manages user binary IDs, cached user data, and role and group membership data depending on which authentication method is used:

Item Windows authentication ASP.NET forms and Web SSO

Binary IDs

Search Server 2008 uses the Windows security identifier (SID).

Search Server 2008 creates a unique binary ID by combining the provider name with the user name.

Caching

User credentials are cached and managed by IIS, Internet Explorer, and Windows.

ASP.NET uses an encrypted cookie to keep the user's credentials during a session.

Role and group membership

Windows maintains the list of Active Directory domain groups the user belongs to in the access token. Search Server 2008 uses information that is stored in the access token.

When a role manager is registered, Windows SharePoint Services uses the standard role manager interface to gather group information about the current user. Each ASP.NET role is treated like a domain group by the authorization process. ASP.NET can cache the roles the user belongs to in a cookie, depending on the settings that are configured in the Web.config file.

Management of user accounts

Understanding how Search Server 2008 handles typical user account management tasks can also influence which authentication method you choose. Generally, users who are members of an authentication provider in one zone can manage accounts across all zones as long as they are granted permissions. The information in the following list applies regardless of which authentication method is implemented:

  • Adding and inviting new users   You can add or invite a new user from any zone and all authentication methods that are configured if the membership provider and role manager are registered in the current Web.config file. When you add a new user, Search Server 2008 resolves the user name against the following sources in the following order:

    • The UserInfoList table that is stored by Search Server 2008. User information will be in this list if users have already been added to another site.

    • The authentication provider that is configured for the current zone. For example, if a user is a member of the authentication provider that is configured for the default zone, Search Server 2008 first checks this associated membership provider.

    • All other authentication providers.

  • Deleting users   User accounts are marked as deleted in the Search Server 2008 database. However, the user record is not removed.

Some user account management behavior within Search Server 2008 differ, depending on the authentication provider. The following table highlights several common user account tasks that differ depending on the authentication method that is implemented:

Task Windows authenticated accounts ASP.NET forms–authenticated and Web SSO-authenticated accounts

Adding and inviting new users

Search Server 2008 validates user identities by using Active Directory.

Search Server 2008 calls the membership provider and the role manager to verify that the user and roles exists.

Changes to logon names

Updated user names are automatically recognized by Search Server 2008. New entries are not added to the UserInfoList table.

You must delete the old user name and then add the new user name. Permissions cannot be migrated.

Logging on

If Integrated Windows authentication (Kerberos protocol or NTLM) is used and the browser is configured to automatically log on, users do not have to manually log on to SharePoint sites. By default, Internet Explorer is configured to automatically log on to intranet sites. If a logon is required (for example, sites that require a different set of credentials), users are prompted only for a user name and password. However, if basic authentication is used, or the user is using a browser that is not configured to automatically log on, users might be prompted for logon credentials when they access a SharePoint site.

Search Server 2008 provides a standard logon page for use with forms authentication. This page includes the following fields: user name, password, sign in automatically (to persist the cookie). You can create your own logon page to add logon controls (for example, create a new account, or reset password).

Browser support

Not all browsers work with each authentication method that is supported. Before selecting authentication methods to allow in your environment, determine which browsers you have to support. Then, determine which authentication methods are supported by the browsers. Internet Explorer works with each supported authentication method. Additional browsers that are supported by Search Server 2008 include the following:

  • Netscape 8.0

  • Netscape 7.2

  • Mozilla 1.7.12

  • Firefox 1.5

  • Safari 2.02

Worksheet

Use the following worksheet to record which authentication methods are appropriate for your environment:

The following table represents an example of a completed worksheet:

Authentication method Allow Don't allow Notes and recommendations

Anonymous

x

Basic

x

Digest

x

Certificates

x

NTLM (Integrated Windows)

x

"Use NTLM for all department sites except finance."

Kerberos (Integrated Windows)

x

"Use Kerberos authentication for sites with a high security service level agreement."

ASP.NET forms

x

"Use forms authentication to allow partner company access to sites hosted in the partner extranet. We currently allow authentication against the following identity management systems: Active Directory, LDAP. Work with Sidney Higa to develop authentication settings for use with forms authentication."

Web SSO

x

"Use this method for partner applications only if a partner company is participating in federated identity management systems. See David Jones for more information."

Additional Notes: "Work with Denise Smith to sign off on all authentication settings for SharePoint Web applications prior to implementing."

See Also

Concepts

Plan for authentication (Search Server 2008)
Plan authentication settings for Web applications (Search Server 2008)
Authentication samples (Search Server 2008)