Active Directory LDAP Compliance

Introduction
Directories?public or private resource lists containing names, locations, and other identifying information?are essential tools often taken for granted in our daily activities. Typically these directories provide information about people, places, or organizations as part of an overall solution. For example, a telephone is virtually useless without a directory to correspond names with telephone numbers. Historically, most directories were only available in printed form.

As the computer revolution forged ahead, printed directories gave way to an electronic counterpart. Many application providers capitalized on the directory concept offering proprietary versions that extended their application?s functionality. Network operating systems also provided directories, typically housing user and device information. Unfortunately, these first generation directories were often developed with little or no concern for interoperability. Isolated and specific in function, they performed admirably. However, it was obvious directories needed to interact within a larger network ecosystem. This idea grew into the definition of the X.500 standard.

Directory Foundation: X.500
In 1988, the International Organization for Standardization (ISO) and the International Telecommunications Union (ITU) introduced the X.500 standard. X.500 defines the protocols and the information model for an application and network platform agnostic directory service. As a distributed directory based on hierarchically named information objects, X.500 specifications characterized a directory that users and applications could browse or search.

The X.500 paradigm includes one or more Directory System Agents (DSAs)?directory servers?with each holding a portion of the Directory Information Base (DIB). The DIB contains named information objects assembled in a tree structure?defined by a Directory Information Tree (DIT)?with each entry having an associated set of attributes. Every attribute has a pre-defined type and one or more associated values. Object classes, containing mandatory and optional attributes, are defined within a directory schema. End users communicate with an X.500 DSA using the Directory Access Protocol (DAP) while the Directory System Protocol (DSP) controls interaction between two or more DSAs.

X.500: The Need for a Lightweight Alternative
Understanding the need for a streamlined directory standard, several implementers proposed a lightweight alternative for connecting to X.500 directories. Ultimately, the first iteration of LDAP gained traction as a simple alternative to the X.500 Directory User Agent (DUA). The new LDAP definition:

 Simplified protocol encoding
 Used text encoding for names and attributes
 Mapped directly onto the TCP/IP stack
 Supplied a simple Application Programming Interface (API)

What Is LDAP?

Organized development of LDAP occurred on several fronts. However, the most notable work, and the first freely available implementation, was completed by the University of Michigan in 1993. The University focused efforts on developing a simpler TCP/IP version of X.500?s DAP. DAP was considered cumbersome as it pushed much of its workload to the client.
Although LDAP is well rooted as a simplified component of the X.500 directory, it has become the de facto directory protocol on the Internet today.

LDAP: First Generation
LDAP?s initial implementations provided gateway services between X.500 directory servers and clients. The clients communicated with an LDAP gateway through LDAP-enabled software. In turn, the gateway handled transactions?on behalf of the client?with the X.500 DSA. This model promoted directory interoperability allowing application providers to easily develop client software capable of communicating with an LDAP gateway service, regardless of the backend platform. While LDAP was initially created to meet this requirement, it became clear that a parting from X.500 was needed to simplify deployments. In 1994, LDAP was transformed into a directory specification with its own database and structuring conventions.

Once transformed, the LDAP specifications reflected a true client-server model with clients making requests directly to servers for information or operations. One or more directory servers may either perform the operation or refer the client to another directory server that may be able to provide the requested information, or perform the requested operation. The LDAP client will see the same view of the directory no matter which server is contacted. If necessary, the LDAP server can authenticate the client to the operating system in use. Once received, the LDAP server will convert a request into an appropriate format for the accessed directory. For X.500 directories, the LDAP server would convert the LDAP request into a DAP request.

Enhancements with Version 2
As interest in LDAP increased, several new developments extended its core functionality while streamlining its footprint. In 1995, Request for Comment (RFC) 1777 was introduced for LDAP Version 2. RFC 1777 eliminated many of the impracticable components of X.500 that were central to the original LDAP specifications. Furthermore, network connectivity was changed from the X.500 Open Standards Intercommunication (OSI) model to the TCP/IP model.

LDAPv2 is officially defined by the following RFCs:
 RFC 1777 ? Lightweight Directory Access Protocol (v2)
 RFC 1778 ? The String Representation of Standard Attribute Syntaxes
 RFC 1779 ? A String Representation of Distinguished Names

