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

Summary: Explore several new features for authentication and authorization in Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0 that make it easier to develop and deploy solutions in Internet-facing and extranet environments. This article is part 1 of 3. (26 printed pages)

Steve Peschka, Microsoft Corporation

Updated: June 2009

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

Contents

  • Introduction to Forms Authentication in SharePoint Products and Technologies

  • Deciding to Use Forms Authentication

  • Reviewing a Typical Scenario for Authentication

  • Reviewing Changes to Authentication Terminology

  • Setting Up Forms Authentication

  • Granting Permissions to Create My Sites

  • Additional Resources

Read part 2 and part 3:

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

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

Introduction to Forms Authentication in SharePoint Products and Technologies

Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0 (in this article series, collectively referred to as SharePoint Products and Technologies) contain several new features for authentication and authorization that help to make it easier for you to develop and deploy solutions in Internet-facing—and especially extranet—environments. In earlier SharePoint versions, at some point all security principals needed to resolve to a Windows identity—either a user account or group.

Office SharePoint Server 2007 and Windows SharePoint Services 3.0 are built upon the ASP.NET 2.0 Framework, which allows you to use forms authentication to authenticate users into the system. Because SharePoint Products and Technologies are built upon the ASP.NET 2.0 pluggable authentication provider model, they can now support authentication for users stored in Active Directory, a Microsoft SQL Server database, in an LDAP directory, or in any other directory that has an ASP.NET 2.0 membership provider. Although Windows SharePoint Services 3.0 does not provide any default membership providers, Office SharePoint Server 2007 does provide a built-in LDAP V3 membership and role provider, and ASP.NET 2.0 includes a SQL Server membership and role provider. However, if you want to use a directory and cannot find a membership provider for it, you can write your own! This is a key technology enabler for heterogeneous environments.

Important

When you use forms authentication, client integration is disabled by default because client integration does not natively support forms authentication. You might be able to use many client integration features with forms authentication, and there are workarounds available to implement varying levels of client integration functionality with forms authentication. Specifically, starting in the Office 2007 Cumulative Update for April 2009 (Microsoft Help and Support), Microsoft Office Word, Microsoft Office Excel, Microsoft Office PowerPoint, and Microsoft Office SharePoint Designer all have native support for forms authentication, as described in Forms Authentication in SharePoint Products and Technologies (Part 3): Forms Authentication vs. Windows Authentication. If you plan to use client integration with forms authentication, you must fully test any available solutions or workarounds to determine whether the performance and functionality are acceptable in your environment. Microsoft Customer Support can provide commercially reasonable support to help you troubleshoot published workarounds.

Deciding to Use Forms Authentication

Some organizations want to use Windows users and groups in SharePoint Products and Technologies, but enter credentials via forms authentication. Before using forms authentication, determine why to use forms authentication in the first place: What is the business driver? If user accounts are stored in a location other than an Active Directory domain controller, or if Active Directory is not available in a particular environment, using forms authentication with a membership provider is a good choice. But if you want to force logon only via forms authentication, but still use Windows and all of the integrated features it provides, you should consider an alternative such as publishing the SharePoint site with Microsoft Internet Security and Acceleration (ISA) Server 2006. ISA Server 2006 allows users to log on by using a forms authentication Web form, but treats them like Windows users after authentication. This implementation provides a more consistent and compelling experience for end users.

Reviewing a Typical Scenario for Authentication

A very common scenario is one in which you have an existing intranet SharePoint site, and the Web application that hosts the site is configured to use Windows authentication. Users log on to corporate desktops and can navigate seamlessly to the SharePoint site by using their logon credentials.

The organization now decides to make this site available on the extranet. Such availability can allow external partners to access and share the content. The organization should not have to duplicate the content between the internal and external sites, and managing both internal and external users' access rights should occur exclusively in the intranet. To accomplish this, user accounts and groups for external users are stored in a SQL Server database. The zone uses the SQL membership and role providers that are included with the Microsoft .NET Framework 2.0.

The rest of this article describes how to configure SharePoint Products and Technologies in this scenario.

Reviewing Changes to Authentication Terminology

Several new features in Office SharePoint Server 2007 and Windows SharePoint Services 3.0 are used to create and configure forms authentication access to a site. In addition, some concepts from SharePoint Products and Technologies 2003 are changed or are renamed. Following are several important definitions to understand when configuring forms authentication in Office SharePoint Server 2007 or Windows SharePoint Services 3.0.

