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

Lesson 3: Configure Authentication Zones and Alternate Access Mappings

In Lesson 1, you learned to create and configure a web application, including the steps used to configure secure communication over SSL. In Lesson 2, you explored the management and configuration of authentication methods, including anonymous authentication. In some environments, users will access a SharePoint web application with a single protocol and URL—for example, https://partners.contoso.com will authenticate with a single provider, such as Windows authentication, and will be subject to a single set of policies.

But what if you want external users to access a web application using one URL and protocol, such as https://partners.contoso.com, and to be authenticated with Forms Based Authentication, but you want internal users to access the web application with a different URL and protocol, such as http://extranet.contoso.com? What if you want to enhance security and performance by implementing off-box SSL termination or a reverse proxy?

In these scenarios, you need zones and alternate access mappings. These concepts can be challenging to understand, and even more challenging to implement, because of the loose association between web applications, IIS sites, zones, intermediate devices, and alternate access mappings. In this lesson, you will learn to manage these components of a SharePoint implementation.

Requesting SharePoint Content: Access Mappings, Zones, and URLs

Earlier in this Training Kit, you learned the high-level processes related to requests for content from SharePoint. Let’s return to this process by following an example. A user wants to access the home page of the Contoso intranet. The user enters the URL http://intranet.contoso.com in a browser. The public URL of the Contoso Intranet Web application is http://intranet.contoso.com—the URL requested by the user. The client queries DNS to resolve the host name intranet.contoso.com to the IP address, 10.0.0.21, which happens to be an IP address bound to a network interface of a server named SP2010-WFE1. The request, http://intranet.contoso.com, is sent to 10.0.0.21 over the standard port for HTTP, port 80. The host header of the request contains intranet.contoso.com, the host name and domain name of the user’s request.

Now, let’s dig deeper into some of the processes that connect the user to the requested content. On SP2010-WFE1, IIS receives the user’s request over port 80 and must determine which IIS Web site will service the request. IIS examines the bindings of each site and identifies the Contoso Intranet site as the correct site, because the site is bound to port 80 and the host header, intranet.contoso.com. IIS passes the request to SharePoint. The internal URL of the Contoso Intranet Web application is the URL of the website as it is received by IIS and passed on to SharePoint. In this simple example, the internal URL is also http://intranet.contoso.com—the same URL is passed, unchanged, from the user to IIS to SharePoint. But you will soon learn that it is not always so simple.

Access Mappings

So far, this example illustrates, in more depth, the processes used to fulfill requests for SharePoint content in the most simple environment. Let’s now turn our attention to the architectural components and concepts that enable SharePoint to determine which web application should respond to the request.

SharePoint must now determine which SharePoint web application will service the request. SharePoint does not maintain a one-to-one mapping with an IIS Web site. SharePoint web applications and IIS Web sites are two separate entities, although they maintain a close relationship.

Therefore, the fact the Contoso Intranet IIS Web site received the request is not sufficient for SharePoint to know that the Contoso Intranet SharePoint web application must continue processing the request. Instead, SharePoint must examine the URL of the request that has been passed to it by IIS. Again, in this simple example, the URL is http://intranet.contoso.com.

SharePoint compares this URL to its access mappings. An access mapping associates a URL to a zone of a specific SharePoint web application. SharePoint sees that the URL, http://intranet.contoso.com, is associated with the default zone of the Contoso Intranet Web application. SharePoint can then continue processing the request in the context of the Contoso Intranet Web application, and return the requested content to the user.

Zones

In the previous paragraph, a new concept was introduced: the zone. A zone is a logical path through which users gain access to a web application. The public face of the zone—the property by which a zone is accessed—is the URL. The zone has other properties that determine how the web application is accessed. For example, the authentication provider is defined for the zone, as are policies including anonymous access restrictions and user policy.

When you create a web application, you also create a zone for the web application named Default, also referred to as the default zone. When you configure the authentication providers for the new web application, the configuration is actually applied to the default zone, not to the web application as a whole. The Public URL setting that you specify when you create the new web application is used to create access mappings that apply the URL as both the public URL and the internal URL associated with the default zone. As you saw earlier, the public and internal URLs are often the same.

A web application can include as many as five zones. The default zone is required, is created automatically, and can be modified. But you cannot delete the default zone. It is deleted automatically when you delete the web application. The four additional zones are optional, can be created, modified, and deleted, and are named intranet, extranet, Internet, and custom.

To define an additional zone, you simply create an access mapping that associates a unique URL to one of the four additional zones, and then users can access the web application through the new URL. For example, you could add a URL, http://company.contoso.com, to the Contoso Intranet Web application as the URL for the zone named intranet. Users could then access the Contoso Intranet Web application using either http://company.contoso.com or http://intranet.contoso.com. Of course you would need to be certain that there was a DNS host record to resolve the names to the IP address of the server, and you would need to add a host header binding to the IIS Web site so that the site would respond to requests to company.contoso.com as well as to http://intranet.contoso.com.

The most important thing to know about a zone at this point in the discussion is that after you have defined an additional zone, the content that users access through the new URL is the same content they access through the default zone. Zones are simply different logical paths to the same web application—an association between the protocol, scheme, hostname, and port of an inbound request from a client, and the web application that will respond to the request.

URLs of SharePoint Site Collections and Content

Let’s take a short digression to examine the answer to the question, “What happens next?” Let’s assume one user browses to http://intranet.contoso.com, the home page of the Contoso intranet, shown in Figure 3-12, and clicks the link to the Company Calendar. You can see in Figure 3-12 that the URL to the Company Calendar is http://intranet.contoso.com/Lists/CompanyCalendar/calendar.aspx.