The Current State of LDAP
Developed by the Internet Engineering Task Force (IETF) in 1997, the current LDAPv3 implementation is a renovation of LDAPv2, which primarily tackles deployment limitations identified within the previous version. LDAPv3 also enriches compatibility with X.500 along with enhanced integration with non-X.500 directories. LDAPv3 encompasses LDAPv2 within a new set of RFCs.

LDAPv3 is a Proposed Standard currently defined by RFC 3377, which includes, the RFCs below in addition to support for the LDAPv2 RFCs listed above :

 RFC 2251 ? Lightweight Directory Access Protocol (v3)
 RFC 2252 ? LDAP (v3): Attribute Syntax Definitions
 RFC 2253 ? LDAP (v3): UTF-8 String Representation of Distinguished Names
 RFC 2254 ? String Representation of LDAP Search Filters
 RFC 2255 ? The LDAP URL Format
 RFC 2256 ? A Summary of X.500(96) User Schema for use with LDAP (v3)
 RFC 2829 ? Authentication Methods for LDAP
 RFC 2830 ? LDAP (v3): Extensions for Transport Layer Security


What Does It Mean to Be LDAP Compliant?
Claiming LDAP compliance seems to be a common occurrence among today?s directory-capable vendors. In truth, applications may be either directory-aware?capable of reading an LDAP directory?or directory-enabled?capable of reading and performing other defined LDAP operations on a directory. Both implementations should be considered LDAP-compliant if proposed standards are followed in achieving an application?s desired level of LDAP functionality. Compliance with standards, however, does not ensure interoperability. Standards may lack sufficient clarity, even after formalization, leading to varying guideline interpretations.

The compliance task for directory server vendors weighs on their ability to conform to defined standards while ensuring interoperability with those standards. In addition, the process of standard formalization is an ongoing effort compounding the difficulty of achieving full compliance. For example, LDAPv2 has been formalized with a defined set of RFCs, however, LDAPv3, a Proposed Standard, is theoretically still a work in progress as it moves toward an Internet Standard. In summary, a vendor?s compliance statement should be viewed as their ability to implement a known set of RFCs, accurately interpret those RFCs to ensure interoperability, and provide a framework capable of incorporating new RFCs.

Achieving Compliance: IETF Applicability Statement
The IETF has established an LDAPv3 Working Group?ldapbis?with the charter of steering the previously mentioned LDAPv3 RFCs through the Internet Standards process. In September 2002, the working group submitted a revised LDAP specification for consideration as a draft standard. Currently, no IETF LDAPv3 conformance or compliance directive exists; however, one of the most pervasive documents to be delivered by the working group is an LDAP applicability statement.
Once complete, an LDAP applicability statement will guide independent vendors toward IETF-based LDAP compliance. In all probability, third-party test suites, based on the applicability statement, will be developed, allowing vendors and end users to accurately determine LDAP compliance. Until then, vendor declarations combined with existing third-party testing suites are the most suitable alternatives.

Achieving Compliance: Third-Party Test Suites
Several LDAP compliance testing and certification solutions exist in the marketplace today. One of the most prominent test suites is offered by the Open Group, a technology-neutral consortium. The Open Group also sponsors the Directory Interoperability Forum (DIF), which compromises architects, strategists, and product managers from customers and vendors of directories and directory-enabled applications. According to the Open Group, the DIF is chartered to ?provide testing and certification for directory servers and applications that use Open Directory Standards.? Microsoft Corporation is an active member of the DIF.

The Open Group LDAP Certifications
Recently released in 2003 are two directory Open Group/DIF test certifications: LDAP Ready and LDAP Certified. With an LDAP Certified directory, the vendor guarantees its LDAP directory server conforms to the LDAPv3 specifications published by the IETF. On the other hand, an LDAP Ready application warrants that it will interoperate with an LDAP Certified directory.

To become LDAP Certified, directory vendors typically submit a warranty of LDAPv3 conformance using the Open Group?s VSLDAP Test Suite as a compliance measuring tool. The warranty is intended to ensure conformity to industry standard specifications, conformity through a product?s lifecycle, and the quick remedy of any nonconformity. At the moment, no vendor has received either of these new certifications.
Setting an LDAP Compliance Baseline
According to the DIF , a baseline of LDAP compliance can be measured by verifying support of the following RFC components. By no means exhaustive, an LDAP compliance baseline can be supplemented by support of additional LDAP RFCs, features, or extensions.