Web Application

Referred to as a virtual server in the previous version of SharePoint Products and Technologies, a virtual server is now a Web application. When a Web application is created, it maps a set of properties, such as the load-balanced URL and the authentication method that will be used, to its Default zone.

Zone

A zone is a way to map multiple Web application configuration settings to a single set of content databases. For example, you can create a Web application, create a content database, and then configure the database to use Windows authentication. All of these settings are configured for the Default zone for the Web application. You can then extend the Web application and map it to a new zone. When you do that, you select a zone to map to, such as Intranet, Internet, Custom, or Extranet. When you configure the second zone, you select an existing or new Internet Information Services (IIS) virtual server and a new load-balanced URL, and determine whether to use NTLM or Kerberos authentication. You can change the authentication provider, for example, to forms authentication, after the new zone is created.

Policy

A policy—useful in many scenarios including when you are configuring a Web application for forms authentication—allows you to grant full access, grant read-only access, deny write access, or deny all access to a user or group on a Web application. This policy grant applies to all sites in the Web application, and it overrides any permissions that are established within individual sites, lists, or items.

Alternate Access Mapping

Alternate access mapping (AAM) is a way to define the different URLs that are associated with a Web application and its set of content databases. It effectively manages the zone relationships described earlier. It also lets you map between internal URLs, such as those a load balancer might use, and the external URLs that users see.

In the earlier versions of SharePoint Products and Technologies, it was less important in an extranet scenario to create an AAM because SharePoint Products and Technologies would get the virtual server and host name information from IIS. In Office SharePoint Server 2007 and Windows SharePoint Services 3.0, you must use AAM or things just will not function correctly.

Authentication Provider

By default, Office SharePoint Server 2007 and Windows SharePoint Services 3.0 use Windows as the authentication provider for new zones. As described earlier, SharePoint Products and Technologies can also use the ASP.NET 2.0 pluggable authentication provider model for the membership provider interface. In addition, SharePoint Products and Technologies also support the role provider interface, which enables you to surface attributes such as group membership about your users. If you are accessing your SharePoint site with forms authentication, you need a membership provider at a minimum. A role provider is optional, but typically quite useful so that you can provision permissions to groups of users, rather than having to add each user to a SharePoint Group.

Setting Up Forms Authentication

Now that we have defined the basic scenario and terminology, we can step through how to configure forms authentication. We make the following assumptions:

  • We created a Web application and the Default zone is using the load balanced URL http://contoso.

  • SQL Server is installed in the extranet on a server named spdb. The SQL membership and role provider are used with this database server.

  • We access the external site at https://www.contoso.com.

Note

If you are using Office SharePoint Server or Windows SharePoint Services in the extranet for collaboration, you should do so securely over Secure Sockets Layer (SSL). In this case, your external site is located at https://www.contoso.com. We are excluding that step here only to simplify and focus on the processes we are addressing in this article. In a true production environment, excluding that step would not be acceptable.

Extending the Existing Web Application

The existing Web application is located at http://contoso, and is secured with Windows authentication in the Default zone. It resembles Figure 1.

Figure 1. Contoso Portal Web application

Contoso Portal Web application

To extend the existing Web application into a new zone

  1. Open your browser and navigate to the Central Administration Web site.

  2. Click the Application Management tab, and then click Create or extend Web application.

  3. Click Extend an existing Web application to open the Extend Web Application to Another IIS Web Site page. To select the Web site you are extending, in the Web Application list, click Change Web Application. In this case it is the Contoso Web application.

    Figure 2. Select Web application list

    Select Web application list

  4. In the dialog box, click the link for the Contoso Web application to select it.

  5. In our scenario, we want to extend the Web application by using the name www.contoso.com. To enable this, create an IIS Web site and configure the Port to 80, and configure the Host Header to www.contoso.com.

    Figure 3. Create IIS Web site

    Create IIS Web site

  6. For default provider, click NTLM. We change this in a later step.

  7. Retain the default selections for anonymous users and SSL. As mentioned earlier, in a true production environment you would choose to enable SSL for an external site.

  8. In the Load Balanced URL section, remove the ":80" from the end of the URL, so that the load-balanced URL is https://www.contoso.com.

  9. In the Zone list, click Extranet, and then click OK to save your changes and extend the Web application.

    Figure 4. Zone list

    Zone list