What if another user accesses the same Contoso intranet application by entering the URL, http://company.contoso.com? When that user clicks the link to the same Company Calendar, the URL will be http://company.contoso.com/Lists/CompanyCalendar/calendar.aspx.

How is it that two different users can submit two URLs and access the same content?

Conceptually, SharePoint itself considers the address of the Company Calendar to be <WebApplicationURL><SiteCollectionURL>Lists/CompanyCalendar/calendar.aspx, where <WebApplicationURL> is the Public URL of the zone, such as http://intranet.contoso.com:80, and <SiteCollectionURL> is the URL of the site collection relative to the web application. For example, the intranet site collection is at the root of the web application, with the relative URL /. The URL of content within a site collection is always stored as a value relative to the site collection itself. For example, SharePoint considers the URL of the company calendar to be Lists/CompanyCalendar/calendar.aspx.

SharePoint renders the home page of the intranet and generates the hyperlink to the Company Calendar by replacing the variables with their values. For the user that accesses the Contoso intranet through the default zone, the resulting hyperlink target URL is http://intranet.contoso.com/Lists/CompanyCalendar/calendar.aspx. SharePoint removes the port, 80, because it is the default port for HTTP. If the Public URL included a non-standard port, it would be included in the link to the Company Calendar. For the user that accesses the Contoso intranet through the intranet zone, the resulting hyperlink target URL is http://company.contoso.com/Lists/CompanyCalendar/calendar.aspx.

By abstracting the URL of the web application and the relative URL of the site collection, SharePoint allows a user to access content through more than one URL, or zone. It also enables you to move content easily. If you create a new web application with the public URL http://portal.contoso.com:80, and you move the content database from the intranet web application to the portal web application, the URL to the Company Calendar will immediately be generated as http://portal.contoso.com/Lists/CompanyCalendar/calendar.aspx. The site collection relative URL, and the relative URL of the Company Calendar did not change—only the web application hosting the site collection changed. Similarly, if you change the external URL of the extranet zone from http://company.contoso.com to http://portal.contoso.com, the URL of the Company Calendar would be rendered with the new hostname.

Access Mappings

Now that you understand the fundamental concepts of access mappings and zones, let’s explore in more detail how you manage each.

You have learned that an access mapping, also called an alternate access mapping, associates a URL to a zone of a specific SharePoint web application. Behind the scenes, in the SharePoint object model, an access mapping is called an alternate URL—it is an SPAlternateURL object in a collection called SPAlternateURLCollection that is a member of the web application. Wouldn’t it have been easier if they just called these alternate URLs?

You can manage URLs from the Alternate Access Mappings page of Central Administration.

MANAGE ALTERNATE ACCESS MAPPINGS

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

2. In the Web Applications section, click Configure Alternate Access Mappings.

   The Alternate Access Mappings page, shown in Figure 3-13, opens.

From here, you can do the following:

• Click the Alternate Access Mappings Collection selector to pick the web application that you want to modify.

• Click Edit Public URLs to add, modify, or delete the public URL of each zone.

• Click Add Internal URLs to add an internal URL to a zone.

• Click Map To External Resource to configure a URL that maps to a resource outside of SharePoint.

• Click an internal URL to edit or delete the internal URL.

It is easy to understand why the public URL and the internal URL are often the same. A user enters the public URL, http://intranet.contoso.com, and IIS receives the request with the same URL and passes the request to SharePoint, which inspects the request and extracts the URL as the internal URL.

It gets more interesting when you answer the question, “Why would the internal URL be different than the public URL?” We will answer the question with two common scenarios:

• Single-label host names and fully qualified host names

• Off-Box SSL Termination

In the process of exploring these scenarios, you will learn the purpose of the internal URL and of the public URL.

Single-Label Host Names and Fully Qualified Host Names

You have configured the Contoso Intranet Web application with the URL http://intranet.contoso.com. This URL is the URL of the web application—a property in and of itself—and it is both the public URL and the internal URL of the web application’s default zone. Let’s assume you want to allow users to get to the intranet by typing http://intranet or with the current URL, http://intranet.contoso.com.

This scenario is supported by two access mappings: You add http://intranet as an additional internal URL to the default zone. When a request for http://intranet is passed to SharePoint by IIS, SharePoint will identify the URL as the internal URL of the default zone of the Contoso Intranet Web application, and will be able to serve the website to the user.

ADD INTERNAL URLS

1. On the Alternate Access Mappings page, click Add Internal URLs.

   The Add Internal URLs page opens.

2. Confirm that the Alternate Access Mapping Collection list displays the web application that you want to modify.

   If it does not, click the list, then click Change Alternate Access Mapping Collection, and then click the name of the web application that you want to modify.

3. In the URL Protocol, Host And Port box, type the internal URL that you want to add.

   The URL should include the protocol and host name, and the port—for example, http://intranet:80. Although you can omit the port if it is a standard port, it is recommended that you use the port for clarity and documentation.

4. In the Zone list, select the zone with which to associate the internal URL and click Save.

The internal URL—http://intranet in this example—allows SharePoint to determine which SharePoint web application is being accessed, and through which of that web application’s zones. However, the request has to be passed by IIS to SharePoint before that can happen. When you add an internal URL, SharePoint does not add a corresponding host header binding to the IIS Web site. You must manually add the host name of the internal URL as a host header binding to the IIS Web site on each server that will respond to the internal URL.

This is not applicable if you are not using host headers—for example, if you have a dedicated IP address bound to the IIS Web site.

