Forms Authentication in SharePoint Products and Technologies (Part 3): Forms Authentication vs. Windows Authentication
Summary: Learn the functional and operational differences between sites that are secured with Windows authentication and those that are secured with forms authentication. This article is part 3 of 3. (17 printed pages)
Steve Peschka, Microsoft Corporation
Revised: June 2009
Applies to: Microsoft Office SharePoint Server 2007, Windows SharePoint Services 3.0
Introduction to Differences Between Forms Authentication and Windows Authentication
Integrating with the 2007 Microsoft Office System
Selecting the "Sign me in automatically" Check Box at Logon
Opening Documents in Internet Explorer
User Profile Imports
Using an LDAP Provider
Using the Microsoft Single Sign-On Service
Introduction to Differences Between Forms Authentication and Windows Authentication
There are several functional and operational differences between sites that are secured with Windows authentication and those that are secured with forms authentication. The following sections highlight several of the more important differences that you should be aware of as you plan your implementation.
This article assumes that Microsoft Office SharePoint Server Service Pack 1 (SP1) is installed. For more information, see Updates Resource Center for SharePoint Products and Technologies.
The crawl process for Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0 content (in this article series, collectively referred to as SharePoint Products and Technologies) is designed to use Windows authentication. When Office SharePoint Server 2007 was released, it was not able to crawl content that was secured with forms authentication. In Service Pack 1, SharePoint Products and Technologies includes the ability to set special crawl rules that describe cookie-based authentication so those sites can be crawled. However, it does a simple crawl of the content only, and does not capture security information or the kind of rich metadata that the crawler can gather when using the native SharePoint protocol handler.
For those reasons, whether or not you have applied Service Pack 1, it is recommended that you crawl SharePoint sites protected by forms authentication by using the native SharePoint protocol handler. If your Web application already includes a zone that is secured with Windows authentication, in most cases you can use that zone for crawling. If your Web application has only a single zone and it is secured with forms authentication, you need to extend it into a new zone by using Windows authentication to support the native protocol handler. For more information, see Prepare to Crawl Host-Named Sites That Use Forms Authentication (Microsoft TechNet).
When you extend the Web application into a new zone, remember the following rules:
If you are using only Windows SharePoint Services, the Default zone must be secured with Windows authentication. If the Default zone is secured with forms authentication and a secondary zone uses Windows authentication, the crawler will not be able to index it.
If you are using Office SharePoint Server 2007, the Default zone can be secured with Windows authentication, but it does not have to be. You can use forms authentication for the Default zone and extend a separate zone for Windows authentication. However, you must change the start address in the default content source to the URL for the Windows authentication zone. When a new Web application is created, a start address is automatically added that uses the URL for the Default zone. Office SharePoint Server 2007 gives you the flexibility to change the values in the list of start addresses, but Windows SharePoint Services does not.
To change the start address
Open your browser and navigate to the Shared Services Provider (SSP) Web site.
Click the Search Settings link.
Click the Content sources and crawl schedules link.
Click the Local Office SharePoint Server sites link.
In the Edit Content Source page that opens, in the Start Addresses section, edit the addresses in the box.
Click OK to save your changes.
Integrating with the 2007 Microsoft Office System
Office SharePoint Server 2007 and Windows SharePoint Services 3.0 users who also have the 2007 Microsoft Office system of applications installed enjoy a high level of integration between the 2007 Office system and SharePoint Products and Technologies. Many of those integration features, however, depend on Windows authentication. Without Windows authentication, some integration points do not work, and others are changed considerably. To help minimize user confusion, SharePoint Products and Technologies offer a mode in which certain menu items that require Windows authentication are removed. In the Central Administration Web site, on the Authentication Provider page, this mode is controlled via the Enable Client Integration box.
When you configure a zone to use forms authentication, the Enable Client Integration box is cleared by default. If a zone is configured in this way, the following changes occur in functionality:
Support for remote interfaces is turned off. That includes WebDAV, SOAP, and Microsoft Office FrontPage remote procedure calls (RPC). Some functionality is not available, such as Web folders or the Web services for accessing content in that site.
Some toolbar items no longer appear:
Open in Outlook
Open In Windows Explorer
Export to Spreadsheet
Open with Database Program
Explorer View option is hidden.
Create an Access View option is hidden.
In picture libraries, the following functionality is removed:
On the Edit Control Block (ECB) menu, the drop-down menu that appears when you click items in document libraries, the following items are removed:
Edit in Word
Edit in Excel
Edit in PowerPoint
Connect To Outlook
In slide libraries the following functionality is removed:
Send to PowerPoint
Also, syncing SharePoint data with Microsoft Office Outlook no longer works.
When operating in this mode, users can still work with documents in SharePoint libraries, but they must right-click items and choose to save a copy to disk. They can then edit and update the document, and then upload it and check it back in when they are finished editing.
Some organizations might want to use forms authentication, but also require the same level of integration they get when using Windows authentication. There are a couple of possible workarounds in this scenario, but it is helpful to examine why this limitation exists.
When a user accesses a page on a site protected by forms authentication, the server looks for a valid authentication cookie. If no cookie is found, or if the cookie is not valid, the server redirects the browser to the logon page by using an HTTP 302 status code. At this page, the user is allowed to authenticate by using his or her credentials. After the credentials are validated, the server creates a valid authentication cookie and sends it back to the browser, with the originally requested page. The browser keeps the cookie in memory and sends it back to the server with every subsequent request to that Web server. With each request, the server checks the validity of the cookie to ensure that it is good (that it has not expired or been tampered with), and then processes the request.
Because the authentication cookie is in memory with the browser process, it introduces some limitations:
The cookie is retained only as long as the browser is open; when the browser is closed the cookie is destroyed with everything else in memory that the browser was using.
The cookie belongs to the browser's application process (such as the .exe file for the browser), and cannot be shared with other processes. Office system applications run in their own processes, for example, msword.exe for Microsoft Office Word. As such, a cookie that a user generated when logging into the site in the browser cannot be shared with Word.
The issues described in this article clarify why the Enable Client Integration option was developed: to help make the end-user experience more uniform and predictable in that environment; however, the user experience is somewhat different for users that are accustomed to SharePoint sites secured with Windows authentication. Even with those restrictions, there are still a few options that can be used to allow for using forms authentication and yet still provide many or all of the deep integration points with Office applications that are available when using Windows authentication.
The Forms Authentication Integration Update for Office 2007
When Office SharePoint Server 2007 and Microsoft Office 2007 were first released, the Office client applications such as Microsoft Office Word and Microsoft Office Excel could not directly open a document from a site that was secured with forms authentication. This is because, as explained earlier, a 302 HTTP response code is sent back to the client when it tries to open an item in a site using forms authentication. The Office clients were not able to respond to a 302 response code, and as a result would display the actual forms logon page in the application, instead of the requested document.
An update is available for Office 2007 client applications that allow the applications to process a 302 HTTP response code. The applications that are affected by this update are Microsoft Office Word 2007, Microsoft Office Excel 2007, Microsoft Office PowerPoint 2007 and Microsoft Office SharePoint Designer2007. Because of this update, an Office application can display the forms logon page that is being used for the site in a pop-up dialog box. To do this, the application issues a request to the SharePoint site. The server sends a response that indicates its authentication method is forms authentication, including the location of the logon page that the client should use to authenticate. The Office application then renders the HTML from that logon page and enables the user to enter credentials. The credentials are sent via an HTTP POST back to the server. If the server returns a redirect response for the document that was originally requested, the Office application assumes that the identity is successfully established. It then uses the authorization cookie that the HTTP POST gave it to retrieve the document and any associated metadata, and open the item.
By using this approach, you can use whatever forms authentication logon page the site uses—whether this is the logon page provided with SharePoint Server, a custom logon page, or even a multifactor logon page. The following figure shows an example of the logon dialog box's appearance when an item is opened on a SharePoint site that uses the standard forms logon page.
Figure 1. Standard forms logon page
To implement this support, use the following procedure.
To implement support for Forms Authentication Integration on the client
Download the Office 2007 Cumulative Update for April 2009 (Microsoft Help and Support).
This update can be used with Office 2007 on a computer that is running the Windows XP or Windows Vista operating system. If you are using Windows Vista, you also need to install Service Pack 2 for Windows Vista (see Service Pack 2 for Windows Server 2008 and Windows Vista).
Install the service pack on each client computer running Office 2007 from which you want to use the Office client to open documents from a site secured with forms authentication.
Configure the appropriate set of registry values on each client computer to enable the Office client applications to use the forms authentication integration features. For more information about the registry values and their locations and functions, see Registry Values.
Install Internet Explorer 7 or later, required to support this feature, on the client computer. However, it is not required to be the default browser.
To implement support for Forms Authentication Integration on the farm running SharePoint Server
Go to Central Administration, click the Application Management tab, and click the Authentication Providers link.
In the Web Applications drop–down list, select the Web application that contains a forms authentication zone, and then click the link for the zone that is configured to use forms authentication.
On the Settings page for the zone, select the Enable anonymous access check box, and then set Enable Client Integration? to Yes.
Selecting the Enable anonymous access check box does not, by itself, grant anonymous access to any content in the Web application. However, it is needed to enable the Office client applications to gather enough information about the site to display the logon window.
Figure 2 shows how the authentication settings for the Web application should appear.
Figure 2. Web application authentication settings
You can use one of several registry values to help control how and when the Office client applications attempt to use forms authentication to authenticate a request. All registry values are stored under the HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Common\Internet\FormsBasedAuthSettings registry subkey. Notice that if a value is not set, the default value is used.
Following is the list of supported registry values and their purposes:
FormsAuthEnabled: Determines whether the Office clients support forms authentication to SharePoint sites.
DWORD: Determines whether forms authentication support is enabled for Office client applications. To enable support, set DWORD to 1 (default).
If this value does not exist or is set to zero (0), the Office client cannot open documents directly from a SharePoint site that is secured with forms authentication.
RequireSameDomainLogin: Sets whether cross-domain redirects are allowed.
DWORD: To enforce same domain logon, set this value to 1. When set, it requires that the logon page for a user is located in the same domain as the document. For example, if the document is hosted in a site at contoso.com, the logon page cannot be in northwinds.com.
If this value does not exist or is 0 (default), the logon page can be hosted in a different domain.
SSLOnly: This value determines whether Office clients can use a forms authentication logon page that is not rendered over an SSL connection.
DWORD: To require logging on over an SSL connection, set this value to 1 (default).
If this value is set to 1 and the user visits a site that is not configured to use SSL, an access denied error message is displayed (Figure 3).
Figure 3. Access denied error message
ScriptEnabled: This value determines whether the logon page can execute script.
DWORD: To enable script in the logon page, set this value to 1 (default).
If this value is set to 0, then the logon page can load, but client side script cannot execute.
ActiveXEnabled: This value determines whether the logon page can execute ActiveX controls.
DWORD: To enable ActiveX controls in the logon page, set this value to 1 (default).
If this value is set to 0, then the logon page can load, but ActiveX controls cannot execute.
BehaviorsEnabled: This value determines whether the logon page can execute DHTML behaviors.
DWORD: To enable DHTML behaviors in the logon page, set this value to 1 (default).
If this value is set to 0, then the logon page can load, but DHTML behaviors cannot execute.
FrameDownloadEnabled: This value determines whether the logon page can download individual frames within the frameset of a logon page.
DWORD: To enable downloading of individual frames in a logon page, set this value to 1 (default).
If this value is set to 0, then individual frames cannot be downloaded. Only the frameset is loaded, so the logon dialog box displays the frames but no content (Figure 4).
Figure 4. Logon dialog box, frameset only
The forms authentication update for Microsoft Office 2007 also enables additional integration when used with a noninteractive authentication method, such as is used by Active Directory Federation Services (ADFS). By supporting a Web-based logon form, the Office client can now reauthenticate to a site secured by ADFS after the ADFS logon cookie expires. Without this support, several known issues can occur if a user is editing a document and the cookie expires before the document is saved. For example, if the logon cookie expires and you try to save a document, you see the error message shown in Figure 5.
Figure 5. ADFS logon cookie expired error message
If you try to browse folders in the SharePoint site from within an Office client application after the ADFS logon cookie expires, you see the error message shown in Figure 6.
Figure 6. Expired logon cookie error message
When an issue like this occurred, you could only save a copy of the document locally, then upload it back to the site. The new ability of the Office client applications to perform a forms logon helps to solve this problem. However, in conjunction with this ability, you need the means to send an authentication prompt to the Office client when the logon cookie does not exist or expires. The Identity Management team at Microsoft and the Microsoft Office team have developed an HttpModule for SharePoint Server 2007 that does this. The HttpModule is available as a source code sample download from the ADFS Product Support blog.
After you obtain the code sample from the blog site, use the following procedure to implement it in your SharePoint farm.
These steps assume you already have both the Office client 2007 Microsoft Office Suite Service Pack 2 installed and a zone in a SharePoint Web application secured with ADFS installed and configured, as described in The Forms Authentication Integration Update for Office 2007.
To use the HttpModule sample
Compile the code sample into a DLL.
Install the compiled DLL into the global assembly cache on each front-end Web server in the farm.
Edit the web.config file as follows on each front end Web server in the farm for the zone that is secured with ADFS:
Add the entry for the HttpModule code sample after the ADFS module. You should see an existing entry such as the following.
<add name="Identity Federation Services Application Authentication Module" type="System.Web.Security.SingleSignOn.WebSsoAuthenticationModule, System.Web.Security.SingleSignOn, Version=220.127.116.11, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null" />
Add the following entry immediately after the existing entry.
<add name="ADFS Module for Office Forms Based Auth" type="ADFSFBA.ADFSFBAHttpModule,ADFSFBA,Version=18.104.22.168, Culture=neutral,PublicKeyToken=083ff59054782422,Custom=null" />
Add the usettp element in the websso section, as follows.
<websso> … <usettp enabled="false"/> … </websso>
After you complete these steps, you can use the Office client in a nearly seamless, integrated experience with SharePoint Server. The authentication prompts for an ADFS-secured site can be further reduced by adding the site for the account logon service (FS-A) to the Local Intranet Zone in Internet Explorer. There are still a few scenarios where integration is incomplete or certain Office applications might not work. The error messages displayed earlier might still periodically appear; however, you can now navigate to a local file system folder in the Office Save dialog box, type the URL for the site and click Enter to reauthenticate to the site from within the Office application. As another example, even with the Office client hotfix and ADFS HttpModule sample installed, you cannot edit a list in Datasheet mode in SharePoint Server. A list of these exceptions is maintained on the same blog where the sample ADFS HttpModule is available for download.
Selecting the "Sign me in automatically" Check Box at Logon
The forms logon page includes a check box that states to Sign me in automatically, and it is cleared by default. If you select the box at logon, an encrypted authentication cookie is persisted to the local disk on the computer from which the user is logging on. The user credentials are not stored in the cookie; instead, what is stored is some encrypted data that identifies the user.
Office system applications look for such an authentication cookie when they receive an authentication prompt. If one exists, it is sent in response to the authentication request. If the cookie is still valid, meaning it has not expired, authentication using the cookie succeeds and the document opens in the Office client application without further intervention from the user.
Some things may still not work quite as expected even with this authentication cookie. For example, Microsoft Office Outlook uses the stssync protocol to synchronize data between Outlook and SharePoint Products and Technologies. While the authentication cookie is valid, this should still work. However, the authentication expires by default after 30 minutes; after that time the synchronization with Outlook will stop working until the user reauthenticates.
A cookie expires based on how old it is; you can change the expiration duration value by adding or updating the time-out parameter in the forms node in the web.config file. For more information, see Forms Element for Authentication (ASP.NET Settings Schema).
The drawback to this approach is that if the computer from which the user logged on is compromised or otherwise not secured at all times, then someone else could log on to that computer and access SharePoint content by using the context of the user who created the authentication cookie. For that reason, there are very few situations in which it is safe to deploy in this way.
If you do choose to implement this method, there are a few parameters that you can use to control the cookie. For example, you can control the following:
The cookie name
SlidingExpiration to control a cookie's lifetime end event
Timeout to control the amount of time that a cookie is valid
For a complete list of attributes you can use in the forms element in the web.config file, see Forms Element for Authentication (ASP.NET Settings Schema).
In Windows Vista, Internet Explorer 7 includes an additional security feature named 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.
Opening Documents in Internet Explorer
You can configure Internet Explorer so that all links for Office documents in Web sites open directly in the browser instead of in the native application. When you do this, several Office application menus and toolbars are merged and displayed with the Internet Explorer menus and toolbars, and the browser hosts the document,worksheet, or presentation.
By opening the document in Internet Explorer, the browser has the advantage of its process being able to use the authentication cookie that was created at logon. This enables Internet Explorer to open the document and respond to the authentication prompts without further intervention from the user. However, the drawback to this approach is that documents hosted in Internet Explorer do not contain all of the native application's menus and toolbars, and the interface is different enough that users can find it confusing or limited.
To configure Internet Explorer to open Office documents in the browser, see Knowledge Base article 162059: How to Configure Internet Explorer to Open Office Documents in the Appropriate Office Program Instead of in Internet Explorer. Although the article explains how to open documents outside Internet Explorer, you can change the values described to implement the opposite behavior.
User Profile Imports
Profile Imports is a feature in Office SharePoint Server 2007 that imports user information into the SharePoint profile system. This profile information is displayed in the My Sites area and allows users to view certain public information about other users in the organization, such as what their skills and interests are, organization hierarchy, or distribution list membership. Profiles can be created either from users in a Windows-based directory or from a Lightweight Directory Access Protocol (LDAP)–based directory. Profile attributes can be augmented from other line-of-business (LOB) systems through the Business Data Catalog.
When you use forms authentication, you have no built-in way to import users and user attributes into the profile system. Importing forms authentication user data requires a custom application that enumerates users, their attributes, and optionally their role information, and then uses that information to create or update profile data in SharePoint Products and Technologies.
The Office SharePoint Server 2007 Profile Import Tool has been created to perform this task, and it uses the same membership provider framework that is included with ASP.NET 2.0. If the membership provider you are using has implemented the GetAllNames method, you can register your provider with the Profile Import Tool. The tool will retrieve all users and create profiles for them if profiles do not exist. If your membership provider has implemented the GetAllProperties, the Profile Import Tool will retrieve all of the properties and add or update them in the profile system for each user.
If the membership provider has not implemented those methods, you can create a class that implements a simple interface defined by the import tool. It lets you write code specifically for your scenario to retrieve users and their attributes, compile it, and then register it with the import tool. The import tool then calls those interfaces implemented by your assembly and updates the profile system accordingly.
You can download the MOSS 2007 Profile Import Tool and source code from CodePlex.
Many users are accustomed to programs such as Outlook, in which they can type a partial name and search to find names that match some part of it. When you use forms authentication in SharePoint Products and Technologies, the same principle applies when searching for user names. However, that functionality does not extend to searching for role provider names. For example, if there is a role defined named "Readers" and a user types in "Read" in the People Picker dialog box and then clicks the search button, the Readers role will not be found. Instead the user has to type the full name to find the role. In addition, depending on how the role provider has implemented the RoleExists method, it may be necessary for the user to enter the name with the correct case sensitivity.
Users also often have an expectation that they can type a user name and click the resolve button, as shown in Figure 7.
Figure 7. People Picker
If the name is correct, the name is underlined with a solid black line; if it is incorrect, the name is underlined with a red dashed line. However, there is an unusual exception to this behavior. If you use Active Directory Federation Services (ADFS) with the WebSSO provider that is included with Office SharePoint Server 2007, it enables you to also use a type of forms authentication to log on to the site. When you use this combination, if a user types a name and clicks the resolve button, it will always underline it with a solid black line, whether a valid user name was entered or not. This behavior can confuse end users, so some additional education regarding its use might be necessary.
In certain situations, alerts might not be sent for forms authenticated users. Consider the following scenario:
There are two users in the members group.
Log on as user1 prior to creating an alert, but do not log on as user2.
Create an alert on the Announcements list and add user1 and user2 to receive alerts.
When creating an alert, you must have sufficient permissions to add multiple users.
Create an Announcement item.
In this scenario, user1 gets an e-mail message describing the alert that was created, and also receives subsequent alerts for newly added announcement items. However, user2 gets only an e-mail message describing the alert that was created, but does not receive subsequent alerts for newly added announcements items.Even after logging on as user2, this user will not receive any subsequent alerts for added items.
The issue here is that the SharePoint Timer service (owstimer.exe) is not able to determine the rights of the user when preparing to send the alert. Alerts in SharePoint Server are security trimmed, so if you do not have rights to content, you will not receive an alert for changes to it. If the SharePoint Timer server process cannot determine who you are or what groups you belong to, then it cannot send you alerts.
To enable alerts to function correctly in this scenario, you must create an application configuration file for the SharePoint Timer service. This is a standard .NET Framework application configuration file that is used with .NET Framework executable files, and you must configure it in the same way as the SharePoint web.config files.
The SharePoint Timer service process is owstimer.exe, so you must create a configuration file named owstimer.exe.config. You must place it in the drive: \Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN directory, and provide the configuration information that describes how to connect to the provider. Following is a sample configuration file that is based on the SQL Membership and Role provider described in Forms Authentication in SharePoint Products and Technologies (Part 1): Introduction.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <configuration> <connectionStrings> <add name=" fbaSQL" connectionString="server=spdb;database=aspnetdb;Trusted_Connection=true" /> </connectionStrings> <system.web> <membership defaultProvider="fbaMembers"> <providers> <add connectionStringName="fbaSQL" applicationName="/" name="fbaMembers" type="System.Web.Security.SqlMembershipProvider, System.Web,Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /> </providers> </membership> <roleManager enabled="true" defaultProvider="fbaRoles"> <providers> <add connectionStringName="fbaSQL" applicationName="/" name="fbaRoles" type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/> </providers> </roleManager> <authentication mode="Forms"> <forms loginUrl="/_layouts/login.aspx" /> </authentication> <identity impersonate="true" /> <globalization fileEncoding="utf-8" /> </system.web> </configuration>
After the configuration file is saved, you must stop and then restart the SharePoint Timer service. You can do this with the Services applet, or from the command-line prompt as follows.
net stop sptimerv3 net start sptimerv3
After you complete these steps, you should be able to add an alert for a user who belongs to the members group who has not yet logged on to the SharePoint site collection, and have the site collection send subsequent alert notifications successfully.
Using the Microsoft Single Sign-On Service
The Microsoft Single Sign-On service (SSO) that is provided with Office SharePoint Server 2007 is designed to work with a Windows identity. If the current user is not a Windows user, it does not work. As a result, forms authentication users cannot take advantage of the default SSO as it is included with Office SharePoint Server 2007.
However, SSO does provide a pluggable framework. This feature lets you specify an alternate SSO provider to the standard SSO provider in Office SharePoint Server 2007. Replacing the default SSO provider in Office SharePoint Server 2007 involves implementing the Microsoft.SharePoint.Portal.SingleSignon.ISsoProvider interface, installing it into the global assembly cache, and registering the new SSO provider with Office SharePoint Server. In your code, implement the GetCredentials and GetSsoProviderInfo methods of the ISsoProvider interface to create a minimally functional SSO provider.
You can register only one SSO provider for Office SharePoint Server 2007. Registering a new SSO provider replaces the default SpsSsoProvider class in Office SharePoint Server. Because only one SSO provider can be in use at a time, Microsoft recommends that you stop the Microsoft Single Sign-On service when using a custom SSO provider.
The Microsoft Office SharePoint Server 2007 SDKincludes documentation about the ISsoProvider interface, and a walkthrough procedure for building an SSO provider, Walkthrough: Implementing a Pluggable SSO Provider.
In this article series, we describe the classes you use to create a custom membership and role provider, and provide sample code for the minimum interfaces that you must implement for the custom provider to work correctly with Office SharePoint Server 2007 and Windows SharePoint Services 3.0. After you create a custom provider. you must take additional steps to register and configure it to begin securing your SharePoint site. We also discuss how to create a custom forms logon page for scenarios in which there are additional logon requirements, such as two-factor authentication. Then, we demonstrate how to use the SharePoint Web services for a Web application that uses forms authentication.
For more information about forms authentication, see the following additional resources:
Plan Authentication Settings for Web Applications in Office SharePoint Server (Microsoft TechNet)