Code:
RFC	Feature	Description
2251	Abandon	The server accepts abandon requests and performs the requested abandon operations.
2251	Add	The server accepts add requests and performs the requested add operations.
2251	Anonymous Bind over SSL	The server accepts a simple bind over SSL where the password is null and treats the client as anonymously authenticated.
2251	Authenticated Simple Bind	The server accepts a simple bind request with a password and authenticates the client by that password.
2251	BER	The server correctly encodes and decodes protocol elements using ASN.1 BER as required by LDAP.
2251	Client Server Communication	The client transmits an operation request to the server, which performs the operation on the directory and returns results/errors.
2251	Compare	The server accepts compare requests and performs the requested compare operations.
2251	Data Model	Each entry must have an objectClass attribute. The attribute specifies the object classes of an entry, which along with system and user schema determine permitted attributes of entries.
2251	Delete	The server accepts delete requests and performs the requested delete operations.
2251	Modify (Add, Delete, Replace)	The server accepts modify requests and performs the operations, including additions, deletions, and replacements.
2251	ModifyDN ? Move Leaf Entry to New Parent	The server accepts modify DN requests to move leaf entries to new parents and performs the leaf move operations.
2251	ModifyDN ? Move Renamed Leaf Entry to New Parent	The server accepts modify DN requests to rename leaf entries and move them to new parents and performs the requested leaf rename and move operations.
2251	ModifyDN - Rename a Leaf Entry	The server accepts modify DN requests to rename leaf entries and performs the requested leaf rename operations.
2251	Search	The server accepts search requests and performs the requested search operations.
2251	Simple Bind with Password over SSL	The server accepts a simple bind request over SSL with a password and authenticates the client by that password.
2251	Simple Common Elements	The server correctly encodes, decodes, and processes the simple common elements of LDAPMessage envelope PDUs.
2251	TCP as the Transporting Protocol	A server implements mapping of LDAP over TCP and provides a protocol listener IP port 389.
2251
2252	Definition of Attributes	The server?s entries have attributes in accordance with the X.500 model. The server supports entries with attributes. 
2251
2252	Definition of Object Classes	The server associates entries with object classes in accordance with the X.500 model.
2251
2253	Distinguished Name	The server correctly encodes and decodes protocol representations of distinguished names.
RFC	Feature	Description
2251	Abandon	The server accepts abandon requests and performs the requested abandon operations.
2251	Add	The server accepts add requests and performs the requested add operations.
2251	Anonymous Bind over SSL	The server accepts a simple bind over SSL where the password is null and treats the client as anonymously authenticated.
2251	Authenticated Simple Bind	The server accepts a simple bind request with a password and authenticates the client by that password.
2251	BER	The server correctly encodes and decodes protocol elements using ASN.1 BER as required by LDAP.
2251	Client Server Communication	The client transmits an operation request to the server, which performs the operation on the directory and returns results/errors.
2251	Compare	The server accepts compare requests and performs the requested compare operations.
2251	Data Model	Each entry must have an objectClass attribute. The attribute specifies the object classes of an entry, which along with system and user schema determine permitted attributes of entries.
2251	Delete	The server accepts delete requests and performs the requested delete operations.
2251	Modify (Add, Delete, Replace)	The server accepts modify requests and performs the operations, including additions, deletions, and replacements.
2251	ModifyDN ? Move Leaf Entry to New Parent	The server accepts modify DN requests to move leaf entries to new parents and performs the leaf move operations.
2251	ModifyDN ? Move Renamed Leaf Entry to New Parent	The server accepts modify DN requests to rename leaf entries and move them to new parents and performs the requested leaf rename and move operations.
2251	ModifyDN - Rename a Leaf Entry	The server accepts modify DN requests to rename leaf entries and performs the requested leaf rename operations.
2251	Search	The server accepts search requests and performs the requested search operations.
2251	Simple Bind with Password over SSL	The server accepts a simple bind request over SSL with a password and authenticates the client by that password.
2251	Simple Common Elements	The server correctly encodes, decodes, and processes the simple common elements of LDAPMessage envelope PDUs.
2251	TCP as the Transporting Protocol	A server implements mapping of LDAP over TCP and provides a protocol listener IP port 389.
2251
2252	Definition of Attributes	The server?s entries have attributes in accordance with the X.500 model. The server supports entries with attributes. 
2251
2252	Definition of Object Classes	The server associates entries with object classes in accordance with the X.500 model.
2251
2253	Distinguished Name	The server correctly encodes and decodes protocol representations of distinguished names.
Active Directory?s LDAP Compliance

