Hosting Multiple User Communities with a Membership Directory

August 1999

Microsoft Corporation

Introduction

This document has been updated to reflect the release of Microsoft SQL Server™ version 7.0. It differs only from the original document of the same name in that it reflects changes in software and service pack versions.

This document covers strategies and techniques for hosting Internet service providers (ISPs) who want to support multiple customers, each with a separate community of users. In particular, this document discusses a mechanism for hosting multiple separate communities of users in a single shared Membership Directory. Although the Microsoft® Site Server 3.0, Commerce Edition documentation does not include a discussion of these topics, you can host multiple separate communities using the released version of Site Server Personalization & Membership (P&M).

Some typical scenarios for hosting with P&M include:

•	Dedicated Hardware and Membership Directories. This scenario is the most complete outsourcing solution. It involves creating an entire separate system for each hosted customer. It is very flexible for the customer, but offers few economies of scale except for shared operational staffing. This scenario is not different in principle from the standard, stand-alone Web site scenario discussed in the Site Server 3.0, Commerce Edition documentation.
•	Shared Web Site and Membership Directory. This scenario is generally appropriate for the lower-end, mass market hosting site, which provides a home Uniform Resource Locator (URL) such as http://domain.com/customer for each customer. This scenario deals with dividing or selling subscriptions to a single Web server and Membership Directory.
•	Shared Hardware, Separate Web Sites, and Membership Directories. Creating separate Web sites and Membership Directories on shared hardware is possible because Microsoft® Internet Information Server (IIS) and Site Server support multiple instances of Web, authentication, and Lightweight Directory Access Protocol (LDAP) Services. In this scenario, each Web site is mapped to a unique Membership Server instance, which serves a unique Membership Directory. Each Membership Directory requires its own Membership Directory database and LDAP Service Membership Server. Each instance in this scenario is essentially like the standard, stand-alone scenario discussed in the Site Server 3.0, Commerce Edition documentation.
•	Separate Web Sites and Shared, Divided Membership Directory. This scenario combines the economies of shared hardware and server platforms with the customer experience of using dedicated equipment. The hosted customers and, more important, the hosted customers' users, do not need to be aware that other customers are hosted by the same ISP.

This document focuses on the last scenario, and discusses in detail the main issues of configuration. Each configuration topic describes the advantages and disadvantages of that configuration, providing you with enough information to make an educated decision for your own situation. It is assumed that you have a basic familiarity with Site Server, P&M, and the Membership Directory. For more information, see the "Personalization & Membership (P&M)" section of the Site Server 3,0, Commerce Edition documentation. To open the documentation, on the Start menu, point to Programs, point to Microsoft Site Server, and then click Documentation.

Top of page

Configuration Issues

To decide which configuration will suit your needs, answer the following questions:

•	Should you use separate hardware systems for each customer, or should customers share some or all of the hardware components?
•	Should each customer have a dedicated Web site and domain, or will you have a common Web site for all customers? Or instead, will you have some combination of dedicated and common Web sites?
•	Should you house each customer, or certain large customers, in a separate Membership Directory, or should you house multiple customers in a single Membership Directory?
•	For a particular Membership Directory, how many LDAP Services do you need?
•	Will you need separate Active User Object (AUO)/Authentication Service combinations for each customer? How many will you need?

The topics that follow address these issues in detail, and describe how some choices you make will dictate other choices.

1. Separate or Shared Hardware

One way to host multiple customers is to add a new hardware system for each new customer. As shown in Figure 1, this approach isolates each customer's Web site, Membership Directory, and other services. The shaded boxes in the diagram indicate components that reside within a single Membership Server.

Figure 1: Isolated Hardware System
See full-sized image.

This approach, however, can quickly become impractical. Normally, it is a good idea to share at least some of your hardware components between customers. For example, if you use a shared Membership Directory, you will automatically be using some common hardware, such as a computer running Microsoft® SQL Server™.

Separate Hardware

The advantages of using separate hardware systems include:

•	You can easily move in-house equipment to a hosted configuration.
•	You can easily implement administrative and process isolation for security and reliability.

The disadvantages of using separate hardware systems include:

•	You need one or more dedicated computers for each customer.
•	If you have relatively few users per customer community, you may end up with under-utilized computers.

