Site Directory in SharePoint Server 2010 [Updated 5/12/2010]

SharePoint Portal Server 2003 and Office SharePoint Server 2007 provided a Site Directory that was commonly used to “catalog” the collection of sites within a server farm environment, most commonly, organizations used categories to isolate like or related site collections and the built-in provisioning callback to ensure site collections were listed in the Site Directory on creation.

In SharePoint Server 2010 the Site Directory has been deprecated, meaning that on new installations of SharePoint Server 2010 you cannot create and have a functional Site Directory; however, the Web Template and configuration options associated with the Site Directory have been retained, though strictly for backwards compatibility support.

While deprecated in SharePoint Server 2010 there are several options available to administrators seeking to provide similar functionality:

  • If an organization has implemented the Site Directory in Office SharePoint Server 2007, on upgrade it will be retained as a fully functional Site Directory in SharePoint Server 2010 with new added benefits such as new multi-lingual support.
  • If an organization does not have a Site Directory to upgrade similar functionality can be achieved through:
    • Implementing Tagging, Notes, etc. to provide the sorting and search functionality associated with the Site Directory.
    • Implement the Links Web Part to provide a simple listing of site collections in the server farm environment.
    • Implement an SPFeature that places a Managed Metadata field within the site creation user interface and leverage a specific Term Set that can be used for classification purposes to provide the “categorical” functionally of the Site Directory in Office SharePoint Server 2007.  For additional information on the SPFeature Class see also http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spfeature(v=office.14).aspx.

Alternative Solutions

If you are seeking an alternative solution that requires minimal development effort to provide the capabilities offered by the Site Directory in Office SharePoint Server 2007, see also http://spsitedirectory2010.codeplex.com/ which provides a set of downloadable solutions to replicate the capabilities of the Site Directory.

Service Connection Points and Governance with SharePoint Server 2010

Keeping the trend going this week we’ll look at Active Directory Markers in SharePoint Server 2010. 

Governance is one of the key planning processes that should occur when considering the deployment of any technology, and SharePoint Server 2010 provides a number of tools and resources to facilitate the product and technology aspects of governance, one of which is the concept of Active Directory Markers to manage and control the uncontrolled proliferation of SharePoint in the Enterprise.

SharePoint Server 2010 uses the Service Connection Point Active Directory Schema (serviceConnectionPoint (SCP))) in order to publish service-specific data in the directory.  Administrators can use the data in a Service Connection Point to locate, connect to, and authenticate and instance of the service.

In order to use this new capability you must first create a container under CN=System,DC=<domain>,DC=com, where the values will reside and provide write access to the specific accounts that will write values to the container – in most cases the person or system account used to deploy SharePoint in your environment.

Configure Active Directory

  1. On a Domain Controller open ADSI Edit (ADSIEDIT.MSC).
  2. Right-click the ADSI Edit node and select Connect to…
    1. On the Connection Settings dialog under Select a well-known Naming Context select Default Naming Context and click OK.
  3. Select the Default naming context node and expand the domain.
  4. Locate and right-click CN=System and select New | Object…
    1. On the Create Object dialog under Select a class… select container and click Next.
    2. In the Value: field enter Microsoft SharePoint Products and click Next.
    3. On the Create Object dialog click Finish.
  5. Right click on the new container (Microsoft SharePoint Products) and select Properties.
    1. On the CN=Microsoft SharePoint Products Properties dialog select the Security tab.
    2. Click Add… and select the individual or service account that will have write permissions to the container on the Select Users, Computers, Service Accounts, or Groups dialog and click OK.
    3. On the CN=Microsoft SharePoint Products Properties dialog under Permissions for <account> select the checkbox labeled Write under Allow and click OK.

Deployment and Validation

When SharePoint Server 2010 is deployed a Service Connection Point object is created as a GUID under the container created in the previous steps.

  1. Locate and right-click the GUID and then select Properties.

The deployed server farm’s Topologies Web Service is created with the value presented as :/Topology/topology.svc">http://<server>:<port>/Topology/topology.svc.

For additional information on Connection Points and Active Directory see also http://msdn.microsoft.com/en-us/library/ms675738(v=VS.85).aspx.

HTTP Request Monitoring and Throttling

