Microsoft Office SharePoint Server 2007 authentication is performed by an authentication mechanism that is supported by one of the available authentication providers. Providers are modules that contain the code necessary to authenticate the credentials of a requestor Authentication for Office SharePoint Server 2007 is built on the ASP.NET authentication model and includes three authentication providers:

Windows authentication provider

Forms-based authentication provider

Web Single Sign-On (SSO) authentication provider

In addition, ASP.NET supports the use of pluggable authentication providers, which means that you can write an authentication provider to support any credential store that you want to use.

The forms-based authentication provider supports authentication against credentials stored in Active Directory, in a database such as a SQL Server database, or in a Lightweight Directory Access Protocol (LDAP) data store such as Novell eDirectory, Novell Directory Services (NDS), or Sun ONE. Forms-based 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.

The forms-based authentication provider supports authentication against credentials stored in one of the following:

The Active Directory directory service

A database

An LDAP data store

To enable forms-based authentication for a Office SharePoint Server 2007 Web site and add users to the user account database, perform the following procedures.

Create a new site

On the home page of the SharePoint Central Administration Web site, click Application Management.

On the Create or Extend Web Application page, click Create a new Web application.

On the Create New Web Application page, in the Security Configuration section, make sure NTLM is selected under Authentication provider. Also, select Yes under Allow Anonymous.

Use the default entries to complete the new Web application creation procedure and click OK.

At this point, you have created a new site placeholder. Use the following procedure to create a site collection.

Create a site collection

On the top link bar, click Application Management.

On the Application Management page, in the SharePoint Site Management section, click Create site collection.

On the Create Site Collection page, in the Web Application section, verify that the Web application in which you want to create the site collection is selected.

If it is not, click Change Web Application on the Web Application menu. Then, on the Select Web Application page, click the Web application in which you want to create the site collection.

In the Title and Description section, type the title and description for the site collection.

In the Web Site Address section, under URL, select the path to use for your URL.

Note:

If you select a wildcard inclusion path, you must also type the site name to use in the URL of your site. The paths available for the URL option are taken from the list of managed paths that have been defined as wildcard inclusions.

In the Template Selection section, in the Select a template list, select the template that you want to use for the top-level site in the site collection.

In the Primary Site Collection Administrator section, enter the user name (in the form domain\username) for the user who will be the site collection administrator.

If you want to identify a user as the secondary owner of the new top-level Web site (recommended), in the Secondary Site Collection Administrator section, enter the user name for the secondary administrator of the site collection.

If you are using quotas to limit resource use for site collections, in the Quota Template section, click a template in the Select a quota template list.

Click OK.

At this point, you have created a site collection. Use the following procedure to configure a forms-based authentication provider.

Configure a forms-based authentication provider

On the home page of the SharePoint Central Administration Web site, click Application Management.

On the Web Application List page, double-click the new Web application that you created in the previous procedure.

On the Application Management page, in the Application Security section, click Authentication providers.

On the Authentication Providers page, click the zone name for the authentication provider whose settings you want to configure.

On the Edit Authentication page, in the Authentication Type section, select Forms.

If you need to explicitly grant anonymous access to a site collection, in the Anonymous Access section, select the Enable anonymous access check box for all sites within the Web application. To disable anonymous access for all sites within the Web application, clear the Enable anonymous access check box.

Note:

If you enable anonymous access here, anonymous access can still be denied at the site collection level or at the site level. However, if you disable anonymous access here, it is disabled at all levels within the Web application.

In the Membership Provider Name section, in the Membership provider name box, type the name of the membership provider that you want to use.

Note:

If the Web application is going to support forms-based authentication, the membership provider must be correctly configured in the Web.config file for the IIS Web application that hosts SharePoint content on each Web server. The membership provider must also be added to the Web.config file for the IIS Web application that hosts Central Administration.

In the Client Integration section, under Enable Client Integration, make sure No is selected, and then click Save.