ADD A BINDING TO AN IIS WEB SITE

1. In IIS Manager, in the console tree, expand the server, then expand Sites, and then click the site to which you want to add a binding.

2. In the Actions pane, click Bindings to open the Site Bindings dialog box.

3. Click Add to open the Add Site Binding dialog box.

4. In the Type box, select the protocol—http or https.

5. In the Host Name box, type the host name.

6. Click OK and then click Close.

After an internal URL has been created, you can modify or delete the URL. On the Alternate Access Mappings page, click the URL in the Internal URL column. If you modify or delete an internal URL, be certain to modify bindings on the IIS Web site accordingly.

In our scenario, users can now request http://intranet, which has been added as an internal URL to the default zone, as shown in Figure 3-13. The zone now has two internal URLs and one public URL, http://intranet.contoso.com.

Let’s consider what happens when a user requests http://intranet. The request arrives at the web server. The host header binding enables IIS to pass the request to the Contoso Intranet IIS Web site. The website’s SharePoint processes receive the request and examine the URL to determine that the request is for the Contoso Intranet Web application. It is now time for SharePoint to render the content of the intranet home page to the user. Remember, from the example presented earlier, that the home page has a link to the company calendar. SharePoint thinks about the link in relative terms. SharePoint considers the URL for the company calendar to be /Lists/CompanyCalendar/calendar.aspx. When SharePoint renders the link, it adds the public URL of the web application—more specifically, of the zone—to the URL. Therefore, the link that SharePoint renders for the company calendar is http://intranet.contoso.com/Lists/CompanyCalendar/calendar.aspx. SharePoint does not render the link as http://intranet/Lists/CompanyCalendar/calendar.aspx.

In this scenario, there is no problem. When a user clicks the link to the company calendar, the user can access the calendar with the http://intranet.contoso.com URL. In fact, all URLs will be rendered with the fully qualified domain name of the host—with the public URL. The first thing that a user clicks will take the user out of the http://intranet URL namespace into the http://intranet.contoso.com namespace. Again, no problem is caused—access is still possible. You have simply given users an alternate, shorter URL with which to get to the intranet home page.

Off-Box SSL Termination

The previous scenario was straightforward. Let’s explore a slightly more complex scenario. You have configured the Contoso Partner Portal to use SSL with the URL https://partners.contoso.com. This is both the public URL and the internal URL of the web application’s default zone.

You decide that you want to reduce the performance burden that SSL places on the web server by installing a device that performs off-box SSL termination. This is a device that is placed on the network, logically, between the user and the web server. The device receives the request using SSL over port 443, decrypts the request, and forwards it to the web server, unencrypted, over http with port 80.

In this configuration, users continue to browse to the public URL https://partners.contoso.com. DNS resolves the IP address as the network interface of the off-box SSL terminator. The device receives the packet, does its magic, and then forwards the request to IIS as http://partners.contoso.com. IIS passes the request to SharePoint, and the internal URL is http://partners.contoso.com.

This scenario is addressed with one access mapping. To support this configuration, you must define the zone so that the public URL is https://partners.contoso.com, and the internal URL is http://partners.contoso.com.

SharePoint must understand that the URL, http://partners.contoso.com, is associated with the default zone of the Contoso Partner Portal web application, so that SharePoint can retrieve the requested content. The internal URL is the mapping that is important for SharePoint to process inbound requests. For this scenario to work, the internal URL of the zone must be http://partners.contoso.com:80, although you can optionally leave out the port if the URL uses the standard port for the protocol.

It is also important that SharePoint knows that, to the user, the web application is known as https://partners.contoso.com, because SharePoint must render hyperlinks and other URLs so that they will be accessible to the user. Consider, again, the link to the company calendar. If SharePoint rendered the link using the internal URL, it would be http://partners.contoso.com/Lists/CompanyCalendar/calendar.aspx, and the user would not be able to click the link and connect to the content successfully.

That is why the public URL is important. The public URL is also referred to as the outgoing URL or the response URL. In this example, the public URL for the default zone is https://partners.contoso.com:443. It is the public URL that is used to ensure that URLs are rendered correctly for users. Because SharePoint knows that the request arrived with an internal URL associated with the default zone, and that the public URL for the default zone is https://partners.contoso.com:443, SharePoint renders the link to the Company Calendar as https://portal.contoso.com/Lists/CompanyCalendar/calendar.aspx. The user is therefore able to click the link and navigate to the company calendar.

To support the preceding off-box SSL termination scenario, if you have created the web application using SSL as https://partners.contoso.com, the public URL is already correct. Add an internal URL, http://partners.contoso.com. The resulting Alternate Access Mapping (AAM) collection for the Contoso Partner Portal application is shown in Figure 3-14.

The second access mapping is the one that supports the scenario. In this case, the first access mapping is a special mapping that cannot be deleted. For each web application, one access mapping represents the default zone. You can recognize this mapping because when you click the URL on the Alternate Access Mappings page, the Delete button is disabled—you cannot delete the mapping. The public URL and the internal URL of this mapping are the same. You cannot change one without changing the other. We recommend that you do not change this mapping in any way. Instead, add other internal URLs to the default zone, and extend the web application to create new zones.

Load Balancing with Request Overwrites

A load balancer is a service or device that distributes inbound requests to more than one web server. The web server that services the request returns the content to the user. For example, let’s say a user requests intranet.contoso.com/SitePages/Home.aspx. The public URL of the zone is thus http://intranet.contoso.com. The load balancer, which can be the Network Load Balancing (NLB) service provided by Windows Server 2008 or a dedicated hardware device, receives the request. Two web servers, named SP2010-WFE1 and SP2010-WFE2, host the intranet web application. The load balancer uses rules, which can be as simple as a round-robin algorithm, to determine the server that will serve the request. The request is distributed to one of the servers.