Managing Users and Roles

After you extend the Web application, you must create the database that will store user names and roles. In this case, there is a database in the perimeter network for this purpose named spdb. We will use the ASP.NET membership and role provider to authenticate users and determine their group memberships, so we must create the ASP.NET membership database.

To create the ASP.NET membership database

  1. On the spdb server, open Windows Explorer.

  2. Navigate to the path %System Drive%\Windows\Microsoft.NET\Framework\v2.0.50727.

  3. To start the ASP.NET SQL Server Setup Wizard, double-click aspnet_regsql.exe.

  4. Start the wizard by clicking Next, and then complete the wizard as shown in Figures 5–9.

    Figure 5. ASP.NET SQL Server Setup Wizard

    ASP.NET SQL Server Setup Wizard

  5. Click Configure SQL Server for application services, and then click Next.

    Figure 6. Select a Setup Option page

    Select a Setup Option page

  6. In the Server box, type spdb for the database name, and then click Next.

    Figure 7. Select the Server and Database page

    Select the Server and Database page

  7. Confirm that the data you typed is correct, and then click Next.

    Figure 8. Confirm Your Settings page

    Confirm Your Settings page

  8. The database is created and the final status information is displayed. Click Finish to complete the wizard.

    Figure 9. ASP.NET SQL Server Setup Wizard completion status

    ASP.NET SQL Server Setup Wizard completion status

To perform actual tasks such as creating users and groups and managing passwords, you need a tool to manage that information. Unfortunately, few existing tools are available to help you. The membership and role provider APIs are fairly rich, however, and you can create both Web-based and Windows-based tools for this task.

For this article, we wrote a tool named MembershipSeeder that demonstrates how to use these APIs in a Windows-based application. The tool and source code are available on CodePlex from the Forms Based Authentication (FBA)page. You can use the MembershipSeeder tool as is for simple user and role management, or you can use the source code as a base on which to create your own tool; however, Microsoft does not provide support for this tool.

To run the MembershipSeeder tool

  1. Start the MembershipSeeder tool.

  2. Click Configure.

  3. In the dialog box that opens, type the name of the computer running SQL Server that hosts your SQL membership database.

  4. Save your changes, and then restart MembershipSeeder so that it will use the new server name.

To create users for testing purposes

  1. In the User Prefix field, type a value.

  2. In the Password field, type the password you want each user to have.

  3. In the # of Users field, select the number of users to create.

  4. Click Create to create users where the user name is the value of the User Prefix field with an incrementing number added to the end.

    For example, if the User Prefix field is user and # of Users is 2, two users are created and named user1 and user2. To add only a single user and not add the numeric value to the end of the user name, select Only create or delete 1 user; don't use the # of Users field check box. Deleting users works similarly to creating users.

    Figure 10. Create users

    Create users

  5. To open a dialog box with a list of all roles that the tool is aware of, click Get Roles, as a shown in Figure 11.

    Figure 11. Get Roles

    Get Roles

  6. To add a new role, type a name for the role in the Role field, and then click Create.

  7. To add users to a role, type the role name in the Role field.

You can add multiple test users to the role and then provide the user credentials with the User Prefix and # of Users fields, just as you created users. The Start Num field is designed to let you add a subset of those users. For example, suppose you created user1 through user50. You created a role named Authors, and you want to add users 5 through 15 to that role. To do this, you type Authors in the Role field, set # of Users to 10 and set Start Num at 5. When you click Add to Role, the users are added to the Authors role.

Also, similar to the process for creating and deleting users, if you want to add only a single user to a role and not a group of users, select the Only add 1 user; don't use the # of Users field check box.

To see all of the users in a role, type the role name in the Role field, and then click Get Users. This displays a dialog box that contains all the users found in that role, as shown in Figure 12.

Figure 12. Get users for role

Get users for role

By default, the MembershipSeeder tool is configured to use the SQL membership and role provider. However, you can manually edit the MembershipSeeder.exe.config file to change providers. As long as the provider implements the interfaces for managing users and groups that the tool uses, you can easily change providers in the .config file and continue to use the tool. If you are using the SQL membership and role provider, there is also another tool available on CodePlex that is useful for some of these account management tasks. You can read about it on the Microsoft SharePoint Products and Technologies Team Blog. For a description of the tool that can be used to add, edit, and delete users, see the Features for Administration section.