Note: If you use separate hardware for each customer, you cannot share software components such as SQL Server, Membership Servers, or Web sites.

Shared Hardware

You can reduce your implementation and maintenance costs by sharing some or all of your hardware components among your customers. However, you must set configuration standards for all of your customers in order to avoid conflicts.

2. Separate or Shared Web Sites

You can use a common Web site for some or all of your customers. Figure 2 shows the software components needed to support a single Web site system.

Figure 2: Components Necessary for a Single Web Site System
See full-sized image.

Internet Information Server (IIS) can host more than one virtual Web site on one computer, as shown in Figure 3, whether or not those sites use a single Membership Server and Membership Directory.

Figure 3: A Multiple Web Site System
See full-sized image.

You must use separate Web sites if you are using:

•	Separate hardware systems for each customer
•	Separate Membership Directories for each customer
•	Separate AUOs/Authentication Services for each customer
•	Separate LDAP Services for each customer

Separate Web Sites

The advantages of using separate Web sites include:

•	It is the easiest way to give your customers separate identities. You can create the illusion of giving your customers their own dedicated sites with full domain name hosting (for example, the customer has domain.com, rather than domain.microsoft.com or microsoft.com/domain as their Web site).
•	You can administer access control lists (ACLs) and authentication methods separately for each site.

However, each hosted customer requires a separate Internet Protocol (IP) address or at least a separate host header name. If you are using Secure Sockets Layer (SSL) encrypted channels and certificates, each customer must have a separate IP address.

Note: You can use separate Web sites whether or not you share hardware or other system components.

Shared Web Site

If you use a shared Web site, you must also use:

•	A shared hardware system
•	A shared Membership Directory and a single LDAP Service
•	A shared AUO and Authentication Service combination

The advantages of using shared Web sites include:

•	The administrative overhead for creating and maintaining the site is potentially lower.
•	A shared Web site is appropriate for low-end consumer Web site hosting, such as personal Web page services.

The disadvantages of using shared Web sites include:

•	The host site domain is visible to the end user in the URL.
•	You can segregate customers within the Membership Directory, but you cannot use segregated namespace authentication. For more information, see "Using Segregated Namespace Divisions for Authentication" later in this document.

3. Separate or Shared Membership Directories

To completely isolate your customers, you can house each customer in a separate Membership Directory, as shown in Figure 1. However, you can house more than one customer in a single Membership Directory and still maintain separate Web sites and support services for each customer, as illustrated in Figure 4.

Figure 4: A Single Membership Directory with Separate Web Sites and Support Services
See full-sized image.

You must use separate Membership Directories if:

•	You are using separate hardware systems for each customer.
•	You are using different authentication modes for different customers.

Separate Membership Directories

The advantages of using separate Membership Directories include:

•	Member administration is easier to delegate.
•	There is no issue of namespace collisions between hosted customers.
•	You can still share hardware among your customers.
•	Scalability issues are not affected by the addition of new hosted customers.

However, if you use separate Membership Directories, you must create and maintain separate databases for each customer.

Important: If you use separate Membership Directories, you must use separate LDAP Services, Web sites, and AUO/Authentication Services for each customer.

Shared Membership Directory

The advantages of using shared Membership Directories include:

•	The administrative overhead is lower than for creating and maintaining many separate databases.
•	You can use shared LDAP Services, thus reducing the system's processing overhead.
•	It may be easier to create directory resources programmatically for new hosted customers.
•	If you are balancing the load among multiple LDAP Services, the balancing task may be easier. For more information, see the Membership Directory Group Scalability white paper.

However, administration is more complex if you use shared Membership Directories, especially if you plan to delegate administration of each customer's users.

There are many additional decisions to make when you use a shared Membership Directory. See "Special Considerations for a Shared Membership Directory" later in this document for information about:

•	Isolating customers from one another within the Membership Directory
•	Simplifying end-user authentication when customers are segregated within the Membership Directory
•	Creating custom class objects for different customers
•	Allowing customers to modify designated class objects and attributes
•	Controlling the automatic creation of groups

4. Separate or Shared LDAP Services for One Membership Directory

A Membership Directory requires at least one Membership Server that contains an LDAP Service. You can use more than one LDAP Service Membership Server for one Membership Directory, as shown in Figure 4. However, for best results, place only one LDAP Service on a single computer. If you are adding another LDAP Service (and Membership Server), create it on a separate computer.