Many load balancers use a shared IP address that receives the request, and then the load balancer forwards the request to the IP address of one of the servers. If this mechanism is used, the URL sent to IIS is the same URL received by the NLB service. There is no need to change access mappings or to create additional zones.

Some load balancers overwrite the request received from the client and submit the request to the web server. For example, let’s say a load balancer receives a request for http://intranet.contoso.com/SitePages/Home.aspx. It changes the URL of the request to address a specific server. The new URL is http://intranet02.contoso.com/SitePages/Home.aspx.

The request is received by SP2010-WFE2, which hosts the intranet web application. The IIS Web site must be bound to intranet02.contoso.com on SP2010-WFE2. Similarly, the IIS Web site must be bound to intranet01.contoso.com on SP2010-WFE1. IIS passes the request to SharePoint as http://intranet02.contoso.com/SitePages/Home.aspx. SharePoint must return the content to the user. To achieve this, the zone must be mapped to the public URL http://intranet.contoso.com and there must be two internal URLs: http://intranet01.contoso.com and http://intranet02.contoso.com.

Review Internal and Public URLs

To summarize, each web application zone has one or more internal URLs. When an inbound request is received by IIS and passed to SharePoint, the URL is examined and matched to an internal URL to determine which web application is being accessed, and through which zone. In simple environments, the internal URL of a zone will be the same as the public URL.

The internal URL will be different from the public URL of a zone if a device or service changes the URL that the user requests. For example, an SSL termination service or device changes the protocol of the request from HTTPS to HTTP. A user requests https://partners.contoso.com over port 443 and an SSL termination device forwards the request to http://partners.contoso.com over port 80. Or, a load balancer uses request overwrites to forward the requests to a web server.

Public URLs

You can also modify the public URLs of a web application. Remember that the primary purpose of the public URL is to enable SharePoint to render content correctly to users. SharePoint uses the public URL as the URL of the web application as it renders hyperlinks and other URLs.

EDIT THE PUBLIC URLS OF A WEB APPLICATION

1. On the Alternate Access Mappings page, click Edit Public URLs.

2. On the Edit Public Zone URLs page, confirm that the Alternate Access Mapping Collection list displays the web application that you want to modify.

   If it does not, click the list, then click Change Alternate Access Mapping Collection, and then click the name of the web application that you want to modify.

3. Enter, edit, or delete the URLs that users use to access the web application.

4. Click Save.

Manage Zones

A zone, as you’ve learned, is a logical path to a web application and, technically, is the result of an access mapping that associates a URL and a web application. Five zones are available for each SharePoint web application: default, intranet, Internet, extranet, and custom.

You can create and delete a zone in a web application in two ways: You can define an alternate access mapping, or you can extend and unextend the web application. You will learn both methods in this section, but it is highly recommended that when you want to create or delete a zone, you always extend or unextend the web application, respectively.

Define an Alternate Access Mapping

Let’s start with the method that is not recommended: defining an Alternate Access Mapping (AAM).

You learned how to add internal and public URLs earlier in the lesson, in the procedures “Add Internal URLs” and “Edit the Public URLs of a Web Application”. If you add a URL to a zone that was previously undefined, you create the zone. The URL you specify as the internal or Public URL of an undefined zone is also added as the public or internal URL, respectively, so that the zone has both the required public URL and the required first internal URL.

Conversely, if you clear the public URL of a zone, or if you delete the last internal URL of a zone, you delete the zone.

It is not recommended to create and delete zones in this fashion. The following are best practices that relate to access mappings and zones:

• Do not add an internal URL associated with a zone that does not yet exist. Doing so creates a zone without an associated website. Instead, extend the web application.

• Do not add a public URL to a zone that does not yet exist. Doing so creates a zone without an associated website. Instead, extend the web application.

• Do not delete the last internal URL associated with a zone. Doing so deletes the zone without deleting the associated website. Instead, unextend the web application.

• Do not remove the public URL associated with a zone. Doing so deletes the zone without deleting the associated website. Instead, unextend the web application.

Extend a Web Application

The second, and recommended method to create a new zone in SharePoint 2010 is to extend a web application. When you extend a web application, you create a new zone and an associated IIS Web site.

EXTEND A WEB APPLICATION

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 to extend.

4. On the ribbon, click Extend.

5. On the Extend Web Application To Another IIS Web Site page, click Create A New IIS Web Site.

6. In the Name box, type a name that is easily recognizable in IIS Manager, such as Contoso Partners Extranet.

7. In the Port box, type the port number. If you are using HTTP, this is usually port 80; HTTPS is usually 443.

8. In the Host Header box, type the host header, which is usually the FQDN of the zone, such as extranet.contoso.com.

   You should configure the host header even if you plan to bind the IIS Web site to a unique IP addresses. The host header becomes the internal URL of the site.

9. Configure the settings in the Security Configuration section. See the section, “Security Configuration,” earlier in this chapter for more information.

10. In the Public URL section, in the URL box, type the external URL of the zone, such as http://extranet.contoso.com:80.

11. In the Zone list, select the zone to which you want to extend the web application, and then click OK.

When you extend a web application, an IIS Web site is created. The IIS Web site for the zones will share the application pool of the web application’s other zones. Do not change the application pool associated with a zone.

The Case for Extending Web Applications