Now that you know the basics of working with the tool, we create the users and groups to use to test the forms authentication implementation.

To create a batch of users for testing purposes

  1. Create a batch of 20 users: user1 through user20.

  2. Create two roles: Admins and Readers.

  3. Add user1 through user3 to the Admins role.

  4. Add user1 through user20 to the Readers role.

Configuring web.config Files

At this point, we have two zones mapped to the Web application, and both are configured to use Windows authentication. The database to store users and roles is created, and it is populated with some sample data to test the forms authentication implementation. The next step is to configure the web.config file for several of the Web applications in the farm to support the forms authentication membership and role providers.

To configure the web.config file for the new zone

  1. Find the correct web.config file.

    When the Web application was extended into the new zone, a directory was created on the SharePoint server that contains files it uses, including web.config. By default, that directory is located in the path %SystemDrive%\Inetpub\wwwroot\wss\VirtualDirectories\zone name. So in our current example, the directory is located at C:\Inetpub\wwwroot\wss\VirtualDirectories\www.contoso.com80.

  2. Open Windows Explorer and navigate to the directory that contains the web.config file for the new zone.

  3. Open the file in a text editor such as Notepad. We need to make four entries: a PeoplePicker wildcard, a connection string, a membership provider, and a role provider.

    The entry for the PeoplePicker wildcard tells the PeoplePicker component in Office SharePoint Server or Windows SharePoint Services the character to use to do a wildcard search for an individual user. For the SQL membership provider, it supports the percent sign (%) as a wildcard character.

  4. In your text editor, search for the string "PeoplePickerWildcards". That should take you to a section of the web.config file that looks like the following code.

    <PeoplePickerWildcards>
      <clear />
      <add key="AspNetSqlMembershipProvider" value="%" />
    </PeoplePickerWildcards>
    

To simplify the example in this article and prevent interference with any of the built-in settings, we will name our membership provider fbaMembers and our role provider fbaRoles. To associate the wildcard search character with our membership provider, we use the fbaMembers name when adding the add subelement to the PeoplePickerWildcards element. After it is added, the PeoplePickerWildcards element looks like the following code.

<PeoplePickerWildcards>
  <clear />
  <add key="AspNetSqlMembershipProvider" value="%" />
  <add key="fbaMembers" value="%" />
</PeoplePickerWildcards>

In the connectionString element, you define the connection string that the membership and role providers use to connect to their data store. The connectionStrings element does not exist by default when you extend a Web application. You need to create it, and then create the individual connectionString element under it.

The connectionStrings element can go directly above the system.web element in the web.config file.

To define the connection string

  1. In your text editor, search for the string "<system.web>", which takes you to the opening tag for the system.web element.

  2. Directly above this tag, add an empty connectionStrings element, which looks like the following code.

    <connectionStrings>
    </connectionStrings>
    
  3. Add a subelement add that has a name attribute, which is the name for the connection string, and a value attribute, which is the actual connection string. In this example, we assume that the default Windows authentication is being used on a computer running SQL Server. The database name is spdb, so after the connection string is added, the entire connectionStrings element looks like the following code.

    <connectionStrings>
      <add name="fbaSQL" 
      connectionString="server=spdb;database=aspnetdb;Trusted_Connection=true" />
    </connectionStrings>
    

    Note

    The application pool account or accounts for any Web applications that use this provider must have at least Read rights to all of the objects in the aspnetdb database specified in the connection string.

The membership and role provider information, which you can add at the same time, must be a subelement to the system.web element. The membership and role provider elements resemble the following code. Important attributes are described following the example.

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

Important Attributes for the Providers

Following are descriptions of the important attributes for providers, shown in the previous code example.

  • defaultProvider   In the Membership and roleManager elements, this is the name of the provider to use by default for this Web application. The name you provide here should be the same as the name attribute for the provider.

  • connectionStringName   In the providers subelement for an individual membership or role provider, this is the name of the connectionString element that contains the connection string the provider uses to communicate with the data store.

  • name   In the providers subelement for an individual membership or role provider, this is the name that is used to refer to the provider. It is used in the defaultProvider attribute, and in the SharePoint Central Administration Web site on the Policy configuration page.

  • type   In the providers subelement for an individual membership or role provider, this describes the Microsoft .NET Framework class type and strong name that implements the membership or role provider. The previous examples include the type for the ASP.NET SQL membership and role provider; if you were using a different provider, you would enter the type name for it in this attribute.

