Identity & Access Management

Create Custom Directories with ADAM

Brian Redmond

At a Glance:

• ADAM versus Active Directory
• Using ADAM effectively
• ADAM bind redirection
• Some ADAM-centric utilities

Active Directory Application Mode, also known as ADAM, is often misunderstood. In this article I will demystify ADAM, explain how it can be a useful tool in many organizations, and show you some valuable utilities that make it easier to use.

ADAM is a directory service based on the Lightweight Directory Access Protocol (LDAP). The concept of an LDAP directory was created after the introduction of X.500 directories. LDAP is similar to X.500, but is more lightweight and is designed for fast, efficient information search. You might think of LDAP as similar to a telephone directory. In computing, LDAP directories store information about people, computers, printers, and services. LDAP directories typically have a replication mechanism that allows this sort of data to be readily accessible across a network or the Internet.

Active Directory® is also an LDAP directory, but in addition, it provides a substantial list of other infrastructure services that are not part of a basic LDAP directory. ADAM is solely an LDAP directory, built for situations where LDAP is the only required protocol. It does not provide all of the additional infrastructure features that Active Directory provides.

Figure 1 shows the differences between ADAM and Active Directory. As you can see, ADAM uses the same Extensible Storage Engine (ESE) database engine as Active Directory. It also uses the same LDAP protocol and replication mechanisms. However, ADAM does not provide a Kerberos service, Group Policy, Global Catalog, and other technologies to support an enterprise-wide security system. LDAP support in ADAM is the same as in Active Directory, which means both are compliant with the LDAPv3 proposed standard (see microsoft.com/windowsserver2003/techinfo/overview/ldapcomp.mspx for more information). This allows you to take a legacy application that requires generic LDAP and possibly migrate it to ADAM, gaining a higher level of standardization and consistency in the directory platform.

Figure 1** ADAM Uses a Subset of Active Directory Components **

Since ADAM and Active Directory share the same database engine and LDAP protocol, you gain some interesting advantages. The programming model is the same; applications that work with Active Directory will typically work in a similar fashion with ADAM. Also, ADAM will scale at least as well as Active Directory, or possibly even better due to less overhead. ADAM shares the same mechanisms for Access Control Lists (ACLs) and delegation of control. This allows for attribute-level control and container-level control within the directory. You can also configure ACLs on the data stored in ADAM for user principals stored in the ADAM instance or for Windows®-based user accounts. By sharing these kinds of technologies, administrators can easily transfer the skills they've acquired in using Active Directory to managing ADAM.

ADAM shares the same reliable replication mechanisms as Active Directory. Multiple ADAM servers can share the same directory, but can still be configured in a multi-master set of replicas. This means that ADAM stores its replication topology within the directory and uses the Knowledge Consistency Checker (KCC) to calculate the actual replica connections. ADAM uses the same serial number (USN)-based delta replication technologies and conflict-resolution algorithms as Active Directory does. If you have worked with Active Directory in the past, you know these technologies to be reliable and resilient. ADAM instances can easily be load balanced using Windows Load Balancing Service or any other network load balancing technology.

ADAM Management Tools

In most cases, the data in ADAM is either synchronized from Active Directory or managed from within a custom application. ADAM does have a number of management tools available to administrators and developers who are building a solution. If you’re used to working with Active Directory, you’ll find many of these tools familiar.

ADAM ADSI Edit Though this is primarily a raw data manipulation utility for administrators, it is the main data-editing utility provided with ADAM. Since ADAM is typically used more for application solutions, organizations often develop front-end interfaces in the application or synchronize the data with another directory.

Ldp This is another raw LDAP tool for viewing and managing the ADAM instance. Ldp.exe can be used with any LDAP directory and allows for viewing, searching, and updating data within the ADAM directory. For example, to connect to an ADAM instance, see the instructions at go.microsoft.com/fwlink/?LinkId=66565.

Dsmgmt With Windows Server 2003, Microsoft increased the focus on providing command-line management tools. The ADAM Dsmgmt tool is used for basic ADAM administrative functions at the command prompt. See go.microsoft.com/fwlink/?LinkId=66566 for more information.

Ldifde and Csvde These tools allow for bulk import and export of directory data. Ldifde uses the LDAP Data Interchange Format (LDIF) for files, while Csvde uses comma-delimited files. Both tools are useful in making mass changes to the directory, but would not be very efficient for ongoing synchronization. For information about Ldifde see go.microsoft.com/fwlink/?LinkId=66568. For information about Csvde see go.microsoft.com/fwlink/?LinkId=66569.