Why is it not recommended to create a zone by defining an access mapping, and why is it recommended to do so by extending the web application? You will learn several reasons in this lesson. The first is that the access mappings you create manually are not added to the IIS site underlying the web application. You must therefore manually change the bindings of the IIS site on each web server in the farm to add the new URL as a host header binding. If you add a new server to the farm, SharePoint will create the IIS site on the new server, but will not add the URLs that you added as access mappings. Similarly, if you delete the web application and IIS site, and then restore the web application from a SharePoint backup, SharePoint will re-create the IIS site but will not re-create the bindings.

These problems illustrate one of the separations between SharePoint and IIS: Changes made directly to IIS are not stored in the SharePoint configuration database; therefore, you cannot manage the settings by using SharePoint.

More important, when you create a zone by defining an access mapping in SharePoint, the only thing you have accomplished is to provide access to the web application with a different URL. Earlier in this lesson, you learned that a number of settings can be scoped to a zone, including authentication providers, anonymous access, and policy. These settings can only be applied if an IIS Web site is associated with the zone.

When you extend a web application, you create an IIS Web site associated with the zone. SharePoint configures the IIS Web site with bindings—for example, with a host header binding for the URL of the new zone. This allows SharePoint and IIS to stay in synch with each other. When you extend a web application to a zone, the configuration of the extended web application is stored in the SharePoint configuration database. Therefore, if you add a new server to the farm, SharePoint can create the IIS site and configure it automatically. Similarly, if you delete a web application and then restore it from backup, SharePoint can configure the IIS site.

Remove a Zone

To remove a zone properly, you should undo the process you used to create the zone. If you created the zone by defining an alternate access mapping, remove the URLs associated with the zone and the zone will be deleted. If a web application has been extended to the zone, you should delete the extended zone using the procedure that follows.

REMOVE AN EXTENDED ZONE

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

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

3. Select the web application for which you want to delete an extended zone.

4. On the ribbon, click the down arrow on the Delete button, and then click Remove SharePoint From IIS Web Site.

   IMPORTANT

   BE VERY CAREFUL

   Be careful that you choose the correct command. Do not choose the Delete Web Application command or click the Delete button itself, because both actions will result in the deletion of the entire web application.

5. In the Select IIS Web Site And Zone To Remove list, select the zone that you want to remove.

   IMPORTANT

   DON’T DELETE THE DEFAULT ZONE

   By default, the default zone selected. If you delete the default zone, the web application will be broken. Be certain that you select a zone other than the default zone.

6. If you also want to delete the IIS Web site associated with the zone, click Yes in the Delete IIS Web Sites section.

7. Click OK.

Multiple Zones

Why might you want more than one zone? Zones are also used to scope certain settings for access to a web application, including authentication providers, anonymous access, and policy. If you want to provide access to the content of a web application with more than one variation of these settings, you must use more than one access zone. In this section, you will explore several common scenarios, and you will learn how to address those scenarios by configuring multiple zones.

Problems Resulting from Multiple Zones

Before we proceed, however, let’s consider the type of problems that can arise whenever more than two zones are in use. Let’s illustrate the problems with examples.

Both John and Jane access the Contoso Partner Portal. John is an internal employee, and accesses the site through the URL http://extranet.contoso.com. Jane is a partner, and accesses the site through the URL https://partners.contoso.com. Jane wants to send John a link to a the company calendar, which SharePoint renders to her as http://extranet.contoso.com/Lists/CompanyCalendar/calendar.aspx because http://extranet.contoso.com is the public URL of the default zone. She copies the link to the calendar and sends it to John. John cannot access the site through the URL namespace, http://extranet.contoso.com, so the link is inaccessible to John.

SharePoint renders the URLs of content with the public URL of the zone through which the site was accessed. Unfortunately, this is true only of links and URLs that SharePoint generates, such as navigation links in the Quick Launch. However, if a link is hard-coded on a page, it is not altered. For example, if Jane pastes a link to the company calendar into an announcement on the home page, she pastes it as http://extranet.contoso.com/Lists/CompanyCalendar/calendar.aspx. When John accesses the site, the URL is not altered to reflect the fact that he is accessing the home page as https://partners.contoso.com. The link is effectively broken for John.

When you are faced with the choice of extending a web application—of creating a new zone—consider the impact on users and applications that will access the web application using a different URL namespace.

With those caveats, let’s explore scenarios that can be implemented by creating additional zones. In each of these scenarios, you use the procedure described earlier, “Extend a Web Application,” to create an additional zone.

Multiple Authentication Providers

A web application can be configured to only one authentication type—either Classic Mode Authentication or Claims Based Authentication. So if you have two solutions that cannot work in the same mode—for example, custom code that uses Windows identities and therefore cannot work in Claims Based Authentication, and another solution that relies on claims—you must separate the solutions into two different web applications.

Within a web application configured for claims authentication, however, you can have more than one authentication provider. For example, different users can be authenticated by either Windows, forms, or SAML token authentication within a single web application, with a single zone. For example, you can support both Windows and Forms Based Authentication (FBA) on the default zone.

This is a significant improvement over previous versions of SharePoint. In SharePoint 2007, you were required to extend a web application into additional zones to implement different types of authentication for users coming from different networks or authentication providers. This could lead to practical business problems because the different users accessed the content through different URLs.

The fact that Claims Based Authentication can support multiple authentication providers with a single zone reduces a significant design driver for multiple zones.

