Active Directory Application Mode (ADAM) as an Enterprise Directory

Wow, its taken me a lot longer to get my first post up than I had hoped - I hope the information proves useful to some of you out there :)

As one of my customers is evaluating ADAM for their Enterprise directory, I have been spending more time with this, and have become aware of several of our largest (Fortune 100) companies that have chosen this direction. When we originally released Active Directory in Windows 2000 Server, we architected it to be LDAP compliant; intending AD to be capable of serving as an Enterprise directory. Many of our customers implemented it as such, and leveraged AD for Single Sign On to many of their business applications. However, they found two problems in this approach:

1. Applications required data about the user that was not stored in Active Directory, requiring the Active Directory schema to be extended, or for the application designer to store user data in a separate database from the one being used to authenticate users.

2. Many business applications had external users (business partners, dealers, vendors, etc.). Few enterprises wanted to add accounts in their internal AD implementation for external users, so separate AD instances were set up, typically in separate forests, requiring complicated trust relationships and firewall rules to accommodate. Alternately, and more commonly, enterprises instead stood up a separate directory entirely to support external users, sometimes even creating accounts for internal users in that directory as well to have a single directory with all users (internal and external) and to simplify enabling scenarios like web single sign-on.

We found our customers who were running Active Directory also turning to pure-play LDAP directories to address the above issues, and consequently not realizing the full value of AD. We needed a directory with the reliability and scalability of AD, but the flexibility and simplicity of a ‘vanilla’ LDAP directory. Enter ADAM. ADAM v1 was first released as an add-on to Windows Server 2003 in July 2003, and v2 currently ships in-the-box with Windows Server 2003 R2.

As I learned more about ADAM, I was surprised at the capabilities of this product that comes at no additional cost with Windows Server. Though certainly not the first or only product to be included in Windows Server, it is becoming one of my favorites. (I’ve got to do another post on all of the products that are included in a Windows Server license – it often surprises people when they see the list.) In any case, here are some of the characteristics of ADAM that compliment AD and differentiate it from other LDAP directories that have proven interesting to my customers:

· The User Proxy Object:   Arguably one of the best features of ADAM. The user proxy object in ADAM maps to a regular Active Directory account, and when an application performs an LDAP Bind operation for authentication of that user in ADAM, the account is verified locally, but the password is checked against AD behind the scenes, and the application does not need to know anything about this interaction. This enables ADAM to serve as a single enterprise directory encompassing internal and external users, while still allowing the internal users to manage their accounts and passwords from a single place – Active Directory.

· Security:   By using the User Proxy object, internal users are able to use their AD Kerberos ticket to authenticate – more secure than an LDAP Bind.

· Broad industry support for Active Directory:   Many commercially available software packages purchased by enterprises, such as SAP, natively support integrated authentication via Active Directory to facilitate single sign on (SSO) using Windows credentials (the user’s Kerberos ticket). Using ADAM with the User Proxy Object enables you to leverage this capability.

· Native Windows Server support for Federation: Though federation support is actually implemented through another product included in Windows Server, Active Directory Federation Services (ADFS), it bears mention here because of its relationship to ADAM in a complete identity management solution. ADFS enables organizations to leverage a business partner’s directory (such as AD) to authenticate users from that partner, while maintaining authorization of users access to applications with the organization that hosts the applications based on the users role within the business partner. Some high points of ADFS:

o Reduces the administrative overhead of managing the provisioning and de-provisioning of external users – leaving that responsibility with the organization they work for.

o Potentially more secure than maintaining external users’ identities internally, as (for example), if a user is fired from a business partner that you are leveraging an ADFS partnership with, that user loses access to your applications when his account is disabled or removed from your business partner’s directory. Without federation, de-provisioning this user is a manual process that you perform when (or if) you find out the user is no longer working for your business partner.

o  Leverages existing business partner AD implementations

o ADFS is standards-based and interoperable with non-Windows platforms. Supports WS-Federation standard, which is widely supported by other Identity Management vendors, such as IBM and Ping.

· Simplified Account/Password Management:

o Use of ADAM for an Enterprise Directory leads to fewer accounts and fewer passwords

§ User proxy object from ADAM to AD eliminates a separate account and password for internal users

§ Active Directory Federation Services could also eliminate separate accounts and passwords for external business partners

o Password complexity: support for enforcing complex passwords is built-into AD/ADAM

o Leveraging AD and user proxy in ADAM is an enabling step toward getting to SSO and leveraging Windows credentials to access web applications

· Existing Active Directory experience

o Any organization already running Active Directory has administrators that are familiar with the underlying ADAM architecture and tools used to manage it

o This existing experience can be leveraged and provide economy of scale in managing enterprise directory services

· Reliability/uptime of AD

o ADAM runs on the same underlying engine as AD

o AD has a strong record of reliability and uptime in our enterprise customers.

· Support

o Organizations can leverage existing support agreements to support ADAM – no new service agreements or contracts to negotiate.

o Microsoft can provide a single throat to choke for directory infrastructure, including Enterprise Directory (ADAM), Meta-directory (MIIS), and Network Operating System Directory (AD).

· LOW COST

o Included in Windows Server license at no additional cost

o All users authenticating to Active Directory already licensed with a Windows Server Client Access License (CAL) – no additional cost to license them to authenticate to ADAM.

o External users covered by a low-cost, highly scalable External Connector License (licensed per server vs per user)

As you probably noticed as you read this, many of these advantages are related to Active Directory rather than just ADAM – and that is exactly the point. ADAM is an LDAP directory like any other; it is specifically its native integration with Active Directory that differentiates it.