Repadmin This tool allows the ADAM administrator to manage and monitor replication of ADAM replicas. For more information see go.microsoft.com/fwlink/?LinkId=66570.

Dsdiag This tool provides diagnostic functionality for ADAM that is useful during troubleshooting situations. For more information see go.microsoft.com/fwlink/?LinkId=66571.

ADAM Schema Management MMC Snap-In The MMC snap-in is used for changing the ADAM instance schema. To access the snap-in, adamschmmgmt.msc, see go.microsoft.com/fwlink/?LinkId=66572.

But there are some notable differences with ADAM, too. ADAM does not require that you convert your server to a domain controller. In fact, multiple instances of ADAM can be run on a single server. Each instance of ADAM on a single server will have its own schema and LDAP port. ADAM can run on either Windows XP or Windows Server™ 2003. This also includes the 64-bit versions of these operating systems.

You can stop, start, install, or uninstall ADAM instances without restarting the system. ADAM supports X.500 naming conventions for the directory (such as O=US, C=Company).

ADAM credentials can only be used for a LDAP BIND into the ADAM instance. Though there are ADAM user and group objects, they will only have access to objects in their specific ADAM partition. ADAM does not use DNS service locator (SRV) records for users to locate ADAM instances. It is only based upon standard server name lookup (DNS A records). And ADAM does not support the concepts of forests, domain trees, or trusts.

ADAM in R2

Windows Server 2003 R2 was recently released by Microsoft as an update to the Windows Server 2003 platform. A number of the new features in R2 focus on identity management, including ADAM, which was previously only available as a separate download. The R2 version of ADAM has also been updated with some interesting new features. For example, ADAM bind operations now support Digest Authentication. This is a more secure authentication mechanism that eliminates the clear text storage of a user's password in memory.

In cases where a user has a proxy object in ADAM representing a user in Active Directory, ADAM will now allow you to change a password in ADAM and have it automatically changed in Active Directory during the same operation.

In the previous version, only Active Directory users could be ADAM administrators. I could not place an ADAM principal in the proper context that would allow it to manage the instance. Users can now be created in the configuration naming context and thus be given the rights to administer the instance.

With the R2 release, Microsoft also added some new tools that make ADAM much easier to implement and manage. Microsoft added a new version of the Ldp.exe tool that allows for raw LDAP functions. This new version also includes a much anticipated ACL editor. R2 also ships with Active Directory Schema Analyzer and ADAM Synchronizer. These two tools can be used in conjunction with each other to replicate data from Active Directory over to your ADAM instance.

Using ADAM Effectively

ADAM is intended to solve certain kinds of application requirements that can't easily be solved with the existing Active Directory infrastructure. ADAM can be a useful tool in a number of different scenarios.

White Pages Directory Because LDAP directories are well suited to quick search of information, Active Directory can certainly act as a "white pages" employee directory for your organization. On the other hand, if you want the directory to include people who are not in Active Directory, ADAM might be the perfect choice.

Using a directory synchronization utility of your choice, you have the ability to pull data from your Active Directory as well as other databases in the organization (see Figure 2). This allows your white pages directory to include people such as contractors, suppliers, partners, or customers who may be stored in a number of other systems. This ADAM instance could be developed with a Web application interface in your intranet, allowing for easy access to white pages data.

Figure 2** Synchronizing White Pages **

Application-Specific Schema Requirements Many organizations are protective of their Active Directory schema, requiring approval by high-level corporate managers to get the schema extended. There is a safe, documented way to extend the Active Directory schema, but in many cases, it may not make sense relative to the goals of the IT group. For example, the attributes needed for the application may be local to that particular application and not needed for other systems, so extending the Active Directory schema may be hard to justify. In these cases, the application-specific data could be stored in an ADAM instance where the schema could be tailored to suit the needs of the application without impacting the larger Active Directory schema.

Figure 3** ADAM Used for Special Data **

In the model shown in Figure 3, the authentication is still handled by Active Directory. When the application needs to access the special schema data about the user (for example, shoe size or shirt size), it can read the data from or write the data to the ADAM instance. In this example, data like shoe size and favorite color do not belong in the corporate authentication directory.

