MOSS Zones and Alternative Access Mapping (AAM)
Multiple Types of Entry, One Application
Within a collaboration environment, it is common to have multiple types of entry for a singular web application that will resolve to the same content for varying types of users (not even in the context of a web application in MOSS, a .NET web application even in general). For example, customers may enter through one URL to access an extranet that you output sales metrics through whereas end users enter through an intranet URL using local domain accounts to view those very same reports all through your various MOSS site collections.
In order to procure an environment where it becomes much easier to build grouping and sorting of these diverse entry points that although will bind to the same content, yet provide granular control that can hook to such things as security policies or authentication providers, Microsoft Office Server System builds off a concept known as zones.
Because of this paradigm of people entering a Microsoft Office Server System environment from a variety of access points, zones are a necessary portion in order to properly architect a SharePoint environment. Since in most perimeter deployments it is exceptionally common to have these types of multiple entry mechanisms, specifically with multiple types of authentication providers, it is necessary to explore the concept of zones.
Before the concept of zones becomes apparent, it is best to step back and look at the basis technology that provides the granular framework that zones implement, Alternative Access Mapping (AAM), authentication providers, and web application policies.
Alternative Access Mapping (AAM)
Alternative Access Mapping, although crucially more important in this revision of SharePoint, is a borrowed concept from the 2003 version. AAM builds up the central factory of how users are redirected upon entry, and through there entire stay on your MOSS instance. It sounds very fancy, however AAM provides the backbone of how the URL formatting will happen throughout the entire user experience. What it provides is multiple entry points to a singular web application, as opposed to having all users conform to a singular point of entry, that others may not have access to. This becomes increasingly important when you are creating multiple facing deployments, such as those that will face both an internal set of users, as well as an extranet scenario whereby partners and other trusted individuals may attempt to get access to your MOSS instance. What AAM provides is the method to conform to a logical URL, a URL that is familiar to users and conveys the meaning of a site, as well as maintaining URL formatting conventions since how users will enter a site internally (usually just through a http://sharepointsecurity) is different than how external users will access it (typically something like (http://extranet.sharepointsecurity.com). Whatever the URL standard is within your organization, multiple points of entry are achieved through Alternate Access Mapping.
Besides some of the neater features that AAM provides, there are also several rudimentary problems that is solves as well, such as keeping search results uniform. If AAM didn’t exist, it would be possible that a user may return results via an improperly formatted URL which may, in turn, lead to an ugly access denied screen.
The default URL, which is bound to the default zone, in the beginning is setup for you by default. If you are only going to have one points of entry for your application, then you have no need to implement any further modifications to the AAM settings. Clearly, having the same URL entries within AAM is not possible, since it is meant to promote the segregation of the URLs that an arbitrary user may use when attempting to gain access to the site. If, for any reasons at all, one of the production URL’s that AAM is using is deleted, it is important to realize that the relevant content DB’s must be updated to reflect this change, otherwise there will be ghost site results returned on various pages.
Policies and Authentication Providers
While the concept of AAM is a neat idea, however it doesn’t really show the power that can exist when you bind them with the concept of Zones in MOSS. MOSS Zones are a method of logical grouping of your AAM settings that both
- Provide an Easy Way To Inventory Your Points of Entry and URL Standards
- Allow the Binding of Authentication Providers and Web Application Policies to Various Entry Points
MOSS Zones don’t have to imply different policies or authentication providers, however they can or don’t have to be closely hooked together. This at first may seem confusing, however the concept in itself is rather simplistic in design an purpose. Consider the following three scenarios:
- You have an end point for extranet clients and one for intranet users. The entry URLs for a singular site may vary heavily, an extranet partner will enter through extranet.x.x whereas the internal customers will use an entry point such as intranet.x.x. These are to be categorized into easily distinguishable zones such as intranet for the latter, and extranet for the former, respectfully. For the case of the partners, you want them to all use forms-based authentication with a SQL membership provider, and for the internal users you wish to maintain Windows Authentication so that they can just pass their related Domain Login tokens directly to the portal. Using Zones, you can bind the SQL membership provider to the extranet zone after setting up the URL entry through the MOSS AAM settings, and use the “intranet” zone in order to bind the standard windows authentication scheme for all internally entering users.
- You have an endpoint for internal users that have domain accounts, and internal users who are considered temporary. The entry URLs for a singular site may vary heavily, the temporary personnel will enter through temp.x.x whereas the internal, permanent employees will use an entry point such as intranet.x.x. Because the temporary employees are only required a short duration on their specific intranet, and never have write or full control rights on any of the content, one can simply build the appropriate URL entries into the AAM settings of MOSS, and then configure the membership provider for SQL which will cut down on the operational work of the network administrator since he does not have to go through AD in order to make them accounts (unless, of course, they require them to login. This is a proof of concept example). The internal users could still login via a permanent-formatted URL which would let them use their domain accounts, and whereas the temporary employees have a web application policy that restricts them to read only, the granular security of MOSS for Secured Objects are still available to internal employees for proper Item-Level Security settings.
- It is a requirement that external clients need not learn another password in order to login to view the sales metrics that you have setup through your MOSS environment. They have to be able to enter, through a specific URL that you have setup through AAM, and use their own corporate domain credentials in order to view the reports. Internal employees, however still need to be able to use their internal account credentials in order to login once they have properly invoked the Windows domain token for identity verification. Using Zones, you could setup an “extranet” zone that would use the HTTP module provided by the MOSS Web Single Sign On functionality, and following be able to assimilate the identities of the extranet users in order to allow them the use of their own corporate credentials as they login to the site. Internal users will still be allowed the functionality of using their domain credentials because they are setup in the intranet zone bound to the Windows Identity in the authentication provider in WCAM.
Although zones are a relatively simple concept in theory, they allow the exploitation of some true power behind what SharePoint allow in regards to authentication and web application policy binding. It is wise to plan zones correctly, they are how the user is going to be traversed throughout your web application as well as how they are authenticated, along with right overriddance provided by web application policies.