What Is Active Directory Application Mode?

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2012, Windows Server 2012 R2

In this section

• The Business Need

• The ADAM Solution

• LDAP Directories Compared to Relational Databases

• ADAM Compared to Active Directory

• ADAM Scenarios

• Related Information

Active Directory Application Mode (ADAM) is a new mode of Active Directory that is designed specifically for directory-enabled applications. ADAM is a Lightweight Directory Access Protocol (LDAP) directory service that runs as a user service, rather than as a system service. You can run ADAM on servers and domain controllers running operating systems in the Windows Server 2003 family (except for Windows Server 2003, Web Edition) and also on client computers running Windows XP Professional.

ADAM contains many Active Directory components and features, but ADAM differs from Active Directory in several key ways, as described in “ADAM Compared to Active Directory” later in this section. Some of the scenarios for which ADAM is designed are described in “ADAM Scenarios” later in this section.

The Business Need

ADAM is a directory service that is designed to meet the needs of organizations that cannot rely solely on Active Directory for providing directory services for directory-enabled applications. While Active Directory offers many benefits for managing network infrastructure, organizations often need a more flexible directory service to support directory-enabled applications.

For example, most directory-enabled applications require the directory service to be extended with application-specific schema extensions. Such schema extensions are supported in Active Directory. However, because Active Directory is mission critical for overall network operations, many administrators consider Active Directory to be “off limits” with respect to application-specific schema changes. In addition, many LDAP directory usage scenarios, including development, portal, and legacy application scenarios, are hindered by the forest and domain requirements of Active Directory.

The ADAM Solution

ADAM is a new mode of Active Directory that is designed for organizations that require flexible support for directory-enabled applications. ADAM provides data storage and retrieval for directory-enabled applications, without the dependencies that are required for Active Directory. ADAM provides much of the same functionality as Active Directory, including multimaster replication, but ADAM does not require the deployment of domains or domain controllers. You can run multiple instances of ADAM concurrently on a single computer, with an independently managed schema for each ADAM instance. You can run ADAM on servers and domain controllers running operating systems in the Windows Server 2003 family (except for Windows Server 2003, Web Edition) and on computers running Windows XP Professional.

The following figure illustrates the ADAM solution. In the figure, the computer running ADAM is hosting three separate ADAM instances, each with independently managed schema and data. Each ADAM instance is supporting a different directory-enabled application. The computers in this figure can reside within or outside an Active Directory forest.

Active Directory Application Mode Solution

LDAP Directories Compared to Relational Databases

Both LDAP directories (such as ADAM and Active Directory) and relational databases (such as Microsoft SQL Server 2000) can be used to support applications. However, LDAP directories and relational databases are designed for different purposes. Understanding the basic differences between these two technologies can help you choose the right technology for your application.

The following table summarizes the basic design differences between LDAP directories and relational databases.

Design Differences Between LDAP Directories and Relational Databases

Given these design differences, LDAP directories and relational databases are each particularly suited to certain types of applications.

LDAP directories are well suited for:

• Applications that manage data that is needed by clients throughout the network. Because LDAP directories can replicate data throughout a network easily and efficiently, LDAP directories are well suited to applications that require wide data distribution.

• Applications with a high ratio of search and read operations to write operations. Because LDAP directories are optimized for search and read operations, they are best suited to applications in which data changes infrequently.

• Applications that benefit from hierarchical storage and security models. LDAP directory services are particularly useful when the data that they store benefits from container-style storage and inheritance-based security. For example, data that is related to enterprise “white pages” usually maps well to a hierarchical model. In other cases in which data corresponds to large business-to-consumer (B2C) e-commerce sites — where users are stored as huge, flat lists, LDAP directories may not be as well suited.

Good candidate applications for LDAP directories include the following:

• White pages applications that store contact and location information about people

• User, security, and resource management applications

• Applications that store network configuration and service policies

Relational databases are well suited for:

• Applications that require complex transactional updates. Directory services do not support complex transactions across multiple object types or tables. Therefore, applications that must observe atomicity, consistency, isolation, and durability (ACID), such as inventory databases, are best suited to relational databases.

