Directory-enabled software, such as Microsoft’s Active Directory, has become a prominent part of many operating systems and applications. What has been lacking, however, is cross-directory integration to meet the diverse needs of authentication, Public Key Infrastructure (PKI), single sign-on, and other features. Companies and developers have therefore had to rely on an array of different directory services.

Why is this necessary, since many of these different directories have Lightweight Directory Access Protocol (LDAP) at their core? Microsoft lists the following reasons in a white paper:

  • Lack of directory interoperability
  • Lack of choice (“Some vendors ship solutions that are ‘certified’ to work only with a limited subset of the directory services in use today.”)
  • Lack of coordination (“In some cases, groups in isolation from one another have installed different business solutions.”)
  • Lack of security interoperability

This proliferation of directories is more than an inconvenience. It also harbors a security risk because of the lack of central control over security aspects including access to VPN, PKI, and network resources.

What Microsoft has realized is that, as it is put in the white paper, “What customers really need is a directory that they can deploy to support both their NOS [network operating system] infrastructure—such as Active Directory—and application use that can, where appropriate, leverage the security that has been built into their NOS infrastructure.”

Enter ADAM
ADAM is the acronym for Microsoft’s new Active Directory in Application Mode. It has already been dubbed “Active Directory Lite,” which is, in fact, quite an apt description.

According to Microsoft, ADAM achieves its integration goals “without the burden of expensive training, additional licensing, or the operational costs incurred by the installation of a different directory technology to support a directory-enabled application.”

ADAM provides organizations, software vendors, and developers with a means of integrating their applications with a directory service cost-effectively, simply, efficiently, and securely.

For developers and software vendors, this is a major benefit, since having to deal with a company’s NOS directory service can be just as daunting (considering integration issues and schema changes) as having to cope with no directory at all.

The core feature that makes ADAM such an attractive solution is its simplicity. By that I not only mean simplicity of usage, but also the fact that it provides a platform for application developers that is no longer tied up with a domain or forest. It is, to quote Microsoft, “a stand-alone version of the directory dedicated to a single application and maintained separate from a corporation’s core Active Directory.”

If it’s still not clear why that is such a good thing, consider this: ADAM runs as a non-operating system service. It therefore doesn’t need to be deployed on a domain controller and you can have multiple instances of it running concurrently on one server. What’s more, each of these instances can be configured separately. Using ADAM in this way obviates the need for changes to Active Directory’s schema, which is a good thing. Each instance of ADAM running on the same computer can have its own schema.

Because it can easily be installed and uninstalled on a workstation, it also makes for easy and safe testing of applications by developers.


ADAM runs on the Standard, Enterprise, and Datacenter editions of Windows Server 2003, as well as on Windows XP Professional. You can download ADAM from here.

What ADAM can do
ADAM will also free your network from the burden of unnecessary and bandwidth-consuming replication traffic because its directory data is not replicated throughout the company’s NOS directory. Also, as Microsoft notes, “Many applications require only a simple application directory. The information stored in this directory might be neither globally interesting nor needful of wide replication. It might require a different service level from the one offered by existing domain controllers hosting a NOS directory. For example, the application data might contain highly volatile information, causing high replication traffic that could strain network resources if stored in the NOS directory. In such cases, ADAM provides locality of data and satisfies the dedicated store requirements of an application.”

Still, ADAM uses the same multi-master replication model that Active Directory does. The replication schedule of each instance of ADAM can also be set and you can replicate application data between multiple ADAM instances.

You also get the benefit of the built-in security provided by Active Directory because of ADAM’s integration with the Windows security model. Access can be controlled with users from Active Directory, a Windows NT 4.0 domain infrastructure, or local computer accounts.

If you’re already familiar with Active Directory administration, you’ll find administering ADAM a breeze, since the tools are based on Active Directory tools.

The usage scenarios provided in Microsoft’s white paper give a good overview of the versatility of this directory service. Here are some examples:

  • An application needs to store personalization data associated with users authenticated by the NOS. Active Directory would require schema changes to the NOS directory. But using ADAM, Active Directory can be used for authentication and service publication, while ADAM can store the personalization data. The personalization data, which is relevant only to the application, is stored only in the ADAM directory. What’s more, as we have seen, this data need not be replicated enterprise-wide between domain controllers, thus reducing replication traffic.
  • Sometimes applications are of interest only to a certain department in a company (or should be limited to that department for security purposes). Also, the department might want to manage its local directory service itself. In such a scenario, ADAM is the answer because it is easy to deploy locally.
  • Applications that use ADAM can be deployed in Windows NT 4.0 domains. In this case, ADAM must be installed on a Windows Server 2003 system that is a member server in the NT 4.0 domain. Then, the application must be directed to ADAM. ADAM can also authenticate NT 4.0 domain users because it employs the Windows-integrated security infrastructure.
  • Because it uses the same programming model as Active Directory and is, as far as administration is concerned, virtually identical to it, ADAM provides an ideal development environment for programmers. An application can be developed using ADAM running on a workstation and then later ported to AD.
  • Another interesting scenario is migration to Active Directory. Consider an organization that has an established directory using X.500-style naming and relies on this directory to serve legacy applications. In this instance, ADAM can be used as an interim solution during migration to serve the legacy applications that rely on X.500-style naming. Active Directory can be deployed to provide a shared security infrastructure, while ADAM provides legacy support. As applications are migrated to AD, they can then be targeted to the NOS and Active Directory. Microsoft suggests using a Metadirectory, such as Microsoft Metadirectory Services 2003, to automatically synchronize the data in Active Directory and ADAM to enable a seamless migration.
  • ADAM can provide faster and simpler directory deployments, which involve less planning of the schema and naming conventions. As mentioned earlier, each instance of ADAM running on a computer can have a different schema. A single instance of ADAM can also host multiple data partitions, allowing you to define storage, distribution, and replication scope of partition data. And ADAM supports both DNS-style and X.500-style distinguished names.

End sum
While, as Microsoft puts it, “the vision of a single enterprise directory is still unfulfilled,” ADAM goes a long way in addressing inter-directory integration in a simple, efficient, and cost-effective manner.