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.
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.
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
|Figure 3. ADAM ADSI Editor showing the Configuration,
Schema, and custom Application naming contexts. (Click image to view
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).
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.
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.