• Applications that require change history information. With LDAP directories, it is not practical to create a centralized log that reflects all the updates that have been applied on all replicas throughout the network. Therefore, applications that require a log of changes that are made to data (for example, for auditing reasons) are best suited to relational databases.

• Applications that do not tolerate replication latency and inconsistency. Because of the store-and-forward style of replication that is used by directory services and the fact that directory service replicas are frequently connected by unreliable network connections, directory-enabled applications cannot be designed to rely on updates that propagate between replicas on any particular schedule or on updates that arrive in a particular order.

Good candidate applications for relational databases include the following:

• Airline reservation systems

• Banking systems

• Accounting applications that require transactional update protections and updates that typically occur quickly

• Centralized data collection

• Hardware inventory applications. Most data about the hardware configuration of client and server computers is not relevant to applications throughout the network.

• Process control. Any application that depends on the timing of data propagation between replicas is not well suited for a directory service.

ADAM Compared to Active Directory

ADAM is a special mode of Active Directory that is based on the same source code as Active Directory. To a large extent, ADAM operates just like Active Directory. However, because ADAM is designed specifically to support directory-enabled applications, rather than server operating system operations, there are some key differences between ADAM and Active Directory. These differences are related to:

• Supported operating systems

• Schema

• Partition naming

• Directory server consolidation

• Replication

• Dependencies

• Performance and scalability

Supported Operating Systems

The following table lists the operating systems that are supported by Active Directory and ADAM.

Operating Systems Supported by Active Directory and ADAM

When you run ADAM on Windows XP Professional, there are certain considerations to keep in mind. For more information, see “ADAM Servers” in “How Active Directory Application Mode Works.”

Schema

The schema defines what kind of information the directory can hold. With Active Directory, a single schema applies to the entire forest; that is, all domain controllers must use the same schema. With ADAM, each stand-alone ADAM instance or ADAM configuration set can have its own schema. In addition, the schema of each ADAM instance is fully independent from the Active Directory schema.

Another difference between ADAM and Active Directory is the size of the base schema. The base schema of Active Directory is designed to support overall server operating system operations, and it is therefore very large. The base schema of ADAM is very small — just large enough to bootstrap the ADAM instance. The ADAM schema is designed to be extended with the schema elements that are required for the applications that the ADAM instance supports.

Finally, while only certain object classes in Active Directory can be used to bind to (or authenticate against) Active Directory, you can give any object class in ADAM the ability to bind to ADAM by adding the msDS-bindableobject auxiliary class and the unicodePwd attribute to the schema definition of an object class. For more information about bindable object classes, see “ADAM Security Principals” in “How Active Directory Application Mode Works.”

Partition Naming

A directory partition is a logical portion of the directory data store. Each ADAM directory partition has its own unique distinguished name. ADAM partition naming is more flexible than partition naming in Active Directory. Active Directory supports only Domain Name System (DNS)–style (DC=) names for top-level directory partitions. Such names can contain only DC= naming components. For example, Active Directory can have a partition named DC=Microsoft,DC=COM, but it cannot have a partition named DC=Microsoft,C=US. In contrast to Active Directory, ADAM can have a directory partition named DC=Microsoft,C=US.

ADAM also supports both DNS-style and X.500-style names for top-level directory partitions. ADAM supports all the distinguished name components that are listed in the following table.

ADAM Directory Partition Distinguished Name Components

For more information about directory partitions, see “Directory Partitions” in “How Active Directory Application Mode Works.”

Directory Server Consolidation

Because of the limitations that are placed on Active Directory by forests and domains, each domain controller can run only one instance of Active Directory. However, with ADAM you can run multiple directory service instances on each computer. Running multiple instances of ADAM on a single computer helps you lower your total cost of ownership (TCO) by consolidating directory operations onto a single server or just a few servers.

Replication

Active Directory domain controllers replicate with each other based on membership in a domain or forest. ADAM instances replicate with each other based on membership in a configuration set. A configuration set is a group of ADAM instances that share and replicate a common configuration partition and schema partition. ADAM instances cannot replicate with Active Directory. Furthermore, ADAM instances replicate on a schedule that is completely independent of the Active Directory replication schedule, even when ADAM is running in an Active Directory forest.