However, separate LDAP Services are usually unnecessary if you are using a shared Membership Directory.

Figure 5: Recommended Configuration when Sharing a Membership Directory
See full-sized image.

Separate LDAP Services

Separate LDAP Services are practical if you are going to host a large, dedicated customer who will cover the costs of the additional overhead and who will require a separate Membership Directory based on size or security.

If you use multiple LDAP Services, you can create separate LDAP Service configurations, such as dynamic data, for different customers. However, server overhead cost will increase significantly.

Important: When you use separate LDAP Services, each customer must have a separate Web site and a separate Active User Object (AUO) and Authentication Service.

Shared LDAP Service

You can reduce server overhead by using a shared LDAP Service, although all customers will then share the same LDAP configuration.

Important: If you use only one LDAP Service, you can have only one Membership Directory.

5. Separate or Shared AUO and Authentication Services

In the simplest configuration, all of the Web sites that share a single Membership Directory use a single Membership Server. That Membership Server contains an LDAP Service, an Authentication Service, and an AUO, as in Figure 3. If you move the LDAP Service to a separate computer and create the appropriate Membership Server on that computer, the Web sites will still use a single Membership Server that contains an Authentication Service and AUO.

For more flexibility, connect each Web site to a separate Membership Server. If you are using a single, shared LDAP Service, that LDAP Service can reside within one of these Membership Servers or in a separate Membership Server on another computer. Each Authentication Service and AUO connects to the common LDAP Service, as shown in Figure 5.

You must use separate AUO/Authentication Service combinations if you are using:

•	Separate hardware systems for each customer
•	Separate Membership Directories for each customer
•	Separate LDAP Services for each customer

You must use a shared AUO/Authentication Service if you are using a shared Web site.

Separate AUO/Authentication Services

The advantages of using separate AUO/Authentication Service combinations include:

•	Each customer can have a different set of user attributes.
•	You can place Web sites on different computers.

However, such configurations increase the complexity of your system.

Important: In order to use separate AUO/Authentication Service combinations, you must use separate Web sites for each customer.

Shared AUO/Authentication Service

A single, shared AUO/Authentication Service combination is a basic configuration and is easy to maintain.

The disadvantages of using a shared AUO/Authentication Service combination include:

•	All Web sites must reside on the same computer.
•	All customers must use the same set of user attributes.

Important: If you use a shared AUO/Authentication Service combination, you must also use a shared LDAP Service and a shared Membership Directory.

Top of page

Special Considerations for a Shared Membership Directory

A Membership Directory has one container for user accounts (ou=Members) and one container for group information (ou=Groups). If multiple customers are going to share a Membership Directory, consider whether it is appropriate for all of the users to reside in a single container, or whether you want to keep each customer's users separate.

Figure 6: Membership Directory with Separated Members and Groups
See full-sized image.

You should also consider whether to allow your customers to customize attributes in the Membership Directory. In addition, you should give some thought to managing the automatic creation of Microsoft Windows NT® groups that correspond to groups in the Membership Directory.

Segregating Customers

You can separate the customers in the Membership Directory by creating subcontainers in the ou=Members and ou=Groups containers. Each subcontainer stores the information for one customer.

Note: If you expect that you will need a lot of storage capacity, you can partition the Membership Directory so that each subcontainer under the ou=Members container is stored in a separate database. This process is beyond the scope of this document. See Creating a New Partitionin the Membership Directory in the "Personalization & Membership (P&M)" section of the Site Server 3.0, Commerce Edition documentation.

Segregating the Membership Directory Namespace

When you use a common Membership Directory namespace, the model is simple and requires less custom configuration. Users from multiple customers can authenticate to the same Web sites without requiring a prefix for user names. This approach might be appropriate, for example, for a cybermall where a user signs up for an account and expects it to be usable at a number of sites. However, to prevent name collision, names must be unique across the entire Membership Directory, not just within a particular customer's set of users.

You can create subcontainers in the Membership Directory namespace so that each customer's users are in a separate container.

Figure 7: Membership Directory with Separated Customer Containers
See full-sized image.

When you segregate the Membership Directory namespace, there is no name collision between separate customers' users. Each customer can have discrete access control lists (ACLs) to allow delegated Membership Directory administration.