Last week I covered Managed Accounts in SharePoint Server 2010, this week we’ll cover HTTP Request Monitoring and Throttling – I’ve been following a lot of conversions surrounding Resource Throttling in SharePoint Server 2010, of which most have focused on the core scenario involving managing large lists; however, there have been a few discussions on HTTP Request Monitoring and Throttling and how that ties in an organizations security architecture or how it can be used to augment it, particularly how it relates to Distributed-Denial of Service (DDoS) attacks.  DDoS attacks are similar in purpose to DoS attacks with the key differentiating characteristic being DDoS attacks involve multiple machines which send repeated requests to a server to load it down and render it inaccessible.

Overview

HTTP Request Monitoring and Throttling is a new feature in SharePoint 2010 that can be used to control resource utilization within your server farm on one or more servers.  HTTP Request Monitoring and Throttling helps prevent a server from running out of resources used to serve existing jobs and high priority user requests such as PUT/POST and is configured on a per-Web application basis.  HTTP Request Monitoring and Throttling monitors a set of performance counters on a server with predefined thresholds shipped out of the box and begins request throttling GET requests when the server is under load exceeding the configured thresholds.

SharePoint 2010 ships with the following HTTP Request Monitoring and Throttling defaults:

Performance Counter Min Max
Processor% Processor Time 0 99
MemoryAvailable Mbytes 20 3.402823E+38
ASP.NETRequests Queued 0 500
ASP.NETRequest Wait Time 0 30000

Performance counters are read every 5 seconds; however, you can configure the interval through Windows PowerShell or the Object Model (see below).  A server enters a throttled state after 3 successive checks have failed, each successive check results in a state.  Initially in 2 warning states, followed by the throttled the state in which the duration is a minimum of 5 seconds.  A server remains in the throttled state until a successful interval has been completed.

So while HTTP Request Monitoring and Throttling is a key capability that can be used to control resource utilization within your server farm and facilitates an optimal user experience it is important to understand that throttling is not designed to provide a barrier against DDoS attacks since throttling occurs only after authentication, and once a request passes authentication, it is always trusted.

To be more precise, throttling is invoked as requests (HTTP) leave the ASP.NET Request Queue and prior to the thread being constructed to manage the request.  So as a request leaves the request queue we call a method which retrieves the state of one or more servers in the topology, and returns a value that corresponds to the “load” of the server – the requests that fall below the priority of the monitor are rejected, with each core scenario handling the request uniquely.

As mentioned above, each core scenario in SharePoint prompts a unique response when the request queue is loaded, for example, for incoming HTTP requests – a throttled state will result in the user begin presented with a 503 Server is Busy (HTTP requests are not queued, the user will need to refresh their page request when in a throttled state).

Scenarios respond differently to a throttled state, with Timer Jobs – throttling occurs in response to the server busy status.  Timer Jobs that have been executed prior to the server entering a throttled state will continue to be executed through their completion; however, any new resource consuming Timer Jobs will not be executed while the server is in a throttled state.

Search is the last common scenario when we think about the interaction between users and SharePoint.  Search will compete with incoming HTTP requests for resource time; however, is placed in a lower priority queue.  Search is typically more demanding an operation than a simple HTTP request so throttling in this scenario occurs depending the state of the request queue.

To understand the request type, SharePoint uses the UserAgent field in the HTTP Header and classifies the request as robot HTTP, user HTTP, Office client application, SOAP robot, or SOAP user.

Configuring HTTP Request Monitoring and Throttling

Enable/Disable HTTP Request Monitoring and Throttling (Windows PowerShell)

HTTP Request Monitoring and Throttling can be enabled or disabled through Windows PowerShell.  The example below illustrates in Windows PowerShell how to disable HTTP Request Monitoring and Throttling, optionally, you could use $True to enable HTTP Request Monitoring and Throttling.

$uri=new-object System.Uri("http://www.contoso.com")
$webApp=[Microsoft.SharePoint.Administration.SPWebApplication]::Lookup($uri)
$httpThrottleSettings=$webApp.HttpThrottleSettings
$httpThrottleSettings.PerformThrottle=$False
$httpThrottleSettings.Update()

Enable Disable HTTP Request Monitoring and Throttling (Central Administration)