Dependencies

One key difference between ADAM and Active Directory is that ADAM is free of some of the underlying dependencies that are required by Active Directory. For example, ADAM does not require or rely on forests or domains. In addition, ADAM does not rely on the File Replication service (FRS) or DNS, both of which are required for Active Directory to function properly.

Performance and Scalability

Because ADAM is based on the same code as Active Directory, ADAM has the same scalability and performance characteristics as Active Directory. In other words, ADAM supports a comparable number of users, sites, and objects as Active Directory. In addition, ADAM LDAP and replication performance is comparable to that of Active Directory.

ADAM Scenarios

ADAM is designed to support a number of usage scenarios, including scenarios that are related to the following:

• Application-specific directories

• Application development

• Support for legacy applications

• Programmatic access to Microsoft Identity Integration Server (MIIS) 3.0

• Extranet access management

Application-specific Directories

In the application-specific directory scenario, a directory-enabled application (such as a portal application) requires an LDAP data store for application-specific data that is associated with application users that reside in Active Directory. Because this application-specific data requires schema extensions that the organization does not want to make to Active Directory, this application-specific data store must reside outside Active Directory. In this scenario, the directory-enabled application can use Active Directory for authentication of users and for service publication while it uses ADAM as a store for the application-specific data that is associated with each user. If the application requires other application-specific data, such as policy and management information, this data can also be stored in ADAM. By using the user principals in Active Directory for authentication and for controlling access to objects in ADAM, the organization can achieve single sign-on (SSO). This design helps avoid the need for each ADAM directory to have its own user database, which prevents a proliferation of user IDs and passwords for end users every time that a new directory-enabled application is introduced on the network. The following figure illustrates an ADAM application-specific directory scenario.

ADAM Application-specific Directory Scenario

The ADAM features that are described in the following sections play an important role in application-specific directory scenarios.

Storage of Application-specific Data

An application can use ADAM to store “private” directory data, which is relevant only to the application, in an application-specific directory service — perhaps on the same server as the application — without requiring any additional configuration to Active Directory. The application-specific data, which does not need to be widely replicated, is stored solely in the ADAM directory that is associated with the application. This design has an added benefit of reducing replication traffic on the network between domain controllers. In addition, because ADAM is based on the same database engine as Active Directory — the Extensible Storage Engine (ESE), the ADAM data store scales to millions of objects and gigabytes of storage.

Tailored Schema

Business data is often organized uniquely for a particular application. ADAM is useful when an organization must use a directory-enabled application that is based on a unique business logic or schema. For example, an application developer may want to expose application data through LDAP in a way that is specific to the clients of the application. The application requires a different schema than the existing Active Directory installation for the server operating system. Without altering the configuration of the Active Directory, the organization is able to provide a directory-enabled application with a tailored schema that meets the organization’s business needs, data requirements, and workflow processes. The workflow and associated data that is represented by the application directory can then be stored in the most intuitive way possible, independent of the existing directory structure. In addition, ADAM helps avoid schema conflicts by providing organizations with a separate and independent directory service for each directory-enabled application.

Local Management in the Organization

In many organizations, departments implement applications that are relevant to their operations. Because these applications are specific to a department, the information that is stored by each application may not be relevant to the rest of the organization. Each department may need to manage its own local directory service independently. For example, a department may require replication schedules that differ from the replication schedules that are offered by the enterprise directory. ADAM supports this requirement by enabling each department to manage its own directory service independently.

Optional Centralized Management

An ADAM instance can be deployed on a locally administered, departmental server or on a centrally managed server, offering a choice of distributed or centralized management. A centrally administered server can host multiple, independently configured instances of ADAM on the same computer, which provides greater efficiency through server consolidation and ease of management. Each separate instance of ADAM can be used by a different directory-enabled application.

Windows NT 4.0 Domains

You can install ADAM on a computer running Windows Server 2003 or Windows XP Professional that is joined to a Windows NT 4.0 domain. Any directory-enabled application that can run on ADAM can also run in a Windows NT 4.0 domain. Because ADAM works with any Windows-integrated security infrastructure, the Windows NT 4.0 domain can be used to authenticate domain users for ADAM.