However, each user must log on with a user name prefix, unless the Membership Directory uses segregated namespace authentication. For more information, see "Using Segregated Namespace Divisions for Authentication" later in this document.

Using Segregated Namespace Divisions for Authentication

When all users are housed in an unsegregated namespace, less custom configuration is required and users from multiple customers can authenticate to a single Web site to access common content. However, users must add the customer's container name as a prefix to their user names when they log on (similar to the Windows NT domain name). In some cases, you can script or hide this in your authentication interface.

If you subdivide the Membership Directory to use separate containers for each customer, users will be required to use the customer prefix to log on to the site. To eliminate this requirement, in addition to subdividing the Membership Directory namespace (discussed earlier in this document), you can use segregated namespace authentication. In this configuration, the Authentication Service looks in a specific customer's container to authenticate users. However, you do not have to protect all of your content in this way. You can use segregated namespace authentication on separate Web sites for each customer, but, for content that is accessible to multiple customers, you can also have another Web site use common namespace authentication against the same Membership Directory. You can enhance the user's experience by using HTML Forms Authentication. Using this authentication method, you can provide the user with a list of customers from which to choose and the appropriate container name will automatically be added to the user name that is entered.

When you segregate the namespace for authentication, the subcontainers of the ou=Members container are invisible to customers. A prefix is not required for authentication when a user logs on. In addition, users from one customer cannot authenticate to another customer's site. However, segregated namespace authentication requires you to set up a separate Web site and AUO/Authentication Service combination for each customer. This configuration is more complex to set up and administer than common namespace authentication.

Configuring Member Objects

You can let your customers use customized attributes in the Membership Directory. However, you might want to avoid letting each customer add their own attributes to the Member object class, which could lead to an unmanageable number of attributes on Member objects for all customers. And you must also avoid allowing one customer to remove the attributes used by another customer.

Following are possible solutions to the problems that can occur when you host a shared Membership Directory.

Restricting Customers to a Fixed Set of Attributes

You can define a fixed set of Member object attributes for your customers that will be the same for all customers. This solution has the advantage of simplicity, at the cost of flexibility. You can use this solution whether or not your customers are segregated within the Membership Directory.

Defining a Fixed Set of Custom Attributes

If your customers are segregated within the Membership Directory, you can define a common set of attributes that will be used by all customers, such as name and e-mail address. The minimum required attributes for the Members object are cn, GUID, user-password, and account-status. In addition, you can allow a fixed number of customizable attributes (such as String1, String2, Integer1, or Custom1). Each customer can use these attributes in different ways. Because the customers are segregated, multiple customers can use these attributes without conflict.

Allowing Custom Attributes on a Custom Class Object

If your customers are segregated within the Membership Directory, you can define a new object class for each customer and allow each customer to add attributes to this custom class. Because each customer's class object is separate, objects for various customers do not affect one another. Customers can select from a set of predefined attributes or can create new attributes for this class.

Create instances of custom classes in a separate area of the Membership Directory, rather than in the ou=Members container. You can create an ou=CustomObjects container at the same level as the ou=Members and ou=Groups containers in the directory information tree (DIT), with customer containers underneath as in the ou=Members container.

In order for Active Server Pages (ASP) scripts to use these custom objects and their attributes, each customer must have a custom Active User Object (AUO) configuration. For information about AUO, see "5. Separate or Shared AUO and Authentication Services," earlier in this document. Each AUO must have a secondary AUO provider that accesses the custom object, configured with an Active Directory Services (ADS) path to the customer's container under the ou=CustomObjects container.

To impose and enforce limitations on such modifications to the Membership Directory schema, you may want to set appropriate ACLs on the cn=Schema object (pointed at designated attributes) and handle such changes through ASP page scripting or a customized Web administration interface.

Controlling Automatic Group Creation

One potential disadvantage of hosting multiple customers in a single Membership Directory is that with Windows NT group autocreation turned on (which is the default), the Authentication Service will automatically create corresponding Windows NT groups for all groups in the Membership Directory, except those in the ou=NTGroups container. If there are many customers, each with many groups, the number of groups can become quite large and create an inconveniently large number of groups on the Web site computer. If all Web sites are on the same computer, this proliferation is not an issue because the groups for all customers are presumably needed. However, you can limit the number of groups created on a given Web site computer in two ways:

•

You can turn off Windows NT group autocreation and manually create any groups you need on a particular computer. The primary disadvantage of this approach is that any new groups must also be created manually, requiring maintenance effort whenever groups are added.

You can use access control lists (ACLs) on the groups in the Membership Directory. The Authentication Service will autocreate Windows NT groups only if the corresponding group in the Membership Directory is visible to the Authentication Service's account. If groups are created within specific containers in the ou=Groups container in the Membership Directory, you can:

•

Set ACLs on each customer's container so that only the Authentication Service accounts (and Membership Directory administrator accounts) for that customer have permission to read this container.

Note: The ACLs must be set on the group containers, not just on the group objects themselves.

•

Remove the SUPERBROKER value from the ds-privileges attribute of the Authentication Service accounts whose functions must be limited.

Note: Removing the SUPERBROKER value removes the ACL-bypassing privilege from the Authentication Service accounts. These accounts must then be in the cn=GRPBRKRdirectoryname group in the Membership Directory in order to have the necessary permissions to authenticate users.

For more information about the SUPERBROKER value, see Disabling the Bypass-ACL-Checking Privilege in the Site Server documentation.

Top of page

Setting up a Shared Membership Directory System

Identifying a Configuration

Table 1 summarizes the possible configurations for a shared Membership Directory and the effects of the choices you make. For example, the table shows that if you use separate hardware systems for each customer, your options are limited. Restriction 1 (from the list that follows the table) applies, meaning you must isolate customer information about separate hardware systems. In addition, you cannot use any of Available Options 3-6. On the other hand, using separate Web sites for each customer (with some or all hardware and other components shared among customers) provides the greatest configuration flexibility.

Available Option 6 applies, meaning that you can use distinct customer domains, authentication methods, and content access control lists (ACLs).

Table 1 Configurations for a Shared Membership Directory

	Shared
Separate	None (all separate)	Hardware	Membership Directory	LDAP Service	AUO/Auth Service	Web Site
Hardware	1	NA	NA	NA	NA	NA
Membership Directory	1	3, 4, 5, 6	NA	NA	NA	NA
LDAP Service	1	3, 4, 5, 6	4, 5, 6	NA	NA	NA
AUO/Auth Service	1	3, 4, 5, 6	4, 5, 6	5, 6	NA	NA
Web Site	1	3, 4, 5, 6	4, 5, 6	5, 6	6	NA
None (all shared)	NA	2	2	2	2	2

Restrictions (numbers appear in Table 1)

1.	Customer information must be isolated on separate hardware systems.
2.	Customer information must be stored together, without distinctions or separate configurations.

Available Options (numbers appear in Table 1)

1.	You can use separate Membership Directories or Authentication modes for each customer.
2.	You can use different Lightweight Directory Access Protocol (LDAP) Service configurations (for example, Dynamic Directory support for one LDAP Service but not for another).
3.	You can use distinct sets of user attributes, custom objects, and segregated namespace authentication.
4.	You can use distinct customer domains, authentication methods, and content ACLs.

Implementing a Shared Directory

Once you have identified a Membership Directory configuration that suits your needs, you can begin implementing it.

To implement a shared Membership Directory with segregated customers

Create the Membership Servers

Organize the hardware you will use.

Set up Microsoft SQL Server and create a SQL Server database. For details, see Using SQL Server with Your Membership Directory in the "P&M" section of the Site Server 3.0, Commerce Edition documentation.

Create the Membership Directory and the first Membership Server. For details, see Creating Membership Servers in the "P&M" section of the Site Server 3.0, Commerce Edition documentation.

The Membership Server must contain an LDAP Service.

Create the additional Membership Servers that you will need.

To use an additional LDAP Service, create a new Membership Server that contains an LDAP Service connected to the common Membership Directory database.

To support segregated customers, each customer will need a separate Membership Server that:

•	Contains an AUO and an Authentication Service.
•	Resides on the computer running that customer's Web site.
•	Uses an LDAP Service connected to the common Membership Directory. Normally, this will be the LDAP Service that you created in step 3.

Set Up the Web Sites

After you have created all of the Membership Servers needed for your customers, you are ready to set up the Web sites.