In addition to Windows PowerShell, HTTP Request Monitoring and Throttling can be enabled and disabled through Central Administration.

  1. In SharePoint 2010 Central Administration click Web application management under Application Manage.
  2. Select the Web application to configure from the list of available Web applications on the Web Applications Management Page.
    1. On the Ribbon select Resource Throttling under General Settings.
    2. On the Resource Throttling page click On under HTTP Request Monitoring and Throttling.
    3. Click OK to save your changes.

Edit a HTTP Request Monitoring and Throttling Threshold (Windows PowerShell)

Thresholds, either out of the both or user created can be configured through Windows PowerShell.  In this example, the CPU utilization threshold is decreased to 75%.

NOTE

Thresholds cannot be configured through Central Administration.

$uri=new-object System.Uri("http://www.contoso.com")
$webApp=[Microsoft.SharePoint.Administration.SPWebApplication]::Lookup($uri)
$httpThrottleSettings=$webApp.HttpThrottleSettings
$cpu=$httpThrottleSettings.PerformanceMonitors[0]
$cpu.MaxValue=75
$httpThrottleSettings.Update()

The following example illustrates how the same can be acheived as the above example using the built-in Set-SPWebApplicationHttpThrottlingMonitor.

Set-SPWebApplicationHttpThrottlingMonitor -Identity http://www.contoso.com -Category "Processor" -Counter "%
Processor Time" -Instance "_Total" -MaxThreshold 75 -MinThreshold 0

HTTP Request Monitoring and Throttling can be enabled through either Windows PowerShell, Central Administration, or the Object Model; however, to configure existing counters or extend the scope of HTTP Request Monitoring and Throttling you must use Windows PowerShell or the Object Model (see more below).

Windows PowerShell or the Object Model can be used to configure:

Refresh Interval

The Refresh Interval specifies the amount of time between successive counter samples.

Performance Monitors

Performance Monitors specify the counters associated with HTTP Request Monitoring and Throttling when the server is under load.  For example Process% Processor Time.

PerfomThrottle

PerformThrottle specifies the boolean value to enable or disable HTTP Request Monitoring and Throttling.  (See above for Windows PowerShell and Central Administration configuration points.)

ThrottleClassifiers

ThrottleClassifiers specifies the set of rules that classify requests, for example, a classifier to throttle PUT requests and a separate classifier to never throttle POST requests.

Add a new HTTP Request Monitoring and Throttling Counter

Adding a new HTTP Request Monitoring and Throttling counter with Windows PowerShell is a process similar to editing an HTTP Request Monitoring and Throttling threshold as shown in the steps above.

In this example we’ll add a new counter that configures a new counter for PhysicalDisk% Disk Time.

$uri = new-object System.Uri("http://www.contoso.com")
$webApp=[Microsoft.SharePoint.Administration.SPWebApplication]::Lookup($uri)
$httpThrottleSettings=$webApp.HttpThrottleSettings
$httpThrottleSettings.AddPerformanceMonitor("PhysicalDisk", "% Disk Time", "_Total", 80, 0)
$httpThrottleSettings.Update()

Extending Core Capabilities and Coverage

Both extending and configuring HTTP Request Monitoring and Throttling in most cases is a simple task, throttling counters can be added through Windows PowerShell as shown above or you can use the Object Model for more complex scenarios.  Since HTTP Request Monitoring and Throttling is also extensible that means you can develop a scenario-focused system for monitoring Windows Server 2008 performance counters and for throttling HTTP requests when those counters indicated that a worker process is too busy to handle all the requests that it is receiving.  The majority of classes you’ll need to begin developing your own system are contained within the Microsoft.SharePoint.Utilities namespace, you’ll find more documentation on this namespace and the classes it contains here http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.utilities(office.14).aspx.

Troubleshooting

With HTTP Request Monitoring and Throttling, it is important to understand what occurred that caused the server to enter a throttled state to prevent future occurrences or adjust the throttling levels.  When a performance monitor exceeds its value, and a throttled state is entered, SharePoint collects a variety of diagnostic information to determine why a particular value was exceeded – this information can include reporting throttled requests to include corresponding SQL requests, etc.

The most common locations you’ll find diagnostic information related to HTTP Request Monitoring and Throttling are the server Application Event Logs and the ULS logs.

