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 ( 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 Provider

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:

  1. 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.
  2. 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.
  3. 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.


The Definitive Guide To MOSS Pluggable Authentication Providers

Want To Skip Directly to Implementation? Check out the Universal Provider Framework (free of course) for Universal Membership, Role, and Profile provider schemas, getting you up and running with nearly any custom database type in less than 30 minutes. The following membership providers where defined using the framework for your convenience:

There are a total of six classes that make up the Universal Provider Framework.

Download Visual Studio Project File

SharePointMembershipProvider.cs – View Online | Download Class File

SharePointProfileProvider.cs – View Online | Download Class File

SharePointRoleProvider.cs View Online | Download Class File

SharePointUsersProvider.cs – View Online | Download Class File

GeneralUtilities.cs – View Online | Download Class File

UserData.cs View Online | Download Class File

SQL Pluggable Provider Management
If you are looking for a way to interact with the SQL provider database, you can find the ASP.NET 2.0 Provider Manager and the business layer classes that it uses here.

Restricting Security Features in Previous Versions of SharePoint and Improvements
In previous versions of SharePoint, there were many built-in security mechanisms and features that allowed a granular collaboration environment with varying types of application architecture. Within this antiquated security framework, one of the most frustrating, foremost restrictions was that SharePoint user accounts were required to resolve back to a Windows identity, severely impacting the application extendibility, particularly with perimeter facing deployments. There were workarounds to adapt to the restriction, creating multiple Active Directory trees and local user accounts was exceedingly common, however for large extranets this was not only a management nightmare but lead to poor security protocol management.

MOSS 2.0 Security Request Flow and IIS Handshaking

The IIS / ASP.NET 2.0 security process flow is relatively straightforward from when a client initiates the authentication handshake for proper verification and routing to the relevant MOSS web application and MOSS zone.

  1. When the request first begins the handshaking process, IIS will ensure that the incoming client request comes from an IP/host that is allowed access to the domain. If this condition the packets are rejects and the request is rejected by the MOSS server.
  2. Assuming that there are relevant IIS authentication routines (such as basic, integrated, digest, etc.) the MOSS IIS instance will perform that specific authentication.
    1. If you select anonymous authentication, IIS does not perform any authentication by default. There is further configuration required to get anonymous authentication to work with MOSS>
    2. If you select basic authentication, users must provide a Windows username and password to connect. This information is sent across the network in clear text, by which it is natively insecure. Therefore, this typically means that SSL will be used.
    3. If you select digest authentication, users must still provide a Windows username and password to connect. The difference that exists between this and bsic authentication is that the password presented will still be hashed after it is sent by the user. Since this is still an IIS authentication routines, the user Windows accounts wil still need to be stored in a network accessible Active Directory.
    4. If you select Windows integrated authentication, users still have a Windows username and password, however the authentication routine will depend Kerberos or typical challenge/response (NTLM). There are some further settings that are needed in Internet Explorer to make the user experience seamless when leveraging Integrated Windows Authentication.
  3. If there is no configuration done in IIS it will leverage anonymous access so client authentication handshake requests will be automatically passed through and authenticated as legit users (although this will not allow access to MOSS, since the Windows membership provider will be used by default). These types of authentication are set on a per virtual server basis, whereas the MOSS authentication providers can be set on a per web application basis (via zones), and multiple site collections can exist in varying web applications, on n number of virtual servers (it is important to remember that the concept of always having to resolve to a Windows identity doesn’t necessarily have to exist in MOSS).
  4. The first thing that MOSS will do when the authentication request is passed to it will see whether impersonation is enabled.This is how MOSS functions with the varying authentication providers, which allows ASP.NET to acts as an authenticated user.
  5. Finally, the identity from the previous step is used to authorize resources from the Microsoft Office Server System. This is based on the authentication providers that are configured as well as varying assets that can affect the authentication providers such as zones and web application policies. The MOSS resources obtained don’t even has to be restricted to the MOSS webforms, since Code Access Security (CAS) can enable exposure to such things such as keys, disks, and various other server resources.

One of the chief improvements in the new revision of SharePoint (Microsoft Office Server System, or MOSS) is the membership and user model which builds off the revamped ASP.NET 2.0 membership model providing user credentials and user roles functionality (with the addition of seven new server-side controls, membership classes to retrieve and update user information within a database, and role management functionality). This new SharePoint /ASP.NET 2.0 membership model presents state-of-the-art provider APIs that allow a SharePoint environment to talk with a variety of backend corporate user account systems, some providers being provided by default whereas others require creating a custom provider, or simply downloading an already created one from Forms-based authentication, the subject of another article, integrate extremely well with this pluggable model, however they are not dependent on each other and can work as independent pieces of technology depending on requirements.

The membership architecture can depicted well visually, as shown in the following diagram:

So How Does This Membership Model Exactly Work?

There are three main pieces that build the application architecture of a membership provider in ASP.NET 2.0. There is the membership API, the membership provider, and the provider specific storage. The actual logic process of the membership model is very simplistic because of its relatively straight-forward design pattern that provides a high layer of abstraction. Instead of being restricted when using the provider API by simply providing methods to tap into a data store through it, the API is flexible and can be molded by a developer, along with definition of the user member storage mechanism.
public class MembershipProvider : ProviderBase
// Public properties
public abstract string ApplicationName { get; set; } public abstract bool
EnablePasswordReset { get; } public abstract bool EnablePasswordRetrieval {
get; } public abstract bool RequiresQuestionAndAnswer { get; }
// Public methods
public override void Initialize (string name, NameValueCollection config);
public abstract bool ValidateUser (string name, string password);
public abstract bool ChangePassword (…);
public abstract MembershipUser CreateUser (…);
public abstract bool DeleteUser (string name, bool deleteAllRelatedData);
public abstract string GetPassword (string name, string answer);
public abstract MembershipUser GetUser (string name, bool userIsOnline);
public abstract string ResetPassword (string name, string answer); public
abstract void UpdateUser (MembershipUser user);



The main class within the membership API is the membership class. The membership class only contains static methods, and it doesn’t require an object instance. Though the controls handle the majority of desired functionally, ASP.NET 2.0 provides public methods of the Membership class to expand the developer’s control. A few of these include:

Adds an arbitrary user to the MOSS membership data store
Removes an arbitrary user from the MOSS membership data store
Generates a random password of a specified length for access into MOSS
Retrieves a collection of MembershipUser objects representing all currently registered users for the pluggable based MOSS environment
Retrieves a MembershipUser object representing a user
Updates information for a specified user
Validates logins based on user names and passwords
Changes MOSS user’s password
ChangePassword- QuestionAndAnswer
Changes the MOSS users question and answer used for password recovery
Get Password
Retrieves a MOSS user password
Resets a MOSS user password by setting it to a new random password
These members reference the MembershipUser class, which represents a user stored in the Membership data system. As stated before, this MembershipProvider class can be extended to create a custom providers for a variety of systems, allowing you extend the way that users can authenticate to your SharePoint environment.
As an example of how these methods work, lets look at how one could programmatically create a user for your MOSS environment to consume. This method could be hooked to any number of pluggable providers, depending on your backend membership data store:
For the first portion of the code, you simply need to call the CreateUser method and fill in the appropriate string entries to populate the membership database with relevant information about the user:
try {
Membership.CreateUser (“Adam”, “Buenz”,;

Following, you should allow there to be some flexibility to be procured for handling if a user does not meet any of the standard criteria. This can be accomplished by leveraging MembershipCreateUserException.StatusCode along with a switch case.

catch (MembershipCreateUserException e)

Following, build the switch case then to handle the various types of exceptions that may occur when you are creating the user. These can vary heavily so it is best to be as robust as possible whilst writing them:
For example, we could do the following starting off with the switch case to parse the status code:
switch (e.StatusCode)

Following we can build out the various types of exceptions that may occur, some of them are the more obvious:

Check whether there is a duplicate username that exists

Check whether there is a duplicate email address that exists

Check whether there is an invalid password entered

The above exception, where we are checking the user password, also has to be implemented programmatically, and can be bound to some of the initial sign on events to validate the password format as users enter into the MOSS instance. For example, it is common for passwords with an organization to require a certain length of characters. This can be achieved by using some regular expressions. Regular expressions are just a way to implement pattern matching within your code, and are supported by all .NET compliant languages.


void OnValidateCredentials (Object sender, CancelEventArgs e)

Then, just create a if statement to start the regex pattern:
if (!Regex.IsMatch (LoginControl.Password, “[a-zA-Z0-9]{8,}”) )

If they don’t meet the requirements, and use a cancel, e.Cancel = true; (whose full setting is CancelEventArgs.Cancel), you can simply display them a message using LoginControl.InstructionText, such as:
LoginControl.InstructionText = “Passwords must be 8 characters at least”

Then setting the e.CancelEventArgs.Cancel to true:
e.Cancel = true;

Along with multiple other types of various exceptions that could occur depending on your implementation.

The schema when using the SQL membership provider provides some great insight into how the database is structured with a pluggable membership provider:

In relation to the membership model for MOSS under pluggable authentication schemes, there are some unique events that are fired in order to facilitate the login process (this events can all be manipulated if you want to provide a custom login procedure to users):


Event that is triggered when a user trips the login process in order to authenticate the user by validating arbitrary passed credentials to MOSS

Event that can optionally be tripped following a login to MOSS

Prevalidation of user credentials in order to implement properly formed entry

Event that is tripped if a user does not enter appropriate credentials to MOSS

For your login page, you will get a default one by MOSS if you use the internet presence template. However, if you need to create your own there are a variety of Visual Studio controls that are available for you to exploit in order to build your own, and a variety that will allow you to customize and enhance a very standard login procedure.

User Interface for altering MOSS pluggable passwords

User Interface for creating new MOSS pluggable user accounts

User Interface for entering and validating MOSS pluggable user names and passwords

Displays authenticated MOSS user names

User Interface for logging in and logging out out of the MOSS instance

Displays different views based on MOSS login status and roles

User Interface for recovering forgotten MOSS instance passwords  

The Role ManagementProvider
The Role Management provider offers three built-in providers:

  • AuthorizationStoreRoleProvider
  • SqlRoleProvider
  • WindowsTokenRoleProvider

The role provider can be depicted visually as well:

These providers produce a lot more functionality over anything available within previous versions of SharePoint, as well as traditional .NET 1.1 applications (roles typically required the use of the Application_AuthenticateRequest method), which still required developers to leverage the custom roles passing through the ASP.NET HTTP pipelines. The purpose of roles is fairly straightforward, it allows a developer the option of creating rules that can control access to various pieces of content within your MOSS environment. A user does not have to be bound to just one role, but can in fact belong to n number of roles as they are defined by a developer. Programmatically, it is straightforward in adding a user to your MOSS role provider.

Firstly, you have to declare the user in a string in order to enable storage of the unique name that will later be passed into the AddUserToRole method. This is done by just declaring a string as such:
string name = Membership.GetUser (“Adam Buenz”).Username;

In the above we are declaring a string with the name, name. Then we are using the GetUser method in and passing in the username of “Adam Buenz” to get that user. Following, we have to add that user to the MOSS role provider by using the AddUserToRole method:
Roles.AddUserToRole (name, “I Love SharePoint Security”);

In the above we are simply passing in the string that we declared before, then declaring what group we are going to add the user to, in this case the role “I Love SharePoint Security”)
They are not a required feature, however when using a pluggable membership provider are easy to implement and manage, allowing you very granular control over your access security.
In order to get the role manager working, it is necessary to enable it. With your MOSS installation, since it will initially target itself to Windows Identities (even the initial authentication provider will be as such), this is disabled. To enable it, locate this section:

Just change the “false” node in the role manager section to true, as depicted below:

< configuration >
< system.web >
< roleManager enabled=”false” / >
< /system.web >
< /configuration >
enable it so it is true:
< configuration >
< system.web >
< roleManager enabled=”true” / >
< /system.web >
< /configuration >



This can either be done through the WAT (Website Administration Tool) or through directly editing the web.config.


One of the features talked about in the overview article is that role cookies can be encrypted. This cookie comes from using the roles class which produces a role caching property. Assuming that the user roles are too large to fit in the cookie or there are some other restrictions, the cookie will store the most frequently used roles.

There are several role methods that related to the new functionality that can be exposed in SharePoint now through the role provider:

Adds a MOSS user to a role

Creates a new MOSS role (see example for instance of using this)

Deletes an existing MOSS role

Gets a collection of MOSS roles for which a user resides

Gets the collection of MOSS users belonging to a specified MOSS role

Indicates whether a MOSS user belongs to a specified MOSS role

Removes a MOSS user from the specified MOSS role

When a user enters a SharePoint environment where there is role checking being used, it will firstly check whether the encrypted cookie mentioned before is available for consumption. This is because frequent checks for the role manager service will result in performance issues, if instead all the relevant roles of the user is held in a tamper-proof cookie (the cookie must remain encrypted and tamper-proof otherwise someone could spoof it), it is much quicker for SharePoint to access this information. By default, this cookie will be held for 30 minutes (as shown in the below attributes), however how long it is held onto can be manipulated through the web.config file of the arbitrary SharePoint site.
Within the web.config, there are several settings related to how the SharePoint cookie will interact with the user, some of these are fairly self-evident, however explanation of each have been included for brevity:

< roleManager enabled=”true” cacheRolesInCookie=”true” / >

To enable the cookie, you must enable the cacheRolesInCookie directive, as shown above. There are also the following attributes that are available for you to use for your MOSS cookies: 

  • cookieName=”.MOSSROLES” – what is the name of this cookie?
  • cookieTimeout=”30″ – how long should this cookie last (what is the cookie lifetime?)
  • cookiePath=”/” – what is the path to the cookie?
  • cookieRequireSSL=”false” – does this cookie require SSL
  • cookieSlidingExpiration=”true” – should expired cookies be renewed?
  • createPersistentCookie=”false” – should we implement persistence for the MOSS cookies?
  • cookieProtection=”All” – what is the cookie protection level?

If this cookie is not located on the client machine, SharePoint will instead make calls through the API the role provider leverages in order to determine the role of the user, and match whether the request matches the role in the environment. If the request is successful, the request will be written back to the encrypted (if the cookie is specified to be encrypted, this again is not a requirement) with the most recently requested role. If so, it will replace the last role stored in the cookie with the most recently requested role. Using this model, the role lookup processes is automated and can be immediately consumed by a SharePoint environment with no custom development needed, only configuration and implementation.

Going Beyond Using The Provider For Authentication
Once you have the provider setup, you can begin to build some pretty neat administration tools that can access the data layer that you can wrap to consume the data. One really neat use of this is building management applications that take advantage of the user options that exist in the environment. For example, sometimes you want to give other administrators within your environment the option of managing the pluggable users in your environment within an easy to use client. For example, lets assume that you are going to build a WinForms client to accomplish this task.

Here is the data access layer class files that I used to access the SQL pluggable provider that build out the WinForms client that allow management of all the custom users that are added to the SharePoint environment.

Once you have these classes define that build the data access layer, you can start to do some pretty neat management from within a WinForms client that ease the amount of visibility that you have over the users in your SharePoint environment.