All About ADAM

Active Directory in Application Mode provides a way to have directory service functionality without needing a domain.

• By Bill Boswell
• September 01, 2003

By tying Active Directory to a Windows domain, Microsoft has complicated life for application developers who want to use a directory service like AD but don’t want their applications to sit in a queue waiting for deployment. “The Finance department wants us to install this software package but it requires AD, so we can’t install it until we finish our Windows 2000 deployment. And besides that, it does a schema modification that we’ll have to test in the lab for a while then get all the business units to approve a global change request which they won’t agree to until they’ve done their own testing.”

This requirement to have a Windows domain to use a Windows directory service has put Microsoft in an uncomfortable position vis-à-vis, its competitors in the enterprise application market. Faced with waiting for a Win2K deployment, an application vendor might decide to use a standalone instance of Novell’s eDirectory, Sun’s iPlanet, OpenLDAP or one of a dozen other offerings.

Microsoft has addressed this issue by developing a version of AD that doesn’t require a domain. It’s called AD in Application Mode, or ADAM. By the time you read this, the final version should be available for download. If not, the ADAM beta is open to any requestor. Go to www.microsoft.com/windowsserver2003/ adam/default.mspx and sign up.

So Who Cares?
The first question you may have is, “Why should I care about ADAM?” The answer requires a look at the reason for using a directory service in the first place.

A directory service acts as a repository of information cataloged in some useful fashion coupled with a query engine capable of delivering a result set based on a search criteria. For example, let’s say the Acme Facilities Management Company of Walla Walla, Washington publishes an application that maps out a building with identifiers for cubicle numbers and phone extensions and Ethernet drops and printers along with the names of people assigned to these items.

Such an application could use just about any database, but a Lightweight Directory Access Protocol (LDAP) directory service is attractive because it uses well-known methods for accessing information that simplifies links to other applications. The Acme developer could build an information repository that scales well across multiple servers in multiple locations, provides single sign-on using existing Windows domain credentials and interfaces more or less easily to other systems using standard LDAP bind requests and query protocols, and then bundle the app with ADSI management tools that have become familiar to system administrators.

ADAM Structure
The first time you see ADAM in production, it might be packaged with an application in such a way that the bones don’t show. It’s best to get familiar with the basic product so you can plan where to put the service, where to replicate, what to do if a server goes down and so forth.

ADAM runs on any flavor of Windows Server 2003 except Web Edition, and it runs on Windows XP SP1 with a recommended hotfix of QFE 817583 to correct a little glitch in secure LDAP binding. The ability to run on an XP desktop is purely for the convenience of a developer. Microsoft doesn’t intend for a production deployment of an ADAM-enabled application to run on a desktop.

The LDAP parlance for a machine that hosts a copy of a directory information base is Directory Service Agent (DSA). In the rest of the column, I’ll use the term DSA to refer to any machine—Windows 2003 server or XP desktop—that hosts an instance of ADAM. Figure 1 shows how an ADAM-enabled application might make use of the information in an ADAM DSA.

Figure 1. A sample ADAM-enabled application stores information in the Application Naming Context (NC), such as information about application users, roles that have admin rights, and parameters that control the application's operation. Think of this as a Registry on steroids. The Configuration and Schema NCs store information that control ADAM operation. (Click image to view larger version.)

An ADAM DSA can be a standalone machine or a member of an NT or AD domain. You get the most flexibility in terms of authentication and replication by using members of an AD domain. We’ll see why in just a minute.

Installing ADAM doesn’t require changes to the schema of a production Windows domain. All ADAM objects are stored in a local Extensible Storage Engine (ESE) database that uses the same Jet database engine as AD. The default database location is \Program Files\Microsoft\Adam.

ADAM isn’t a part of the local security authority, so its data files can be backed up and restored pretty much like any other set of files. You don’t need a special version of your backup program. ADAM files are not included in the suite of System State files. Restoring an ADAM instance essentially consists of reinstalling the ADAM application on a machine without creating an application naming context, then restoring the data files. ADAM comes with a special version of Ntdsutil called Dsdbutil that permits authoritatively restoring all or part of a naming context.

Unlike AD, ADAM doesn’t use SRV records in DNS to identify DSAs and their services. This isn’t required because the application developer (one hopes) keeps track of the DSAs that host an instance of the application. The fully qualified DNS name of each DSA is stored as an attribute of the server object, but this requires locating a DSA in the first place. Microsoft may include a DNS locator mechanism in future versions of ADAM.

ADAM in Production
When ADAM is installed on a machine, setup prompts for a name to assign to the service that will host the ADAM information base. This is called an instance. For example, the Acme Facilities Management application could create an instance called ACME.

ADAM uses the standard TCP port 389 for LDAP and TCP port 636 for LDAP over SSL. If you install ADAM on a Windows 2003 domain controller, or configure two instances of ADAM on the same machine, then the second instance selects TCP port 50000 and 50001 for LDAP and secure LDAP. These port selections can be modified during and after setup to facilitate operations through a firewall.

ADAM runs as a service called Dsamain. The name given to the instance in Setup becomes the display name for the ADAM service on the DSA. In this example, the process list in Task Manager would include an item called ACME. If you wanted to stop and start this service, you would find the service in the Services console. Figure 2 shows an example.