Extranet Authentication It can be difficult to implement Web applications in an extranet or intranet and provide strong and effective authentication. Kerberos does not work over the Internet, so providing a seamless Web single sign-on (SSO) login experience for users is quite difficult. Solutions often involve placing a policy server in the perimeter network (also known as the DMZ, or demilitarized zone, and screened subnet) that can manage authentication and provide tokens to users for Web SSO.

Microsoft recently released Active Directory Federation Services (ADFS) as a solution for cross-organization trusts to allow federated relationships for Web applications. ADFS can also provide Web SSO for Internet-based Web applications. Generally, policy servers like ADFS do not store user credentials and instead use some sort of LDAP directory. ADFS is designed to work with either Active Directory or ADAM. In this case, ADAM would store the credentials of application users and ADFS would handle the authentication.

In Figure 4, ADFS is running on the Web server and intercepts all requests. Each request is verified against the ADFS Federation Server, which checks ADAM for the validity of the account. Once validated, a token (cookie) is issued and can be used against any other server in the perimeter network environment. (See Matt Steele's article in this issue of TechNet Magazine for more information about ADFS.)

Figure 4** ADAM Used with ADFS **

Legacy LDAP Migration There are many third-party and custom applications developed to work with LDAP directories. Many organizations would like to minimize the number of directories they manage. If some of these applications can be migrated to Active Directory or ADAM, they can begin to accomplish this goal (see Figure 5).

Some applications require special schemas or naming contexts (for example, "O=corp,O=contoso,C=us") that are not compatible with Active Directory. ADAM can replace the legacy LDAP directory and the application could continue to function normally. This solution can be combined with the ADAM bind redirection ability to limit the number of passwords you would need to maintain.

Figure 5** Migrating Legacy Directories **

ADAM Bind Redirection

ADAM bind redirection is a special function that allows legacy applications to be integrated with Active Directory even if they are not designed to support it. This solution is generally targeted at applications that only support LDAP bind as an authentication mechanism. In some cases, the special schema or naming context may force you to avoid Active Directory, making ADAM a perfect choice. That said, you would not want to contribute to the multiple passwords users must remember by employing an additional directory with its own user ID and password.

You can create a special user proxy object in ADAM that maps to a regular Active Directory user account. The user proxy does not have an actual password stored in the ADAM object itself. When the application performs its normal bind operation, it checks the ID locally, but checks the password against Active Directory under the covers (see Figure 6). The application does not need to be aware of this Active Directory interaction. This is clearly beneficial because you can reduce the number of passwords users must remember and maintain. Also, by using ADAM instead of the legacy LDAP directory, your IT department gains consistency across the supported directory solutions.

Figure 6** Using LDAP Bind Redirection **

Active Directory Schema Analyzer

When you build an ADAM instance, you first need to create the appropriate schema for the data to be stored. If you are building a custom application, you can easily build your schema using custom LDIF files, scripts, or in the ADAM Schema Management MMC snap-in. When copying data from an existing Active Directory instance, it would be cumbersome to build the schema file needed. Active Directory Schema Analyzer was created to allow ADAM administrators to quickly copy the schema from an Active Directory instance and then import it into ADAM.

To import a schema, start by opening the ADSchemaAnalyzer utility. Now use the Load target schema function. Here you will enter the connection details for the Active Directory server from which you want to copy the schema (see Figure 7). This will load your Active Directory schema into ADSchemaAnalyzer.

Figure 7** Loading the Target Schema **

Next, use the Load base schema function. This works much like loading the target schema except you enter the connection details about the ADAM instance where you want to copy the schema. When the ADAM schema is imported, ADSchemaAnalyzer compares the two and finds any differences. You can then use the "Mark all non-present elements as included" function to mark the missing schema elements that are needed within ADAM.

Figure 8** Preparing the Schema for ADAM **

Use the Create LDIF file command to create a schema file that will be ready for importing into ADAM, as shown in Figure 8. You can then use an Ldifde command to import the schema into ADAM. The Ldifde syntax needed is provided for you in a comment within the LDIF file created by the tool. For example, you would see something like this:

ldifde -i -u -f "C:\test.ldf" -s adamserver.contoso.com:3389 
-b adammgr contoso * -j . -c "cn=Configuration,dc=X" #ConfigurationNamingContext

Once complete, the ADAM schema is identical to the Active Directory schema.

Active Directory to ADAM Synchronizer

The other new tool to look at is the Active Directory to ADAM Synchronizer, Adamsync. Now that your ADAM schema matches your Active Directory schema, you can start copying actual data from Active Directory into ADAM. There are a number of different ways to copy and synchronize the data, as detailed in Figure 9.

Figure 9 Active Directory Synchronization Options

Adamsync is a command-line utility that performs a one-way synchronization of data from Active Directory into ADAM. Adamsync uses an XML-based con-figuration file that drives the parameters of the ongoing synchronization (see Figure 10). The details of the configuration are stored in the ADAM instance itself. You will need to extend the schema of your ADAM instance in order to do this. A default schema file is provided with a base install.

Figure 10 Adamsync Config File

<?xml version="1.0"?>
<doc>
 <configuration>
  <description>Sample Adamsync Configuration 
    File</description>
  <security-mode>object</security-mode>
  <source-ad-name>AD-DC</source-ad-name>
  <source-ad-partition>dc=contoso,dc=com
    </source-ad-partition>
  <source-ad-account>administrator
    </source-ad-account>
  <account-domain>contoso.com</account-domain>
  <target-dn>ou=People,o=contoso,c=us
    </target-dn>
  <query>
     <base-dn>ou=Coporate,dc=contoso,dc=com
      </base-dn>
   <object-filter>(objectClass=user)
     </object-filter>
   <attributes>
    <include>displayname</include>
    <include>givenName</include>
    <include>sn</include>
    <include>mail</include>
    <include>sAMAccountName</include>
   </attributes>
  </query>
  <schedule>
   <aging>
    <frequency>0</frequency>
    <num-objects>0</num-objects>
   </aging>
   <schtasks-cmd></schtasks-cmd>
  </schedule>
 </configuration>
 <synchronizer-state>
  <dirsync-cookie></dirsync-cookie>
  <status></status>
  <authoritative-adam-instance>
    </authoritative-adam-instance>
  <configuration-file-guid>
    </configuration-file-guid>
  <last-sync-attempt-time>
    </last-sync-attempt-time>
  <last-sync-success-time>
    </last-sync-success-time>
  <last-sync-error-time>
    </last-sync-error-time>
  <last-sync-error-string>
    </last-sync-error-string>
  <consecutive-sync-failures>
    </consecutive-sync-failures>
  <user-credentials>
    </user-credentials>
  <runs-since-last-object-update>
    </runs-since-last-object-update>
  <runs-since-last-full-sync>
    </runs-since-last-full-sync>
 </synchronizer-state>
</doc>

You can create one or more Adamsync configurations and install them into ADAM using the /install parameter. Once installed, Adamsync will keep the specified ADAM instance up to date by working with the Active Directory DirSynch mechanism. You have the ability to filter on particular containers and object types. You can also select attributes to include or exclude as needed. The ability to have multiple configurations at once allows you to have multiple Active Directory domains all synchronized into a single ADAM instance.

Here is how the synchronization process works. First, create an XML configuration file. A sample is provided with the ADAM installation and placed in the C:\Windows\Adam folder. The sample shown in Figure 10 shows some of the key areas that need to be updated. The source and target domains must be identified and the query section allows you to limit the data you want to import from Active Directory.

Next, install the configuration file using the /install parameter:

adamsync /install adamserver.contoso.com:3389 CONFIG-FILE.XML

You can use the /list parameter to view any installed Adamsync configurations. All other parameters can be viewed by running Adamsync with the /? parameter.

The following command performs a full synchronization of the data by using the /fs parameter:

adamsync /fs adamserver.contoso.com:3389 "ou=People,o=contoso,c=us"

Once a full sync is performed, ongoing synchronizations would only need the /sync parameter:

adamsync /sync adamserver.contoso.com:3389 "ou=People,o=contoso,c=us"

The /log command-line parameter can be used to output debugging information for troubleshooting.

adamsync /sync localhost:4389 "ou=People,ou=test2,o=contoso,c=us" /log –

You should now be able to see your ADAM instance populated with data from Active Directory.

Conclusion

After reviewing all of the capabilities that ADAM supplies, you can see that it provides one agile little directory service and is a valuable supplement to the more feature-rich Active Directory. ADAM gives you the ability to expand the power of Active Directory. ADAM lets you adapt schemas to your particular application needs, and it supports a directory for applications to address numerous application architecture solutions. All of this is possible, while retaining the technology requirements and skill sets consistent with Active Directory.

Brian Redmond is a Technology Specialist with Microsoft specializing in identity management and infrastructure technologies. Brian is based in Pittsburgh, PA, and enjoys biking, hiking, baseball, and traveling. He can be reached at brian.redmond@microsoft.com

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.