Windows 2000 Server
With the release of Windows 2000 Server, Microsoft made its first introduction of Active Directory?directory service. With a foundation stemming from proven Microsoft technologies, Active Directory?s origins lie within the original 1996 release of Microsoft Exchange Server 4.0. Active Directory, however, was a significant paradigm shift from the familiar Windows NT 4.0 identity store. By envisioning a directory capable of extending beyond a typical NOS store, Microsoft?s first implementation of Active Directory became a viable repository for many forms of enterprise data.
To allow Active Directory to gain popularity as an enterprise repository, Microsoft had to make an early commitment to LDAP. The Windows 2000 implementation of Active Directory is an LDAP-compliant directory supporting the core LDAP RFCs available at the time of its release. Currently, Windows 2000 Active Directory reaches LDAP compliance through support of the following RFCs.

Code:
RFC	Core LDAP RFCs	RFC Status
2251 *Lightweight Directory Access Protocol (v3)	Proposed
2252 *Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions *Proposed
2253	Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names *Proposed
2254	The String Representation of LDAP Search Filters *Proposed
2255	The LDAP URL Format	Proposed
2256	A Summary of the X.500(96) User Schema for use with LDAPv3 *Proposed
2829	Authentication Methods for LDAP *Proposed
2830	Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security *Proposed
RFC	Additional LDAP RFC Support	RFC Status
2696	LDAP Control Extension for Simple Paged Results Manipulation *Proposed
2247	Using Domains in LDAP/X.500 Distinguished Names *Proposed
Windows Server 2003
Building on the foundation established in Windows 2000 Server, the Active Directory service in Windows Server 2003 extends beyond the baseline of LDAP compliance into one of the most comprehensive directory servers offering a wide range of LDAP support. Accordingly, the Windows Server 2003 Active Directory service introduces a number of new LDAP capabilities targeted for IT professionals and application developers. Some of the latest LDAP features include:
 Dynamic Entries - Active Directory can store dynamic entries allowing the directory to assign Time-To-Live (TTL) values to determine automatic entry deletion.
 Transport Layer Security (TLS) - Connections to Active Directory over LDAP can now be protected using the TLS security protocol.
 Digest Authentication Mechanism - Connections to Active Directory over LDAP can now be authenticated using the DIGEST-MD5 Simple Authentication and Security Layer (SASL) authentication mechanism. The Windows Digest Security Support Provider (SSP) provides an interface for using Digest Authentication as an SASL mechanism.
 Virtual List Views (VLV) - When an LDAP query has a large result set, it is inefficient for a client application to pull down the entire set from the server. VLV allows a client application to ?window? through a large result set without having to transfer the entire set from the server.
 Concurrent LDAP Binds - Although not specifically defined by the IETF, Concurrent LDAP Bind provides the ability to perform multiple LDAP binds on one connection for the purpose of authenticating users.

Although the LDAP compliance guidelines proposed by the Directory Interoperability Forum signify conformance at a base level, organizations demand directory servers capable of providing robust network and application services. This is one of the driving forces behind Microsoft?s support of virtually all IETF- recognized LDAP components. Although LDAP compliance should always be considered a work in progress until full IETF standardization, Microsoft?s current LDAP compliance in Windows Server 2003 includes support of the following RFCs.

