Active Directory Interoperability (and the Resources that will Help You Understand It)
Summary: This article introduces Active Directory in a nutshell and points to resources that more completely explain interoperability with Active Directory.
Published: March 2012
If you are reading this article, you are likely someone who has been tasked with implementing some portion of a software system that can interoperate with Microsoft Active Directory. Or you might have an academic assignment that places similar requirements on you. These assertions are made only as a way to ensure that you have found the information you want. If you are in neither of these groups, but just have an overwhelming interest in Active Directory interoperability, welcome.
This article is not intended to be a full-on explanation of Active Directory or of interoperation with it, though these subjects will be introduced. Rather, it is intended to point you to the resources that do give more complete information about these subjects.
Active Directory in a Nutshell
First, let’s take a very high-level look at Active Directory. If you are well-versed in things Active Directory, feel free to skip ahead a bit, possibly to examine the “Flavors of Active Directory” or even all the way to the various references in the latter half of this article.
Active Directory is a security and identity system, also known as a directory service. It stores information in a specialized data store that represents a directory of information; this information is typically about people or other network entities, similar to a telephone directory, but can be relevant for other things as well (for example, computer systems and applications); Active Directory provides client access to the information in the data store. The data store is centralized and the information is stored hierarchically in the form of directory objects, or just objects, with attributes.
An example might be useful at this point.
Say that the Active Directory data store has a directory object named Users. The Users object is a container object, the contents of which (referred to as child directory objects) are also containers named for various logical divisions of users; for example, Accounting Department, Human Resources Department, Engineering Department, and so on. The contents of each of these containers, in turn, are User objects, each of which represents one individual user and holds attributes that store information about that user, such as his or her user name, password, or telephone number. This example is depicted in the following figure.
The primary means of accessing data in Active Directory is the Lightweight Directory Access Protocol, or LDAP for short. LDAP is documented in various RFCs, which are identified by RFC 3377. These RFCs define the messages and processing for the creation, manipulation, and retrieval of directory data.
The Flavors of Active Directory
Active Directory is deployed in one of two configurations: Active Directory Domain Services, AD DS, and Active Directory Lightweight Directory Services, AD LDS.
AD DS is an enterprise-centric configuration of Active Directory where there are typically multiple domain controllers, all of which contain the same data and have the same state through a process known as replication. Note that a domain controller, or DC, can be thought of as a service that is running on a server and hosts the Active Directory data store; it is typical, however, for a domain controller server to be reserved for the sole purpose of hosting Active Directory. A DC handles requests from clients of the directory, typically for authentication purposes, and also interacts with other DCs, as appropriate.
In a directory environment that is implemented by AD LDS, on the other hand, the DCs (or, perhaps directory servers, which is a more intuitive term for AD LDS) are typically independent of one another and do not share state unless configured to do so. The operation of an AD LDS directory is essentially the same as that of an AD DS directory, but AD LDS is more of an application-centric store and therefore subject to some limitations; for example, some of the capabilities like core Windows authentication are not available, and the types of objects that are available in the data store by default are more limited and more specific to applications.
As a point of comparison, AD DS would typically be used to maintain and provide access to the distributed resources (users, computers, printers, etc.) of an organization. AD LDS would typically be used to provide a private data store for applications and to enable interaction among applications on a network.
References for a Better Understanding of AD and Interoperability with It
The rest of the information in this article is intended to point you to the resources you will need to better understand what Active directory is and how to create software implementations that can interoperate with it.
High-level articles on AD DS and AD LDS can be found on MSDN under the following titles and locations:
If you are unfamiliar with LDAP, you will want to peruse the LDAP RFCs. A roadmap of the LDAP RFCs is available through RFC 3377.
An overview of the protocols that are relevant to the Active Directory system is available in a document called "[MS-ADOD]: Active Directory Protocols Overview". This document is available on MSDN under the Windows Overview node. It describes some of the typical behaviors that Active Directory exhibits, and the protocols that support those behaviors.
The Main Specification
The main specification for Active Directory interoperability is called "[MS-ADTS]: Active Directory Technical Specification", or "[MS-ADTS]" for short, and is available through MSDN under the Windows Protocol documents. The following sections are of special note.
The Active Directory Schema
The Active Directory schema is fully described in a set of documents that should be considered to be appendixes to [MS-ADTS], meaning that the schema documents don't stand on their own, but are to be used in conjunction with [MS-ADTS], especially section 220.127.116.11 and sub-sections. The Active Directory schema documents are identified in the following lists.
For AD DS:
Note that the name of each of these documents indicates whether the document pertains to the definitions of Active Directory attributes or classes and, for attributes, the range of the definitions.
For AD LDS
The Active Directory schema can also be downloaded in plain text format (using LDIF syntax) from the Microsoft Download Center.
In AD DS, multiple DCs can be configured to handle domain tasks, all of which need to have the same domain data and state. Reconciliation of data and state across a domain (or even further) is accomplished in Active Directory by a mechanism called directory replication, or simply replication. Replication for Active Directory is fully described and defined in [MS-DRSR]: Directory Replication Service (DRS) Remote Protocol Specification. This document also contains information about the administrative tasks associated with a domain such as converting names between formats and retrieving information about AD DS domain controllers.
Account and Security Information
Account and security information can be created, maintained, and retrieved using the Security Account Manager protocols, and the Local Security Authority protocols, respectively. These protocols are defined in the following documents.
For implementations that are not expected to include the Security Account Manager, account creation tasks can also be handled using LDAP. Additionally, security activities like authentication can be handled by Kerberos, which is defined in RFC 4120 and extended as described in the document [MS-KILE]: Kerberos Protocol Extensions.
Finally, access to the directory is now available through SOAP-based Web Services protocols. The basis for this access is the WS-Transfer protocol described at http://www.w3.org/Submission/2006/SUBM-WS-Transfer-20060927/ and the WS-Enumeration protocol described at http://www.w3.org/Submission/2006/SUBM-WS-Enumeration-20060315/. This type of access to Active Directory includes additional protocols and extensions as identified in the following list.
Sections In This Article