Hosting Multiple Communities with a Single Shared Membership Directory (216362)

MORE INFORMATION

If you want the community container names to be hidden from the user authentication process, the Authentication Service for each customer must be directed toward the container in which appropriate member data is located. In such a case, a separate Authentication Service instance is required for each container on each application server (but not for each application on a single server).

To change the container that the Authentication Service uses as the starting point for finding users for authentication (the base DN), run the PMADMIN script on the Membership Server to which the customer's Web site is mapped. where: [instance] is the instance number of the Membership Server to which the customer's Web site is mapped.

NOTE: To determine the instance numbers, use the following command: [container]
Distinguished Name of the customer's container under ou=Members specified from lowest first, and not including the o=[root] value

For example, a service provider supports three different customers on a single Website. All three instances share the same LDAP, which connects to a SQL Server database.

Each customer's Web Server uses a different Membership Server instance. If each customer is segregated in the Membership Directory database, the Authentication Service may be reconfigured to use the correct container. In this case, the following PMADMIN commands would correctly reconfigure the Authentication Service: For a detailed explanation of strategies and techniques for hosting Internet Service Providers (ISPs) who want to support multiple customers, each with a separate community of users, see the Hosting Multiple User Communities with a Membership Directory white paper in the MCIS Resource Kit.