Code:
RFC	Core LDAP Requirements ? RFC 3377	RFC Status	Timeline
2251	Lightweight Directory Access Protocol (v3)	Proposed	Windows 2000
2252	Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions *Proposed	Windows 2000
2253	Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names *Proposed	Windows 2000
2254	The String Representation of LDAP Search Filters *Proposed	Windows 2000
2255	The LDAP URL Format	Proposed	Windows 2000
2256	A Summary of the X.500(96) User Schema for use with LDAPv3 *Proposed	Windows 2000
2829	Authentication Methods for LDAP *Proposed	Windows 2000
2830	Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security *Proposed	Windows 2000
RFC	Additional LDAP RFC Support	RFC Status	Timeline
2696	LDAP Control Extension for Simple Paged Results Manipulation *Proposed	Windows 2000
2247	Using Domains in LDAP/X.500 Distinguished Names *Proposed	Windows 2000
2589	LDAP Protocol (v3): Extensions for Dynamic Directory Services *Proposed	Windows Server 2003
2798	Definition of the inetOrgPerson LDAP Object Class	Proposed	Windows Server 2003
2831	Using Digest Authentication as an SASL Mechanism *Proposed	Windows Server 2003
2891	LDAP Control Extension for Server Side Sorting of Search Results *Proposed	Windows Server 2003
Compliance Misconceptions
Since the release of Windows 2000 Server Active Directory, many assertions have been made about its LDAPv3 compliance. As noted previously, Active Directory and Microsoft Exchange Server have supported a baseline of LDAP compliance since inception. Furthermore, Active Directory extends this baseline by supporting a majority of the LDAP Informational and Proposed RFCs. Although Microsoft?s commitment to building one of the most comprehensive and interoperable directories in the marketplace is obvious, there are still common compliance misconceptions worth discussing.
inetOrgPerson
One of the most widely publicized Windows 2000 Server LDAP non-compliance claims pivots on the support of RFC 2798 and inetOrgPerson. RFC 2798 was submitted as an Informational RFC in April 2000 defining the inetOrgPerson LDAP object class. The object class definition is considered an extension to LDAPv3 and, as such, is not included in the RFC 3377 LDAPv3 specifications.
Nevertheless, the timing of the Windows 2000 Server release in February 2000 and the introduction of RFC 2798 in April of that same year barred the inclusion of the inetOrgPerson Object Class within the Windows 2000 Server Active Directory schema. However, any Windows 2000 Active Directory implementation can easily accommodate inetOrgPerson through Active Directory?s extensible schema.
In response to customer requests for an inetOrgPerson object class for Windows 2000, Microsoft released the Windows 2000 inetOrgPerson Kit. The kit, which is freely available, derives inetOrgPerson from the user class within Active Directory?s schema. In addition to defining the inetOrgPerson, the kit delivers basic administrative control over the class object. See the ?Additional Resources? section for information on obtaining the Microsoft Windows 2000 inetOrgPerson Kit.
As noted previously, Windows Server 2003?s Active Directory schema includes the full definition and provides complete manageability of RFC 2798 and the inetOrgPerson LDAP Object Class.
Native LDAP Calls
Another common misconception is that Active Directory does not support native LDAP calls, thereby forcing developers to use Active Directory Services Interface (ADSI) for access to the directory. In fact, Active Directory fully supports native LDAP calls through support of the LDAP API (RFC 1823) ? it is actually the primary access method for the majority of Window?s directory operations. Microsoft merely provides ADSI as an abstraction layer to simplify directory development and promote directory interoperability.
It is important to note that Active Directory does have some functionality that is not exposed by the LDAP protocol since the functionality extends beyond the LDAP model. For instance, LDAP applications bind to specific directory servers via the server's DNS name whereas Active Directory applications have the option of employing a distributed locator service to find a nearby replica of a given directory partition. This option does not force ISVs to rewrite their applications since they can bind to a specific LDAP server as usual. However, if an ISV wants to use the Active Directory distributed locator service to reduce the customer cost of managing an application, they can call the DsGetDcName API and then use LDAP. Conversely, the ISV may use ADSI, which abstracts away both DsGetDcName and LDAP. The choice is entirely up to the ISV.
Active Directory fully supports writing to the Server Principal Name via the Windows Server 2003 and Windows 2000 Server LDAP APIs.

