Getting to Know ADAM

Lightweight Directory Access Protocol (LDAP) directories are commonplace in today's enterprise. It isn't unusual to find one directory that supports authentication and management of users and computers, another that supports VPN users, and a third that supports public key infrastructure (PKI). The growing sophistication of applications available to extranet and Internet users typified by business-to-business (B2B), business-to-consumer (B2C), and government-to-citizen systems has led to increased use of directories in the demilitarized zone (DMZ), too. Although Active Directory (AD) can support all these applications, AD requires a supporting infrastructure, such as DNS services, and significantly increases management overhead. Consequently, AD might be too heavyweight a solution for environments that require only a simple LDAP directory. In other cases, organizations that have deployed LDAP directories struggle with the problem of integrating directory security with OS security, often having to manage each separately and with different sets of credentials.

A full-featured yet flexible LDAP directory that can leverage the native security mechanisms of the Windows platform, Active Directory Application Mode (ADAM), solves both problems. In addition to supporting many Windows Server 2003 and Windows 2000 Server AD features, ADAM supports some non-AD features and can run on both Windows 2003 and Windows XP Service Pack 1 (SP1). Unlike AD, multiple instances of ADAM can run on a server, including a domain controller (DC), and you can specify which ports an ADAM instance listens on for LDAP requests. (You can't currently specify which interfaces and IP addresses ADAM listens on, however.) ADAM uses the same multimaster replication model that AD uses and supports sites that use scheduled intersite replication.

Windows 2003 licensees can download ADAM from Microsoft's Web site. In this article, I discuss how to install ADAM, populate it with user information, and integrate it with AD.

Installation
The ADAM download package is a little larger than 8MB. When you run the package, it prompts you for the folder to which to write the installation files. To install ADAM, simply execute the adamsetup.exe file. You must be a member of the Administrators group on the system on which you want to install ADAM.

The Active Directory Application Mode Setup Wizard helps you install and configure ADAM. The wizard's first page is the welcome page, which is followed by the End User License Agreement (EULA), then by a page that asks whether you want to install both ADAM and the accompanying tools or just ADAM itself. In the next step, the wizard asks whether you want to install a unique instance of ADAM or an instance that will be a replica of another local or remote instance. Whether you create a unique instance or a replica, the wizard prompts you for the name you want to give the instance and the ports that the instance will listen on—the default ports are TCP 389 for LDAP and TCP 636 for LDAP over Secure Sockets Layer (SSL). The instance name and the ports that the instance will listen on must be unique on the server. If you install ADAM on a DC or a server that's already running ADAM, the default ports will be in use and you'll need to select alternative ports.

When you create a unique instance of ADAM, the wizard asks whether it should create an application partition. If you're installing ADAM to support an application that will create its own partitions, you can elect not to create a partition; otherwise, you'll need to create a partition and specify its distinguished name (DN)—for example, CN=Partition,DC=CONTOSO,DC=COM. If you install an instance of ADAM that isn't unique (i.e., a replica of an existing instance that you want to use to form a replication set), the wizard prompts you to enter the host name and port number of an existing instance whose configuration and data the wizard can replicate, as Figure 1 shows. Subsequent steps request credentials for an account that has administrative privileges to the instance you're replicating and the partitions to replicate, as Figure 2 shows.

Next, the wizard prompts you for the location of the directory data and recovery files. ADAM can run under the context of the system's Network Service account or a named user account—the wizard lets you choose which you want to use. If your system isn't a member of a domain, you need to use a named user account if the instance is a replica or if you intend to create replicas of the instance later; for replication to work, the username and password must be the same for all instances. You need to ensure that any account you use as a service account for ADAM has the necessary privileges to log on as a service.

The next wizard step lets you select ADAM administrators. You can elect to make the logged-on user an administrator or name another user or group of users. If you're creating an application partition, you can select LDAP Data Interchange Format (LDIF) files to import and use to create a schema. ADAM ships with four LDIF files:

Unless you have an application that will create a schema, you should import one or more of these classes. After the wizard finishes, the installation process installs the instance of ADAM and populates the directory either with the schema from the LDIF files that you specified or with a replicated instance's schema and objects.

The ADAM installation wizard creates a program group called ADAM. This program group contains shortcuts to the Microsoft Management Console (MMC) ADSI Edit snap-in, the online Help file, and a command shell that opens into %systemroot%ADAM and lets you run command-line tools and access the LDIF files that ship with ADAM. The Help file contains details about how to use the command-line tools.

To remove instances of ADAM directories, you can use the Control Panel Add/Remove Programs applet. The instance names appear as program names in the list of installed software. When you remove an instance of ADAM, the applet removes its data and recovery files from the system. If you remove the last instance, the applet also removes the ADAM program files.

Using ADAM
After you install ADAM, the next step is to populate the directory with data. You can populate the directory in several ways. If you installed ADAM to support an application, that application might be able populate the directory for you. The simplest population method, however, is to use ldifde.exe from the ADAM Tools Command Prompt (click Start, All Programs, ADAM, ADAM Tools Command Prompt). Ldifde.exe can export objects and can use a data file that contains a list of objects and the operations to perform on them. Listing 1 shows a sample LDIF data file that ldifde.exe can use to load two users into the directory. You can use the command line to load users from the information contained in an LDIF data file. For example, the following command loads the user information contained in a file called importusers.ldf into the directory on the local server:

ldifde -i -s localhost -f importusers.ldf

You can also use LDIF files to create and manage the directory—for example, to create organizational units (OUs). You can export objects from one directory to an LDIF file, then import them into another directory. If you want to use ldifde.exe to import objects into the directory or to modify existing objects, you need the appropriate permissions. The simplest way to guarantee that you have the appropriate permissions is to log on to the server using the credentials of an account that has administrative permissions to ADAM—for example, as a member of the group that you specified as ADAM administrators during installation. Alternatively, you can specify credentials to use when binding to the directory as command-line parameters. As with other command-line tools, you can be prompted for the password by specifying an asterisk (*) for the password on the command line.

Another way to manage the directory is through the ADAM ADSI Edit snap-in. With this tool, you can extend the schema, create OUs, move objects, and even create objects, such as users. You can use the ldp.exe tool to query ADAM directories. Both ADSI Edit and Ldp are graphical tools. Several other command-line tools offer security, management, and diagnostic applications. Of particular interest is csvde.exe, which lets you export objects in the directory to a comma-separated value (CSV) file or import into the directory objects from a CSV file.

Directory Authentication and Authorization
Users can use different types of credentials to access the ADAM directory. Because ADAM integrates with Windows security, users can use their local or domain account to bind to the directory. Users who have an account in the ADAM directory can also use that account to authenticate to the directory. When you use an account in the directory to bind to the directory, you need to use the full DN. For example, the username for Bill Anderson (a user that the LDIF file in Listing 1 adds to the directory) would be CN=banderson,CN=Application,DC=ADAM,DC=CON-TOSO,DC=COM.

You can set the password for ADAM-based user accounts through the ADSI Edit snap-in or by using ldp.exe. A directory-enabled application (e.g., a Web-based application that uses ADAM as an authentication and authorization store) can also set the password. And sample code that shows how to set passwords and manage users and groups programmatically through VBScript, Visual Basic .NET, and C# is available on Microsoft's Web site at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/

adam/adam/setting_a_user_password.asp.

You can prevent users from using credentials in the ADAM directory to bind to the directory, as you might want to, for example, if you use the directory only to publish information (e.g., email address, telephone number, mailing address, X.509v3 certificates). To do so, you need to set the value of the msDS-UserAccountDisabled attribute to TRUE for each account you want to disable. If the attribute doesn't exist for a user object, or if it does exist and is set to FALSE, a user can use his or her ADAM account to bind to the directory. You can't prevent someone from using a Windows local or domain system account to bind to an ADAM directory.

ADAM supports authentication by AD through a proxy object and bind redirection. With this method of authentication, users use their domain credentials to sign on to ADAM with a DN. This method of authentication lets you build directories that support applications for users who have AD accounts and for external users who have ADAM accounts. Duplicating user objects in ADAM for users who have accounts in AD raises management concerns and problems with keeping the objects synchronized. To use the ADAM proxy object, you need to import the MS-UserProxy LDIF file and the ADAM server must be a member server in a domain. Users represented in ADAM by proxy objects must have their objectSID attribute in the UserProxy class set to the value of their SID in AD.

ADAM defines four default roles that ADAM instances use as broad authorization controls. Roles are implemented as group objects in ADAM. The predefined roles are Administrators, Readers, Users, and Instances. For a user to hold a role, the user must be added to the role object's multivalued member attribute through the ADSI Edit snap-in, the ldp.exe tool, or programmatically. Roles are limited in scope to partitions and, along with other objects in the directory, are replicated between instances of ADAM in a configuration set. Administrators have full administrative access to an ADAM instance, Readers can view any object in a partition, and Users have only the permissions afforded to them through ACLs. Instances is a largely undocumented role.

You can view and set permissions to objects and object attributes in an ADAM instance by using the dsacls.exe command-line tool. ADAM supports a wide range of permissions and inheritance of permissions—you can find the full list of permissions and how to specify them by typing

dsacls /?

at a command line to view the online Help. When you set permissions, you can specify users and groups in several formats, including DN and domainuser formats.

Principals in ACLs are identified by their SID. Because users and groups, whether Windows- or ADAM-based, have SIDs, you can add both users and groups to an ACL. ADAM generates and maintains the SID for ADAM users and groups, and the SID is still guaranteed to be unique.

Going Deep
I've barely scratched the surface of ADAM in this article. To learn about additional features, such as application partitions and replication, I recommend you visit the Microsoft Web site at http://www.microsoft.com/windowsserver2003/adam/default.mspx, at which you can download white papers, reviewer guides, and the ADAM Feature Pack.

In an upcoming article, I'll describe how to use the Identity Integration Feature Pack for Microsoft Windows Server Active Directory to populate an ADAM directory with data from another ADAM directory or AD. This approach can be useful for applications and directories hosted in a DMZ. It also provides an alternative to using ADAM replication, proxy objects, or integrated Windows security, all of which might require opening ports in the firewall between the DMZ and the internal network.