The Personalization and Membership Directory Service and Active Directory

Site Server 3.0 and Windows 2000

Editor's Note: Each month, this column discusses various aspects of the advanced administration of e-business sites. This month's column examines DSs—specifically, the Site Server 3.0 P&M DS and Win2K AD coexisting on a Win2K domain controller.

In my travels this summer speaking at Microsoft TechEd conferences, I learned just how prevalent but troublesome the Microsoft Site Server 3.0 Personalization and Membership (P&M) Directory Service (DS) has become. P&M overcomes the domain limits of Windows NT 4.0. Technically, you can have millions of authenticated users (on the Internet or not), which is extremely powerful. For this reason, P&M is popular in intranet, extranet, and Internet Web sites around the world. It's also why Site Server P&M will be around for a long time, even though Active Directory (AD) is available.

However, P&M dominated the question-and-answer session I held after each TechEd presentation. Arguably, P&M is the most difficult technology in the most difficult product Microsoft has. Its slow adoption is related to that complexity—well, that and a few bugs.

The real problem that IIS administrators have been wrestling with is the migration of their P&M DSs to AD since Windows 2000 shipped. Now that Microsoft Exchange 2000 Server has shipped, the industry is seeing a plethora of Win2K conversions (Exchange 2000 requires Win2K), and that, of course, means AD implementations. This month, I show you how to run the P&M DS on Win2K.

Running the P&M DS and AD on Win2K
People are shocked when I tell them that I run P&M on the Win2K domain controller that hosts AD. I don't know why people are surprised. When you understand the basic architecture of both DSs, having both DSs coexist not only on the same network but also on the same box makes perfect sense. You see, Lightweight Directory Access Protocol (LDAP) servers listening on specific ports service both DSs (i.e., P&M DS and AD). AD is fixed to port 389 because Exchange has always lived there. You can configure membership servers on any available port. By default, membership servers start at port 1002 and increment by one with each new membership server you create. (The default membership server that the Site Server installation process creates lives on port 1002.) If you're using a membership server, it probably lives on port 1003 and can coexist with the LDAP server listening on port 389 for AD requests.

The first step in running P&M on Win2K is to install Site Server. Site Server Service Pack 4 (SP4) lets you install Site Server on Win2K. You also need a small patch file (ss3w2k.exe) that facilitates the operation of Microsoft FrontPage Server Extensions. You can download SP4 and the patch from http://www.microsoft.com/siteserver/site/deployadmin/sp4.htm. The site has detailed installation instructions, but to install P&M on a Win2K server, you must perform these steps:

This installation procedure shows you the real beauty of a Site Server installation on Win2K—its simplicity. If you've installed Site Server 3.0 on NT 4.0, you know how difficult that installation process is. You must install numerous service packs, and the installation order is crucial. Site Server is undisputedly the single most difficult product to install and configure that Microsoft offers.

If you're experienced with Site Server 3.0 P&M and already have membership servers, you can create a new membership server on your Win2K box and point the server to the LDAP server and port running your existing membership server on NT 4.0. Choose Custom Installation, and select AUO Object; don't select LDAP Server. The system will prompt you for the name of your LDAP server and the port on which it's running, as Figure 2 shows. For those of you new to P&M, use these steps to create a membership server on your Win2K server on port 1003:

After you've created your membership server, you need to populate it with data. Go back to the Site Server Service Admin snap-in, right-click Membership Directory Manager (MDM), and select Properties. Change the port number to the port number of the membership server you just created, and click OK. This step attaches the MDM to the membership server you just created. Click the ou=Members container. You'll see the cn=Administrator user.

Note that this Administrator isn't the domain Administrator that lives in AD or a local system account. This Administrator user lives only in the P&M DS.

Right-click cn=Administrator, and select Properties. Click Add Attribute, and persist some attributes with their values for the Administrator (e.g., first name, last name, address). You'll use a simple Active Server Pages (ASP) page to render this data to the browser later.

Leveraging Both DSs with ASP
Now that both AD and the P&M DS are accessible, let's look at an ASP page that retrieves data from both DSs. Earlier, you persisted attributes to the Administrator user in the P&M DS. Do the same for the Administrator user in AD, but give the AD Administrator different values from the attributes you persisted for the P&M DS Administrator. Using the Active Directory Users and Computers tool, follow these steps to persist the data:

At this point, you're ready for the test. Download DSGet.asp, which Listing 1 shows, from the IIS Administrator Code Library (http://www.iisadministrator.com/). Place the file on your Web site, and apply Integrated Windows authentication to it. By applying Integrated Windows authentication, you run the ASP page under the security context of the currently authenticated user. (If you run under the Anonymous account, you won't have the permissions necessary for looking at attributes for the Administrator users.)

Edit the page in Microsoft Visual InterDev or your favorite editor. You need to change two lines that have hard-coded references to the LDAP servers for the P&M DS and AD before you can run the page. The only difference between the way the Microsoft Active Directory Service Interfaces (ADSI) code works with AD and the way it works with the P&M DS is the syntax of the User object. AD uses a domain-like syntax:

strObject = "LDAP://CN= _Administrator,CN=Users,DC= _InterKnowlogy,DC=com"

In this AD syntax, specify the name of your domain for the DC= element (in my case, InterKnowlogy).

P&M uses the traditional DS syntax, which has its roots in X.500:

strObject = "LDAP://localhost: _1003/o=InterKnowlogy/ou= _Members/cn=Administrator"

In this P&M syntax, specify your realm (i.e., directory name) in the o= element (in my case, InterKnowlogy).

Notice that the code to retrieve the attribute values from the two DSs

Response.Write("First Name: " & _objADs.Get("givenName") & _ "
")Response.Write("Last Name: " & _ objADs.Get("sn"))

is exactly the same for both DSs. This feature of ADSI and LDAP is nice. Standards exist that together serve as the universal translator for DSs. This same code would work in a Netscape DS or any LDAP 3.0-compliant DS.

Make sure you're logged on as an Administrator or a user with enough permissions to read the DSs. Run the DSGet.asp. Figure 5 shows the results of executing DSGet.asp. The ASP page reads from both the P&M DS and AD within the same page.

Next Month
You've learned how to install, configure, and run Site Server 3.0 P&M on Win2K. Next month, Gail Fitzmaurice and I will show you how to build, install, and configure wireless applications for IIS.