Set up separate Web sites for each customer. For details, see "Adding Sites" in the IIS documentation.

For each customer, you need:

•	An IP address and domain name space name. For details, see "Using DHCP Manager" in the Windows NT documentation.
•	A file system directory to use as the Web site root directory.

For each customer, map the Web site to the Membership Server that contains that customer's AUO. For details, see Mapping Application Servers to Membership Servers in the "P&M" section of the Site Server 3.0, Commerce Edition documentation.

Create and Configure the Containers

After creating all of the Web sites necessary for your customers, you must create and configure the customer containers in the Membership Directory.

1.	In the ou=Members and ou=Groups containers, create containers for each customer. For details, see Creating New Objects in the Membership Directory in the "P&M" section of the Site Server 3.0, Commerce Edition documentation.
2.	In each customer's container in the ou=Groups container, create an administrator group. For details, see Creating and Deleting Groups in the Membership Directory in the "P&M" section of the Site Server 3.0, Commerce Edition documentation.
3.	In each customer's container in the ou=Members container, create an administrator account and make that account a member of the customer's administrator group. For information about groups, see Adding and Removing Group Members in the "P&M" section of the Site Server documentation.

Set Up the Security

After establishing the customer containers in the Membership Directory, you must configure the security by setting permissions and implementing authentication.

Set the Membership Directory access control lists (ACLs). Each customer's administrator group should have permission to do the following:

•	Create users in the customer's container under ou=Members.
•	Create groups in the customer's container under ou=Groups, and add members to those groups.

Set Windows NT ACLs on Web site content so that each customer's administrator group has permissions on the appropriate Web site's root directory.

Set up each customer's Authentication Service to search for users in the appropriate container under ou=Members. You can do this in one of two ways.

•	Use the P&M command-line interface, as follows: Pmadmin Set AuthSvc /ID=<instance#> /BaseDN="<container>"
•	Use Microsoft® Visual Basic®, Scripting Edition (VBScript) and the P&M COM APIs. Execute the following sample code (in a text or .vbs file) from the Windows NT command prompt: set authconfig = createobject("memadmin.brokConfig") call authconfig.getconfig(<instance#>) authconfig.bszBaseDN = "<container>" call authconfig.setconfig

where, in either case:

<instance#> is the instance number of the Membership Server to which the customer's Web site is mapped and <container> is the distinguished name (DN) of the customer's container under ou=Members.

For more information, see P&M Command Line Interface in the "P&M" section of the Site Server 3.0, Commerce Edition documentation.

If you need to modify the Windows NT Group auto-mapping settings, see Non-administrative Group Creation and Mapping in the "P&M" section of the Site Server documentation.

Set up each customer's AUO to use the appropriate container under ou=Members. For details, see Configuring AUO in the "P&M" section of the Site Server 3.0, Commerce Edition documentation.

The ADS path of each customer's default AUO provider should have the form:

LDAP:\\<computername>:<LDAPport>\o=<directoryname>\ou=Members\ou=<customername>

If each customer will have a custom class object or custom attributes:

•

Create the schema objects. For details, see Creating Objects in the Membership Directory and Working with Classes and Attributes in the "P&M" section of the Site Server documentation.

•

If necessary, create containers for the custom objects. Add a secondary provider to each customer's AUO with an ADS path of the form

LDAP:\\<computername>:<LDAPport>\o=<directoryname>\ou=CustomObjects\ou=<customername>

and a schema path of the form

LDAP:\\<computername>:<LDAPport>\o=<directoryname>\ou=Admin\cn=Schema\cn=<customerobject>

For details, see Configuring AUO in the "Personalization & Membership" section of the Site Server 3.0 Commerce Edition documentation.

Top of page

Hosting Multiple User Communities with a Membership Directory

On This Page

Introduction

Configuration Issues

1. Separate or Shared Hardware

2. Separate or Shared Web Sites

3. Separate or Shared Membership Directories

4. Separate or Shared LDAP Services for One Membership Directory

5. Separate or Shared AUO and Authentication Services

Special Considerations for a Shared Membership Directory

Segregating Customers

Configuring Member Objects

Controlling Automatic Group Creation

Setting up a Shared Membership Directory System

Identifying a Configuration

Implementing a Shared Directory