In Part 1 of my blog series on Alternate Access Mappings, I gave a brief introduction to the feature and an example of how it can be used.  In Part 2, I described some of the common AAM-related problems people run into when deploying SharePoint and how to avoid them.  For the final article in our series, I'll discuss how AAM integrates with some other features in SharePoint.

Authentication Providers

As I mentioned in Part 1 of this blog series, AAM allows you to expose a web application in as many as 5 different AAM zones, with a different IIS Web site backing each zone.  (As an aside, some people accidentally refer to this as having up to 5 different web applications sharing the same content database(s).  In reality, there is just one web application.)  Not only do these zones allow you to use multiple URLs to access the same web application, they allow you to use multiple authentication providers to access the same web application as well.

When extending a web application into a zone, SharePoint only offers you the choice of using Windows authentication provided by Internet Information Services.  Once the web application has been extended into the zone, you can modify that zone to use a different type of authentication.  To do this, browse to the SharePoint 3.0 Central Administration site and click Application Management --> Authentication providers.  Next, select your web application from the Web Application selector on the right side of the page.  Finally, select the zone that you wish to modify.  Now you change your authentication settings for that zone.

The power of this feature is that it allows you to configure completely independent authentication settings to access the very same content.  For example, you might configure some content to be anonymously accessible while other content requires credentials.  You could configure one zone to have anonymous access enabled and all other forms of authentication disabled, guaranteeing that only the anonymous content will be accessible.  At the same time, another zone can have anonymous access disabled while NTLM authentication is enabled, guaranteeing that only authenticated access will be allowed.  Plus, you can even have different types of accounts to access the same content - one zone can be configured to use Windows Active Directory (AD) accounts while another zone can be configured to use non-AD accounts via ASP.NET Forms authentication.

Web Application Policies

Web application policies allow administrators to grant or deny access to accounts and security groups for all sites exposed through a zone.  This can be useful for a variety of scenarios.

For example, the SharePoint search crawler must go through the same authorization infrastructure as everyone else - it can only crawl content that it has access to.  However, users would still like search to crawl restricted content so that authorized users can find that content in search results.  The search service uses a "Full Read" policy on the web applications to give its crawler permission to read all content on that web application.  That way, it can crawl and index all existing and future content, even content that the site administrator hasn't explicitly given it access to.

Another example would be help desk personnel who need administrative access to SharePoint sites so that they can assist users.  To do this, you can create a web application policy that grants the help desk staff accounts "Full Control" permission so that they have full administrative access to all current and future sites on the web application.

Because policies are tied to both web applications and their zones, you can ensure that the policy you've applied to one zone doesn't affect other zones.  This can be useful if you have content exposed both on the corporate network and to the Internet.  For example, suppose you've given a help desk staff account Full Control permission over a web application's zone that has been assigned to the corporate network.  If someone were to try and use that account to access the site over the Internet, that Full Control policy wouldn't apply because it would recognize that the URL is in a different zone.  Therefore, the account wouldn't automatically be given administrative access to the site.

External Resource Mappings

On the Alternate Access Mappings page, you may have noticed a button on the toolbar called "Map to External Resource."  It allows you to extend the AAM functionality to content that is not hosted within the SharePoint farm.  When you click on this button, you will be asked to create an entry for an external resource, which you could conceptually think of as another web application.  Once you have an external resource, you can assign different URLs and zones to it in the same way that you do for SharePoint web applications.  This feature isn't utilized in Windows SharePoint Services 3.0, but third party products that build on top of WSS can make use of it.

For example, Office SharePoint Server 2007's search technology is able to crawl content external to the SharePoint farm such as file shares and Web sites.  If that content is available at different URLs on different networks, then you would want search to return search results using the appropriate URLs for the user's current network.  By using AAM's external resource mapping technology, search can remap the external URLs in its search results to match the user's zone.

I hope you've found this series on AAM helpful.  As always, feel free to ask any questions via the blog comments.

Troy Starr