Definition of ADAM

ADAM stands for Active Directory/Application Mode. ADAM is the Microsoft product that provides a stand-alone directory service without any of the network operating system features of Active Directory. Microsoft created ADAM in response to demand from customers for a platform that applications could use to provide simple directory service features without all of the additional features, limitations, and deployment complexity that come with Active Directory. The analogy we like to use is that ADAM is like an empty SQL Server database with an LDAP interface. It doesn't really do anything until you add some schema elements and data to it and write some code to access it. Let's explain ADAM by way of comparison with Active Directory and then mention a few possible scenarios where one might use ADAM.

Comparing ADAM with Active Directory

Since ADAM is based on Active Directory technologies, ADAM and Active Directory share many similarities, but also some important differences.

• ADAM is based on the underlying Active Directory database and technologies, and it provides similar scalability and performance, as well as the same replication engine. ADAM instances can be replicated.
• ADAM does not function as a network operating system and has no integrated DNS services.
• ADAM does not use the organizational concept of forests and domains. Instead, ADAM instances that replicate specific directory partitions are said to be part of the same configuration set.
• ADAM is not a store for Windows user and computer accounts. We cannot log on to Windows with accounts stored in ADAM.
• ADAM does not provide Kerberos services (Ticket Granting Service, etc.), like Active Directory does. ADAM cannot be used as a Kerberos realm.
• ADAM installs with a very basic schema. We are supposed to extend the schema to contain the classes and attribute definitions that our application needs. It is possible to add most of the Active Directory schema to ADAM, but this is not done by default.
• ADAM runs as a standard Windows service, not as an integral part of the operating system (a system service), like Active Directory does. This means that we can run multiple ADAM instances on the same machine on different network ports and under different service accounts. ADAM is not integrated with the Local Security Authority system service, as Active Directory is. Unlike the current version of Active Directory, we can start and stop ADAM whenever we like.
• ADAM allows us to use other LDAP naming attributes, such as "O" and "C," that are used in other LDAP directories. Additionally, we can root the directory in any namespace we want, such as O=foobar or CN=myadaminstance. Active Directory restricts us to using DNS names such as DC=foobar, DC=com for the root of a naming context.
• We can create user account objects in ADAM that can be authenticated with a simple LDAP bind. This makes ADAM useful as a user store for applications.
• ADAM can also use an LDAP bind to authenticate Windows users. By Windows users, we mean users that are stored in a domain such as Active Directory, or users stored on the local server where ADAM is installed. This feature is called pass-through authentication. Here, no object representing the Windows user is actually stored in ADAM. ADAM simply forwards the authentication request on to the machine itself.
• ADAM does not require an additional license beyond the license you purchased for the host operating system. We also can redistribute ADAM with our own products, subject to the terms of the license agreement, of course (we are not lawyers; read the fine print).

Based on our experience so far, many people have had difficulty determining exactly what ADAM is, or more importantly, what they are supposed to do with it. So, what exactly did Microsoft have in mind when it released this thing? Here are some common scenarios that we hope will help to illustrate the concept.

• Let's say we are building a public-facing web site that can hold thousands (or hopefully millions) of accounts for our (hopefully paying) customers. We do not want to use Active Directory, as we do not need all of its features; we simply want a user store. ADAM gives us an alternative to using a traditional relational database such as SQL Server to store these accounts, authenticate our users, and manage the life cycle of their accounts. Because it already has first-class support for things like secure password storage, password policies, account life cycles, and groups, ADAM provides many benefits over SQL out of the box.
• Now, let's take the same example we just described, but instead of a public-facing web site, we have an extranet scenario with internal users who are stored in Active Directory but external users who are not. Again, we can use ADAM and its pass-through authentication feature to store the external users in ADAM and authenticate both types of users with an LDAP bind. This keeps the application design simple and prevents us from having to duplicate our internal user accounts in a separate directory, reducing the complexity of managing the identity life cycle on our internal accounts.
• ADAM is a great place to store company-wide directory information that we might not want to include inside Active Directoryfor example, items such as pictures that can take up a lot of space and consume precious replication bandwidth. We also can use ADAM in this case as a central aggregation point for many disparate directories, including non-Microsoft directories and perhaps even directories that are not implemented with LDAP at all.
• Perhaps we are building a commercial product, such as a certificate authority that issues certificates for SSL, end-user encryption, or code signing, and we are targeting our product for the Windows platform. We would like to provide an LDAP interface into our certificate store. ADAM allows us to use Microsoft's LDAP database to provide these features, saving us the trouble of building such a store ourselves and giving us all of the enterprise-scale features that Active Directory is known for (a robust store for large numbers of objects, replication, deployment flexibility, etc.). We can then redistribute ADAM with our product, assuming it already targets Windows Server 2003.

This book deals primarily with Active Directory, but much of it applies directly to ADAM as well. When there are interesting differences, we point them out and try to provide relevant examples whenever possible.