To view the collection of counters and their corresponding values you can use the Get-SPWebApplicationHttpThrottlingMonitors CmdLet, and conversely to configure counters you can use the Set-SPWebApplicationHttpThrottlingMonitors CmdLet.

For additional information on the Get- and Set-SPWebApplicationHttpThrottlingMonitors run Get-Help Get- or Set-SPWebApplicationHttpThrottlingMonitors in the SharePoint 2010 Management Shell.

Claims-Based Identity in SharePoint 2010 [Updated]

Claims-based identity or Claims Mode Authentication in Microsoft SharePoint Server 2010 has been all the buzz.  Developers are looking to do more with augmentation of claims and IT Professionals are looking at new opportunities to delegate identities – whether across machine  or trust boundaries, or to provide seamless and secure solutions enabling robust interoperability scenarios with external systems.  Understanding claims-based identity is the first step in realizing its potential and to understand it, we need to understand the basic concepts and nomenclature.

Basic Definitions

Identities

Identities are basically pieces of information about a person or an object, for example a user.  Identity is commonly encapsulated within a token, in a claims-based identity scenario, that token carries one or more “claims” about that user.

Claims

A “claim” if effectively an assertion made about an object by a trusted system.  These “claims” such as date of birth or given name as an example, are included in a token in addition to a digital signature that validates the issuer and prevents tampering.

Issuer

The issuer is the STS or Security Token Service, the STS gathers its information from an attribute store that contains the information about the user.  The attribute store can be Active Directory, Windows Live Id, etc.

There are many more definitions beyond these that you should be aware of, most of which can be found in the Additional Resources at the bottom of this post.  The definitions above will get you through the basic walkthrough that follows.

Identity and authentication are topics far too broad to cover in a single post, the best way to learn more is to 1) experiment with Claims Mode Authentication in Microsoft SharePoint Server 2010 (see walkthrough below) 2) read more on Claims Mode Authentication and claims-based identity (see Additional Resources at the bottom of this post).

Step-by-step Walkthrough

This step-by-step walkthrough is intended for those looking to understand both Claim/Forms-based Authentication in Microsoft SharePoint Server 2010.  The following assumptions are made in this walkthrough:

  • You have Domain Controller with the Domain Root:  contoso.com with user objects in the Users container.

NOTES

If your Active Directory Domain Services configuration differs from that used in this walkthrough you will need to edit the server and userContainer attributes for the role provider and the server and groupContainer attributes for the membership provider for your configuration.

This walkthrough uses the LDAP membership and role provider that ships with Microsoft SharePoint Server 2010 and uses Active Directory Domain Services as the authorative source for users and groups.

Create a new Web Application using Claims-based Authentication

In this step you will create a new Web application using the Uri http://claims.contoso.com using Claims-based Authentication.

1. On the Central Administration Home page, in the Application Management section, click Manage web applications.

2. On the ribbon, click New.

3. On the Create New Web Application page, in the Authentication section, click Claims Based Authentication.

4. In the IIS Web Site section click Create a new IIS web site, and then type the name of the Web site in the Name box.

5. In the IIS Web Site section, in the Port box, type the port number you want to use to access the Web application.

6. In the IIS Web Site section, in the Host Header box, type the URL you want to use to access the Web application as claims.contoso.com. This is an optional field.

7. In the IIS Web Site section, in the Path box, type the path to the site directory on the server.

8. In the Security Configuration section, choose whether or not to use allow anonymous access and whether or not to use Secure Sockets Layer (SSL).

    a) Under Allow Anonymous, click No.

    b) Under Use Secure Sockets Layer (SSL), click Yes or No.

9. In the Identity Providers section, select Enable Windows Authentication, and in the drop-down menu select NTLM.

10. To enable forms-based authentication, select Enable ASP.NET Membership and Role Provider, and then enter the membership provider name and the role manager name in the boxes as LdapMembershipProvider and LdapRoleProvider respectively.

11. In the Sign In Page URL section, the Default Sign In Page URL is selected, which will redirect users to a default sign in Web site for claims-based authentication.

12. In the Public URL section, type http://claims.contoso.com as the URL for the domain name for all sites that users will access in this Web application.