This completes the configuration changes needed for the new zone's web.config file. Changes to the other web.config files are almost identical to these changes; however, other web.config files may have some of the parent elements already present, such as the connectionStrings element.

Configure Central Administration and Existing Windows Authentication Web Application web.config Files

For the Central Administration and existing Windows authentication Web application web.config files, you make the same changes as described previously for the forms authentication zone's web.config file—with one exception. In the defaultProvider attribute for the roleManager element, the name should be AspNetWindowsTokenRoleProvider instead of fbaRoles. It looks like the following code example.

<roleManager enabled="true" defaultProvider="AspNetWindowsTokenRoleProvider"> 

The reason the default provider is different from the forms authentication zone is that the default role information for these Web applications is provided by Windows. That is important for Office SharePoint Server 2007 and Windows SharePoint Services to know when trying to determine what groups an individual user belongs to. The default membership provider does not need to be changed in the same way because authentication is managed by IIS; SharePoint Products and Technologies recognize that the site is using Windows authentication.

Note

If you have multiple front-end Web servers, you must make these changes to the web.config files on each server.

Configuring the Zone’s Provider

You must configure the zone's Provider information to use forms authentication with the membership and role provider that was added to the web.config files.

To configure the zone's provider

  1. Open your browser and navigate to the Central Administration Web site.

  2. Click the Application Management tab.

  3. Click Authentication providers.

  4. Ensure that the correct Web application is selected; it is displayed in the upper-right corner of the page. If the correct Web application is not shown, click the Web application drop-down list to select the correct one. With the correct Web application displayed, click the authentication type link that is displayed next to the Extranet zone. By default, the link text is Windows, as shown in Figure 13.

    Figure 13. Authentication Providers list

    Authentication Providers list

  5. In the Authentication Type section, click Forms. The page updates and displays Membership provider name and Role manager name boxes.

  6. Type the appropriate values in the Membership and Role boxes. Based on the current scenario, the page should look like Figure 14.

    Figure 14. Configure forms authentication Provider

    Configure forms authentication Provider

  7. Click Save to commit your changes. The browser returns to the Authentication Providers main page, which should now display the new authentication provider name next to the Extranet zone, as shown in Figure 15.

    Figure 15. Updated Authentication Providers list

    Updated Authentication Providers list

The final configuration step is to grant the appropriate policy for forms authentication users.

Granting the Appropriate Policy

Policies provide a mechanism to grant or deny rights to all site collections and subsites in a Web application, and override any permission settings that are applied on individual items or sites in that Web application. In this scenario, rights are granted to at least one forms authentication user. This policy allows the user to log on to the site, and then enables the user to add other forms authentication users and roles to SharePoint groups so that the rest of the forms authentication users can access the site.

In the specific scenario used in this article, this step is not necessary because we configured the Windows-secured Web application so that we can add and remove forms authentication users and roles and Windows users and roles from the same Web application. However, you might encounter situations in which a Windows-secured Web application is not being used. In that case, a policy is the only way to grant rights to a user.

For this scenario we grant a Full Rights policy to user1. That user can then log on to the site and provision other forms authentication users and roles into SharePoint groups.

To create the Full Rights policy

  1. Open your browser and navigate to the Central Administration Web site.

  2. Click the Application Management tab, and then click Policy for Web application.

  3. Ensure that the correct Web application is selected; it is displayed in the upper-right corner. Click Add Users.

  4. In the Zones list, click the Extranet zone.

    Important

    This step is critical! If you select the wrong zone, you cannot correctly grant the policy rights.

  5. On the Add Users page, click the address book icon to open the People Picker dialog box, as shown in Figure 16.

    Figure 16. Add Users page

    Add Users

  6. In the People Picker dialog box, type user1 in the Find box, and then click the search button.

    If you created 20 users, as described earlier in this article, 11 results should be returned: user1 through user19. If so, the configuration you created in the web.config file is correct. If not, there is a problem in the web.config files, which you must correct.

    You should also notice that the account name is displayed in the format that SharePoint uses internally to keep track of it: MembershipProviderName:accountName. In this scenario, that means the account name for user1 is fbaMembers:user1.

  7. Double-click user1 to add it to the Add box, and then click OK.

  8. Select Full Control, as shown in Figure 17.

    Figure 17. Choose permissions on Add Users page

    Choose permissions on Add Users page

  9. Click Finish to save your changes.