If you select Yes, features that start client applications according to document types will be enabled. This option will not work correctly with some types of forms-based authentication.

If you select No, features that start client applications according to document types will be disabled. Users will have to download documents and then upload them after they make changes.

If you have not installed Microsoft Office SharePoint Server 2007 with Service Pack 2 (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 Office SharePoint Server 2007 with SP2. When client integration is disabled, links to client applications are not visible and documents cannot be opened in client applications; documents can only be opened in a Web browser. However, users can download documents, edit them in client applications locally, and then upload them to the site.

After a user provides credentials, the system issues a cookie that identifies the user. On subsequent requests, the system first checks the cookie to see whether the user has already been authenticated, so the user does not have to supply credentials again.

If the user has not selected the Remember me? box on the logon page, the credential information is not cached on the client computer, and is valid only during the current session. This is especially important in a scenario where users are connecting from public computers or kiosks, where you would not want user credentials to be cached. Users are required to reauthenticate if they close the browser, log off from a session, or navigate to another Web site. Also, you can configure a maximum idle session time-out value to force reauthentication if a user is idle for a prolonged period of time during a session.

Implementing forms-based authentication can interfere with enterprise search functionality. To enable search across content authenticated using a custom authentication mechanism, you must have the Default zone configured to support NTLM authentication. The Office SharePoint Server 2007 search crawler polls zones in the following order:

Default zone

Intranet zone

Internet zone

Custom zone

Extranet zone

Note:

If you use forms-based authentication and the Office SharePoint Server 2007 search crawler polls a zone that is configured to support Kerberos authentication, the Office SharePoint Server 2007 search crawler will fail. If you use forms-based authentication and the Office SharePoint Server 2007 search crawler polls a zone that is configured to support basic or certificate authentication, you have to configure a crawl rule and provide credentials or certificates in the Shared Services Provider (SSP) search settings. If a crawl rule is not configured, the crawler will cycle through all of the zones until it finds a zone that is configured with NTLM. If the crawler finds a zone configured with NTLM, the crawl will succeed. If the crawler finds a zone configured with Kerberos or Digest authentication, the crawl will fail and polling will stop.

Office SharePoint Server 2007 does not allow a Web application to work with the same provider name across multiple zones. You can configure the Web.config file to use the same provider for each zone; however, the name of the provider has to be unique for each zone.

To plan a forms-based authentication implementation across your Office SharePoint Server 2007 deployment, you need to determine how to configure forms-based authentication to interoperate with My Sites Web applications. To ensure that forms-based authenticated users can perform people searches and create My Sites Web applications in an Office SharePoint Server 2007 farm, perform the following procedure:

Create a Web application with NTLM authentication configured for the Default zone. For information about creating a Web application, see Create or extend Web applications.

At this point, all the Web applications are extended to the Default zone, and the authentication mechanism is configured as NTLM.

To ensure that the crawler can access the content, configure the extended content Web application for forms-based authentication by selecting the Web application from the Web Application list in Central Administration, as shown in the following figure:

Follow the link to Create or Extend Web Application and choose the option to extend a Web application. Type in the details, such as choosing a port number where the new Web application will be hosted in IIS, and choosing the zone that this extended Web application will reside under.

The following figure shows the original Web application, which is always created in the Default zone, and the extended Web application created under the Custom zone.

Each of the zones identifies the logical separation of access restrictions to the same content.

Note:

You cannot increase the number of zones.

Configure the membership provider name of the extended Web application for forms-based authentication, as shown in the following figure.

After extending the content Web application to a different zone, you can configure authentication providers and enable different authentication mechanisms using different URLs. At this point, add a provider section in the Web.config file of the extended Web application.

Note:

Adding the provider section in the Web.config file for the default zone will have no impact on Office SharePoint Server 2007 awareness of the provider for the new zone. Practically, the two zones are isolated from each other as far as IIS Web sites are concerned, even though they will still share the same application pool.

Modify the authentication provider by following the link to the Authentication Providers page. This page displays all of the zones on which the Web application has been extended. Select the appropriate zone and configure the authentication provider. In the preceding example, the authentication provider is configured as the PeopleDCLDAPMemberShipProvider for the Custom zone.

Add the first administrative user who will have administrative access on all site collections within the Web application. In this example, the content is the same and the site collections are identical across all the extended zones (Default and Custom), even though the URLs are different. When the Web application is first created, the application pool identity is granted Full Read permissions on the Web application for all zones. For the Default zone, access is controlled by the primary site collection administrator who was specified during the creation of the site collection at the root of the Web application. For the extended zone, you have to add a specific user with Full Control on the Web application to enable initial logon to the site collections and to perform administrative tasks. To add a user, click Add Users on the Policy for Web Application page, and select a zone. Run the People Picker and resolve the name of the user.

Note:

The user will be added as provider:username because the People Picker will resolve the user by using the provider configured in the Web.config file for the extended Web application. Office SharePoint Server 2007 ignores the custom provider if All Zones is selected in the Zone drop-down list. Therefore, it is very important to ensure that the appropriate zone is selected.

After the user has been added, verify that forms-based authentication is functioning and browse to the URL for the extended zone. In this example, the content Web application is in the Default zone on port 2000 and is extended to the Custom zone on port 2001. Browse to the extended port.

At this point, the forms-based authentication logon screen is displayed. Type the credentials for the user you added earlier, and click Submit. You are then redirected to the Default.aspx page of the site.

The Default.aspx page is very similar to a standard Default.aspx page of a default zone site. However, in this example, the My Site creation link is not displayed. My Sites and personalization are services provided by the Shared Services Provider (SSP). There is an existing SSP that provides these services to this Web application. At this point in the procedure, the SSP is unaware of the new user, whose credentials you used to log in. Because links are security trimmed, they are not displayed and, in this example, the current user is not recognized by the SSP. To correct this situation, enable the SSP for forms-based authentication, as described in the following procedure.

To configure the Shared Services Provider (SSP) for forms-based authentication, extend the SSP administration Web application to map to the same zone as the content Web application. On the Manage this Farm's Shared Services page, the administration site host for the SSP is listed on port 80, and the SSP is only aware of NTLM authentication. To make the SSP aware of the custom provider, configure the SSP for forms-based authentication.

Extend the Web application on port 80 (the administration site host) to the same zone on which the content Web application was extended, and then configure the extended Web application for forms-based authentication.

Note:

Typically, users are not aware of this new Web application and this Web application only provides forms-based authentication awareness to the SSP.

Browse to the new SSP administration site. After the administration Web application is forms-based authentication enabled, you can point the browser to a URL such as http://<server>:<extended port>/ssp/admin/default.aspx. This is similar to the URL for the SSP administration site (with a different port number). However, now you are prompted for credentials on the forms-based authentication logon page.

After you enter the credentials of the user that you added during the Add Users procedure on the Policy for Web Application page, you are redirected to the Administration page.

Note:

If you try to browse to Personalization Services Permissions in the User Profiles and My Sites section of the Shared Services Administration page, access is denied. This is because the logged-on user does not have permissions to modify personalization services permissions even though the forms-based authenticated user has permissions to browse the site. To change this behavior, the user has to have permissions explicitly provided in a different account, and the account itself has to have permissions to modify personalization services permissions. In this example, that configuration would be difficult to configure because you are currently browsing using the one account that has been added with Full Control over the SSP. Users in a Windows authenticated zone are the only ones who have permissions to edit personalization services permissions. To enable forms-based authenticated users to edit personalization services permissions, you must be logged on as a user in a Windows authenticated zone.

Add permissions for personalization links by logging in to the SSP administration site using the Default zone.

Note:

Make sure the welcome control displays the identity of the Windows user.

Browse to the Personalization Services Permissions page, and launch the People Picker.

Try resolving the forms-based authenticated user here. The People Picker will not resolve the forms-based authenticated user because this zone is not aware that there is another provider that can be queried to find these users.

To make this zone aware of the provider, modify the Web.config file for this zone and add the same provider section that you added for enabling forms-based authentication.

Important:

In the Web.config file, do not set the defaultProvider attribute. If you set this attribute, the People Picker and security trimmer will always use this provider to resolve and authenticate users.

Browse back to the Personalization Services Permissions page and launch the People Picker, which now resolves the forms-based authentication user and displays all users who meet the same criteria.

Select a user and a choose the permissions you want to assign to this user:

Create Personal Site: This permission is required to make the My Site link visible, and enables users to create a My Site.

Use Personal Features: This permission enables users to access SSP and My Site features.

At this point, you can log back on to the Custom zone SSP site as a forms-based authenticated user and add additional users. In addition, you can configure sets of permissions for these additional users. After the user is enabled with the Create Personal Site permissions, the My Site link will be displayed. You can browse to the Custom zone portal using the forms-based authenticated user and note the Welcome control suite displays the My Site link. However, clicking the link will not actually create a My Site. This is because the SSP still only refers to the default zone for the My Site host, even though the SSP is extended on the Custom zone. The Web application is not yet aware of the forms authenticated users. You can address this by extending the My Site Web application and configuring it for forms-based authentication.

Because you can manually set the My Site host from within the SSP, it does not matter if the My Site host is extended to a different zone than the SSP administration Web application. If you are implementing a scenario in which these two zones have to be different, you can browse to the SSP, using forms-based authentication, and manually set the My Site host. Browse to the SSP administration Web site using forms-based authentication and then browse to the My Site Settings page.

Now you can edit the personal site provider to point to the newly extended My Site Web application. If you extend the My Site Web application onto the same zone as the SSP administration Web application, Office SharePoint Server 2007 will automatically realign the My Sites and this manual configuration is not necessary.

In addition, you can go to the content site, log on by using forms-based authentication, and create a My Site for the forms-based authenticated user.

To plan a forms-based authentication implementation across your Office SharePoint Server 2007 deployment, you need to determine how to configure forms-based authentication to interoperate with user profiles and people search. Office SharePoint Server 2007 imports user profiles using the active authentication provider. For people search to work with forms-based authentication, the user profiles have to be imported with the forms-based authentication provider. If the same set of users is imported using Windows authentication over the Default zone, and forms-based authentication over the Custom zone, profile import will import the same set of users at the same time, identifying them differently. For example, the user, "domain\user1" is treated differently from the user "provider:user1". This is true even though all of the properties are identical, including the source from which they were imported. It is the provider that differentiates the two users and treats them as two different users.

Assuming that you have already configured the SSP administration Web application to work with forms-based authentication, perform the following procedures to enable people search. Make sure that the SSP administration Web application is extended and correctly configured to use forms-based authentication. In addition, note that the administrative user should be explicitly assigned permission to manage user profiles from the Personalization Service Permissions page.

To configure a user profile import, browse to the SSP administration site for the Custom zone. Because this has already been configured with forms-based authentication, you can logon using the credentials of the administrative user.

Click User Profiles and Properties and configure a new import connection.

The available options are Active Directory, LDAP Directory, Active Directory Resource, and Business Data Catalog. In this example, because the source is a user store on a domain, an LDAP directory is selected as the connection type.

Populate the connection name and the name of the LDAP server, as defined in the provider section.

Type the provider name, as listed in the Web.config file, and the user name attribute from the provider section. The rest of the information should be filled in automatically.

Start the import using the newly added import connection.

Verify that the profiles are imported by clicking View User Profiles, as shown in the following figure:

After the import is performed, the user profile store in Office SharePoint Server 2007 is updated with the new profiles. To enable people search, perform the next procedure.

Initiate a crawl of the people content source. When the crawl is complete, you will be able to perform a people search on the forms-based authentication site.