However, you can still specify different authentication providers on each zone and, in some cases, it will be required. If a zone is configured for forms-based authentication, the zone supports only one provider for FBA. It is not common to require multiple FBA providers, but if some users must be authenticated using the SQLMembershipProvider against a SQL database, and others must be authenticated using the LDAPMembershipProvider against an instance of Active Directory Lightweight Directory Services (AD LDS) or some other LDAP source, those users must access the site through two different zones, and therefore two different URLs. Alternately, you could write a custom FBA provider that abstracts the authentication provided by the two different sources.

Anonymous Access Enabled

Let’s examine a scenario in which all content on the Contoso Intranet Web application can be accessed by authenticated users, based on permissions assigned to the content, using the URL http://intranet.contoso.com. However, you also want a subset of intranet content to be accessible by anonymous users—such as customers who are visiting Contoso and are connected to the Contoso network—using the URL http://visitors.contoso.com.

To support this scenario, you extend the Contoso Intranet Web application to a new zone—perhaps to the zone named intranet—with the public URL, http://visitors.contoso.com, to the web application. Each zone that has an extended web application supports its own authentication settings. On the zone named intranet associated with http://visitors.contoso.com, you enable anonymous access. Anonymous access remains disabled on the zone named default that is associated with http://intranet.contoso.com.

When a user enters a URL that begins with http://visitors.contoso.com, the request is received by SharePoint and SharePoint can map the request to the intranet zone of the Contoso Intranet Web application. This zone will accept anonymous connections.

Anonymous Access Restrictions

Anonymous user policy is also set per zone. You might want to allow anonymous users to access both http://intranet.contoso.com and http://visitors.contoso.com, but enforce read-only access through the zone associated with the URL http://visitors.contoso.com.

Reverse Proxy

A reverse proxy is a service that acts as a connector between end users and the web server. A user makes a request, and the reverse proxy receives the request. The reverse proxy filters and translates the request, and then forwards the request to the web server. SharePoint is compatible with many reverse proxy services and devices.

Although each reverse proxy product varies in functionality, they all have the following common characteristics:

• The reverse proxy can authenticate the user and perform inbound filtering based on characteristics of the request packet, and then forward only eligible requests to the web server.

• The reverse proxy can change the URL (host name or port) of the URL requested by the user. For example, a user requests http://portal.contoso.com and a reverse proxy receives the request and forwards the request to http://partners.contoso.com.

• The reverse proxy can receive requests using one port or protocol, and then forward the requests using another port or protocol. In this way, a reverse proxy can perform off-box SSL termination.

• The reverse proxy can forward the request to a different port than the port on which the request was originally received, and can change the HTTP host header field, thereby masking the internal name of a server or application from external users.

In reverse proxy scenarios, the URL of a request is directed to the reverse proxy. The URL sent by the reverse proxy to the web server is typically a different host name or port. For example, a user requests the home page of the Contoso Extranet web application, https://portal.contoso.com/SitePages/Home.aspx. The public URL of the Contoso Extranet web application—the URL as known to users—is thus https://portal.contoso.com. A reverse proxy that handles SSL encryption receives the request over port 443, and translates the request—for example, to http://extranet.contoso.com/SitePages/Home.aspx to the web server over port 80. The internal URL of the Contoso Extranet web application—the URL of the web application as known to SharePoint—is thus http://extranet.contoso.com. Typically, this URL is not directly accessible to the user—the user would not be able to resolve or connect to the site using the URL http://extranet.contoso.com—port 80 would be blocked by the firewall sitting between the user and the reverse proxy.

HTTPS and HTTP

Earlier you learned to configure a single zone so that it could be accessed by users over SSL using off-box termination. The intermediate device forwarded requests to HTTP port 80 on the web server, but users did not access the web application directly using HTTP.

What if you want to provide access to a web application to users on your internal network with the URL http://intranet.contoso.com but you want access from outside the network to use SSL, and thus the URL https://intranet.contoso.com?

In this configuration—when you want to support user access through both HTTP and HTTPS protocols, you must have two zones. Extend the web application. One zone—typically the default zone—is configured for SSL and the other zone without SSL. Do not simply add the SSL binding to the IIS Web site that is also bound to HTTP.

Different Policies

You will learn about web policies in Chapter 4. In short, a policy can grant a user or group permissions to content in a web application that override any permissions associated with a specific site, list, library, folder, item, or document. For example, you can specify a policy for the default zone of the Contoso Intranet that grants the Level 3 Help Desk group Full Control permission to content so that they can support users who are attempting to post content to the intranet. This policy applies when the Contoso Intranet Web application is accessed with the URL http://intranet.contoso.com, which is the external or public URL associated with the default zone representing the corporate network. You might want to prevent such broad application of Full Control permission when users in the Level 3 Help Desk group access the Contoso Intranet Web application over the Internet. If the Contoso Intranet Web application is extended to the Internet zone as http://portal.contoso.com, the web policies associated with the Internet zone are separate, so you can forego granting the Level 3 Help Desk group Full Control policy. Access using the external Internet zone’s external URL, http://portal.contoso.com, is not subject to the same web policies as the default zone.

Guidance and Recommendations for Zones and Access Mappings

You have explored common scenarios that require more than one zone, and you know some of the common problems that might arise when you have multiple zones. You also know that the best practice for creating an additional zone is to extend a web application. You should also be familiar with the following best practices and recommendations:

• Configure the default zone as the most secure zone. Typically, this means that, if you plan to use SSL for any zone, you should use it for the default zone. If you plan to enable anonymous authentication on one but not all zones, do not enable anonymous authentication on the default zone. When SharePoint cannot determine which policies to apply to an inbound request, it applies the policies associated with the default zone.

