MCTS Self-Paced Training Kit (Exam 70-667): Configuring Microsoft® SharePoint® 2010: Managing Web Applications

Lesson 2: Configure Authentication

SharePoint Server 2010 is a distributed application that is logically divided into three tiers: the front-end web server tier, the application server tier, and the back-end database tier. SharePoint can also interact with external systems—for example, by presenting data stored in an external database in a list. Each tier or system is a trusted subsystem, and authentication is required by default. Authentication is the process of verifying the identity of a user making a request to an application. The application must be assured that the user is authentic before the system performs authorization, which is the process of verifying that the user has permission to make the request, and personalization, which determines how the application interacts with the user.

SharePoint 2010 supports numerous methods by which users can be authenticated, including Windows authentication methods such as NTLM or Kerberos, forms-based authentication with methods that use LDAP directories or SQL databases as sources of user credentials and groups, and claims authentication using Security Assertion Markup Language (SAML) tokens. In this lesson, you will master the concepts and procedures related to authentication in SharePoint.

Configure Anonymous Access

Let’s start our exploration of authentication by detailing the processes by which you can configure anonymous access, so that users can access SharePoint content without validation of the users’ identities. Anonymous access is disabled by default, which provides an additional layer of security because IIS rejects anonymous access requests before they can ever be processed by SharePoint. To configure the level of access that anonymous users have to content, you must manage three settings:

• Anonymous authentication for the web application

• Permissions assigned to anonymous users for sites, lists, and libraries

• Anonymous access restriction policies for the web application’s zones

Enable Anonymous Authentication

You can enable anonymous authentication when you create a web application or after creating a web application. To enable anonymous authentication while creating a web application, simply click Yes for the Allow Anonymous setting on the Create New Web Application page, or, in Windows PowerShell, use the -AllowAnonymous switch parameter of the New-SPWebApplication cmdlet.

ENABLE OR DISABLE ANONYMOUS ACCESS ON AN EXISTING WEB APPLICATION

1. In the Central Administration Quick Launch, click Application Management.

2. In the Web Applications section, click Manage Web Applications.

3. On the Web Applications Management page, click the name of the web application for which you want to enable or disable anonymous access.

4. On the ribbon, click Authentication Providers.

5. On the Authentication Providers page, click the name of the zone for which you want to enable or disable anonymous access. For example, click Default.

   The Edit Authentication page opens.

6. On the Edit Authentication page, select or clear the Enable Anonymous Access check box, and then click Save.

When you enable anonymous access, SharePoint enables anonymous authentication for the IIS Web site.

When you install the Web Server IIS role, IIS creates the IUSR_computername account to authenticate anonymous users in response to a request for web content. The IUSR_computername account, where computername is the name of the server that is running IIS, gives the user access to resources anonymously under the context of the IUSR account.

Grant Permissions to Anonymous Users

Enabling anonymous access for a web application allows anonymous authentication, but it does not authorize anonymous users, in the context of the IUSR account, to access any content. Therefore, it is not enough simply to enable anonymous access for a web application—you must also grant permissions to anonymous users at the site level.

CONFIGURE ANONYMOUS ACCESS FOR A SITE

1. Click Site Actions, and then click Site Permissions.

   The Permissions page opens.

2. On the ribbon, click Anonymous Access.

   If you are not in the top-level site of a site collection, but rather are in a subsite, and if the top-level site does not allow anonymous access, you will not see the Anonymous Access button on the ribbon. This is because the subsite inherits the permissions from its parent site. Click Stop Inheriting Permissions to block inheritance, and then you can configure anonymous access permissions for the subsite.

   The Anonymous Access page opens.

3. In the Anonymous Users Can Access group, choose one of the following options:

   • Entire Web Site Anonymous users can view content on the entire Web site.

   • Lists And Libraries Anonymous users can view content in certain lists or libraries.

   • Nothing Anonymous users have no access to the site.

4. Click OK.

If you select the Lists And Libraries option, all lists and libraries do not allow anonymous access by default. You must therefore assign anonymous access permissions to specific lists and libraries.

CONFIGURE ANONYMOUS ACCESS TO A LIST OR LIBRARY

1. Navigate to a list or library for which you want to configure anonymous access.

2. On the ribbon, click the List or Library tab.

3. Click the List Permissions or Library Permissions button.

   The Permissions page opens.

4. Click Stop Inheriting Permissions.

5. Click Anonymous Access.

   The Anonymous Access page opens.

6. In the Anonymous Users Can list, select the check boxes for the permissions you want to assign to anonymous users.

   In a document library, anonymous users can, at most, view items. Anonymous users cannot be granted add, edit, or delete item permission.

7. Click OK.

As you’ve learned, anonymous access involves configuration at both the web application and site levels. You must enable anonymous authentication for the web application, which in turn enables anonymous authentication for the IIS Web site, and then you must specify what content anonymous users can access. You will learn more about configuring permissions and security on sites, lists, and libraries, including the concept of inheritance, in Chapter 4.

Anonymous Access Restrictions

Farm administrators can enforce permissions related to anonymous access across all sites in a web application by using anonymous access restrictions.

CONFIGURE ANONYMOUS ACCESS RESTRICTIONS

1. On the Web Applications Management page of Central Administration, select the web application that you want to configure.

2. On the ribbon, click Anonymous Policy.

   The Anonymous Access Restrictions page opens, as shown in Figure 3-7.

   

   Figure 3-7. Anonymous Access Restrictions

3. In the Zones list, select the zone to which the policy will apply.

   To apply to the policy to all access to the web application, select All Zones.

4. In the Permissions section, click one of the following options:

   • None No policy is defined. Anonymous access will be determined by permissions granted to sites, lists, and libraries.

   • Deny Write Anonymous users will be unable to modify content. This policy overrides access granted on content within the web application, effectively ensuring that if a site collection administrator has granted any permissions at all to anonymous users, the maximum level of access will be Read.

   • Deny All This policy overrides all permissions granted on content within a web application. Anonymous users will not have access.

5. Click Save.

The two policies that override site content permissions are primarily used in the following two scenarios:

• Temporarily Disable Access You want to prevent anonymous users temporarily from writing or accessing content, but you do not want to change permissions on content.

• Restrict Anonymous Access Through A Zone You want to restrict anonymous access using one zone, or URL, that is otherwise allowed using another zone. For example, if a web application can be accessed using HTTP using the URL http://partners.contoso.com, and can also be accessed using HTTPS with the URL https://partners.contoso.com, you might want to ensure that anonymous access is only possible using HTTPS. To do this, you must enable anonymous authentication for the web application; then grant permissions to anonymous users on sites, lists, or libraries in the web application; and then configure anonymous access restrictions to deny all access through the zone associated with the HTTP URL. You will learn more about zones in Lesson 3.

Understand Authentication Types

Authentication—verification of a user’s credentials—is performed by a software component called an authentication provider. Authentication providers support one or more authentication methods. For example, the integrated Windows authentication provider supports both the NTLM and the Negotiate (Kerberos or NTLM) methods. An authentication method defines the protocols and data sources by which the provider performs authentication. In Lesson 1, you learned that there are two types of authentication in SharePoint Server 2010:

• Classic Mode Authentication Classic Mode Authentication is the same type of authentication that was used in Microsoft Office SharePoint Server 2007. Classic Mode Authentication uses Windows authentication provider, which relies on Active Directory to authenticate users.

• Claims Based Authentication Claims Based Authentication is a new feature in SharePoint 2010. Claims Based Authentication can use the Windows authentication provider—just as can Classic Mode Authentication—as well as Forms Based Authentication (FBA) and SAML token providers. You will learn more about Claims Based Authentication later in this lesson.

Each of the providers supports multiple authentication methods. Table 3-1 summarizes the authentication types, providers, and methods. You will learn about each provider and method later in this lesson.

Table 3-1. Authentication Options for SharePoint Web Applications

TYPE	PROVIDER	METHODS
Classic Mode Authentication	Windows	Anonymous, Basic, Digest, NTLM, Negotiate (Kerberos or NTLM)
Claims Based Authentication	Windows	Anonymous, Basic, Digest, NTLM, Negotiate (Kerberos or NTLM)
	FBA	LDAP, SQL database, Other DB, Custom
	SAML	ADFS 2.0, Windows Live ID, Third Party

Configure Classic Mode Authentication

Classic Mode Authentication is one of the two types of authentication supported by SharePoint 2010. If you do not require claims, and if you will use only Windows authentication, you can create a web application that uses Classic Mode Authentication.

Classic Mode Authentication supports one authentication provider—Windows—and several methods of Windows authentication: NTLM, Kerberos, Basic, Digest, and Anonymous. You can configure the authentication method when you create the web application or after a web application has been created.

Create a Web Application with Classic Mode Authentication

As you learned in Lesson 1, when you create a web application, you can specify authentication settings on the Create New Web Application page, shown in Figure 3-8.

You can also specify authentication settings when you create a new web application by using Windows PowerShell.

CREATE A NEW WEB APPLICATION WITH CLASSIC MODE AUTHENTICATION

The following example shows the use of the New-SPWebApplication cmdlet to create a new web application:

New-SPWebApplication -Name <Name> -Port <Port> -HostHeader <HostHeader>
-AuthenticationMethod <AuthenticationMethod> [-AllowAnonymousAccess]
[-SecureSocketsLayer] -URL <URL> -ApplicationPool <ApplicationPool>
-ApplicationPoolAccount <ApplicationPoolAccount> -DatabaseName <DatabaseName>

Where:

• <Name> is the name of the new web application.

• <Port> is the port on which the web application will be created in IIS.

• <HostHeader> is the host header, in the format server.domain.com.

  Note that the Get-Help documentation for the cmdlet states that the format for <HostHeader> is http://server.domain.com. The documentation is incorrect.

• <AuthenticationMethod> is the Windows authentication method, which can be NTLM or Kerberos.

  If you specify Kerberos, it is actually the Negotiate (Kerberos or NTLM) method that is used.

