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. (12 printed pages)

Steve Peschka, Microsoft Corporation

December 2007

Applies to: Microsoft Office SharePoint Server 2007, Windows SharePoint Services 3.0

Contents

z

Introduction to Differences Between Forms Authentication and Windows Authentication

z

Crawling Content

z

Integrating with the 2007 Microsoft Office System

z

Opening Documents in Internet Explorer

z

Checking the "Sign me in automatically" Check Box at Logon

z

Using an HttpModule During Authentication

z

User Profile Imports

z

Resolving Names

z

Using an LDAP Provider

z

Using the Microsoft Single Sign-On Service

z

Conclusion

z

Additional Resources

Read also:

Forms Authentication in SharePoint Products and Technologies (Part 1): Introduction

[ http://msdn2.microsoft.com/en-us/library/bb975136(printer).aspx ]

Forms Authentication in SharePoint Products and Technologies (Part 2): Membership and Role Provider Samples

[ http://msdn2.microsoft.com/en-us/library/bb975135(printer).aspx ]

Introduction to Differences Between Forms Authentication and Windows Authentication

©2008 Microsoft Corporation. All rights

reserved.

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.

In addition, there was also at least one pre-SP1 hotfix that was important to forms authentication users when
using Web applications that were deployed into multiple zones. In one issue, alerts were sent out to users who
used the URL from the Default zone for the Web application. If we apply the example from this article series,
that meant that users who accessed the site at http://www.contoso.com would receive alerts that use the
URL http://contoso. Those users would not be able to access the site using that URL. The hotfix for this issue
is rolled up into

Microsoft Windows SharePoint Services 3.0 Service Pack 1 (SP1)

[ http://technet.microsoft.com/en-us/office/sharepointserver/bb735839.aspx ] .

Note:

To take advantage of this hotfix, download and install

Microsoft Windows SharePoint Services 3.0

Service Pack 1 (SP1)

[ http://technet.microsoft.com/en-

Strona 1 z 12

Forms Authentication in SharePoint Products and Technologies (Part 3): Forms Auth...

2008-02-22

http://msdn2.microsoft.com/en-us/library/bb977430(printer).aspx

Crawling Content

Integrating with the 2007 Microsoft Office System

us/office/sharepointserver/bb735839.aspx ] .

The crawl process for Microsoft Office SharePoint Server (MOSS) 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
include 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

[ http://technet2.microsoft.com/windowsserver/WSS/en/library/378c4673-0814-4255-a79c-
7c4b6a4732a51033.mspx?mfr=true ] .

When you extend the Web application into a new zone, remember the following rules:

z

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.

z

If you are using MOSS 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. MOSS 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

1. Open your browser and navigate to the Shared Services Provider (SSP) Web site.

2. Click the Search Settings link.

3. Click the Content sources and crawl schedules link.

4. Click the Local Office SharePoint Server sites link.

5. In the Edit Content Source page that opens, in the Start Addresses section, edit the addresses in the

box.

6. Click OK to save your changes.

MOSS 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:

z

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.

z

Some toolbar items no longer appear:

Strona 2 z 12

Forms Authentication in SharePoint Products and Technologies (Part 3): Forms Auth...

2008-02-22

http://msdn2.microsoft.com/en-us/library/bb977430(printer).aspx

z

New Document

z

Open in Outlook

z

Open In Windows Explorer

z

Export to Spreadsheet

z

Open with Database Program

z

Explorer View option is hidden.

z

Create an Access View option is hidden.

z

In picture libraries, the following functionality is removed:

z

Upload Multiple

z

Edit Picture

z

Download

z

Send To

z

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:

z

Edit in Word

z

Edit in Excel

z

Edit in PowerPoint

z

Discuss

z

Connect To Outlook

z

In slide libraries the following functionality is removed:

z

Publish Slide

z

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:

z

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.

z

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

Strona 3 z 12

Forms Authentication in SharePoint Products and Technologies (Part 3): Forms Auth...

2008-02-22

http://msdn2.microsoft.com/en-us/library/bb977430(printer).aspx

Opening Documents in Internet Explorer

Checking the "Sign me in automatically" Check Box at Logon

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.

z

Office system applications do not know how to respond to the 302 response sent back from the server.
For example, if you are using forms authentication and have the Enable Client Integration feature turned
on, the Enable Client Integration menu includes an Edit in Word menu when you select a Word
document. If you click the Edit in Word menu, instead of opening the document, Word displays the
forms logon page shown in Figure 1.

Figure 1. Forms logon page

All of the issues described here justify why the Enable Client Integration option was developed: so the end-
user experience would be more uniform and predictable in that environment, though different for users that
are used 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.

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 is able to take advantage of its process having the
authentication cookie that was created at logon. That allows Internet Explorer to open the document and
respond to the authentication prompts without further intervention from the user. 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 may 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

[ http://support.microsoft.com/kb/162059 ] . It explains how to open documents outside

Internet Explorer, but you can change the values described to implement the opposite behavior.

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

Strona 4 z 12

Forms Authentication in SharePoint Products and Technologies (Part 3): Forms Auth...

2008-02-22

http://msdn2.microsoft.com/en-us/library/bb977430(printer).aspx

Using an HttpModule During Authentication

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)

[ http://msdn2.microsoft.com/en-us/library/1d3t3c61

(printer).aspx ] .

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:

z

The cookie name

z

RequireSSL to force Secure Sockets Layer (SSL) in order to use cookies

z

SlidingExpiration to control a cookie's lifetime end event

z

Timeout to control how long a cookie is valid

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:

z

Disable protected mode.

z

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://msdn2.microsoft.com/en-us/library/bb250462.aspx ] .

Note:

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)

[ http://msdn2.microsoft.com/en-

us/library/1d3t3c61(printer).aspx ] .

Another option is to write an

HttpModule

[ http://msdn2.microsoft.com/en-us/library/zec9k340(printer).aspx ]

that changes the authentication challenge type. For this scenario, the challenge type must change from the
302 redirection response that Internet Information Services (IIS) issues for forms authentication, to a
Windows-style Basic authentication challenge. That allows the user to enter credentials in a dialog box prompt,
which is an approach that Microsoft Office applications can use successfully.

A proof of concept for this approach has been developed by members of the Microsoft Services and SharePoint
Product Group teams. It is available as an unsupported code sample on CodePlex, for use as is. For more
information, see

Forms Based Authentication (FBA)

[ http://www.codeplex.com/CKS/release/projectreleases.aspx?releaseid=7450 ] on CodePlex. All source code
is included with simple installation instructions.

The drawback to this approach, however, is that it requires users to reenter their credentials each time a
document is opened from the SharePoint site.

Strona 5 z 12

Forms Authentication in SharePoint Products and Technologies (Part 3): Forms Auth...

2008-02-22

http://msdn2.microsoft.com/en-us/library/bb977430(printer).aspx

User Profile Imports

Resolving Names

Using an LDAP Provider

Profile Imports is a feature in MOSS 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 MOSS 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

[ http://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=sptoolbox&ReleaseId=8728 ] 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 2.

Figure 2. 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 MOSS 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.

The LDAP membership and role provider is included with Office SharePoint Server 2007. It allows you to use
an LDAP v3 directory as the authoritative source for SharePoint users and groups. It has been used with many
LDAP directories, although most of the examples that are available currently have demonstrated how to
connect to Active Directory Domain Services. Novell eDirectory, Sun Microsystems SunONE iPlanet (the
middleware offerings formerly known as iPlanet and SunONE have been rebranded to Sun Java System), and
the Unix OpenLDAP server are also frequently used in extranet scenarios. Following is one example of a
membership and role provider configuration section for the web.config file that connects to each.

Strona 6 z 12

Forms Authentication in SharePoint Products and Technologies (Part 3): Forms Auth...

2008-02-22

http://msdn2.microsoft.com/en-us/library/bb977430(printer).aspx

Configuration Example for Novell eDirectory

Configuration Example for Sun Java System (formerly iPlanet and SunONE)

<

membership

defaultProvider="LdapMembership"

>

<

providers

>

<

add

name="LdapMembership"
type="Microsoft.Office.Server.Security.LDAPMembershipProvider,
Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral,
PublicKeyToken=71E9BCE111E9429C"
server=" your server name or IP address " port="389" useSSL="false"
userDNAttribute="uniqueID"
userNameAttribute="uid"
userContainer="o=Novell"
userObjectClass="person"
userFilter="(ObjectClass=person)"
scope="Subtree"

/>

</

providers

>

</

membership

>

<

roleManager

defaultProvider="LdapRole" enabled="true" cacheRolesInCookie="false"

cookieName=".PeopleDCRole"

>

<

providers

>

<

add

name="LdapRole"
type="Microsoft.Office.Server.Security.LDAPRoleProvider,
Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral,
PublicKeyToken=71E9BCE111E9429C"
server="your server name or IP address"
port="389"
useSSL="false"
groupContainer="o=Novell"
groupNameAttribute="cn"
groupMemberAttribute="member"
userNameAttribute="cn"
dnAttribute="dn"
groupFilter="(&amp;(ObjectClass=groupOfNames))"
userFilter="(&amp;(ObjectClass=person))"
scope="Subtree"
useUserDNAttribute="false"

/>

</

providers

>

</

roleManager

>

Xml

Copy Code

<

membership

defaultProvider="LdapMembership"

>

<

providers

>

<

add

name="LdapMembership"
type="Microsoft.Office.Server.Security.LDAPMembershipProvider,
Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral,
PublicKeyToken=71E9BCE111E9429C"
server="myServerName"
port="21801"
useSSL="false"
userDNAttribute="entryDN"
userNameAttribute="uid"
userContainer="dc=CONTOSO,dc=COM"
userObjectClass="Inetorgperson"
userFilter="(ObjectClass=Inetorgperson)"
scope="Subtree"
otherRequiredUserAttributes="sn,givenname,cn"

/>

</

providers

>

</

membership

>

<

roleManager

defaultProvider="LdapRole" enabled="true" cacheRolesInCookie="false"

cookieName=".PeopleDCRole"

>

<

providers

>

<

add

name="LdapRole"
type="Microsoft.Office.Server.Security.LDAPRoleProvider,

Xml

Copy Code

Strona 7 z 12

Forms Authentication in SharePoint Products and Technologies (Part 3): Forms Auth...

2008-02-22

http://msdn2.microsoft.com/en-us/library/bb977430(printer).aspx

Configuration Example for OpenLDAP

Constraints of Using the LDAP Membership and Role Provider

Be aware of the following constraints when you are using the LDAP membership and role provider:

z

Trusted forests If you are using the LDAP provider with Active Directory, there are scenarios (such as
in an extranet) where there may be trusted forests in use. When a site is configured to use Windows
authentication, users from either forest are able to authenticate and use SharePoint resources. The LDAP
provider, however, tries to authenticate against only the forest that the membership provider is
configured to check. It does not authenticate against a trusted forest, and it does not follow LDAP
referrals.

If you need to authenticate against more than one forest, you should extend SharePoint Products and

Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral,
PublicKeyToken=71E9BCE111E9429C"
server="myServerName"
port="21801"
useSSL="false"
groupContainer="dc=CONTOSO,dc=COM"
groupNameAttribute="cn"
groupMemberAttribute="uniqueMember"
userNameAttribute="uid"
dnAttribute="entryDN"
groupFilter="(ObjectClass=groupofuniquenames)"
scope="Subtree"

/>

</

providers

>

</

roleManager

>

<

membership

defaultProvider="LdapMembership"

>

<

providers

>

<

add

name="LdapMembership"
type="Microsoft.Office.Server.Security.LDAPMembershipProvider,
Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral,
PublicKeyToken=71E9BCE111E9429C"
server="

<

server

name

>

"

port="389"
useSSL="false"
useDNAttribute="false"
userNameAttribute="uid"
userContainer="ou=People,dc=domain,dc=org"
userObjectClass="person"
userFilter="(ObjectClass=person)"
scope="Subtree"
otherRequiredUserAttributes="uid,cn"

/>

</

providers

>

</

membership

>

<

roleManager

defaultProvider="LdapRole" enabled="true"

cacheRolesInCookie="false" cookieName=".PeopleDCRole"

>

<

providers

>

<

add

name="LdapRole"
type="Microsoft.Office.Server.Security.LDAPRoleProvider,
Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral,
PublicKeyToken=71E9BCE111E9429C"
server="

<

server

name

>

"

port="389"
useSSL="false"
groupContainer="dc=domain,dc=org"
userNameAttribute="uid"
useUserDNAttribute="false"
userFilter="(objectClass=person)"
groupNameAttribute="cn"
dnAttribute=""
scope="Subtree"

/>

</

providers

>

</

roleManager

>

Xml

Copy Code

Strona 8 z 12

Forms Authentication in SharePoint Products and Technologies (Part 3): Forms Auth...

2008-02-22

http://msdn2.microsoft.com/en-us/library/bb977430(printer).aspx

Technologies into an additional zone for each forest that will be used for authentication. Then configure
each zone to use a different forest in the membership and role settings of the zone's web.config file.

z

Primary group membership In Active Directory, each user has a primary group. When the LDAP Role
provider is used with Active Directory, a user's primary group is not included in the list of roles for the
user. By default, a user's primary group is the Domain Users group. As a result, the Domain Users group
is not a good choice to add to a SharePoint group when you are provisioning permissions because unless
user's primary group is changed, no user will be returned in the membership of that role. For more
information, see the primaryGroupID attribute in

User Security Attributes

[ http://msdn2.microsoft.com/en-us/library/ms677943(printer).aspx ] .

z

Authenticated binds The release version of SharePoint Products and Technologies supported using
only anonymous binds to an LDAP server. Many customers requested support for authenticated binds to
an LDAP directory, and it is added in

Microsoft Office SharePoint Server 2007 Service Pack 1 (SP1)

[ http://technet.microsoft.com/en-us/office/sharepointserver/bb735839.aspx ] . If you require
authenticated binds to your LDAP server and want to use the LDAP provider that is provided with MOSS
2007, you must first apply Service Pack 1.

With Service Pack 1, the Membership element and Role provider element in the web.config file supports two
additional attributes: connectionUsername and connectionPassword. If you provide values for these
attributes, the provider will attempt to use those credentials when querying the LDAP directory. Following is an
example of an entry for a membership provider that uses these new attributes.

If you are performing authenticated binds to an LDAP directory, you should use the connectionUsername
and connectionPassword attributes for both the membership and role provider elements. Notice that these
elements are shown in plain text in the web.config file. Although this is generally not a good practice, ASP.NET
2.0 fortunately lets you encrypt configuration sections in the web.config file. There are different ways and
options available for encrypting sections, however, those are beyond the scope of this article. For more
information about encrypting configuration sections by using DPAPI, see

How To: Encrypt Configuration

Sections in ASP.NET 2.0 Using DPAPI

[ http://msdn2.microsoft.com/en-us/library/ms998280(printer).aspx ] .

For more information about encrypting by using RSA, see

How To: Encrypt Configuration Sections in ASP.NET

2.0 Using RSA

[ http://msdn2.microsoft.com/en-us/library/ms998283(printer).aspx ] .

In the simplest scenario, you can encrypt the membership and role provider sections by using the
aspnet_regiis.exe utility provided with ASP.NET 2.0. The sections can be encrypted by using DPAPI and the
local machine keys. You must repeat the process on each front-end Web server; however, because you must
also update the membership and role provider entries on each front-end Web server in the farm, you update
both at the same time. Following is an example of the command line you can use to encrypt the membership
and roleManager sections of the web.config file for a Web application. It uses DPAPI with the local machine
key.

In this scenario, the virtual directory for the SharePoint Web application whose web.config sections are being

<

add

connectionUsername="myDomain\myUser"
connectionPassword="myPassword"
server="myLdapServer"
port="389"
useSSL="false"
userDNAttribute="distinguishedName"
userNameAttribute="sAMAccountName"
userContainer="CN=Users,DC=myforest,DC=com"
userObjectClass="person"
userFilter="(ObjectClass=person)"
scope="Subtree"
otherRequiredUserAttributes="sn,givenname,cn"
name="LdapMembership"
type="Microsoft.Office.Server.Security.LDAPMembershipProvider,
Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral,
PublicKeyToken=71E9BCE111E9429C"

/>

Xml

Copy Code

aspnet_regiis.exe -
pef "system.web/membership" "C:\Inetpub\wwwroot\wss\VirtualDirectories\99" -
prov "DataProtectionConfigurationProvider"
aspnet_regiis.exe -
pef "system.web/roleManager" "C:\Inetpub\wwwroot\wss\VirtualDirectories\99" -
prov "DataProtectionConfigurationProvider"

Copy Code

Strona 9 z 12

Forms Authentication in SharePoint Products and Technologies (Part 3): Forms Auth...

2008-02-22

http://msdn2.microsoft.com/en-us/library/bb977430(printer).aspx

Using the Microsoft Single Sign-On Service

encrypted is mapped to the physical directory C:\Inetpub\wwwroot\wss\VirtualDirectories\99. Also, the
aspnet_regiis.exe application is located by default in the path
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727

. After the sections are encrypted, they look like the

following code example (only the membership section is shown here).

Fortunately, because these encryption methods are a core part of ASP.NET 2.0, the application does not need
to handle these methods differently in order to work. If the credentials or other attributes of the sections must
be changed, they can be decrypted by using the same utility. Following is an example of removing encryption
from the membership section through the command line.

Note:

Line breaks in the <CipherData> tag are provided only for readability.

<

membership

configProtectionProvider="DataProtectionConfigurationProvider"

>

<

EncryptedData

>

<

CipherData

>

<

CipherValue

>

AQAAANCMnd8BFdERjHoAwE/Cl+sBAAAAxi12BeT890eeO/wBnFBr

rgQAAAACAAAAAAADZgAAqAAAABAAAACMwGpKV471oWCBmSEw8YDcAAAAAASAAACgAAAAEAA
AAFXOS3tZWyEiBr6O4CRdJ0QwBQAAadCe3M7P75Mr83axr3dTTsrjZBKLF/2GbxxVykjbSj
lH2QJQQHOGdklUQcunOCitfbOsBBvFh+3D/NMYVQoQZdVPFyT6X2uCdLfyPbRAfhEsZISw9
aOOm8jsRbIVmjHyx+T2ZcjlLMp0D8IliSSS/QkZghxi/XXK6rT1V7PxFE/7IGGSvC9tVND8
lw9p1KkGMYNyltMeg/aiXC0SUskrV515lbu4rFk8fcrXWtoccuso3+Tvq37RyX7fdv7nIoD
SxFP0DVqoDfZv4pxQubjUSFP5NlrHOBaPbKTcjx/5OKCL/fZtlYc++0GwthWo12E0usd2W9
6c78IhramW/zBvQFk8pCcsk5q2/njpQHg2103nrrG6UpJwd1tTIZQjiaISe/YUT33yU0WXt
bl/2LLq20dmYJ6mXv+2vge6IocnAYLhG+tbOviJdGGu/NEQLUS/L29440tVqoJGYnqF2oqr
tYe+4KLgf76TqLEV/BRyGtjspaewmwOj1SGcVYmdGMj4DvrmVrVXcJi9IQnExlv+q7KOj0T
2glP+2Ya3T/wPqM/C0xENtgcnQ3DdYxlKr6kJ1gt26FvGYEGsD/EPdMGRAh2a3rKKCd9leE
vKLVviP5o8jhdcY28NY7vh+DPTePOahLmoT/d+uJcNxfSZQ7CgCyz+AvNb6Tf86CtPHqmJR
NZN0OBsheEkNJ8SkgpnO4lYmW2DhqJeP93vEfRQl3eZ++MNvxas5niSyi/xD2Um0F+m/ckH
OagBRXoI9+wWyYS8rpdexG5EaYzqzXMn+72kDdai68OyqL1NusY0zJIBqG+Ipp8Jj1ErDoz
92aH+ttCDVRL/oZXH7wj9ohaL3skxyyDSkZBJoDUNrLyUE6UBIHljqbFAITdVuyVTXb7de3
qxgFMYXFULp0oJrZW5I7SVu6jazQ3ehEc3fxCDAMv0cU+49IdqJGX3nF2vsOLdS5oabj9ID
1xbkbPYli7RE3KoHP+ZkptINXNSHjYLg5RJdcIoS4DNf9m1vFrOhfS3uzCDCAmpVw0WiFcw
axiY2K9l9mFv9/+l4KL0IAUNPZhOda/+dC9/S+ifee3t32sIU9eOu8/7mQtl0PAOvk7dk3/
Qd4kC1oqf5pcQiDA9AR3iWP2O9jZt0memRX5GG6yGaqoMs1TY8t4hPlXC/VJDeJHNcjztEv
+Q5WktOkbSczQdl2PgWp/daOhzGrhcQiavB/2Qxm26prYABx3aUaFXSwPl9z7LDxEKIenrX
/NwFdtssZah5F/JJwziptxjrp8aCsB3VlkXkEWK1jlYmCpPjjoW/sb3rmEKAIq9qILSNAtD
M8mX4ryXYoc6uKtzp8XH56aLi33BM9eghnxanHMKLZNQnxmPEVhhX1BpsqIzNn0P+bbBmdz
Oy03Yl+Pp/EFCgC44p+CvfyGPlisQolHqvvgT03DC29LxX2buGF0PUBQpET7JWmjPcp2F22
zop4UCmW4XDaiWal4KI2SIHC/jorlFul+0OeNXfp3kIWmyWy8YLnMDboRxD7z/yb0Qql4wW
FC6u8AY/yKYtFVhS776Qv/ez4f+rLNZlXLwtcE/ezj3aGTxqboWu7tXy22K/RlkWeeRYucJ
0GwcA8N1bOIaVPMuqqA8DGpDJJOtEhNRzSO0toBt89mCc9qG0fTQSeqJDX4Og3iJOkdgoj4
wcW3iQrT1Jfn4pnQKrcne688yfm5V1PlwoPOkKo90CxVuy887giiG+aj+7KuWobinOD9yDV
XJeDWdvWZQrR2dL+r7zZxb59QUAAAA9atGPbGXe++gGm9Q3XnNhTc/RQM=

</

CipherValue

>

</

CipherData

>

</

EncryptedData

>

</

membership

>

Xml

Copy Code

aspnet_regiis.exe -
pdf "system.web/membership" "C:\Inetpub\wwwroot\wss\VirtualDirectories\99"

Copy Code

The Microsoft Single Sign-On service (SSO) that is provided with MOSS 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 MOSS 2007.

However, SSO does provide a pluggable framework. This feature lets you specify an alternate SSO provider to
the standard SSO provider in MOSS 2007. Replacing the default SSO provider in MOSS 2007 involves
implementing the

Microsoft.SharePoint.Portal.SingleSignon.ISsoProvider interface

[ http://msdn2.microsoft.com/en-us/library/ms559528(printer).aspx ] , installing it into the global assembly
cache, and registering the new SSO provider with MOSS. In your code, implement the

GetCredentials

[ http://msdn2.microsoft.com/en-us/library/ms500141(printer).aspx ] and

GetSsoProviderInfo

[ http://msdn2.microsoft.com/en-us/library/ms543911(printer).aspx ] methods of the ISsoProvider interface
to create a minimally functional SSO provider.

You can register only one SSO provider for MOSS 2007. Registering a new SSO provider replaces the default

Strona 10 z 12

Forms Authentication in SharePoint Products and Technologies (Part 3): Forms Au...

2008-02-22

http://msdn2.microsoft.com/en-us/library/bb977430(printer).aspx

Conclusion

Additional Resources

SpsSsoProvider class

[ http://msdn2.microsoft.com/en-us/library/ms493224(printer).aspx ] in MOSS. 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 SDK

[ http://msdn2.microsoft.com/en-us/library/ms550992

(printer).aspx ] includes documentation about the ISsoProvider interface, and a walkthrough procedure for
building an SSO provider,

Walkthrough: Implementing a Pluggable SSO Provider

[ http://msdn2.microsoft.com/en-us/library/ms566925(printer).aspx ] .

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 MOSS 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:

z

Forms Authentication in SharePoint Products and Technologies (Part 1): Introduction

[ http://msdn2.microsoft.com/en-us/library/bb975136(printer).aspx ]

z

Forms Authentication in SharePoint Products and Technologies (Part 2): Membership and Role Provider
Samples

[ http://msdn2.microsoft.com/en-us/library/bb975135(printer).aspx ]

z

What Every SharePoint Administrator Needs to Know About Alternate Access Mappings Part 1 of 3

[ http://blogs.msdn.com/sharepoint/archive/2007/03/06/what-every-sharepoint-administrator-needs-to-
know-about-alternate-access-mappings-part-1.aspx ]

z

What Every SharePoint Administrator Needs to Know About Alternate Access Mappings Part 2 of 3

[ http://blogs.msdn.com/sharepoint/archive/2007/03/19/what-every-sharepoint-administrator-needs-to-
know-about-alternate-access-mappings-part-2-of-3.aspx ]

z

What Every SharePoint Administrator Needs to Know About Alternate Access Mappings Part 3 of 3

[ http://blogs.msdn.com/sharepoint/archive/2007/04/18/what-every-sharepoint-administrator-needs-to-
know-about-alternate-access-mappings-part-3-of-3.aspx ]

z

Configuring Multiple Authentication Providers for SharePoint 2007

[ http://blogs.msdn.com/sharepoint/archive/2006/08/16/702010.aspx ]

z

SharePoint Server 2007 Developer Portal

[ http://msdn2.microsoft.com/en-us/office/aa905503.aspx ]

z

How to Use ADFS to Turn MOSS 2007 into a Claims-Aware Application

[ http://blogs.msdn.com/sharepoint/archive/2007/02/15/how-to-use-adfs-to-turn-moss-2007-into-a-
claims-aware-application.aspx ]

z

Plan Authentication Settings for Web Applications in Office SharePoint Server

[ http://technet2.microsoft.com/Office/en-us/library/d3e0e0fc-77b6-4109-87d6-
53ad088db01d1033.mspx?mfr=true ]

z

How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI

[ http://msdn2.microsoft.com/en-

us/library/ms998280(printer).aspx ]

z

How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA

[ http://msdn2.microsoft.com/en-

us/library/ms998283(printer).aspx ]

z

User Security Attributes

[ http://msdn2.microsoft.com/en-us/library/ms677943(printer).aspx ]

z

Office Developer Center

[ http://msdn.microsoft.com/office ]

z

SharePoint Server 2007 Developer Portal

[ http://msdn.microsoft.com/office/server/moss/ ]

z

Windows SharePoint Services Developer Center

[ http://msdn.microsoft.com/wss ]

Strona 11 z 12

Forms Authentication in SharePoint Products and Technologies (Part 3): Forms Au...

2008-02-22

http://msdn2.microsoft.com/en-us/library/bb977430(printer).aspx

Community Content

Strona 12 z 12

Forms Authentication in SharePoint Products and Technologies (Part 3): Forms Au...

2008-02-22

http://msdn2.microsoft.com/en-us/library/bb977430(printer).aspx