• System-generated alerts, such as those related to quotas and site collection usage, are sent using the URLs associated with the default zone. Therefore, you should configure a web application’s default zone external URL as the most-often used URL. This consideration should be secondary to the primary recommendation in this list.

• You have learned that you can manually modify host header bindings on the IIS Web site from the IIS Manager, but this is not recommended. Any changes you make using the IIS Manager will not be recorded in the configuration database of the farm, and will not be replicated to other servers in the farm.

• Do not modify the host header binding that SharePoint applies to an IIS site. If SharePoint Server 2010 tries to provision an IIS Web site on another computer in the farm for the same web application and zone, the original host header binding is used instead of the modified binding. If you want to modify an existing binding for an IIS Web site, remove the web application from the zone and then re-extend the web application into the zone with the host header you want to use.

• Do not add the public URL of a zone as a binding to the IIS site of another zone. For example, if the public URL of the extranet zone is http://extranet.contoso.com, do not add the host header extranet.contoso.com to the IIS site of the default zone. Such manual configuration is not replicated to other IIS servers in the farm. It is not recommended to use the same IIS Web site for multiple zones, unless you are specifically told to do so by Microsoft.

• Host-named site collections cannot use alternate access mappings. Host-named site collections are automatically considered to be in the default zone, and the URL of the request must not be modified between the end user and the server. You will learn more about host-named site collections later in this training kit.

• One zone must be configured to use Windows authentication. The crawler uses NTLM to authenticate. If no zone supports NTLM, content will not be indexed, and therefore a search will never produce results from the web application.

• A URL should never be used as the internal URL of two different zones. The public URL of one zone should never be used as the internal URL of a different zone. If you put these rules together, a URL can only be used once within a web application: either as the public URL of a zone or as the internal URL of a zone. A URL can only be used twice when the URL is both the public and internal URL of a single zone.

Lesson Summary

• Each SharePoint web application is created with a zone named default that cannot be deleted. Four additional zones can be defined: intranet, Internet, extranet, and custom.

• A zone is defined by one public URL and one or more internal URLs. Each URL includes a protocol, scheme, host name, and port. For example, the public URL of the Contoso intranet is http://intranet.contoso.com:80, although the port, 80, can be omitted when you use the standard port for the HTTP protocol (80) or HTTPS protocol (443).

• The internal URL of an access mapping associates the internal URL of a request—the URL as it is received by SharePoint—to a web application zone. The internal URL is also called the incoming URL.

• The public URL of a web application allows SharePoint to render content to the user with URLs—for example, target URLs of hyperlinks—with a protocol and host name that are valid for the user, which might be different than the internal URLs of the web application itself. The public URL is also called the external URL, load-balanced URL, or outgoing URL.

• Each zone can specify unique configuration, such as anonymous authentication and restrictions, user policy, and SSL.

• If the internal URL of a request SharePoint has received from IIS is http://intranet.contoso.com, SharePoint knows that the request is associated with the zone named Default for the Contoso Intranet Web application. SharePoint then performs authentication as configured for the zone, and after the user has been authenticated, SharePoint parses the full URL of the request to determine the site collection and content database that must be accessed. Finally, SharePoint authorizes the user’s access, based on a combination of the user’s permissions to content and any policies that are enforced on the web application or zone, and then fulfills the request, returning the home page of the Contoso intranet to the user.

PRACTICE: Configure Access Mappings and Zones

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 configure common access and authentication scenarios that require the configuration of access mappings and zones.

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 2 of this chapter. If you are currently logged on to SP2010-WFE1, log off before beginning the exercises.

EXERCISE 1 Modify Access Mappings

In this exercise, you

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

2. Add http://intranet as an internal URL to the default zone of the Contoso Intranet Web application.

3. Add http://intranet as a host header binding to the Contoso Intranet IIS Web site.

4. Confirm that you can open the site with the URL http://intranet.

   The first time you open a site, IIS loads, compiles, and caches the site. This can take a while. If the site takes too long to load, an error appears. Refresh the page.

5. Observe that the URL to the home page in the address bar is http://intranet.contoso.com/SitePages/Home.aspx.

   A redirector loads the home page of the site. The redirector uses the public URL of the web application zone.

EXERCISE 2 Configure Windows-Claims Authentication

In this exercise, you configure authentication for the Contoso Partners Web application so that Windows Authentication is the only authentication provider. This exercise is intended to ensure that the web application is correctly configured for this practice.

• Verify that the Contoso Partner Portal Web application is configured with the following authentication settings:

  • NTLM authentication: Enabled

  • Forms Based Authentication: Disabled

EXERCISE 3 Extend a Web Application

In this exercise, you enable users to access the Contoso Partners Web application using http://extranet.contoso.com from the internal network and https://partners.contoso.com from the extranet. To do this, you extend the web application to a new zone for intranet users, with the URL http://extranet.contoso.com. Your information security manager has recommended that you use the host name extranet for your internal users so that it is clear to them that content in the web application is for external consumption.

1. Extend the Contoso Partner Portal to a new zone. Use the following specifications and guidance:

   • IIS Web site name: Contoso Partners Extranet

   • Port: 80

   • Host header: extranet.contoso.com

   • Authentication: NTLM

   • Public URL: http://extranet.contoso.com:80

   • Zone: Intranet

   It might seem counterintuitive to use the intranet zone for a zone with the URL extranet. Remember that the names of the zones (intranet, extranet, Internet, and custom) have no technical meaning. Furthermore, in this scenario, the zone is for internal users to access the Contoso Partner Portal. Access is from the intranet, using HTTP. The site is an external-facing site on which to collaborate with partners, thus the user-facing name of the zone is extranet.