• The -AllowAnonymousAccess switch parameter, if specified, enables anonymous authentication.

• The -SecureSocketsLayer parameter, if specified, enables SSL for the web application.

  As you learned in Lesson 1, you must also use IIS Manager to create the certificate in the server’s certificate store and bind the certificate to the IIS Web site.

• <URL> is the public URL for the web application’s default zone.

• <ApplicationPool> is the name of the application pool.

• <ApplicationPoolAccount> is the managed account that the application pool will use.

  This parameter is required if you are specifying an <ApplicationPool> that does not already exist. Use the Get-SPManagedAccount cmdlet as shown in the following example. If the <ApplicationPool> already exists, do not include this parameter.

• <DatabaseName> is the name for the first content database for the web application.

For example, the following command creates the Contoso partner portal web application with configuration similar to the web application that was created by using Central Administration in Lesson 1:

New-SPWebApplication -Name "Contoso Partner Portal" -Port 443
-HostHeader "partners.contoso.com" -AuthenticationMethod "NTLM" -SecureSocketsLayer
-URL "https://partners.contoso.com:443" -ApplicationPool "SharePoint Extranet Applications"
-ApplicationPoolAccount (Get-SPManagedAccount "CONTOSO\SP_WebApps")
-DatabaseName "SharePoint_Content_Partners"

The command creates a new application pool. If the application pool already exists, you would not include the -ApplicationPoolAccount parameter and value.

Configure a Web Application with Classic Mode Authentication

After a web application is created, you can modify authentication settings on the Edit Authentication page, shown in Figure 3-9.

You can access the Edit Authentication page from the Web Applications Management or the Authentication Providers pages of Central Administration.

CONFIGURE AUTHENTICATION SETTINGS FROM THE WEB APPLICATIONS MANAGEMENT PAGE

1. In the Central Administration Quick Launch, click Application Management.

2. In the Web Applications section, click Manage Web Applications.

3. Select the web application that you want to modify.

4. On the ribbon, click Authentication Providers.

5. Click the link to the zone that you want to modify.

   By default, each new web application has a single zone, called Default. You will learn more about zones later in this chapter.

   The Edit Authentication page appears.

6. Make your changes, and then click Save.

CONFIGURE AUTHENTICATION SETTINGS FROM THE AUTHENTICATION PROVIDERS PAGE

1. In the Central Administration Quick Launch, click Security.

2. In the Web Applications section, click Specify Authentication Providers.

3. Click the Web Application picker to select the web application that you want to modify.

4. Click the link to the zone that you want to modify.

5. On the Edit Authentication page, make your changes, and then click Save.

Windows Authentication Methods

Windows authentication is available in both classic-mode and claims-based authentication. However, when a web application is using classic-mode authentication, only the Windows authentication provider is supported.

Windows authentication supports the following authentication methods:

• Integrated Windows authentication, which can use either NT LAN Manager (NTLM) or Negotiate (Kerberos or NTLM) authentication methods.

• Basic.

• Anonymous.

• Digest.

• Client certificates.

NTLM

Introduced more than a decade ago, NTLM is the most established form of authentication in Microsoft products.

When a user logs on to his or her computer, the user is prompted for a user name and password. The user name is sent to the domain controller, but the password is never sent over the network. Instead, there is an encrypted challenge/response protocol through which a hash of the password is passed through a one-way hashing algorithm (the challenge) by both the client and the domain controller. The client sends the result (the response) to the domain controller. If the result matches what the domain controller obtained as a result, the password entered by the user must have been correct, and the user is authenticated.

It gets more complicated when a user connects to a server, such as a SharePoint server. If the SharePoint server is a member server—not a domain controller—it has no way of knowing the user’s password. So when the user connects to the server, the server has to pass the authentication request up to a domain controller. If the domain controller responds to the server that the user is valid, the authentication succeeds.

Although NTLM is not the most efficient authentication method, and is slightly less secure than Kerberos, it is often chosen as the authentication method for SharePoint web applications because it is easy to set up—it just works, out of the box.

Kerberos

Kerberos is the default authentication method for Windows clients and servers in an Active Directory domain.

Kerberos uses a process that involves encrypted tickets to verify authenticity. When a user logs on and authenticates with the domain, the domain controller’s Key Distribution Center (KDC) issues the user a ticket-granting-ticket (TGT) that effectively represents that the user has been authenticated. For the lifetime of the TGT (10 hours by default), the user no longer needs to be authenticated.

When the user wants to connect to a service, such as a SharePoint web application that uses Kerberos authentication, the client application returns to a domain controller’s KDC, presents the TGT, which confirms that the client has already been authenticated, and requests from a domain controller a service ticket for the specific service to which the client will connect. The client then goes to the service and presents the service ticket.

Because the entire process is encrypted with keys unique to each player (the client, the service, and the domain), the service is able to examine the service ticket and determine that it is being presented by an authenticated client. The service ticket contains the client’s identity and roles; the session is established.

This is a very simplistic—but accurate—explanation of Kerberos. If you are interested in more details about Kerberos, see the resources listed in the “Additional Resources About Kerberos Authentication” section.

One of the benefits of Kerberos is that when the client connects to the service, the service does not have to round-trip the authentication to a domain controller, as in NTLM. Instead, the client’s ticket for the service ensures the client has been authenticated. This results in improved authentication performance for Kerberos as compared to NTLM.

Another benefit is that Kerberos tickets can be delegated—that is, forwarded or proxied between tiers. For example, a client connecting to a website provides a Kerberos ticket, and the website can pass the ticket to a back-end data source that can authenticate the user for data access. The web tier does not need to know the user’s password to achieve this “double-hop” authentication. The web tier also does not need permissions to the back-end data source—it is all done using the authentication of the client.

To secure this “double-hop” authentication, you can configure Kerberos constrained delegation. Constrained delegation restricts which services are allowed to delegate user credentials by specifying, for each application pool or service, the services to which a Kerberos ticket can be forwarded. If you choose to configure constrained delegation, you should configure and test Kerberos with unconstrained delegation and resolve any issues you might encounter prior to configuring constrained delegation.

Kerberos is considered by many organizations to be a preferable authentication mechanism because of the following advantages:

• More secure than NTLM. Kerberos protocols ensure mutual authentication, which prevents what are called “man in the middle” attacks whereby a rogue service could pretend to be a domain controller and intercept authentication requests from clients. Kerberos tickets also contain timestamps that reduce the likelihood of “replay attacks” in which an authentication token can be intercepted and used at a later date for malicious purposes.

• More scalable than NTLM. Kerberos supports authentication across trusted realms and, because it is an industry standard, is supported by platforms other than Windows.

• Supports delegation. Delegation and constrained delegation were explained earlier. Delegation allows a service to impersonate a user without knowing the user’s password. Windows Server 2003 and later support constrained delegation as well, which adds a further level of security to the implementation of Kerberos in a Windows enterprise.

• Reduced load on domain controllers. Kerberos requires fewer trips to a domain controller for authentication than NTLM.

The disadvantage of Kerberos is that it requires additional steps to configure. You will learn the fundamental steps to configure Kerberos later in this lesson.

Negotiate (Kerberos or NTLM)

To use Kerberos authentication for a SharePoint web application, select the Negotiate (Kerberos or NTLM) authentication method. The Negotiate authentication method attempts to use Kerberos authentication. But if Kerberos authentication is not supported in the deployed environment, or if the client does not support Kerberos, authentication falls back to NTLM.

IIS passes the Negotiate security header when Windows Integrated authentication is used to authenticate client requests. The Negotiate security header lets clients select between Kerberos authentication and NTLM authentication. The Negotiate process selects Kerberos authentication unless one of the following conditions is true:

• One of the systems that is involved in the authentication cannot use Kerberos authentication.

• The calling application does not provide enough information to use Kerberos authentication.

If the Negotiate process cannot use the Kerberos protocol, the Negotiate process selects the NTLM protocol.

Configure Kerberos Authentication

To configure Kerberos authentication, you must use service principal names or SPNs for your SharePoint services, web applications, and SQL Server. This section will summarize the process. For a detailed walkthrough of creating a SharePoint farm with Kerberos authentication, see the TechNet article “Configure Kerberos authentication (SharePoint Server 2010)” at http://technet.microsoft.com/en-us/library/ee806870.aspx.

Earlier in this lesson, you learned that when a client wants to connect to a web application that uses Kerberos authentication, the client requests a service ticket from a domain controller’s KDC. The request indicates the service to which the client will connect by specifying the service’s service principal name or SPN.

The SPN is made up of three components. The first is the service class for the request, which is always HTTP—the HTTP service class includes both the HTTP and HTTPS protocols. The second is the host name, and the third is the port (if not port 80) of the web application. Together, these three components comprise the SPN of the web application.

For example, a request to http://intranet.contoso.com on port 80 equates to an SPN of HTTP/intranet.contoso.com. Note that the SPN syntax uses a single forward slash between the service class and host name portions of the name. A request to https://partners.contoso.com on port 443 equates to an SPN of HTTP/partners.contoso.com:443. A request to http://sp2010-wfe1:9999 for Central Administration equates to an SPN of HTTP/sp2010-wfe1:9999.

A security principal—a user or computer account in Active Directory—can have one or more associated SPNs. SPNs are an attribute of security principals in Active Directory. That means an account, such as an application pool account, can have multiple SPNs—for example, both HTTP/intranet.contoso.com and HTTP/partners.contoso.com:443.

When a domain controller’s KDC receives the service ticket request from a client, it looks up the requested SPN. The KDC then creates a session key for the service and encrypts the session key with the password of the account with which the SPN is associated. The KDC issues a service ticket, containing the session key, to the client. The client presents the service ticket to the service. The service, which knows its own password, decrypts the session key and authentication is complete.

If a client submits a service ticket request for an SPN that does not exist in the identity store, no service ticket can be established and the client will throw an access denied error.

For this reason, each component of a SharePoint infrastructure that uses Kerberos authentication requires at least one SPN. For example, the intranet web application app pool account must have an SPN of HTTP/intranet.contoso.com.

Configure Service Principal Names for a Service or Application Pool

Note that it is the app pool—not the server—that is associated with the SPN because the app pool is the security context within which the service—the web application in this case—is running. It also makes sense if you consider that each SPN can be associated with only one security principal, and if a web app is load balanced—running on several servers—it is the one app pool account that is constant across all servers and therefore must have the SPN.

For each web application, you should assign two SPNs—one with the fully qualified domain name for the service, and one with the NetBIOS name of the service. Therefore, the intranet web application pool account should also be assigned an SPN of HTTP/intranet.

In many environments, a single application pool can be used by multiple web applications. The app pool account should be given a pair of SPNs for each of its web applications that use Kerberos authentication.

You can use ADSI Edit to add SPNs to an account. To configure an SPN for a service or application pool account, you must have domain administrative permissions or a delegation to modify the servicePrincipalName property.

CONFIGURE SPNS USING ADSI EDIT

1. Start ADSI Edit.

2. In the console tree, right-click ADSI Edit, and then click Connect To.

3. In the Connection Settings dialog box, click OK.

4. In the console tree, expand Default Naming Context, then expand the domain, and then expand the nodes representing the OUs in which the account exists. Click the OU in which the account exists.

5. In the Details pane, right-click the service or application pool account, and then click Properties to open the Properties dialog box.

6. In the Attributes list, double-click servicePrincipalName to open the Multi-Valued String Editor dialog box.

7. In the Value To Add field, type the SPN, and then click Add.

   Repeat step 7 for additional SPNs. Remember that an app pool account should have two SPNs, in the form HTTP/site.domain.com and HTTP/site, for each web application that uses Kerberos authentication in the app pool. Remember also to add the port number if the site runs on a port other than port 80—for example, HTTP/site.contoso.com:9999 and HTTP/site:9999.

8. Click OK twice.

You can also use the command-line tool Setspn.exe to add SPNs to an account.

CONFIGURE SPNS USING SETSPN

The following example shows the use of the SetSPN command to add an SPN to an account:

setspn <domain\user> -s <SPN>

Where:

• <domain\user> identifies the security principal to which you want to add an SPN.

• <SPN> is the service principal name that you want to add.

For example, to add SPNs for the intranet web application to the app pool account, you can type the following commands:

setspn CONTOSO\SP_WebApps -s HTTP/intranet.contoso.com
setspn CONTOSO\SP_WebApps -s HTTP/intranet

The most useful facts to know about SetSPN are the following:

• The -s parameter adds an SPN to an account after verifying that a duplicate SPN does not already exist. Duplicate SPNs can cause authentication problems, and it is recommended that you use each SPN only once in a forest. The -s parameter is new in Windows Server 2008. Previously, you used the -a switch, which adds an SPN but does not check for duplicates. It is recommended that you use -s now that it is available, but some documentation might refer to -a.

• The -L switch lists the SPNs associated with a specific user or computer account.

• The -Q switch lists the accounts associated with a specific SPN.

You can type setspn.exe /? for more information about SetSPN.

Configure Service Principal Names for SQL Server

To configure Kerberos authentication for SQL Server, you will need to add SPNs to the SQL Server service account—for example, CONTOSO\SVC_SQL. By default, SQL Server communication is over port 1433, so the two SPNs for a SQL Server running on a server named SQLSERVER01 would be the following:

• MSSQLSvc/sqlserver01:1433

• MSSQLSvc/sqlserver01.contoso.com:1433

Verify Kerberos Authentication to a Web Application

After you have configured your environment to support Kerberos authentication for a web application, you can validate that Kerberos is being used to authenticate a user. By opening the website you will generate an entry in the Windows Security event log. Examine the Security event log on the web server. The audit event generated by the user’s logon will show the security ID of the user and the Logon Process, which should be Kerberos, as shown in Figure 3-10.

Alternately, you can use Klist.exe. KList is a command-line utility included in the default installation of Windows Server 2008 and Windows Server 2008 R2 which can be used to list and purge Kerberos tickets on a given computer. To verify Kerberos with KList, open the website on a client, and then use KList on the client to enumerate its tickets. You will see the ticket with the SPN of the web application, as shown in Figure 3-11.

Connect to Back-End Systems

In Chapter 8, “Implementing Enterprise Service Applications,” you will learn to connect SharePoint to back-end data systems. For example, you might use Excel Services to present information in a database outside of SharePoint, or you might use Business Data Connectivity Services to create a SharePoint list that displays items stored in another system.

There are several ways to configure connection to a back-end or external system, including the Secure Store Service, the Claims To Windows Token Service, and Kerberos delegation. This chapter has examined authentication to a web application. If you need to support authentication to back end systems, be sure to read the details in Chapter 8.

Additional Resources about Kerberos Authentication

If you want to configure your entire SharePoint environment to support Kerberos, there are numerous additional steps to perform. You can learn more about configuring Kerberos by reading the following articles:

• “Configure Kerberos authentication (SharePoint Server 2010),” http://technet.microsoft.com/en-us/library/ee806870.aspx.

• “Kerberos (Windows Server 2008 and Windows Server 2008 R2 Technical Library),” http://technet.microsoft.com/en-us/library/cc753173(WS.10).aspx.

• “Kerberos Authentication Technical Reference (Windows Security Collection),” http://technet.microsoft.com/en-us/library/cc739058(WS.10).aspx.

• “Windows Authentication,” http://technet.microsoft.com/en-us/library/cc755284(WS.10).aspx.

• “Kerberos Explained,” http://technet.microsoft.com/en-us/library/bb742516.aspx.

• “How to use SPNs when you configure Web applications that are hosted on Internet Information Services,” http://support.microsoft.com/kb/929650.

• “Setspn,” http://technet.microsoft.com/en-us/library/cc731241(WS.10).aspx.

• “Microsoft Kerberos (Windows),” http://msdn.microsoft.com/library/aa378747.

• “Ask the Directory Services Team: Kerberos for the Busy Admin,” http://blogs.technet.com/b/askds/archive/2008/03/06/kerberos-for-the-busy-admin.aspx.

• “Configure Kerberos authentication for the claims to Windows token service (SharePoint Server 2010),” http://technet.microsoft.com/en-us/library/ee806887.aspx.

You can also download the white paper “Configuring Kerberos authentication for SharePoint 2010 Products” at http://technet.microsoft.com/en-us/library/ff829837.aspx.

Additional Windows Authentication Methods

Although NTLM or Negotiate (Kerberos or NTLM) are the most commonly used authentication methods, Classic Mode Windows authentication also supports anonymous, basic, and digest authentication methods.

Anonymous

Anonymous authentication enables users to connect to a web application without providing credentials. You can enable anonymous authentication on either the Create New Web Application or Edit Authentication pages.

Anonymous authentication was detailed earlier in this lesson. You learned that anonymous authentication does not provide anonymous users with permission to content within a web application. Anonymous access must be granted at the securable object. You can grant anonymous users permission to an entire site or to specific lists and libraries. You can then restrict access at the web application by applying anonymous access restriction policies, which override permissions.

Basic

Like Integrated Windows authentication, Basic authentication relies on a set of credentials for the user in Active Directory. However, Basic authentication enables a web browser to submit credentials when making an HTTP request, and the credentials are sent as Base64 clear text, unencrypted, to the server. Credentials used in Basic authentication are easily compromised. If you choose to use Basic authentication, you should always enable Secure Sockets Layer (SSL) encryption.

You cannot select Basic authentication when you create a SharePoint web application. Instead, you must do so after creating the web application.

ENABLE BASIC AUTHENTICATION

1. In the Central Administration Quick Launch, click Application Management.

2. In the Web Applications section, click Manage Web Applications.

   The Web Applications Management page opens.

3. Click the name of the web application for which you want to enable or disable anonymous access.

4. On the ribbon, click Authentication Providers.

   The Authentication Providers page opens.

5. Click the name of the zone for which you want to enable or disable anonymous access. For example, click Default.

   The Edit Authentication page opens.

6. In the IIS Authentication Settings section, shown earlier in Figure 3-9, select the Basic Authentication check box.

7. Click Save.

8. Close the Authentication Providers page.

9. Start Command Prompt using the Run As Administrator option, and then type IISRESET.

If you select Negotiate (Kerberos) and Basic Authentication, clients should attempt authentication in the following order: Kerberos, NTLM, Basic authentication.

Digest

Digest authentication provides the same functionality as Basic authentication, but with increased security. User credentials are encrypted instead of being sent over the network in plaintext. User credentials are sent as an MD5 message digest in which the original user name and password cannot be deciphered. Digest authentication uses a challenge/response protocol that requires the authentication requestor to present valid credentials in response to a challenge from the server. To authenticate against the server, the client has to supply an MD5 message digest in a response that contains a shared secret password string.

Digest authentication for SharePoint is not particularly common. To implement digest authentication, you will have to select Windows authentication in Central Administration, then configure the IIS Web site for Digest authentication.

Understand Claims Based Authentication

Consider the following summary of Claims Based Authentication:

• Claims Based Authentication is a flexible framework based on Security Assertion Markup Language (SAML) tokens, and built on the Windows Identity Foundation (WIF). Tokens contain assertions about a user’s identity that are generated by trusted authentication providers, which include Windows authentication—just as in Classic Mode Authentication—as well as Forms Based Authentication (FBA) and standard SAML tokens issued by trusted authorities such as Windows Live ID or Active Directory Federated Services 2.0 (ADFS 2.0). By extending the reach of trusted authentication providers, Claims Based Authentication enables authentication across Windows-based systems and systems that are not Windows based. Claims Based Authentication becomes particularly powerful when tokens contain other attributes of a user, such as demographic or organizational information. These attributes can originate within the user’s organization, other organizations, or the Internet.

Doesn’t that sound really complex? Don’t give up; read on.

Review Authentication in a Windows Domain

If you are not already familiar with Claims Based Authentication, the preceding description of Claims Based Authentication may sound complex. But the concepts related to Claims Based Authentication can be pretty straightforward if you start from the perspective of an authentication scheme that you already understand: authentication within a Windows domain. Let’s review the basics of Windows authentication as a basis from which to understand Claims Based Authentication.

When you require access to a system, such as a file server, the system must know who you are before you can be granted access to resources. It would not be manageable to maintain a list of user names and passwords on each system. Therefore, you create a Windows domain by implementing Active Directory Domain Services (AD DS). Within a domain, all systems trust the authentication mechanism of the domain—Kerberos—to validate the identity of a user. So, when you access a file server, the file server does not have to authenticate you. Instead, you bring to the server a Kerberos service ticket that identifies you. The ticket has been created using processes that include encryption using keys known only by the server and the domain. So the server knows that the service ticket is valid. It looks at the ticket to know who you are. The server accepts the ticket’s assertion as to your identity because the server trusts the source of the ticket—the AD DS domain’s Kerberos KDC. The server does not have to perform authentication—it trusts an external authentication provider.

The Kerberos service ticket does not just identify you. It also contains a list of your domain security group memberships. Again, because the ticket comes from a trusted authority, the server uses that list of groups. The server builds a token that contains your identity—your user account’s security identifier, or SID—and the SIDs of the groups to which you belong. The token is then used by the local security subsystem to determine whether you have access to a file by comparing the SIDs on the file’s access control list to the SIDs in your token. This security token represents you to the local server.

In the past, when a developer wanted to create a secure website, the developer had to build an authentication component. With SharePoint, in Classic Mode Authentication, your Windows security token is translated into an object that represents you within SharePoint—an object called an SPUser object. You can think of the SPUser object in a SharePoint web application as the conceptual equivalent of your Windows security token—it represents you during your interactions with the web application.

Claims Authentication to a SharePoint Web Application

A claim is a set of assertions—information about a user. At the most basic conceptual level, a Kerberos service ticket is a claim that, among other things, asserts the identity and group memberships of a user. When you access a SharePoint web application that uses Claims Based Authentication, the web application accepts a claim and translates that claim into the SPUser object which, as you know, represents you during your interactions with the web application.

This is the first difference between Classic Mode Authentication and Claims Based Authentication. In Classic Mode Authentication, the web application relies on IIS to pass your Windows security token to the web application. In Claims Based Authentication, the web application relies on the farm’s Security Token Service (STS) to deliver a token that contains claims, including claims about your identity.

In Classic Mode Authentication, IIS relies on Active Directory to actually perform authentication. IIS can receive credentials using several methods, including NTLM, Kerberos, Basic, and Digest. In the case of NTLM, Basic, and Digest authentication, IIS authenticates the credentials against Active Directory. In the case of Kerberos authentication, the service ticket contains credentials that have already been authenticated.

In Claims Based Authentication, the STS also does not actually perform authentication. Instead, it relies on a trusted authority to do so. The authority can be Active Directory, or it can be one of a number of other authentication providers. If the Claims Based Application uses the Windows authentication provider, the STS performs essentially the same function as IIS does in Classic Mode Authentication. If Kerberos is available, the service ticket is processed and turned into a set of claims about the user’s identity and group memberships. If NTLM, Basic, or Digest authentication are used, the STS authenticates the credentials against Active Directory and then the NT token is translated into a set of claims about the user’s identity and group memberships.

The resulting claims are provided to the web application as a token which, as you know, is translated into an SPUser object within the web application.

By this point in the discussion, you should understand that a component called an STS is doing the work of building tokens that contain claims. You should also have an understanding that if only Windows authentication is used, there is conceptually little difference between Classic Mode Authentication and Claims Based Authentication. But the story is just beginning.

What if you want to make a web application available to partners, but you do not want to add accounts for partner users to your AD DS domain? In the past, a web developer would have to write a custom component to authenticate users and to administer user identities. Now, however, you can use the Forms Based Authentication provider to authenticate users against credentials stored in AD DS; in Active Directory Lightweight Directory Services (AD LDS); in a database such as a SQL Server database; or in an LDAP data store such as Novell eDirectory, Novell Directory Services (NDS), or Sun ONE. Or you can use SAML to authenticate users against credentials stored in Active Directory Federated Services 2.0 (ADFS 2.0), by Windows Live ID, or by a custom trusted source.

Claims Based Authentication thus allows SharePoint web applications to be extended to more diverse sets of users, across domains, forests, and non-Windows environments. You can change the authentication provider or the methods of authentication without having to change the web application itself.

Trust

How are claims actually built? When you attempt to access a web application that uses Claims Based Authentication, you are transparently redirected to a sign-in page for the STS, at which you are authenticated. In some cases, such as Windows authentication, you might never even see this transaction if your browser’s security settings are configured to authenticate you silently to trusted sites, and if the website is in a trusted zone. The STS authenticates you and provides a token to your browser. Your browser then returns to the original website, submits the token, and the web application then knows who you are.

But if the browser is submitting a token with assertions about your identity, how does the web application know that those assertions come from a trusted source, and that you have not fabricated a false token containing erroneous statements about who you are?

The process uses a series of standards called WS-* standards that effectively ensure that the token can be used by the web application. To make a long, complicated story very short, the web application has been configured to trust the STS. The trust involves the exchange of certificates that are used to encrypt the token. If the web application is able to decrypt the token with the shared secret, it knows that the token must have been generated by the trusted STS.

Trust is at the heart of any security system. In an AD DS domain, each component of Windows trusts the local security subsystem, which in turn trusts the domain, which in turn trusts other domains in the forest, and that trust can then be extended to other domains or forests. In SharePoint, all web applications and services in a farm trust the Security Token Service of the farm.

Claims

When a claim is presented to a web application, the claim contains assertions about the user’s identity. It also can contain claims about the user’s group memberships. Each of the authentication methods available in Claims Based Authentication can provide the STS with an enumeration of the user’s group memberships, which are added to the claim.

But a claim can provide more than just user and group information, and this is where claims become particularly valuable. Let’s assume that you want to be able to send email messages to users from a website. How do you determine a user’s email address? You can build and maintain a local database of user email addresses, but in an AD DS domain that information is stored in Active Directory, and so a local database would have to be kept in synch with changes made in Active Directory. Or you can add code to query Active Directory each time an email address is needed. Both approaches require additional work by the website developer.

A claim can include a user’s email address or any other attribute of the user, such as the user’s manager or the manager’s email address, department, job title, age, or gender. Because the claims are presented by the user to the web application, the web application does not need to maintain local copies of the attributes, nor does it need to go look up the attributes in an external source. Instead, the STS is configured to collect the attributes and to create claims.

Claims Based Authentication thus reduces the burden on applications themselves to maintain or look up information about users. Attributes in claims can be used for a variety of purposes. You can assign permissions to content that are based on a claim. For example, you can specify that users must have a job title of Vice President or higher to access content. You can also use claims to look up users. For example, if you want to assign a task to a user, but you can only remember the user’s manager, the picker control can expose the manager attribute of users who belong to the site. Developers are particularly excited about the possibilities that are presented now that SharePoint 2010 supports claims.

Federation

Let’s now assume that certain content in a web application can only be accessed by users who are employees of your company, Contoso, or of a partner company, Litware. How do you make this work? It would be a burden to have duplicate copies of all Litware user accounts in your AD DS domain or in a separate database, and to keep changes in synch. It would be much easier to simply rely on the administrators at Litware to maintain their user accounts, and to trust the authentication performed by Litware.

With Windows domains, you could configure a trust whereby the Contoso domain trusts the Litware domain. However, firewalls can often prevent trusts from being correctly established and maintained, and many organizations have policies that forbid Windows trusts to external organizations.

Claims Based Authentication supports federation, which extends the concepts of trust and claims to third parties. For example, you can configure ADFS 2.0 to authenticate users against both domains, without requiring a trust. You then configure SharePoint’s STS to trust the STS exposed by ADFS 2.0. From a terminology perspective, SharePoint’s STS becomes the relying party STS (RP-STS) and the STS of ADFS 2.0 becomes the identity provider STS (IP-STS).

When a user attempts to access a website, the user is redirected to the IP STS for authentication. The token issued by the IP STS (ADFS 2.0 in this example) is then presented to the RP STS (SharePoint’s STS in this example), which can augment the token with additional claims before giving the client the token that is then submitted to the web application.

Another example of federated identity is Windows Live ID authentication. You can configure SharePoint’s STS to trust tokens issued by Windows Live ID, just as some Microsoft sites do.

Claims Authentication

Claims authentication is built on the Windows Identity Foundation (WIF). WIF is a set of .NET Framework classes that are used to implement claims-based identity. Claims authentication relies on standards such as WS-Federation, WS-Trust, and protocols such as SAML. Claims Based Authentication thus enables you to extend both authentication (identification) and the collection of informational attributes about a user to sources beyond your domain.

It’s not important that you, as an IT Pro, master all of the concepts, standards, and protocols, and the tools used to create code used to leverage claims. However, you must be able to configure SharePoint to support claims authentication. In the next section, you will learn how to configure SharePoint for Windows-Claims, Forms-Claims, and SAML-Claims authentication.

Now, test yourself: Return to the beginning of this section, “Understand Claims Based Authentication,” and read the summary once again. Does it make sense now?

Configure Windows-Claims Authentication

Now that you understand Claims Based Authentication, we can turn our attention to the procedures required to create and configure web applications that use Claims Based Authentication. First, we will explore creating a web application that uses the Windows authentication provider for Claims Based Authentication—Windows-Claims authentication. You can create a web application that uses Claims Based Authentication by using Central Administration or Windows PowerShell.

CREATE A WEB APPLICATION WITH WINDOWS-CLAIMS AUTHENTICATION USING CENTRAL ADMINISTRATION

1. In the Central Administration Quick Launch, click Application Management.

2. In the Web Applications section, click Manage Web Applications.

3. On the ribbon, click New to open the Create New Web Application page.

4. In the Authentication section, click Claims Based Authentication.

5. In the Claims Authentication Types section, select the Enable Windows Authentication check box.

6. If you want to use NTLM or Kerberos as the authentication method, select the Integrated Windows Authentication check box. Then, in the drop-down menu, select Negotiate (Kerberos) or NTLM.

7. If you want users’ credentials to be sent over a network in a nonencrypted form, select the Basic Authentication (Password Is Sent In Clear Text) check box. If you use basic authentication, ensure that SSL is enabled; otherwise, the credentials can be intercepted by a malicious user.

8. Configure other settings for the new web application. See Lesson 1 for more information about the settings you can configure when creating a web application.

To create a web application by using Windows PowerShell, you must first create an object that represents the authentication provider by using the New-SPAuthenticationProvider cmdlet.

CREATE AN AUTHENTICATION PROVIDER USING WINDOWS POWERSHELL

The following example shows the use of the New-SPAuthenticationProvider cmdlet to create a new Windows authentication provider.

$ap = New-SPAuthenticationProvider [-UseWindowsIntegratedAuthentication]
[-DisableKerberos | DisableKerberos:$false]
[-UseBasicAuthentication] [-AllowAnonymous]

Where:

• The -UseWindowsIntegratedAuthentication switch parameter specifies that the authentication provider will be Windows.

• The -DisableKerberos switch parameter, if specified, disables Kerberos authentication. The authentication provider uses NTLM only.

  The -DisableKerberos:$false syntax enables authentication.

  NOTE

  AN RTM BUG

  In the RTM version of SharePoint, there is a bug in the class that initializes DisableKerberos to true. Therefore, the switch parameter does not work as documented. You must use -DisableKerberos:$false to enable Kerberos. It is likely that in a future release, Microsoft will either correct the behavior so that Kerberos is enabled by default and the documentation will be correct, or add a switch parameter that enables Kerberos.

• The -UseBasicAuthentication switch parameter, if specified, enables Basic authentication.

After you create the object representing the authentication provider, you pass the object as the -AuthenticationProvider parameter to the New-SPWebApplication cmdlet.

CREATE A WEB APPLICATION WITH CLAIMS BASED AUTHENTICATION USING WINDOWS POWERSHELL

The following example shows the use of the New-SPWebApplication cmdlet to create a new web application:

New-SPWebApplication -Name <Name> -Port <Port> -HostHeader <HostHeader>
-AuthenticationProvider <AuthenticationProvider> [-AllowAnonymousAccess]
[-SecureSocketsLayer] -URL <URL> -ApplicationPool <ApplicationPool>
-ApplicationPoolAccount <ApplicationPoolAccount> -DatabaseName <DatabaseName>

Where:

• <Name> is the name of the new web application.

• <Port> is the port on which the web application will be created in IIS.

• <HostHeader> is the host header, in the format server.domain.com.

  Note that the Get-Help documentation for the cmdlet states that the format for <HostHeader> is http://server.domain.com. The documentation is incorrect.

• <AuthenticationProvider> is an object representing an authentication provider.

  Use the New-SPAuthenticationProvider cmdlet to create an object representing an authentication provider, as described earlier.

• The -AllowAnonymousAccess switch parameter, if specified, enables anonymous authentication.

• The -SecureSocketsLayer parameter, if specified, enables SSL for the web application.

  As you learned in Lesson 1, you must also use IIS Manager to create the certificate in the server’s certificate store and bind the certificate to the IIS Web site.

• <URL> is the public URL for the web application’s default zone.

• <ApplicationPool> is the name of the application pool.

• <ApplicationPoolAccount> is the managed account that the application pool will use.

  This parameter is required if you are specifying an <ApplicationPool> that does not already exist. Use the Get-SPManagedAccount cmdlet as shown in the following example. If the <ApplicationPool> already exists, do not include this parameter.

• <DatabaseName> is the name for the first content database for the web application.

For example, the following command creates the partner portal web application with configuration similar to the web application that was created by using Central Administration in Lesson 1, but with Claims Based Authentication. A Windows authentication provider is constructed that uses only NTLM—Kerberos is disabled—and passed as the authentication provider for the new web application.

$ap = New-SPAuthenticationProvider -UseWindowsIntegratedAuthentication
   -DisableKerberos
New-SPWebApplication -Name "Contoso Partner Portal" -Port 443
   -HostHeader "partners.contoso.com" -AuthenticationProvider $ap -SecureSocketsLayer
   -URL "https://partners.contoso.com:443"
   -ApplicationPool "SharePoint Extranet Applications"
   -ApplicationPoolAccount (Get-SPManagedAccount "CONTOSO\SP_WebApps")
   -DatabaseName "SharePoint_Content_Partners"

After you have created the web application, create a site collection. When you create a site collection, you must specify the primary site collection administrator. You can use Central Administration or the New-SPSite cmdlet, as described in Chapter 2.

Configure Forms Based Authentication

Forms Based Authentication (FBA) is an identity management system that is based on ASP.NET membership and role provider authentication.

If an unauthenticated user attempts to access a web application using FBA, the user is redirected to a logon form, with which the user submits credentials. The credentials are authenticated against an identity store, which can be AD DS; a database such as a SQL Server database; or an LDAP data store such as Active Directory Lightweight Directory Services (AD LDS), Novell eDirectory, Novell Directory Services (NDS), or Sun ONE.

SharePoint Server 2010 uses the standard ASP.NET membership provider interface to authenticate the user, and the standard ASP.NET role manager interface to gather group information about the user. Each ASP.NET role is treated as a domain group by the authorization process in SharePoint Server 2010. The resulting information about the user is converted into claims by the STS, thus FBA is also called Forms-Claims authentication.

To configure FBA, you must manage the following settings, each of which is detailed later in this section:

• The web application’s authentication mode The web application must use Claims Based Authentication. In SharePoint Server 2010, Forms-Based Authentication is available only when you use Claims Based Authentication.

  NOTE

  FBA AND CLASSIC MODE AUTHENTICATION

  If you upgrade a SharePoint 2007 web application that uses FBA, the upgraded web application is configured to use Classic Mode Authentication, and FBA will not function. You must convert the web application to Claims Based Authentication, as described later in this lesson.

• The config file of the Security Token Service (STS) Application As you have learned, the STS generates and manages claims tokens. The STS uses the FBA authentication provider to authenticate the user on behalf of the relying party—either the web application or Central Administration. It is the STS that actually performs the authentication, so it must know which provider and data source to use.

• The Web.config file of the web application’s IIS site You must register the membership provider and role manager in the Web.config file. Although the web application does not perform authentication, it does perform other tasks against the users and roles that are provided. For example, when you assign a task or grant permissions to a user or group, the People Picker control must know the sources from which it can find users.

  NOTE

  REGISTERING THE ROLE MANAGER IS NOW REQUIRED

  In SharePoint 2007, you were required to register only the membership provider; registering the role manager was optional In SharePoint 2010, you are required to register both.

• The Web.config file of the Central Administration IIS site If you want to manage membership users or roles from the SharePoint Central Administration web site, you must register the membership provider and the role manager in the Web.config file of the Central Administration website as well. For example, you might want assign a user as the primary site collection administrator. If Central Administration does not know how to locate and interact with the FBA provider, it will be unable to locate the user and add the user as the site collection owner.

• Access to the database against which users are authenticated The user database must allow SharePoint to authenticate and look up users.

Create a Web Application with Forms-Claims Authentication

Forms Based Authentication is available only to an application that uses Claims Based Authentication. You can create the web application by using Central Administration or Windows PowerShell.

CREATE A WEB APPLICATION WITH FORMS-CLAIMS AUTHENTICATION USING CENTRAL ADMINISTRATION

1. In the Central Administration Quick Launch, click Application Management.

2. In the Web Applications section, click Manage Web Applications.

3. On the ribbon, click New to open the Create New Web Application page.

4. In the Authentication section, click Claims Based Authentication.

5. In the Claims Authentication Types section, select the Enable Forms Based Authentication (FBA) check box.

   NOTE

   IF YOU DON’T ENABLE FBA

   If you clear the Enable Windows Authentication check box, a warning message appears: “If Windows authentication is not selected on any Zone of this Web application, crawling for this Web application will be disabled.” The crawler requires a zone that uses Windows authentication to index SharePoint content. You will learn more about zones in Lesson 3, and about crawling in Chapter 7.

6. Enter the membership provider name and the role manager name in the boxes. You will learn more about these settings later in this lesson.

7. In the Sign In Page URL section, do one of the following:

   • Click Default Sign In Page if you want users to be redirected to a SharePoint’s default sign-in page for claims-based authentication.

   • Click Custom Sign In Page, and then type the URL of the customized sign-in page to which you want users redirected for Claims Based Authentication for the web application.

8. Configure other settings for the new web application. See Lesson 1 for more information about the settings you can configure when creating a web application.

CREATE A WEB APPLICATION WITH FORMS-CLAIMS AUTHENTICATION USING WINDOWS POWERSHELL

The following example shows the use of the New-SPAuthenticationProvider cmdlet to create a new Forms Based Authentication authentication provider.

$ap = New-SPAuthenticationProvider -ASPNETMembershipProvider <MembershipProviderName>
-ASPNETRoleProviderName <RoleProviderName>

Where:

• <MembershipProviderName> specifies the name of the membership provider. The name must be the valid name of an ASP.NET provider defined in the Web.config file of the application.

• <RoleProviderName> specifies the name of the membership provider. The name must be the valid name of an ASP.NET membership provider defined in the Web.config file of the application.

After you create the object representing the authentication provider, you pass the object as the -AuthenticationProvider parameter to the New-SPWebApplication cmdlet, as described earlier in the procedure, “Create a Web Application with Claims Based Authentication Using Windows PowerShell.”

For example, the following command creates the partner portal web application with configuration similar to the web application that was created by using Central Administration in Lesson 1, but with Forms-Claims authentication.

$ap = New-SPAuthenticationProvider -ASPNETMembershipProvider "MyMembershipProvider"
   -ASPNETRoleProviderName "MyRoleManager"
New-SPWebApplication -Name "Contoso Partner Portal"
   -Port 443 -HostHeader "partners.contoso.com" -AuthenticationProvider $ap
   -SecureSocketsLayer
   -URL "https://partners.contoso.com:443"
   -ApplicationPool "SharePoint Extranet Applications"
   -ApplicationPoolAccount (Get-SPManagedAccount "CONTOSO\SP_WebApps")
   -DatabaseName "SharePoint_Content_Partners"

Configure Web.config Files

After you have successfully created a web application that uses Claims Based Authentication, you must manually configure the specifics of the authentication provider by modifying the configuration file of the IIS site, Web.config.

This section details the configuration of Web.config. Do not be concerned if it sounds confusing. It is! In the practice for this lesson, you will configure FBA. The practice will thus give you hands-on experience modifying Web.config files, and a chance to review and reinforce the details presented here.

The following sample illustrates the structure of the Web.config file, focused on the elements that are important to configure for FBA.

<configuration>
...
  <SharePoint>
    <PeoplePickerWildcards>
      <clear />
      <add key="AspNetSqlMembershipProvider" value="%" />
      <add key="MyMembershipProvider" value="*"/>
      <add key="MyRoleManager" value="*"/>
    </PeoplePickerWildcards>
  </SharePoint>
  <connectionStrings>
    <add name="MyConnectionString" [define the connection] />
  </connectionStrings>
  <system.web>
  ...
    <membership>
      <providers>
       <add name="MyMembershipProvider" [define the membership provider] />
      </providers>
    </membership>
    <roleManager>
      <providers>
        <add name="MyRoleManager" [define the role manager] />
      </providers>
    </roleManager>
    ...
  </system.web>
  ...
</configuration>

As you work with the Web.config files, keep the following tips in mind:

• An element can have values—for example, you might see <roleManager enabled=“true”>, where enabled=“true” is a value of the element roleManager. Do not change the existing values within a tag unless you have been instructed to do so.

• If an element does not exist, you can create it. For example, the Web.config file of the STS site does not have a <system.web> element. You can create it in the relative position shown in the preceding example.

• Names are used to link configuration elements. The name of the membership provider and role manager you configure for the SharePoint web application must have a matching entry in the <membership><providers> and the <roleManager><providers> elements, respectively. If the providers connect to a data source, the connection string must be registered in the <connectionStrings> element with a name that matches the name that is used in the definition of the providers in the <membership><providers> and the <roleManager><providers> elements. Keep close tabs on the names that you use to ensure all of the configuration elements are properly associated.

The <connectionStrings> element shown in the preceding example defines a connection to the identity store, typically a SQL database or LDAP directory. The following example registers a connection string named MySQLDatabase that connects to the database named aspnetdb on the server named SP2010-WFE1.contoso.com using integrated authentication:

<connectionStrings>
    <add name="MySQLDatabase"
         connectionString="server=SP2010-WFE1.contoso.com;
         database=aspnetdb;
         Integrated Security=SSPI" />
</connectionStrings>

You define a membership provider to connect the web application to a provider—a software component that performs the authentication. The most popular out-of-box FBA membership provider is the ASP.NET SQLMembershipProvider provider, which uses a membership database on a SQL server that contains information about users, groups (roles), and profile attributes. When you define the provider, you specify values of the provider that determine its exact behavior. For example, you pass a connection string to the provider so that the provider knows which data source to work with.

The following example configures a SQLMembershipProvider named MyMembershipProvider, and instructs the provider to access the data source referred to by the connection string named MySQLDatabase:

<add name="MyMembershipProvider"
     connectionStringName="MySQLDatabase"
     applicationName="/"
     type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3600.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
     description="Stores and retrieves roles from SQL Server"
     passwordAttemptWindow="5"
     enablePasswordRetrieval="false"
     enablePasswordReset="false"
     requiresQuestionAndAnswer="true"
     requiresUniqueEmail="true"
     passwordFormat="Hashed"/>

Next, you define a role manager. The role manager, also called a role provider, is the software component responsible for identifying the roles, or groups, to which a user belongs. The most popular out-of-box role manager is the ASP.NET SQLRoleProvider, which works against the same membership database as the SQLMembershipProvider, but is responsible for determining the user’s group memberships.

The following example configures a SQLRoleProvider named MyRoleManager that uses the same data source referred to by the connection string name, MySQLDatabase:

<add name="MyRoleManager"
     connectionStringName="MySQLDatabase"
     applicationName="/"
     type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.3600.0,
     Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
     description="Stores and retrieves roles from SQL Server"/>

The definition of the membership provider and role manager determines how authentication is performed for a web application. The following examples define the membership provider named MyMembershipProvider and the role manager named MyRoleManager to use the LDAPMembershipProvider and LDAPRoleProvider providers, respectively, with the contoso.com domain as the data source. If these providers were registered in the Web.config files instead of the identically named providers shown previously, the web application would authenticate against the domain instead of against a SQL membership database.

<configuration>
. . .
  <system.web>
  . . .
    <membership>
      <providers>
     <add name="MyMembershipProvider"
         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="DC=contoso,DC=com"
         userObjectClass="person"
         userFilter="(ObjectClass=person)"
         scope="Subtree"
         otherRequiredUserAttributes="sn,givenname,cn" />
      </providers>
    </membership>
    <roleManager>
      <providers>
      <add name="MyRoleManager"
         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="DC=contoso,DC=com"
         groupNameAttribute="cn"
         groupNameAlternateSearchAttribute="samAccountName"
         groupMemberAttribute="member"
         userNameAttribute="sAMAccountName"
         dnAttribute="distinguishedName"
         groupFilter="(ObjectClass=group)"
         userFilter="(ObjectClass=person)"
         scope="Subtree" />
      </providers>
    </roleManager>
    . . .
  </system.web>
  . . .
</configuration>

In the case of the LDAP providers, you do not use or need a <connectionStrings> element, because all of the configuration of the connection is defined in the provider itself. Each provider, data source, and scenario requires slightly different configuration.

Hopefully you can see how the architecture of Claims Based Authentication allows the configuration of authentication to be separated fully from the web application itself. All you have to do is change the configuration of the IIS Web site’s Web.config file and you can completely change the source of authentication.

One additional change to Web.config is often overlooked: the <PeoplePickerWildards> element. If you don’t configure this element, the People Picker control will only accept exact matches. The People Picker is used in many places in SharePoint, including assigning tasks and assigning security permissions. There is already a <PeoplePickerWildcards> element in the Web.config file—you must simply define the wildcard that is used for your membership and role providers, as shown in the following example:

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

Two wildcard definitions are added to the default list—one for the membership provider and one for the role manager. The key tag must match the name of the provider that you configured by using Central Administration or the New-SPAuthenticationProvider cmdlet. For LDAP data sources, the value should be an asterisk (*). For SQL data sources, the value should be a percent symbol (%).

To properly configure SharePoint for Forms Based Authentication for a web application, you must configure three Web.config files:

• The Web.config file of the forms-based authentication claims-based web application

• The Web.config file of the Central Administration Web application

• The Web.config file of the Security Token Service

Assign Permissions to the User Database

SharePoint will authenticate users against the associated directory, which can be a database such as a SQL database, an LDAP directory such as an AD DS domain or an instance of AD LDS, or a custom provider. SharePoint will also use the directory to look up users, such as when you use the People Picker control to grant users or groups permissions, or to assign a task. For these reasons, the database must allow access by the application pool identities used by Central Administration, by the web application, by the Security Token Service Application, and by services.

The exact permissions required will vary based on your environment and the provider and database that you use for FBA. For example, in the environment that is built by this training kit, if you use a SQL database with the ASP.NET SQLMembershipProvider and SQLRoleProvider providers, the SQL database must allow access by the application pool identity of the web application (SP_WebApps, for example), the SharePoint farm service account (SP_Farm), which is used by Central Administration, and by the SharePoint service applications app pool identity (SP_ServiceApps), which is used by the Security Token Service Application and other services.

Validate Configuration

You can test and verify that your configuration is successful by performing the following actions:

• In Central Administration, create a test site collection in the site. When you configure the Site Collection Administrator, click the Browse button. Search for a user in the Select People And Groups dialog box. Search both with an exact match of the user name, which tests the membership provider configuration and by typing only the first few characters, which tests the PeoplePickerWildcards configuration.

• Sign in to the web application by using credentials in the FBA provider. Be certain to close any existing connections to the web application before doing so, so that any cached connections are purged. After the website has rendered, test PeoplePickerWildcards by adding a user from the membership provider and a group from the role manager to the site’s Visitors group.

Create a Site Collection for a Claims Based Authentication Web App

As mentioned earlier, you can use Central Administration to create a site collection. You can also use the New-SPSite cmdlet, as described in Chapter 2, but an additional step is required to specify a site collection administrator in the -OwnerAlias attribute. If a web application uses Windows authentication, you can simply specify the user name—for example, CONTOSO\SP_Admin. With FBA and SAML authentication providers, you must pass the user as an SPClaimsPrincipal object. To do this, you must first create the SPClaimsPrincipal object, as shown in the following example:

$cp = New-SPClaimsPrincipal -Identity "<MembershipProvider>:<SiteOwner>"
-IdentityType FormsUser

Where:

• <MembershipProvider> is the name of your membership provider

• <SiteOwner> is the user name of the user that you want to assign as the site collection owner.

You then pass the object to the New-SPSite cmdlet, as in the following example:

$cp = New-SPClaimsPrincipal -Identity "MyMembershipProvider:SiteAdministrator"
   -IdentityType FormsUser
New-SPSite -Url "https://partners.contoso.com" -Name "Contoso Partner Portal"
   -OwnerAlias $cp -Template "STS#0"