Directory Interoperability
It is not uncommon to find a variety of directories?from resource to application-specific?deployed within the enterprise today. However, multiple directories can create complex challenges for the users, administrators, and developers of any organization. From multiple user logon requirements and management complexities to developers needing to support multiple versions of their applications, directory complexities may continue without a common management and development framework. Microsoft has introduced several interoperability tools to help customers reduce the complexities of using and managing heterogeneous directory servers.
LDAP API
An LDAP API is available through the Microsoft Developer Network (MSDN) Platform SDK. It provides native LDAP functionality for client applications to search for and retrieve information from an LDAP-compliant directory server. Additional functions, such as modifying directory entries or access control to allow clients to authenticate themselves, are also available from within the LDAP API. Actually, the API supports all LDAP compliance specific functions identified in the previous sections to assist in development efforts.
Active Directory Services Interface
ADSI is a set of Component Object Model (COM) programming interfaces that make it easy for customers and independent software vendors (ISVs) to build applications that register with, access, and manage multiple directory services with a single set of well-defined interfaces. ADSI is an open API.
One of the most familiar open programming APIs is Open Data Base Connectivity (ODBC). ODBC provides open interfaces for relational databases, thus allowing developers to write applications and tools that work with any database that supports ODBC. Because of the thriving ODBC development community, every major relational database now supports ODBC. ADSI is equivalent to ODBC for directory services.
ADSI provides developers with access to multiple directory service providers through a set of interfaces. Applications written to ADSI work with any directory service that offers an ADSI provider, thus addressing some of the complexities outlined previously. By abstracting the capabilities of directory services from different network providers, ADSI presents a single set of directory service interfaces for managing network resources.
For example, ADSI defines a naming convention that can uniquely identify an ADSI object in an LDAP-compliant or similar directory. These names are called AdsPath strings. In the following code example, AdsPath contains the LDAP provider?s moniker and the provider?s specific path to identify an organizational unit in the Sample Domain:
LDAP://OU=Sales, DC=Sample, DC=COM
As an interoperability tool, ADSI is:
 Open - Any directory vendor can implement an ADSI provider; Microsoft has included an LDAP ADSI provider.
 Directory Service Independent - Administrative applications are not bound to a vendor's directory service as applications can be developed without understanding of vendor-specific directory APIs.
 Multiple Development Language Capable - COM applications can be written in languages such as Microsoft? Visual Basic?, Microsoft Visual Basic Scripting Edition (VBScript), and C/C++.
 Simple Programming Model - ADSI consists of a small, easy-to-learn set of interfaces.
 Scriptable - Any automation-compatible language can be used to develop directory service applications. Administrators and developers can use the tools they already know.
 Functionally Rich - ISVs and sophisticated end users can develop serious applications using the same ADSI models used for simple scripted administrative applications.
 Extensible - Directory providers, ISVs, and end users can extend ADSI with new objects and functions to add value or meet unique needs.
 OLE DB Aware - ADSI provides an OLE DB interface so that programmers familiar with database programming through OLE DB can use it effectively.
Development Environments
ADSI client applications can be written in many languages. For most administrative tasks, ADSI defines interfaces and objects accessible from automation-compliant languages like Microsoft? Visual Basic?, Microsoft Visual Basic Scripting Edition (VBScript), Active Server Pages (ASP), and Java to the more performance and efficiency-conscious languages such as C and C++. A good foundation in COM programming is useful to the ADSI programmer.
Active Directory Application Mode
Active Directory Application Mode (ADAM) is a new capability of Microsoft Active Directory that addresses certain deployment scenarios related to directory-enabled applications. ADAM runs as a non-operating system service and, as such, does not require deployment on a domain controller. Running as a non-operating system service means that multiple instances of ADAM can run concurrently on a single server, with each instance being independently configurable.
While the vision of a single enterprise directory is still unfulfilled, ADAM represents a significant breakthrough in directory services technology that separates typical Network Operating System (NOS) functionality from a native LDAP directory.
Directory Services Markup Language
The Directory Services Markup Language (DSML) provides a means of representing directory structural information and directory operations as an XML document. The intent of DSML is to allow XML-based enterprise applications to leverage profile and resource information from a directory in their native environment. DSML allows XML and directories to work together and provides a common ground for all XML-based applications to make better use of directories.
DSML Services for Windows extends the power of the Active Directory service. Because DSML Services for Windows uses open standards such as HTTP, XML, and SOAP, a greater level of interoperability is possible. For example, in addition to the already standard Lightweight Directory Access Protocol (LDAP), many devices and other platforms have other alternatives to communicate with Active Directory. This provides a number of key benefits for IT administrators and independent software vendors (ISVs), who can now have even more open-standard choices to access Active Directory.
DSML Services for Windows supports DSML version 2 (DSMLv2). DSMLv2 is a standard approved by the Organization for the Advancement of Structural Information Standards (OASIS) and backed by many directory services vendors. Supporting the DSMLv2 specification allows better interoperability with other directory services vendors who are also supporting this standard. For information about the DSMLv2 specification and schema, see the OASIS Web site.
Microsoft Identity Integration Server 2003, Enterprise Edition
For organizations that must support heterogeneous directories, Microsoft Identity Integration Server (MIIS) 2003, Enterprise Edition, enables the integration and management of identity information across multiple repositories, systems, and platforms. Although the administration of these multiple repositories often leads to time-consuming and redundant efforts, it also causes frustration for users who may need to remember multiple IDs and passwords for varying applications or systems. The larger the organization, the greater the potential for multiple repositories and the effort required to keep them current.
MIIS augments Active Directory by providing broad interoperability capabilities, including integration with a wide range of identity repositories; provisioning and synchronizing identity information across multiple stores; and brokering changes to identity information by automatically detecting updates and sharing the changes across systems.