2. Open a new tab in Internet Explorer, and browse to https://partners.contoso.com. Sign in as CONTOSO\SP_Admin.

   The first time you open a site, IIS loads, compiles, and caches the site. This can take a while. If the site takes too long to load, an error appears. Refresh the page.

3. Open a new tab in Internet Explorer, and browse to http://extranet.contoso.com.

   The Contoso Partner Portal site opens.

   The first time you open a site, IIS loads, compiles, and caches the site. This can take a while. If the site takes too long to load, an error appears. Refresh the page.

EXERCISE 4 Configure Authentication on a Zone

In this exercise, you enable anonymous users to access the root site collection of the Contoso Partner Portal as a landing page from which you can provide links to other sites that require authentication. So that users on non-Windows systems can authenticate to the portal, you will enable Basic authentication as well.

1. Enable anonymous authentication for the default zone of the Contoso Partner Portal Web application.

2. Enable Basic authentication for the default zone of the Contoso Partner Portal Web application.

EXERCISE 5 Configure Anonymous Access Restrictions

In this exercise, you enforce a security policy of your SharePoint governance plan that requires authenticated access to change any content. You do this by configuring an anonymous access restriction policy on the zone through which anonymous users are allowed to authenticate.

• Apply a Deny Write anonymous access restriction policy to the default zone of the Contoso Partner Portal Web application.

  You could apply the policy to all zones, but in this scenario, anonymous authentication is allowed only for the default zone.

EXERCISE 6 Complete and Validate Anonymous Access

In this exercise, you validate that users must be authenticated to access the Contoso Partner Portal site using the URL http://extranet.contoso.com, and that anonymous users can access the site using the URL https://partners.contoso.com.

1. Close all instances of Internet Explorer so that cached connections are eliminated.

2. Start Internet Explorer and browse to http://extranet.contoso.com. Sign out of the site.

   A Windows Internet Explorer message opens: The webpage you are viewing is trying to close the window.

   Click Yes.

   Question: Why did the window close?

3. Start Internet Explorer and browse to https://partners.contoso.com. When the Windows Security dialog box appears, click Cancel to log on as an anonymous user.

   A 401 Unauthorized error page opens.

   Question: Why can you not access the site as an anonymous user?

4. Refresh the page and sign in as CONTOSO\SP_Admin with the password Pa$$w0rd. Give anonymous users access to the entire site.

5. Close Internet Explorer. Start Internet Explorer and browse to https://partners.contoso.com.

6. When the Contoso Partner Portal site opens, observe the Sign In control in the upper-right corner. You are connected as an anonymous user.

EXERCISE 7 Create the CHAPTER 03 Snapshot

The CHAPTER 03 snapshot captures the state of the environment at the end of Chapter 03. Perform this procedure for each of the following virtual machines: SP2010-WFE1, CONTOSO-DC.

1. Shut down the virtual machine.

2. Unmount any ISO image currently mounted to the CD/DVD drive. Use the “Unmount an ISO Image” procedure in the Lab Environment Build Guide on the companion media.

3. Create a snapshot named CHAPTER 03. Use the “Create a Snapshot” procedure in the Lab Environment Build Guide on the companion media.

Lesson Review

You can use the following questions to test your knowledge of the information in Lesson 3, “Configure Authentication Zones and Alternate Access Mappings.” 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 created a SharePoint-based timecard application, http://timecards.contoso.com. You want users to be able to browse to the application using either http://timecards.contoso.com or http://timecards. What steps must you take? (Choose two. Each correct answer is a part of the solution.)

   1. Modify the IIS Web site.

   2. Modify the Web.config file.

   3. Modify the managed paths.

   4. Modify the Alternate Access Mappings.

   5. Extend the web application.

2. You have created a web application with the URL http://server1. Users can access the application from systems connected to the corporate network, and can authenticate with Windows authentication. You want to allow users to access the application from external systems with the URL https://server1.contoso.com. What do you do? (Choose all that apply. Each correct answer is a part of the solution.)

   1. Extend the web application to a new IIS Web site.

   2. Enable SSL for the web application.

   3. Add a binding to an IIS Web site.

   4. Install a certificate on the web server.

3. You have created a web application with the URL, http://partners.contoso.com. You want users to access the web application as https://partners.contoso.com, through a device that will offload the processing of SSL. What do you do?

   1. Add a host header, https://partners.contoso.com, to the IIS Web site.

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

   3. Modify Alternate Access Mappings in Central Administration.

   4. Extend the web application to create a new zone.

4. You have created a web application, http://intranet.contoso.com. Users access the intranet and make changes to content while connected to the corporate network. You want to provide access to the site from outside the corporate network, but you want to ensure that users accessing the site from outside cannot change content. What do you do? (Choose all that apply. Each correct answer is a part of the solution.)

   1. Extend the web application to the extranet zone.

   2. Configure user policy on the extranet zone.

   3. Set the content database to read-only.

   4. Specify permissions on the top-level site collection that allow only read access.

   5. Configure a Deny Write anonymous access restriction.

5. You have created a web application with the URL http://server1. The application uses Windows authentication. You want to allow anonymous connections through the URL https://server1.contoso.com. What must you do? (Choose all that apply. Each correct answer is a part of the solution.)

   1. Enable anonymous authentication on the default zone.

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

   3. Modify Alternate Access Mappings in Central Administration.

   4. Extend the web application to create a new zone.

   5. Modify anonymous access restrictions.

   6. Modify the authentication provider.