The basic configuration is now complete; user1 should be able to log on to the site at www.contoso.com. Both forms authentication and Windows users and roles can be added from either Web site.

Granting Permissions to Create My Sites

When you log on to a site by using forms authentication, you may notice that by default, a My Site link does not appear in the upper-right corner of the page, as it does with sites secured with Windows authentication. In Windows authentication, by default the configuration for My Sites is a special group named NT AUTHORITY\authenticated users, who are granted rights to create My Sites. By default, each authenticated Windows user is granted the appropriate permissions to create a My Site. When you access a site as a forms authentication user, however, you do not have an associated Windows credential. Therefore, to Office SharePoint Server or Windows SharePoint Services, you are not a member of that Windows group so you do not have rights to create a My Site. As a result, the menu does not appear.

The process to grant forms authentication users the appropriate permissions to create My Sites is very similar to what you do to extend an existing Windows authentication site with forms authentication. For those steps, refer to the details provided in the section Setting Up Forms Authentication earlier in this article.

To enable forms authentication users to create My Sites

  1. Extend the Shared Services Provider (SSP) Web application into a new zone.

    For consistency, the zone you extend the SSP Web application into should be the same zone into which the forms authentication was extended, but this is not required unless the My Sites are hosted in the same Web application as the SSP. In the scenario described earlier in this article, forms authentication was used in the Extranet zone. In this example, it is extended into the Extranet zone also.

  2. Modify the web.config file for the new zone to use the same forms authentication membership and role providers.

  3. Modify the web.config file for the default SSP zone to use the same forms authentication membership and role providers. Because it is a Windows authentication site, remember to change the default role provider to AspNetWindowsTokenRoleProvider.

  4. Use the Authentication Provider administration page to configure the new zone to use forms authentication.

After you complete these steps, you can change the permissions in the My Sites section to allow forms authentication users to create My Sites.

To configure the permissions

  1. Open your browser and navigate to the SSP Web site.

  2. Click Personalization services permissions.

  3. Click Add Users/Groups.

  4. Click the address book button to open the People Picker dialog box.

  5. You can use the picker to grant either individual users or roles the right to create My Sites. Assuming you created and populated the Readers role as described earlier in this document, type Readers in the Find box, and then click the search button. Search should find a group named Readers that has an account name of fbaRoles:Readers.

  6. Double-click the Readers group in the search results pane. Selecting this group gives all members of the Readers role the right to create My Sites.

  7. Click OK to close the People Picker dialog box.

  8. Select the Create personal site check box and the Use personal features check box. The completed page should look like Figure 18.

    Figure 18. Configure permissions to create My Sites

    Configure permissions to create My Sites

  9. Click Save to save your changes.

All members of the Readers role now have the rights to create My Sites, and the My Site menu link appears in the upper-right corner of the page for them also.

Before forms authentication users can actually create a My Site, you must perform one additional step. To create a My Site, or view the public details of other users, you must grant rights to the My Site host site to all forms authentication users who will use My Sites.

When a user clicks the My Site link, he or she is directed to the /_layouts/MySite.aspx page in the My Site host application. That page determines whether the user already has a My Site created. If so, the user is automatically redirected to his or her site. If not, the My Site is created for the user and then the user is redirected to it. But to be able to navigate to the MySite.aspx page, a My Site user must have, at a minimum, Read rights on that site. Using the example from this article, someone with administrative rights on the My Site host site must add the Readers role to a SharePoint site group that has, at a minimum, Read rights on the site. After that is completed, forms authentication users can create My Sites.

Hosting My Sites in a Separate Web Application

If My Sites are hosted in the same Web application that was already extended for forms authentication users, no further action is needed. However, if you host your My Sites in a separate Web application, you must also extend it as described previously.

To host My Sites in a separate Web application

  1. Extend the My Site Web application into a new zone. The zone you extend it into MUST BE the same zone into which the forms authentication zone was extended. For the My Sites to display the correct URL for both Windows users and forms authentication users, you must also extend the Web application into the same zone; in this scenario, it is the Extranet zone.

  2. Modify the web.config file for the new zone to use the same forms authentication membership and role providers.

  3. Modify the web.config file for the existing My Site zone to use the same forms authentication membership and role providers. If it is a Windows authentication site, remember to change the default role provider to AspNetWindowsTokenRoleProvider.

  4. Use the Authentication Provider administration page to configure the new zone to use forms authentication.