Configure SAML Token Authentication

SAML token-based authentication allows SharePoint web applications to accept claims of identity that are authenticated from an STS other than SharePoint’s STS. For example, you might configure a SharePoint web application to use Active Directory Federated Service 2.0 (AD FS 2.0) for authentication.

SAML token-based administration is the most generic and standards-based implementation of a claims-based environment. Earlier in this lesson, you learned how such an environment works: SharePoint is the relying party STS (RP-STS) and the external STS is the identity provider STS (IP-STS). The IP-STS authenticates the user against the user directory associated with the IP-STS, and then issues a token with claims about the user. The IP-STS is the conceptual equivalent of a domain controller in a claims-based environment.

Let’s follow an example. A common scenario is that two organizations want to collaborate together on a project, but each organization wants to be in full control of the user accounts in its Windows domain. AD FS is a federated authentication service, so it can be configured to use multiple mechanisms of authentication. Instead of creating a trust between each organization’s Windows domain, AD FS is configured to authenticate users against each domain, and to generate a security token for the user that can be used by the collaborative environment’s web application. The domains are the authentication provider, but AD FS is the IP-STS. Users sign in to AD FS and AD FS issues a signed SAML token with claims about the user’s identity. The RP-STS trusts AD-FS.

Tokens can include any number of claims about a user, such as a user name and groups the user belongs to, as well as descriptive attributes. The party application receives the SAML token and uses the claims inside to decide whether to grant the client access to the requested resource. Therefore, one of the claims in the token must uniquely identify the user: this is called the identity claim. The IP-STS does not have to create the identity claim with the user name that is submitted when the user logs on to the IP-STS. For example, AD FS does not have to create the identity claim with a user’s domain user name. The IP-STS can instead create the identity claim using another unique identifier. Many implementations of claims use the email address attribute as the identity claim. The RP-STS must know which claim is guaranteed to be unique for tokens created by the IP-STS.

For this reason, configuration of a claims environment using SAML token-based authentication requires cooperation between the administrators of the RP-STS and IP-STS. The following elements must be coordinated:

• In SharePoint 2010 products, each web application that is configured to use a SAML provider is added to the IP-STS server as a separate RP-STS entry. This task is performed by the owner of the IP-STS. Each web application is identified as a realm, which is simply the URL namespace associated with the relying party web application, such as https://portal.contoso.com.

• Only the owner of the IP-STS knows which value in the token will always be unique per user and therefore can be relied upon as the identity claim. That information must be communicated to the owner of the IP-STS.

• Tokens will be signed using a certificate generated by the IP-STS. That certificate must be transferred from the IP-STS to the RP-STS.

Implementing SAML token-based authentication with SharePoint 2010 products involves the following processes:

1. Export the token-signing certificate from the IP-STS. This certificate is known as the ImportTrustCertificate.

2. Copy the certificate to a server computer in the SharePoint Server 2010 farm.

3. Define the claim that will be used as the unique identifier of the user. Identifying the unique identifier for the user is part of the claims-mapping process. Claims mapping is performed by using Windows PowerShell.

4. Define additional claims mappings. Define other values in the token that will be used by the RP-STS. For example, many tokens include a value that specifies user roles that can be used to permission resources in the SharePoint Server 2010 farm. All claims from an incoming token that do not have a mapping will be discarded.

5. Create a new authentication provider by using Windows PowerShell. This process creates the SPTrustedIdentityTokenIssuer.

   During this process, you submit the ImportTrustCertificate, the identity claim mapping, and additional claim mappings. You must also create and specify a realm—the URL namespace that is associated with the first SharePoint web applications that you are configuring for SAML token-based authentication.

   After the SPTrustedIdentityTokenIssuer is created, you can create and add more realms for additional SharePoint web applications. This is how you configure multiple web applications to use the same SPTrustedIdentityTokenIssuer.

6. For each realm that is added to the SPTrustedIdentityTokenIssuer, you must create an RP-STS entry on the IP-STS.

7. Create a new SharePoint web application and configure it to use the newly created authentication provider. The authentication provider will appear as an option in Central Administration when claims mode is selected for the web application.

You can configure multiple SAML token-based authentication providers. However, you can only use a token-signing certificate once in a farm. All providers that are configured will appear as options in Central Administration. Claims from different trusted STS environments will not conflict.

If you are implementing SAML token-based authentication with a partner company and your own environment includes an IP-STS, we recommend that you work with the administrator of your internal claims environment to establish a trust relationship from your internal IP-STS to the partner STS. The result is a type of chain of trust and authentication. This approach does not require adding an additional authentication provider to your SharePoint Server 2010 farm. It also allows your claims administrators to manage the whole claims environment.

Multiple Authentication Providers

In SharePoint 2007, if you wanted users to authenticate to a web application using both Windows authentication and Forms Based Authentication, you were required to extend the web application to a second zone. A zone is a URL namespace through which a web application can be accessed. You could then configure one zone to use Windows authentication, such as http://extranet.contoso.com, and another zone to use Forms Based Authentication, such as https://partners.contoso.com.

In SharePoint 2010, this is no longer necessary. If a web application is configured for Claims Based Authentication, you can use multiple authentication providers in a single zone. You will learn more about zones in Lesson 3.

Choose an Authentication Type

As you’ve learned, the default authentication type is Classic Mode Authentication, which supports only the Windows authentication provider and its methods, NTLM and Kerberos, as well as the less regularly used Basic and Digest authentication provided by IIS. When you upgrade a web application, it is upgraded to Classic Mode Authentication.

When you create a new web application, the default is Classic Mode Authentication. If you will use FBA or SAML token-based authentication, you must choose Claims Based Authentication. If you will use only Windows authentication, you can choose either Classic Mode Authentication or Claims Based Authentication.

Although many resources recommend that you use Claims Based Authentication by default for all new web applications, it is important that you test the functionality of the web application in a lab environment before deploying it in production. Depending on the scenario, Claims Based Authentication might not be the best choice. Claims Based Authentication is a new feature in SharePoint Server 2010, and the community is only now learning the nuances of its implementation. Search the Internet for known issues related to Claims Based Authentication, such as the following:

• Custom code might need to be updated. Web Parts or other custom code that relies on or uses Windows identities will have to be updated. If the custom code uses Windows identities, use Classic Mode Authentication until the code is updated.

• Search alerts are currently not supported with claims-based authentication.

• There are problems using the audiences feature with some authentication providers.

• LDAP environments can be implemented by using either forms-based authentication or SAML token-based authentication. We recommend that you use forms-based authentication because it is less complex. However, if the environment supports WS-Federation 1.1 and SAML Token 1.1, SAML is recommended. Profile synchronization is not supported with LDAP providers that are not associated with ADFS 2.0.

Convert Web Applications to Claims Authentication

If you create a web application with Classic Mode Authentication, you can convert the web application to Claims Based Authentication. This is also important if you upgrade a SharePoint 2007 web application that uses Forms Based Authentication to SharePoint 2010. By default, an upgraded application is configured for Classic Mode Authentication. Classic Mode Authentication does not support FBA, so the application will not be accessible by FBA users until it is converted to Claims Based Authentication.

Before you convert to Claims Based Authentication, you should be aware of considerations related to Claims Based Authentication, as discussed in the previous section.

CONVERT A WEB APPLICATION TO CLAIMS BASED AUTHENTICATION

In SharePoint 2010 Management Shell, type the following:

$w = Get-SPWebApplication "http://<WebApplicationURL>/"
$w.UseClaimsAuthentication = 1
$w.Update()
$w.ProvisionGlobally()

Where:

• <WebApplicationURL> is the URL of the web application that you want to convert to Claims Based Authentication.

After converting the web application, you must migrate users and permissions to account for the new authentication scheme.

MIGRATE USERS AND PERMISSIONS

In SharePoint 2010 Management Shell, type the following:

$w = Get-SPWebApplication "http://<WebApplicationURL>/"
$w.MigrateUsers(True)

Where:

• <WebApplicationURL> is the URL of the web application for which you want to migrate users and permissions.

This process can take quite some time to complete. Be sure to test it in a lab environment so that you can budget appropriate service windows within which to perform the migration in the production environment.

PRACTICE: Configure Authentication

Practices are designed to guide you through important procedures. The instructions in the Training Kit are high-level instructions that will challenge you to think carefully and to apply the procedures that are covered in this lesson, and elsewhere in the Training Kit. If you need assistance, consult the detailed, step-by-step instructions in the Practice Answers on the companion media.

In this practice, you will configure authentication for the Contoso Partner Portal web application. First, you will enable anonymous access. Then, you will re-create the application configured to use Claims Based Authentication. You will create a database of users as an identity store for the SQLMembershipProvider, and you will configure Forms Based Authentication for the web application.

Prepare for the Practice

Before you perform this practice, you must ensure that your lab environment has been built according to the instructions found in the Introduction to this Training Kit. You must also have performed the practice in Lesson 1 of this chapter. If you are currently logged on to SP2010-WFE1, log off before beginning the exercises.

EXERCISE 1 Configure Anonymous Access

In this exercise, you configure anonymous access to the Contoso Partner Portal that you created in the practice of Lesson 1.

1. Log on to SP2010-WFE1 as CONTOSO\SP_Admin with the password Pa$$w0rd.

2. In Central Administration, enable anonymous authentication for the Contoso Partner Portal web application.

3. Open a new tab of Internet Explorer, and then browse to https://partners.contoso.com.

   An error page opens: There is a problem with this website’s security certificate. Continue to the website.

   The site is loaded, compiled, and cached for first-time access, and then the site opens.

   If an error appears, refresh the page. It is possible that the client timed out while the site was being loaded by IIS.

4. Enable anonymous access to the entire website.

5. Close the tab of Internet Explorer that displays the Partners site, start a new instance of Internet Explorer, and then browse to https://partners.contoso.com.

   You must use a new instance to clear the cache of the authenticated sign-in.