13. In the Application Pool section, create a new application pool for this Web application.

      To create a new application pool, click Create a new application pool.

      a) In the Application pool name box, type Claims Application Pool as the name of the new application pool.

      b) Under Select a security account for this application pool, click Predefined, and then select the appropriate security account from the drop-down menu.

14. In the Database Name and Authentication section, choose the database server, database name, and authentication method (Windows authentication) for your new Web application.

15. In the Service Application Connections section, select the service application connections that will be available to the Web application. In the drop-down menu, click default.

16. In the Customer Experience Improvement Program section, click Yes or No.

17. Click OK to create the new Web application.

Configure Forms-based Authentication Support for Central Administration

In this step you will edit the Web.Config configuration file that corresponds with the Central Administration Web application to support Forms-based Authentication.

1. Click Start, All Programs, Accessories, and then click Windows Explorer.

2. Navigate to the root directory for the Central Administration Web application and open Web.Config in a text editor.

3. Copy the following Xml to the Clipboard.

  <membership>
    <providers>
      <add name="LdapMembershipProvider"
        type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
        server="contoso.com"
        port="389"
        useSSL="false"
        userDNAttribute="distinguishedName"
        userNameAttribute="sAMAccountName"
        userContainer="CN=Users,DC=contoso,DC=com"
        userObjectClass="person"
        userFilter="(ObjectClass=person)"
        scope="Subtree"
        otherRequiredUserAttributes="sn,givenname,cn" />
    </providers>
  </membership>
  <roleManager enabled="true" defaultProvider="AspNetWindowsTokenRoleProvider">
    <providers>
      <add name="LdapRoleProvider"
        type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
        server="contoso.com"
        port="389"
        useSSL="false"
        groupContainer="CN=Users,DC=contoso,DC=com"
        groupNameAttribute="cn"
        groupNameAlternateSearchAttribute="samAccountName"
        groupMemberAttribute="member"
        userNameAttribute="sAMAccountName"
        dnAttribute="distinguishedName"
        groupFilter="(ObjectClass=group)"
        userFilter="(ObjectClass=person)"
        scope="Subtree" />
    </providers>
  </roleManager>

4. Paste the contents from the Clipboard immediately following the <system.web> element.

5. Save and close the Web.Config configuration file.

Configure the Security Token Service for Forms-based Authentication

1. Click Start, and then click Control Panel and click System and Security, and then click Administrative Tools.

2. In the Administrative Tools window, double-click Internet Information Services (IIS) Manager.

3. In Internet Information Services (IIS) Manager expand the Server node, and then expand the Sites node.

4. Expand the SharePoint Web Services node and locate SecurityTokenServiceApplication, and then click Explore in the Action pane.

5. Scroll to the bottom of the Web.Config configuration file and locate the </system.net> element.

6. Copy the following Xml to the Clipboard.

  <membership>
    <providers>
      <add name="LdapMembershipProvider"
        type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
        server="contoso.com"
        port="389"
        useSSL="false"
        userDNAttribute="distinguishedName"
        userNameAttribute="sAMAccountName"
        userContainer="CN=Users,DC=contoso,DC=com"
        userObjectClass="person"
        userFilter="(ObjectClass=person)"
        scope="Subtree"
        otherRequiredUserAttributes="sn,givenname,cn" />
    </providers>
  </membership>
  <roleManager enabled="true">
    <providers>
      <add name="LdapRoleProvider"
        type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
        server="contoso.com"
        port="389"
        useSSL="false"
        groupContainer="CN=Users,DC=contoso,DC=com"
        groupNameAttribute="cn"
        groupNameAlternateSearchAttribute="samAccountName"
        groupMemberAttribute="member"
        userNameAttribute="sAMAccountName"
        dnAttribute="distinguishedName"
        groupFilter="(ObjectClass=group)"
        userFilter="(ObjectClass=person)"
        scope="Subtree" />
    </providers>
  </roleManager>

7. Paste the contents from the Clipboard immediately following the </system.net> element.

8. Save and close the Web.Config configuration file.

NOTE

In some scenarios the SharePoint Central Administration Web.Config may contain pre-existing <roleManager> and <membership> elements. Locate and remove these entries if they exist – they will commonly be located prior to the </system.web> element.

Configure the claims.contoso.com Web Application for Forms-based Authentication