Application Development

Developers can use ADAM to prototype an application for Active Directory. ADAM uses the same programming model as Active Directory and provides a similar administration experience. Developers can work with a local instance of ADAM on a developer workstation and then move the application to Active Directory.

Active Directory Application Mode Setup Wizard

One feature that enhances the use of ADAM for application development scenarios is the Active Directory Application Mode Setup Wizard. ADAM provides a simple setup wizard that requires little manual input. The setup can easily be scripted, which is beneficial for unattended and silent installations as part of application installation. Developers can install and uninstall ADAM or use multiple instances of ADAM during the development phase. No reboot is required during setup.

Locally Installed, Locally Managed

Consider a scenario in which an application developer is developing a directory-enabled application. Having the directory on a server or domain controller requires the organization to provide a server-class development server. This server must be managed, and installing or uninstalling the directory can affect other users. ADAM does not have to be installed on a server or domain controller; it runs effectively on client computers. Therefore, you can deploy an application without using the resources of a dedicated information technology (IT) professional. ADAM runs on the following:

• Computers running Windows XP Professional

• Domain controllers and servers running:

  • Windows Server 2003, Standard Edition

  • Windows Server 2003, Enterprise Edition

  • Windows Server 2003, Datacenter Edition

Support for Legacy Applications

In a legacy application scenario, suppose that your organization has an established directory using the X.500-style attribute value assertions of o=<organization> and c=<country>, and the organization relies on this directory to serve legacy applications. In addition, the organization wants to migrate to Active Directory. In this scenario, to enable migration to Active Directory, you can deploy ADAM to service the applications that rely on X.500-style naming, which Active Directory does not support. You can deploy Active Directory in the organization to provide a shared security infrastructure, while ADAM provides direct support for the legacy applications. As applications are rewritten to avoid the use of o= and c=, the applications can be migrated to Active Directory. You can use a metadirectory application, such as MIIS 3.0, to synchronize data from ADAM to Active Directory automatically for a seamless migration experience. The following figure illustrates an ADAM legacy application scenario.

ADAM Legacy Application Scenario

Programmatic Access to MIIS 3.0

In a scenario of programmatic access to MIIS 3.0, ADAM provides a read/write interface to MIIS 3.0. MIIS 3.0 synchronizes data between multiple data stores, including LDAP directory services, SQL databases, and other data stores. MIIS 3.0 stores its data in SQL Server 2000. By design, the data that is held by MIIS 3.0 is not available for modification; the data can only be updated when synchronization with one of the connected data sources occurs. You can use ADAM to enable LDAP programmatic access to MIIS 3.0 data. First, the data from an installation of MIIS 3.0 is synchronized to an existing ADAM instance. The data in ADAM can then be modified programmatically through one of the LDAP programmatic interfaces to ADAM. After the data has been updated in ADAM, the data can be resynchronized with MIIS 3.0, updating the data that is held by MIIS 3.0. The following figure illustrates an ADAM scenario of programmatic access to MIIS 3.0.

ADAM Scenario Featuring Programmatic Access to MIIS 3.0

Extranet Access Management

In an extranet access management scenario, an organization uses a Web portal application (such as OpenNetwork DirectorySmart or Netegrity SiteMinder) to handle extranet access management. The Web portal application stores the authorization information as data in an LDAP directory and uses the directory for authentication purposes only. In such a scenario, ADAM can be used as the LDAP directory store to provide simple authentication support for the Web portal application. Because ADAM can host user objects that are not Windows security principals but are authenticated with LDAP simple binds, all the user information, as well as authorization data for these applications, can be stored in ADAM. This configuration works equally well in heterogeneous environments, where Active Directory is not present as the infrastructure provider. In this case, the Web clients are serviced by the portal application, which can be running on any platform, while ADAM is used as a simple LDAP store. The following figure illustrates an ADAM extranet access management scenario.

ADAM Extranet Access Management Scenario

Related Information

The following resources contain additional information that is relevant to this section:

• How Active Directory Application Mode Works