Figure 2. The ADAM service in the Services console showing the custom display name that matches the instance name.

The application developer must assign a security context to the service. This is done by assigning a user account to the service during setup. If the ADAM DSA belongs to an AD domain, setup defaults to using the Network Service account for a security context. This account has limited local access rights, making it more suitable from a security perspective than using an administrative account.

Here is where using domain member machines as DSAs gives you flexibility. ADAM uses the same authentication mechanisms as the domain version of AD, including Kerberos. The Network Service account on one DSA can use the Kerberos ticket obtained by the member computer to access an ADAM instance on another DSA. If you install ADAM on standalone machines, a local account must be created on each machine with the same name and password to use for the security context of the ADAM instance. From what I’ve seen, the ADAM beta doesn’t have a way to use Kerberos tickets from an MIT v5 realm. Also, in the beta version of ADAM, the service account can’t be changed once the ADAM instance has been initialized.

Scalability
ADAM uses the same replication engine as AD, with sites and site links and a Knowledge Consistency Checker to calculate replication paths and install connection objects between DSAs. Constructing sites in ADAM is a little tricky, because the only tool for creating and managing objects is the ADSI Editor. You can use Repadmin to aid in troubleshooting.

AD, like any LDAP service, partitions its information base into Naming Contexts. A naming context forms a discrete replication unit. Win2K domains have three standard naming contexts: Domain, Configuration and Schema. ADAM retains the Configuration and Schema naming contexts and replaces the Domain NC with a general-purpose Application naming context where a developer can store objects that support the production application. The first ADAM DSA becomes the Schema role master, but the token can be transferred to other members of the configuration set.

Figure 3 shows the ADAM naming context contents displayed in a custom version of the ADSI Editor that accompanies the ADAM beta. The “acme_afm” container is the Application naming context. A single ADAM instance can host multiple application naming contexts, but ADAM doesn’t have a Global Catalog to aggregate Application naming contexts hosted by separate DSAs, so the developer would have to code multiple searches and merge the results. In production, it’s likely that an app would use a single Application NC.

Figure 3. ADAM ADSI Editor showing the Configuration, Schema, and custom Application naming contexts. (Click image to view larger version.)

Because ADAM top-level container names need not match a DNS namespace, a developer is free to use X.500 distinguished names when creating an ADAM instance. For example, the Acme Facilities Management application might root at o=Acme. The Configuration naming context is rooted at a Globally Unique Identifier (GUID).

Role Playing
ADAM includes a generic Group class to which Microsoft has assigned the term “role.” A default ADAM installation defines four basic roles: Administrators, Instances, Readers and Users. A Windows account from an AD domain can be added to a role. This creates a Foreign Security Principal in the ADAM information base, similar to the way an AD domain handles a group member from a trusted domain. Figure 2 highlights the contents of the Foreign Security Principals container in a typical ADAM instance. The ADAM beta doesn’t have a way to add accounts from non-Windows directory services. ADAM doesn’t support using group policies.

The ADAM beta doesn’t install any User classes by default on the assumption that an application developer would want to use Windows accounts from an AD domain rather than create special accounts in ADAM. The beta does include User and InetOrgPerson class definitions in an LDAP Data Interchange Format (LDIF) file that can be imported using a special version of LDIFDE. Using ADAM accounts permits the application to run independently from a Windows domain.

Security
Authorization in ADAM uses the same object model as standard AD for domains. Objects in the ADAM information base have security descriptors that define who can access the objects and what operations can be performed. An access control entry in a security descriptor requires a SID, so user and group accounts created within ADAM are given a special SID to make up for the fact that they weren’t created by an NT security authority.

ADAM Setup prompts for a Windows account to act as full administrator of the instance. This account is assigned full control access permissions at the top of all three naming contexts with full inheritance down the tree. In the ADAM beta, permissions are managed using either the Dsacls command-line tool or LDP, Microsoft’s general purpose LDAP browser. Figure 3 shows some of the security settings on an Application naming context as displayed by LDP. In a production application, the developer would use API function calls to assign permissions. For example, the Acme Facilities Management application could create an AFM_Manager group and grant the group partial permissions in the Acme_AFM Application naming context.

Figure 4. ADAM ADSI Editor showing the Configuration, Schema, and custom Application naming contexts.

Authentication is a whole different story. Authentication is probably the single greatest challenge for developers who want to use ADAM completely independently of Windows. Although an LDAP bind request is standardized, different platforms and applications use different password hashing algorithms and different encryption mechanisms for their requests. Developing multi-tier applications using ADAM is also a challenge because Windows uses account impersonation extensively, and ADAM doesn’t support impersonation. However, as long as users are members of a Win2K or Windows 2003 domain, they can be granted access to an ADAM instance using proxy objects and bind redirection.

Figure 5. ADAM Application naming context permissions as shown by LDP. (Click image to view larger version.)

What to Expect
It’ll probably be quite a while before you see production applications appear that use ADAM. This gives you time to test it in a lab and get familiar with its idiosyncrasies so when the time comes to deploy an ADAM-enabled application, you’ll be ready to architect a stable and secure implementation. You might not even lose your weekends doing the deployment.