What is ADAM?

  • Article

ADAM stands for Active Directory Application Mode and is a new application released with Windows Server 2003 (though it can run on Windows XP).  It is a lightweight LDAP directory that offers basic LDAP functions with a subset of Active Directory functionality.

From the introduction whitepaper on microsoft.com:  “ADAM is a new capability in Active Directory that addresses certain deployment scenarios that are related to directory-enabled applications. ADAM runs as a non-operating-system service, and, as such, it does not require deployment on a domain controller. Running as a non-operating-system service means that multiple instances of ADAM can run concurrently on a single server, and each instance can be configured independently.”

What is it for?  You might be wondering why you would not just use AD?  The usage scenarios described below might drive why you would not use AD.  In many cases, AD is providing an authentication directory for an enterprise.  When specific application requirements arise that require directory customization, often they look to AD.  Unfortunately, making changes to the schema at many organizations requires a Presidential decree.  In some cases, the application may need to store local application data that only applies to this app locally.  We may not want to replicate this data to the entire global AD.  In the end, if LDAP functionality is needed and AD cannot be utilized, ADAM becomes a great candidate.

Below are some usage scenarios for ADAM:

  • Application specific schema requirements.  If your application requires schema changes that do not apply to the entire AD globally (or you cannot get them approved!), ADAM becomes a good candidate.
  • Third party LDAP migration.  If an application currently requires basic LDAP functionality and you are migrating away from this technology, ADAM can be a good interim replacement for this LDAP directory while the application is re-developed.
  • Storage for application personalization data.  This data might not make sense to place in AD.
  • LDAP required in extranet.  Some companies are opposed to placing AD in the extranet.  ADAM could meet their needs.
  • Requirements for X.500 naming style.  AD would not support a naming scheme such as:  O=Organization, C=US.
  • Localized installation.  Could be installed on a server as a service locally to the specific to the machine.  No need to make the machine a domain controller.
  • Developer requirement.  Maybe someone is developing an AD integrated app, but we do not want to have development activities occurring against the DC's. A local ADAM installation for the developer could solve the problem.
  • Data that is changing frequently.  This might cause added AD replication that is not efficient.  Certainly application partitions can help here.  Depending on the data, SQL Server may make sense as well.

There are probably others, but this gives you a start.  Tons of good info on the link below:

https://www.microsoft.com/windowsserver2003/adam/default.mspx