I recently blogged about Microsoft Identity Integration Server (MIIS), which is Microsoft’s platform for connecting directory enabled applications and facilitating identity management. For organisations that require flexible support for directory enabled applications and for which organisational constraints or schema issues prevent the use of Active Directory (AD), Microsoft has developed Active Directory application mode (ADAM).

ADAM is a lightweight directory access protocol (LDAP) directory, providing many of the features of AD, but which can be used to support directory enabled applications that are not considered safe for use with AD. Although AD was designed to be extendable, possible concerns over safety could include:

• Unacceptable schema changes.
• Security risks.
• Directory management requirements.
• Development requirements.

ADAM runs as a user service (rather than as a system service) and multiple instances can be run concurrently on a single computer, with an independent configuration for each instance. Unlike AD, ADAM doesn’t have any dependencies on the domain name system (DNS) or file replication service (FRS). Instances that share the same configuration and schema can be added to a configuration set and will replicate changes to one another; however ADAM cannot replicate with AD – instead, there is a beta tool called the Active Directory to ADAM Synchronizer that provides one way synchronisation from AD to ADAM.

On the client side, ADAM supports any client that is written to the LDAP v3 technical specification as well as Active Directory service interfaces (ADSI) for clients from Windows 2000 onwards.

To illustrate where ADAM might be useful, here are three example scenarios:

1. The first scenario is an intranet portal application for users that have been authenticated by AD. Because ADAM is integrated with the Windows security model, any application that is deployed using ADAM can authenticate access against AD across the enterprise. Global data is stored in AD, whilst application-specific data is stored in ADAM. As the application uses AD for authentication it doesn’t need to maintain its own database of user IDs and passwords (although this is supported if required) and because ADAM is used for the application’s personalisation data, there is no need to extend the AD schema. Different departments using the application may have different schema requirements and apply different business logic to directory data. The answer to this is ADAM’s support for multiple instances, each with their own schema, without needing to modify the enterprise schema or to manage yet another set of user accounts and passwords. These isolated ADAM instances may be deployed and managed locally or centrally.
   
2. The second scenario is a web portal application that handles extranet access management. In this case the portal directory is used for authentication purposes only. ADAM can be used to store application information, while authenticating user objects using LDAP simple binds, allowing ADAM to work in heterogeneous environments and in situations where AD is not present (or is deliberately segregated).
   
3. The final scenario considers an organisation in the process of migrating to AD but which still has applications that rely on an X.500 naming convention or directory. ADAM can serve as an interim solution to support the legacy applications through the migration process which using AD for user authentication and a shared security infrastructure. Optionally, MIIS can be used to transform identity information between AD, ADAM and any other identity stores in use. By using a single directory technology for both the network operating system and application directory needs, overall infrastructure costs are reduced as additional investments are not required for training, administration, or management of the application directory. The LDAP, ADSI, and directory services markup language (DSML) application programming interfaces are also equivalent between the two directory services, so that applications may be built on ADAM and then migrated to AD as needed, with minimal change.
   

By using ADAM to isolate application-specific information from AD and for simple authentication for extranet applications, organisations are able to develop, deploy and manage directory-enabled solutions without the need to create separate user databases or change the schema of AD to support each application. Because the ADAM directory can easily be installed, reinstall, or removed, it may be considered for deployment with an application.

Similar to the partition structure in AD, ADAM consists of a number of naming contexts (NCs), which are:

• Configuration NC – CN=Configuration,CN={GUID}
• Schema NC – CN=Schema,CN=Configuration,CN={GUID}
• One or more application directory partitions (ADPs), e.g. cn=partition1,dc=markwilson,dc=co,dc=uk.

The configuration and schema NCs are provided by default and are automatically configured, with the application directory partitions specified by the administrator. Note that they are defined by an instance GUID, and not using DNS names. Because it is an LDAP directory, ADAM can also support x.500 names for integration with legacy applications (LDAP was designed as a lightweight version of the X.500 directory access protocol).

ADAM can be installed on computers running any version of Windows XP or Windows Server 2003 (32- or 64-bit) and does not require a forest, domain, or domain controller so can be installed on computers that are configured as domain controllers, domain members or workgroup members.

During installation the only options required are:

• Acceptance of the license agreement.
• Whether or not to install the ADAM administration tools.
• Whether to install a unique instance, or a replica of an existing instance.
• Instance name (a service will be created named ADAM_instancename).
• LDAP and SSL port numbers (389 and 636 by default, but these should be changed to high numbered ports if AD is or will be installed on the same computer).
• Whether or not to install an ADP (and if so, the ADP name) – some applications will create their own ADP on installation.
• Data and data recovery file locations (by default, %Program Files%\Microsoft ADAM\instancename\data.
• Service account information (network or a specified account).
• ADAM administrator details.
• Any lightweight directory interchange format (LDIF) files to extend the application partition schema – these can also be imported at a later time, using LDIF directory exchange utility (ldifde.exe).

Once installed, ADAM has a limited toolset, with ADAM ADSI Edit, ADAM Help and the ADAM Tools Command Prompt. Many of the command prompt tools have the same names as their AD counterparts, so it is important to use the correct command prompt.

ADAM security is based on the AD model, with the majority of default permissions set on the NC head for a number of default groups, held in the roles container for each partition. For an application directory partition, the default groups are Administrators, Readers and Users. There is no user interface for setting security, instead the ADAM version of the dsacls.exe support tool is used although the ldp.exe support tool is useful for viewing security descriptors. An LDAP simple bind is used for ADAM security principles, whilst for Windows security principles, a simple authentication and security layer (SASL) bind is used (either Kerberos or NTLM) and there is also provision for binding to ADAM and redirecting to AD via an ADAM proxy object. Anonymous access is also available, controlled using the dSHeuristics flag (in the configuration directory partition – CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,CN={GUID} – on which various bits are set to indicate various directory operations, detailed in the product documentation).

Although ADAM cannot replicate objects to and from AD (for that, either MIIS or the Identity Integration Feature Pack for Active Directory is required), the AD to ADAM Synchronizer allows application administrators and developers to use an XML configuration file and a scriptable command line interface to specify a filtered and scoped subset of data to be pulled from AD to ADAM.

No data is written back to AD and the objects and values in ADAM are not transformed in any way. Object or attribute based evaluation rules cannot be implemented and values from the source (AD) are authoritative. While the application may extend the data stored in ADAM, any shared data will be overwritten on subsequent runs, with data values from AD.

Using the ADAM synchronizer involves:

• Extending the ADAM schema to support the ADAM synchronizer along with the attributes and objects that are to be imported.
• Setting the appropriate fields in the ADAM synchronizer’s conf_public.xml file and loading the file.
• Running the synchronisation.

ADAM looks to be a useful addition to the Microsoft directory services toolset. I only wish that some of the Microsoft applications used it so I could avoid extending the AD schema for them (e.g. Exchange, ISA Server and SharePoint Portal Server).

Credits

Although I have provided additional information from my own research, the inspiration for this blog post was a seminar hosted by Microsoft, during which John Craddock and Sally Storey from Kimberry Associates presented on stretching directory boundaries: cross platform identity management, authentication and security. The ADAM deployment scenarios above were taken from Microsoft’s ADAM overview presentation.