Microsoft's Active Directory Application Mode (ADAM)

Microsoft's introduction of ADAM has set the stage for a major shift in the way directories are used for application authentication.

META Trend: Driven by compliance and cost, organizations will focus on identity as a business asset. Identity management will continue to confuse, but grow, as more organizations spawn projects around identity infrastructure (e.g., enterprise directories, Web SSO) and user life-cycle management. Web services (2005/06) will expand identity to non-person users and exacerbate the need for identity solutions. Identity infrastructure will be incorporated into application infrastructure "stacks," incorporating finer-grained authorization (2004-06), and cease as a standalone market (2006/07). User life-cycle management will draw closer to other operations functions (2006/07).

Setting the Stage: Why ADAM?
With Microsoft’s release of its Windows 2000 (Win2000) operating system, a viable and relatively scalable directory solution in the form of Active Directory (AD) was also delivered. AD proved suitable as a framework for file/print/network authentication services, a global address list repository for Microsoft Exchange, and a repository for other infrastructure needs such as domain name services and group policy application for network assets. However, extensive use of AD as an application directory (i.e., delivering authentication services for direct application access) did not widely occur. Driving multiple application authentication needs onto the existing functions of AD was considered a complex and potentially unsecure or unstable exposure by some IT organizations. Other organizations considered the basic architecture of AD (as a network operating system-centric directory) as unsuited for application-specific directory needs, yet others were concerned about changing the schema to meet application requirements and excessive replication potential. This resulted in a relatively small number of AD implementations specifically devoted to application authentication or implementations that included such functions during normal service delivery.

In early 2003, Microsoft introduced Windows 2003 (Win2003) and, shortly thereafter, ADAM. This mode or variant of Active Directory sought to fulfill several requirements. One important requirement was to provide Microsoft customers with a viable product that could compete effectively with application-centric directories on the market such as Sun One directory server, Novell eDirectory, IBM Directory Server, Oracle Internet Directory, Siemens DirX Directory, and Computer Associates eTrust Directory. With the exception of Novell’s eDirectory, these products came from different roots. Like Active Directory, eDirectory was a network operating system directory that made the transition to a standalone application during the late 1990s. The other directory products evolved from relational database systems, e-mail databases, or hierarchical file systems. Although initially deployed as externally facing extranet directories during many enterprise forays in the Internet, directory services within enterprises (i.e., the “intranet”) are also quite common, serving Web application authentication needs for employees. The Lightweight Directory Access Protocol (LDAP) is the primary client-to-server standard currently used in directory implementations. It is into this environment that Microsoft has introduced ADAM (Figure 1).

ADAM Design Principles
The deployment of Win2000 and Win2003 Active Directory for medium- to large-sized enterprises is usually an extensive planning process requiring considerable time and effort. There are many issues to consider because AD serves multiple purposes. In contrast, ADAM can be considered as a lightweight version of AD, where those infrastructure features associated with operating system support are not present. What is present is a data store and services for accessing it. Application programming interfaces provided with ADAM include Active Directory, Active Directory Service Interface, LDAP, and System.DirectoryServices. Microsoft’s purpose in designing ADAM this way was to create a simple developer-friendly platform that allowed for the deployment and use of Active Directory capability during application development without the need for interaction with extensive production Active Directory changes.

ADAM can operate completely independent of Active Directory domain and forest concepts. For all intents and purposes, it can be deployed as a standalone LDAP directory. However, it can operate with Active Directory replication with the use of a feature pack and participate in AD replication network plans. ADAM has its own independent schema and naming context but is still integrated tightly enough to utilize Windows security principles for authentication and access control. ADAM is designed to run only on the Windows 2003 server platform and Windows XP Professional.

Microsoft infrastructure designers tend to view infrastructure as a tool for developers, and ADAM is no exception. ADAM takes the concept of the “directory per application” as a valid design principle. ADAM is a lightweight service capable of running on a low-cost platform and (in Microsoft’s view) being integrated with other ADAMs through a directory integration solution such as Microsoft Identity Integration Server (MIIS), or through direct integration with a central Active Directory serving in a “global host” style mode (see Delta 2415). The concept of distributed directory services from a geographic perspective as well as from an application perspective is appealing to many organizations. The concept of developing applications with quick access to directory services during that development and testing is also enticing.

The Implications of ADAM
There is good news and there is bad news about ADAM. The good news is that Microsoft is maintaining a standards-based direction by ensuring that ADAM supports LDAP Version 3 and applications that rely on x.500-style naming. It is also good that ADAM is not so tightly coupled to Microsoft Windows as Active Directory, enabling more scalability and flexibility opportunities to occur. Perhaps the best news is the pricing model of ADAM. Buyers of Windows 2003 essentially get ADAM free. If ADAM is able to scale effectively, it represents a major threat to the traditional LDAP directory market and will eventually undermine it within two to three years.

The bad news is that, by offering the ability to distribute identity infrastructure so easily and effectively, the burden now falls on process and organization within the enterprise to ensure that rogue installations of ADAM do not undermine the identity infrastructure of organizations. Decisions regarding how many directories are enough directories - and whether each enterprise application deserves its own directory versus using a central enterprise directory (physical or logical) - must now be part of planning discussions. Multiple ADAMs with different schemas will resemble multivendor directory networks enough to give metadirectory products like Microsoft’s MIIS a challenge. Regrettably, the release of ADAM was not matched with releases of effective management and administrative applications for networked ADAM systems (though the Identity Integration Feature Pack, providing some additional capability, is available with Windows Server 2003 EE). It is something that will be needed quickly if customers actually buy into Microsoft’s vision of the ADAM architecture.

Bottom Line: Microsoft’s release of Active Directory Application Mode provides application developers with easier access to an effective identity infrastructure platform, but it presents organizations with two new challenges: managing the development environment to prevent indiscriminate proliferation of “rogue” ADAMs and maintaining a homogeneous identity services strategy that ensures data integrity across multiple implementations of ADAM through the use of directory integration services such as MIIS.

Business Impact: Making life easier for builders does not necessarily make life easier for those that must run the result unless care is taken to address the issue.

META Group originally published this article on 9 February 2004.