1. Click Start, All Programs, Accessories, and then click Windows Explorer.

2. Navigate to the root directory for the Central Administration Web application and open Web.Config in a text editor.

3. Copy the following Xml to the Clipboard.

  <add name="LdapRoleProvider" 
    type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" 
    server="contoso.com" 
    port="389" 
    useSSL="false" 
    groupContainer="CN=Users,DC=contoso,DC=com" 
    groupNameAttribute="cn" 
    groupNameAlternateSearchAttribute="samAccountName" 
    groupMemberAttribute="member" 
    userNameAttribute="sAMAccountName" 
    dnAttribute="distinguishedName" 
    groupFilter="(ObjectClass=group)" 
    userFilter="(ObjectClass=person)" 
    scope="Subtree" />

4. Paste the contents from the Clipboard immediately following the

  <roleManager>
    <provider>

nodes.

5. Copy the following Xml to the Clipboard.

  <add name="LdapMembershipProvider" 
    type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" 
    server="contoso.com" 
    port="389" 
    useSSL="false" 
    userDNAttribute="distinguishedName" 
    userNameAttribute="sAMAccountName" 
    userContainer="CN=Users,DC=contoso,DC=com" 
    userObjectClass="person" 
    userFilter="(ObjectClass=person)" 
    scope="Subtree" 
    otherRequiredUserAttributes="sn,givenname,cn" />

6. Paste the contents from the Clipboard immediately following the

  <membership>
    <provider>

nodes.

7. Save and close the Web.Config configuration file.

Create a new User Policy

1. On the Central Administration Home page, in the Application Management section, click Manage web applications.

2. On the Web Applications Management page select the claims.contoso.com Web application.

3. On the ribbon, click User Policy.

4. On the Policy for Web Applications page click Add Users.

5. On the Add Users page select Default from the Zones drop down and click Next.

6. On the Add Users page click the Address Book icon and enter the account specifics in the Users field and press Enter (you will be presented with the new claims-based People Picker user interface shown in the screenshot below).

NOTE

Choose Full Control – Has full control. under Choose Permissions on the Add Users page.

Claims Picker

NOTE

You will be presented with two entries for each unique user representing the Active Directory and Ldap provider identities.

This completes the configuration, you can now browse to http://claims.contoso.com and will be presented with a logon page that prompts the user to select their identity provider (see illustration).

Multi-mode Login

Upgrade Notes

If you were using Forms-based Authentication or WebSSO in Office SharePoint Server 2007 you will need to convert those Web applications to Claims Mode Authentication in Microsoft SharePoint Server 2010.  The first step in this process is to update the Web.Config configuration files to reflect the values in Microsoft SharePoint Server 2010 keeping in mind that the membership and role provider names you used in Office SharePoint Server 2007 must be the same in Microsoft SharePoint Server 2010.

NOTE

For custom membership and role providers you will always call MembershipProvider.ValidateUser Method and all of the roles you call will become claims that are presented in the SAML token.

The next step in the process is to switch to Claims|Windows authentication.  This can be achieved through Windows PowerShell using the following example script:

$webApp = Get-SPWebApplication "http://claims.contoso.com/"
$webApp.UseClaimsAuthentication = $True;
$webApp.Update()
$webApp.ProvisionGlobally()

The final step in the process is to migrate users and permissions from the Office SharePoint Server 2007 naming conventions to the new Microsoft SharePoint Server 2010 naming conventions.  This can be achieved through Windows PowerShell using the following example script:

$webApp = Get-SPWebApplication "http://claims.contoso.com/"
$webApp.MigrateUsers($True)

Additional Resources

To learn more about the format of ASP.NET configuration files see also http://msdn.microsoft.com/en-us/library/ackhksh7(vs.71).aspx.

Read more on Claims-based Authentication in the Microsoft SharePoint Server 2010 IT Professional Evaluation Guide

Read the article Plan Authentication Methods (SharePoint Server 2010) on TechNet

Read the article Configure Forms-based Authentication for a Claims-based Web Application on TechNet (this article also provides some good upgrade material)

Read the article Configure the Security Token Service on TechNet

Read about SharePoint and Claims-based Identity on MSDN

Download and read A Guide to Claims-Based Identity and Access Control

Download and read Claims-Based Identity for Windows