From a configuration standpoint, you must consider one other aspect when configuring options for My Sites. If you intend to host multiple authentication membership providers and allow all of them to create My Sites, there could potentially be name collision issues. For example, if both membership providers had user accounts with the name user1, there would be a conflict when the second user1 tried to create a My Site because a site collection named user1 would already exist. In that scenario, you can configure the naming used when creating My Sites to include the provider name in addition to the account name.

To configure My Sites to be created with a name in the format of provider_accountName

  1. Open your browser and navigate to the SSP Web site.

  2. Click My Site settings.

  3. In the Site Naming Format section, click Domain and user name.

    If you select the first or second option, all sites for forms authentication users are created with the user name only.

  4. Click OK to save your changes.

There is one final point to make here. If your My Sites are hosted in a separate Web application, when forms authentication users click the My Site link, they are taken to the forms logon page again, even if they have already authenticated to their main corporate content site (in our example, https://www.contoso.com). The reason is that the authentication cookie that is generated when a user logs on to a forms authentication site is associated with the domain name. Domain name, in this case, refers to the URL namespace, not an Active Directory domain.

For example, if your corporate content is hosted on a site at domain www.contoso.com, and My Sites are hosted on a site at domain mysites.contoso.com, the content requires two different authentication cookies. The user experience may seem strange at first, because most users think of all the content as just "one Web site." It may cause some confusion when the forms logon page is shown again just from clicking a link in the main corporate content site.

However, by following the steps described earlier in this article, both Windows and forms authentication users should be able to create and use My Sites.

Provider-Specific Features

Providers may have differing characteristics that can impact how you design your solution and implementation. This section describes some of the features of individual providers that you should be aware of when planning your farm.

LDAP Provider

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 is used with many LDAP directories, although most of the examples that are available currently demonstrate 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 used frequently in extranet scenarios. Following is one example of a membership and role provider configuration section for the web.config file that connects to each.

Configuration Example for Novell eDirectory

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

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="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, 
    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>

Configuration Example for OpenLDAP

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

LDAP Membership and Role Provider Usage Constraints

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

  • Trusted forests If you use the LDAP provider with Active Directory, there are scenarios (such as in an extranet) in which trusted forests might be in use. When a site is configured to use Windows authentication, users from either forest can 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 multiple forests, you should extend SharePoint Products and Technologies into an additional zone for each forest that is 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.

  • 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 the user's primary group is changed, no user is returned in the membership of that role. For more information, see the primaryGroupID attribute in User Security Attributes.

  • 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). If you require support for authenticated binds to your LDAP server and want to use the LDAP provider in Office SharePoint Server 2007, you must first apply Office SharePoint Server 2007 SP1.

With Office SharePoint Server SP1, the Membership element and Role provider element in the web.config file support two additional attributes: connectionUsername and connectionPassword. If you provide values for these attributes, the provider attempts 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.

<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" 
/>

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 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. For more information about encrypting by using RSA, see How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA.

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. You can encrypt the sections 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.

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"

In this scenario, the virtual directory for the SharePoint Web application whose web.config sections are being 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 example (only the membership section is shown here).

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>

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, you can decrypt them by using the same utility. Following is an example of removing encryption from the membership section through the command line.

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

Active Directory Membership Provider

The Active Directory provider is designed to let you use forms authentication to capture the credentials of a Windows identity and validate them against Active Directory. However, that does not mean that it provides all of the same Windows functionality and features that are available to a Windows user who is logging onto a Windows desktop. Some of the distinctive differences for the Active Directory Membership provider include:

  • Cannot validate credentials from other domains.  The provider can only validate credentials for the domain (and optionally a container within the domain) against which the provider is configured to work.  The underlying reason is that the provider connects to Active Directory by using an authenticated LDAP bind, and then also validates that the user object exists within the container scope defined by the connection string.  As a result you cannot type in credentials for a user in another domain in the forest. If you use this provider, all user accounts must exist in the same domain.

  • The provider has no way to prompt a user to renew his or her password prior to expiration.  The provider can only validate credentials and tell whether a user account is locked out.

This concludes part 1 of this article series.

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

Additional Resources

For more information about forms authentication, see the following additional resources: