Active Directory Application Mode: Frequently Asked Questions

For organizations that require a flexible directory service for use within applications, Microsoft has developed Active Directory Application Mode (ADAM), a Lightweight Directory Access Protocol (LDAP) directory service. You can run ADAM on servers running Microsoft Windows Server 2003 and also on clients running Microsoft Windows XP Professional.

ADAM provides data storage and retrieval for directory-enabled applications, without the dependencies that are required for the Active Directory directory service. ADAM provides much of the same functionality as Active Directory, but it does not require the deployment of domains or domain controllers, and the directory schema for ADAM is completely independent of the enterprise schema you may be using in an Active Directory domain. You can run multiple instances of ADAM concurrently on a single computer, with an independently managed schema for each ADAM instance.

For more information about ADAM, please see the Introduction to ADAM.

ADAM is based on the same code as the Active Directory directory service. Therefore, ADAM has scalability characteristics that are comparable to Active Directory, with regard to both the total number of supported objects and the total size of the replication topology and number of sites.

ADAM running on Microsoft Windows XP Professional is intended for use as a personal directory data store. If you intend to use ADAM with distributed applications, run it on Microsoft Windows Server 2003 Standard Edition; Windows Server 2003 Enterprise Edition; or Windows Server 2003 Datacenter Edition.

ADAM is designed for use with directory-enabled applications that support Lightweight Directory Access Protocol (LDAP) v2 or LDAP v3. For information about ADAM, Active Directory, and Request for Comments (RFC) compliance, see the Active Directory LDAP Compliance white paper.

ADAM supports Network Load Balancing (NLB) when ADAM runs on Windows Server 2003 Standard Edition; Windows Server 2003 Enterprise Edition; or Windows Server 2003 Datacenter Edition. In addition, ADAM supports NLB with LDAP over Secure Sockets Layer (SSL) (LDAPS).

ADAM does not currently support server clusters.

ADAM has been tested with up to 5 million objects. ADAM shares its core code with Active Directory in Windows Server 2003, which has been tested with up to 60 million objects.

A common scenario is one in which a portal application must store personalization data that is associated with users who are authenticated by Active Directory. Storing this personalization data in Active Directory itself would require schema changes to the user class, which is often expensive or complex to do in a large enterprise network. Instead of modifying the Active Directory schema, the application can use Active Directory for authentication and service publication, while using ADAM to store user personalization data. In effect, ADAM architecturally acts as an application-specific extension to Active Directory.

ADAM can also be used for authentication in cases where the enterprise Active Directory does not store the user authentication information. This can be useful in public-facing e-commerce sites.

ADAM is also useful for developers who are prototyping an application that will use Active Directory. In this case, the application in development can work against an instance of ADAM without disrupting the enterprise deployment of Active Directory.

For more information about the scenarios for which ADAM is designed, including Microsoft Windows NT 4.0 scenarios, see the Introduction to Active Directory Application Mode white paper.

We recommend that you exclude the following ADAM files from antivirus software scans:

For information about how to exclude these files from scanning, see the product documentation for your antivirus software.

Note: Running antivirus software against these files can cause problems with the Extensible Storage Engine (ESE) that require you to stop and restart the ADAM service.

By default, these files are located in:

     \Program Files\Microsoft ADAM\instancename\Data

where instancename is the ADAM instance name that you specify during installation.

If the Guest account on a computer on which ADAM is running is enabled, unsuccessful bind attempts to ADAM may be reported as successful, even though the bind attempts actually failed. To prevent these unsuccessful binds from being reported as successful, you can disable the Guest account on computers running ADAM. For information about disabling the Guest account, search for "guest account" in Help and Support Center in Windows Server 2003.

When the computer running ADAM is joined to a workgroup, you must set the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\forceguest to 0. (The default is 1.) Otherwise, users connecting to ADAM over the network are forced into a security context of Guest, and binds to ADAM fail.

To enable SSL-based encrypted connections to ADAM, you must have a certification authority (CA) in place to issue and manage certificates. You can set up a CA on a computer running Microsoft Windows® 2000 Server or Windows Server 2003. For more information about installing and using a CA, see the Certificate Services topic in the Windows Server 2003 Help.

The general steps for setting up SSL for ADAM are as follows:

Notes:

The authentication mechanisms that ADAM supports depend on the type of security principal being authenticated. ADAM supports three types of security principals: local Windows security principals, Active Directory security principals, and ADAM security principals. (In addition, ADAM can be configured to support anonymous binding. For more information, see "How do I enable anonymous binding in ADAM?" later in this article.) The authentication methods that are supported for each of the three types of security principals are as follows:

Bind redirection is designed for applications that cannot be rewritten to use Windows security principals. You should only use bind redirection if you cannot use Windows security principals with your application. Using Windows security principals directly from your application takes advantage of the Active Directory infrastructure. Also, when you use bind redirection, you must present Active Directory passwords to ADAM in plain text, which can be encrypted with SSL. By using Windows security principals, you do not need to present Active Directory credentials in plain text to ADAM.

Anonymous binding is not enabled by default in ADAM. (This is also true for Active Directory.) To allow anonymous LDAP binding to an ADAM instance, complete the following procedure.

To allow anonymous LDAP binding to an ADAM instance:

When ADAM runs in a workgroup environment (rather than in a domain environment), the ADAM administrator account on each of the ADAM instances in a configuration set is only recognized on the local computer, not on the remote ADAM instances. To resolve this issue, add the ADAM administrator account (or group) from each of the ADAM instances to the ADAM Administrators group in each of the other ADAM instances. You can also use one of the Windows built-in accounts or groups (such as BUILTIN\Administrators) as the ADAM administrator account. Such built-in accounts and groups will be recognized on each of the ADAM instances.

To enable directory object access auditing in ADAM, complete the following tasks:

To enable auditing in Group Policy and apply the Group policy to the ADAM server:

NOTE: Complete this procedure on a stand-alone ADAM server.

NOTE: To apply the new policy, you can either wait for the next GPO refresh interval to complete, or you can open a new command prompt (cmd) and then type gpupdate /force. You can verify in the Event Viewer if the new policy was applied.

Part 2: Enable access auditing for a particular ADAM directory object in ADAM:

To enable access auditing for a particular ADAM directory object:

NOTE: Access auditing changes applied to ADAM objects (event ID 566) are logged in the Event Viewer under Windows Logs/Security

As a best security practice, you should not disable strong encryption in a production environment. Strong encryption ensures that passwords are transmitted only across secure channels. For test environments only, you can disable strong encryption, as described in the following procedure.

To disable the requirement for strong encryption in ADAM:

By default, an ADAM instance running on Windows Server 2003 automatically enforces any local or domain password policies that exist. If you create a new ADAM user and assign a password to that user that does not meet the requirements of the password policy that is in effect, the user will be disabled by default. To enable the user, you must assign a password that meets the password policy requirements and then enable the user. For information about enabling an ADAM user, see "To disable or enable an ADAM user" in the ADAM Administrator's Guide. To open the ADAM Administrator's Guide, click Start, point to All Programs, point to ADAM, and then click ADAM Help.

For information about how to change ADAM user passwords, see "To set or modify the password of an ADAM user" in the How To section of the ADAM Administrator's Guide. To open the ADAM Administrator's Guide, click Start, point to All Programs, point to ADAM, and then click ADAM Help.

Note: You cannot change the password of an Active Directory security principal through ADAM. You can only change the password of ADAM security principals.

You cannot create a userproxy object for a domain user in an ADAM directory partition that already contains a foreign principal object (FPO) for that same domain user.

No, ADAM cannot host Active Directory partitions. In addition, application directory partitions that are hosted in Active Directory cannot be replicated to ADAM. For information about how to synchronize data between Active Directory and ADAM, see "How do I synchronize data between Active Directory and ADAM?" later in this article.

By default, you can only create OUs under the following objects:

For example, you can create an OU in an application partition named o=Microsoft,c=US, but you cannot create an OU in an application partition named l=Microsoft,c=US.

Note: You can modify the possiblesuperiors attribute of the OU object class in the schema to modify the types of objects that can contain OUs.

You can use dsmgmt to add an application directory partition to an ADAM instance, as described in the following procedure.

To add an ADAM directory partition using dsmgmt:

After you create a partition, you must unbind and rebind to ADAM. When you rebind, you will get the Administrator security IDs (SID) for the partition in your access token, and you will be able to create objects in the partition. ADAM performs token evaluation only on bind.

Make sure that you are using the version of Ldifde.exe that is provided with ADAM. The easiest way to ensure that you are using the correct version of Ldifde.exe is to start Ldifde.exe from an ADAM Tools command prompt. To open an ADAM Tools command prompt, click Start, point to All Programs, point to ADAM, and then click ADAM Tools Command Prompt.

In the versions of Ldifde.exe and Csvde.exe that are provided with ADAM, the -z switch forces the command to ignore errors during import. As an alternative, you can use the -k switch, which ignores only Constraint Violation and Object Already Exists errors.

You can use the Identity Integration Feature Pack for Microsoft Windows Server Active Directory—or a non–Microsoft synchronizing solution—to synchronize data between Active Directory and ADAM.

For information about obtaining the Identity Integration Feature Pack for Microsoft Windows Server Active Directory, see the Microsoft Identity Integration Server 2003 Web site.