6. Observe that the Welcome control in the upper-right corner of the page reads, “Sign In.”

   You are not yet authenticated to the site.

7. Click Site Actions, and then observe that you do not have access to administrative pages as an anonymous user.

8. Close the instance of Internet Explorer that displays the Partners site.

EXERCISE 2 Delete a Web Application

In this exercise, you delete the Contoso Partner Portal site. In the following exercises, you will re-create the application so that it uses Claims Based Authentication.

• Delete the Contoso Partner Portal site. Be sure to delete the content databases and the IIS sites.

EXERCISE 3 Create a Web Application with Claims Based Authentication

In this exercise, you create a web application for collaboration with partners of Contoso. The web application will use Claims Based Authentication with the Windows authentication provider.

• Use Central Administration to create a web application collaboration with partners. Use the following specifications and guidance:

  • Authentication: Claims Based Authentication

  • Name: Contoso Partner Portal

  • Port: 443

  • Host header: partners.contoso.com

  • Authentication provider: Negotiate (Kerberos)

  • Anonymous authentication: No

  • Secure Sockets Layer (SSL): Yes

  • URL: https://partners.contoso.com:443

  • Application pool: SharePoint Extranet Applications

  • Application identity: CONTOSO\SP_WebApps

  • Content database name: SharePoint_Content_Partners

EXERCISE 4 Create a Site Collection Using Central Administration

In this exercise, you use Central Administration to create a site collection at the root of the new web application.

1. Use Central Administration to create a site collection. Use the following specifications and guidance:

   • Web application: https://partners.contoso.com

   • Title: Contoso Partner Portal

   • Description: Sites for collaboration with partners

   • URL: https://partners.contoso.com/

   • Template: Team Site

   • Primary site collection administrator: CONTOSO\SP_Admin

2. Open a new tab of Internet Explorer, and then browse to https://partners.contoso.com.

   An error page opens: There is a problem with this website’s security certificate. Continue to the website.

   The site is loaded, compiled, and cached for first-time access, and then the site opens.

   If an error appears, refresh the page. It is possible that the client timed out while the site was being loaded by IIS.

EXERCISE 5 Configure Forms Based Authentication

In this exercise, you configure the Contoso Partner Portal to use Forms Based Authentication. You then examine the Web.config files for the web application, Central Administration, and STS, in which you will identify the locations that you must modify to configure the authentication provider.

You will not complete the configuration of FBA because that requires establishing an external database of users. The Suggested Practice at the end of this chapter gives you the opportunity to complete the process.

1. In the Central Administration, configure the Contoso Partner Portal web application using the following specifications and guidance:

   • Authentication provider #1: Integrated Windows authentication with the Negotiate (NTLM or Kerberos) method

   • Authentication provider #2: Forms Based Authentication

   • ASP.NET membership provider: MyMembershipProvider

   • ASP.NET role manager: MyRoleManager

EXERCISE 6 Configure Web.config Files

In this exercise, you examine the Web.config files for the web application, Central Administration, and STS, in which you will identify the locations that you must modify to configure the authentication provider for FBA. You will not actually complete the configuration of FBA because FBA requires an external database of users. The Suggested Practice, at the end of this chapter, gives you the opportunity to complete the process.

1. Open the Web.config file of the Contoso Partner Portal IIS Web site.

2. Search for the <connectionStrings> element.

   This file does not have an existing <connectionStrings> element. In a production environment, a Web.config file might already have a <connectionStrings> element, in which case you would simply register the new connection string by inserting an <add> element.

   The <connectionStrings> section must be a child element of <configuration>, which is the root element of Web.config. In other words, <connectionStrings> must be a first-level element. It is common practice to place it immediately before the <system.web> element begins.

3. Search for the beginning of the <system.web> element.

   Be certain that the <system.web> element that you find is a first-level element—a child of <configuration>. Some <system.web> elements are lower-level children of other elements.

4. Inside the <system.web> element, find the <membership> element. Inside the <membership> element, find the <providers> element.

   The <providers> element contains child <add> elements that define each membership provider. You can register a new provider in this element.

   The name attribute of the <add> element must match the name that you configured as the ASP.NET Membership Provider in the web application. If the provider uses a connection string, the connectionStringName attribute must match the name of the connection string that you added to the <connectionStrings> element.

5. Inside the <system.web> element, find the <roleManager> element. Inside the <roleManager> element, find the <providers> element.

   The <providers> element contains child <add> elements that define each role provider. You can register a new provider in this element.

   The name attribute of the <add> element must match the name that you configured as the ASP.NET Membership Provider in the web application. If the provider uses a connection string, the connectionStringName attribute must match the name of the connection string that you added to the <connectionStrings> element.

6. Find the <PeoplePickerWildcards> element.

   The <PeoplePickerWildcards> element defines, for each custom authentication provider, the wildcard that can be used when searching for a user in the People Picker. Without a wildcard definition, the People Picker will locate only the user that is an exact match to the search criteria. With a wildcard defined, you can enter the first characters of the user’s name and the search will locate all matching users.

   Each wildcard is defined by an <add> element in the <PeoplePickerWildcards> element. You can register the wildcards for your membership provider and role provider in this element.

   The keys must match the name of the membership and role providers that have been configured for the web application. For a SQL database, the wildcard value is %. For an LDAP directory, the wildcard value is *.

Lesson Summary

• If you want to enable anonymous users to access content in a SharePoint website, you must first enable anonymous authentication for the web application zone. Then a site collection administrator can enable anonymous access to an entire site—and to the objects in the site that inherit permissions from the site—or to individual lists and libraries. Finally, a farm administrator can enforce anonymous access restrictions, which are policies applied to a web application zone that prevent anonymous users from changing or even accessing content.

• SharePoint supports two authentication types: Classic Mode Authentication and Claims Based Authentication.

• In Classic Mode Authentication, users are authenticated by Windows—NTLM, Kerberos, Basic, or Digest authentication—and the resulting security token is passed by IIS to SharePoint. SharePoint translates the token to an SPUser object, which represents the user and his or her groups to the web application.

• In Claims Based Authentication, an unauthenticated user is redirected to the Security Token Service, which authenticates the user then provides the user with a token that contains claims about the user’s identity, and can contain claims about the user’s roles and other attributes. The web application trusts the token that was generated and signed by the STS, and translates the claims to an SPUser object.

• Windows Authentication and its methods are supported by both Classic Mode Authentication and Claims Based Authentication.

• Forms Based Authentication is an authentication provider supported by Claims Based Authentication. A user is redirected to a form and submits credentials, typically a user name and password. An authentication method validates the credentials. The authentication method can be the ASP.NET SQLMembershipProvider, which uses a SQL database of users as a directory; an LDAPMembershipProvider, which uses an LDAP directory such as an AD DS domain or instance of AD LDS as a directory; or a custom membership provider. FBA can also use a role manager to provide a list of the groups to which a user belongs. The user identity and roles are converted by the STS to a token.

• SAML token-based authentication uses Security Assertion Markup Language (SAML) tokens issued by an IP-STS external to SharePoint, such as AD FS 2.0. The trusted identity provider is registered with the SharePoint farm by importing the trust certificate of the IP-STS. Web applications can then be configured to use the trusted identity provider.

• When you upgrade a SharePoint 2007 web application that uses FBA, the application is configured to use Classic Mode Authentication, which does not use FBA, so the application will be inaccessible to FBA users. You must convert the application and then migrate users and permissions—tasks that you perform by using Windows PowerShell.

Lesson Review

You can use the following questions to test your knowledge of the information in Lesson 2, “Configure Authentication.” The questions are also available on the companion media in a practice test if you prefer to review them in electronic form.

1. You have just configured a web application to use the Negotiate (NTLM or Kerberos) authentication method of the Windows authentication provider. What else must you do to configure Kerberos authentication?

   1. Use Setspn.exe.

   2. Add an SSL binding to the IIS Web site.

   3. Register a trusted identity provider.

   4. Configure the Web.config file of the web application.

2. You have just configured a web application to use the Negotiate (NTLM or Kerberos) authentication method of the Windows authentication provider. How can you verify that the Kerberos protocol is being used? (Choose all that apply.)

   1. Browse to the website. If the website opens, Kerberos authentication is working properly.

   2. Browse to the website, then examine the Security event log of the client.

   3. Browse to the website, then examine the Security event log of the server.

   4. Use Klist.exe on the server.

   5. Use Klist.exe on the client.

   6. Use Setspn.exe.

3. WebApp1 contains a single site collection. You want to allow site collection administrators to be able to grant anonymous users read-only access to content in WebApp1, based on business requirements known to the administrators. What do you do? (Choose all that apply. Each correct answer is a part of the solution.)

   1. In the Site Permissions page of the top-level website in the site collection, enable anonymous access with the Entire Site option.

   2. Configure anonymous access restrictions on all zones with the Deny Write option.

   3. Enable anonymous access on the web application.

   4. In the Site Permissions page of the top-level website in the site collection, enable anonymous access with the Lists and Libraries option.

4. You have created a web application that uses Classic Mode Authentication and the NTLM authentication method. You want to provide access to users at a partner organization. Their accounts will be kept in a SQL database. What must you do to provide this access? (Choose all that apply. Each correct answer is a part of the solution.)

   1. Modify firewall settings to open port 389 to inbound TCP traffic.

   2. Create SQL logins for each partner user.

   3. Modify Web.config files.

   4. Convert the web application to Claims Based Authentication.

   5. Use Central Administration to configure the membership provider and the role provider of the web application.

5. You have just configured WebApplication1 to use Forms Based Authentication by modifying the authentication provider. When you attempt to authenticate to the website, an error appears. What else do you have to do? (Choose all that apply. Each correct answer is a part of the solution.)

   1. Modify the Web.config file of Central Administration.

   2. Modify the Web.config file of the Secure Store Service.

   3. Modify the Web.config file of the Security Token Service Application.

   4. Modify the Web.config file of the web application.

   5. Assign permissions to application pool identities.