Active Directory Service Interfaces -The Easy Way to Access and Manage LDAP-Based Directories (Windows NT 4.0)

  • Article
Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Updated : February 1, 1997

Active Directory Service Interfaces: The Easy Way to Access and Manage LDAP-Based Directories

This paper provides detailed information on how the Active Directory Service Interfaces (ADSI) provide the easy way to implement the Lightweight Directory Access Protocol (LDAP), as defined by the Internet Engineering Task Force (IETF). This document also describes how ADSI helps access and manage products from other vendors that support LDAP and other directory APIs.

The ADSI Software Developer's Kit for Windows NT 4.0 is available to all customers by downloading from the Microsoft Internet Web site at https://www.microsoft.com/win32dev/netwrk/adsi.htm

On This Page

Executive Summary
Introduction
Microsoft Directory Services Strategy
History of LDAP
Lightweight Directory Access Protocol (LDAP) Overview
Microsoft's commitment to LDAP-based Directories
Microsoft's LDAP-based Directory
APIs to access LDAP Directory Services
Conclusion

Executive Summary

Enterprise Computing environments need to store directory information in a centralized data store so that data can be added, deleted, modified, or queried by users and applications. The types of directory information that are stored vary greatly—the common ones are user accounts, e-mail addresses, digital certificates, component object names, network names, and so on. This type of information is central to many applications and their usage. The amount of information stored varies greatly with the size the enterprise and its needs. It is important to access the information both from within the enterprise and from the Internet. This centralized data store, plus the services that manage it, has come to be known as a Directory Service.

The Directory Service must be accessible via an open, standards-based protocol. Using an open protocol enables the information in the Directory Services to be accessible to clients from different vendors. Thus, Directory Services from different vendors can communicate using an open protocol and can exchange information to create aggregated directories.

Active Directory is the Directory Service that is integrated with the next release of the Microsoft® Windows NT® Server operating system. It offers the hierarchical view, extensibility, scalability, and distributed security required by all customers. The Active Directory will natively support LDAP, the Internet Engineering Task Force's (IETF) Specification rfc1777 for directory interoperability, which means that it is completely integrated with the Internet. With this level of LDAP commitment, customers can deploy Active Directory in a corporate computing environment and interoperate with LDAP clients from multiple vendors.

While the Active Directory will natively support LDAP, there is an even better way to access the directory than using the low-level LDAP C APIs. To make it easier to write directory-enabled applications that access the Active Directory and other LDAP-enabled directories, Microsoft developed Active Directory Service Interfaces (ADSI).

ADSI is an extensible, easy-to-use programming interface that can be used to write applications to access and manage the following:

  • Active Directory

  • any LDAP-based directory

  • ther Directory Services in a customer's network, including NDS

This initiative—supported by the major Directory Service vendors in the industry—is designed to enable developers and vendors to plug in service providers specific to each directory. Via this service provider architecture, developers can build applications to a single programming interface that will be able to access and manage multiple directories. With ADSI as the means to access and manage multiple directory services, customers and developers will find it easier and less costly to deploy directory-enabled applications.

As part of its commitment to LDAP, Microsoft has built an LDAP provider for the ADSI Software Development Kit. Also, by making ADSI the easy way to do LDAP, Microsoft provides the infrastructure within its operating systems to provide user-empowering interoperability within a heterogeneous computing environment.

Introduction

Microsoft is committed to implementing open standards that benefit its customers. By incorporating technologies based on open standards, Microsoft has created the building blocks that will allow Windows NT Server to better integrate into a heterogeneous environment. This paper discusses two major issues: 1) why ADSI is necessary and 2) the way in which Microsoft has implemented the critical components of the LDAP specification rfc1777in the Active Directory and ADSI. Further, this paper will discuss what Microsoft is doing today to extend the capabilities of LDAP beyond the version 2 Specification, including the contributions Microsoft is making to the version 3 specification.

Challenges of Multiple Directory Services

One of the challenges of working within a large, distributed computing environment is identifying and locating resources such as users, groups and documents. A directory service is part of a distributed computing environment that provides a way to locate and identify the users and resources available in the system. A directory service is like a phone directory. Given a name for a person or a resource, it provides the information necessary to access that person or resource. You do not have to use specific binding information to access a resource on the network.

Most enterprises already have many different directories in place. For example, network operating systems, electronic mail systems, and "groupware" products all have their own directories. As such, they each have their own API set for accessing and managing the directory. Many issues arise when a single enterprise deploys multiple directories. These issues include usability, data consistency, development cost, and support cost, among others. More importantly, how do these customers manage all of these different services in an easy, consistent, and cost-effective manner?

To make it easier to write directory-enabled applications that help customers access and manage multiple directories, Microsoft developed Active Directory Service Interfaces (ADSI). Active Directory Service Interfaces addresses these issues by providing a single, consistent, open set of interfaces for managing and using multiple directories.

What Are Active Directory Service Interfaces?

Active Directory Service Interfaces abstracts the capabilities of directory services from different network providers to present a single set of directory service interfaces for managing network resources. The standard Active Directory Service Interfaces objects are those found within multiple namespaces**.** The typical namespaces for Active Directory Service Interfaces are directory services for various network operating systems. Administrators and developers can use Active Directory Service Interfaces services to enumerate and manage the resources in a directory service, no matter which network environment contains the resource.

Active Directory Service Interfaces makes it easier to perform common administrative tasks, such as adding new users, managing printers, and locating resources throughout the distributed computing environment.

Active Directory Service Interfaces makes it easy for developers to "directory- enable" their applications. Administrators and developers deal with a single set of directory service interfaces, regardless of the installed directory service(s).

Active Directory Service Interfaces are one component of the Windows® Open Services Architecture (WOSA).

Who Will Use Active Directory Service Interfaces?

Network Administrators will use Active Directory Service Interfaces to automate common administrative tasks, such as adding users and groups, managing printers, and setting permissions on network resources.

Independent Software Vendors (ISVs) and end user developers will use Active Directory Service Interfaces to "directory enable" their products and applications. Services can publish themselves in a directory, clients can use the directory to find the services, and both can use the directory to find and manipulate other objects of interest. Because Active Directory Service Interfaces are independent of the underlying directory service(s), the directory-enabled products and applications will operate successfully in multiple network and directory environments. And even though Active Directory will natively support LDAP, ADSI is a even better way to access the directory than using the low-level LDAP C APIs.

Benefits of Active Directory Service Interfaces

Feature

Benefit

Open

Any directory provider can implement an Active Directory Service Interfaces provider; users gain freedom of choice in directory services without sacrificing manageability.

DS Independent

Administrative applications are not tightly bound to a given vendor's directory service. The same application can work on multiple directories. Development time and support costs are reduced.

Java Support

Active Directory Service Interfaces objects provide easy access to directory services for Java applets and programs through Java COM.

Simple Programming Model

Administrative and other directory-enabled applications can be developed with no need to understand vendor-specific directory APIs.

OLE Automation Server

Any OLE Automation Controller (for example, Visual Basic, Perl, Rexx, C/C++ and others) can be used to develop directory service applications. Administrators and developers can use the tools they already know. Productivity is enhanced—development time and support costs are reduced.

Functionally Rich

ISVs and sophisticated end users can develop serious applications using the same Active Directory Service Interfaces models that are used for simple scripted administrative applications.

Extensible

Directory providers, ISVs, and end users can extend Active Directory Service Interfaces with new objects and functions to add value or meet unique needs.

Microsoft Directory Services Strategy

The computing strategies of corporations focus on providing immediate delivery of valuable information to users from any location and stored in any format. This concept, named "Information at Your Fingertips" by Bill Gates, is the primary business mission of Microsoft. This mission drives the development of Microsoft's technologies and tools.

Microsoft views Directory Services as a critical component in a system that finds and delivers that information to your fingertips. Directory Services are a store for information about the organization; e.g., phone/mail address book, the computing environment of the organization (user accounts, printers, objects, and so on), and other miscellaneous information that needs to be found in a location-independent manner. These Directory Services must also provide a single interface for all of the applications deployed in your environment. The Windows NT Server Directory Services already offer extensive integration of applications into the Directory Service, including all of the BackOffice family of applications as well as more than 130 applications from other vendors. The Active Directory Service Interfaces build on this infrastructure, making it easier to integrate applications into the directory.

Most enterprise computing environments use widely differing information technology systems from several different vendors. This variation—often caused by different needs within a corporation—causes complexity when integrating a computing infrastructure. Microsoft's mission is to enable customers to effectively integrate Microsoft products and technologies with a variety of computing environments: this includes Directory Services.

Microsoft has built the Active Directory to support a number of different industry standards so that it can integrate with products that support any of these popular standards. Microsoft's plans include support for X.500 Directory standards, such as:

  • Subsets of the 1993 Directory Access Protocol (DAP)

  • 1993 Directory System Protocol (DSP)

  • Directory Information Shadowing Protocol (DISP)

How Does LDAP Fit Into Active Directory?

Microsoft is also building Active Directory on the LDAP protocol, making Active Directory the easiest way to implement LDAP in a network environment. Microsoft will fully support the LDAP protocol and, via ADSI, will allow any LDAP Directory Service to interoperate with Active Directory. In addition, while ADSI is the easiest way to access the directory via LDAP, the Active Directory also fully supports the LDAP C APIs for directory access.

Microsoft will continue to develop and support standards that are required to integrate Directory Services with products and technologies that are prevalent in organizations. Microsoft will also continue to work with standards bodies to incorporate features into their Directory Services products so that they can integrate seamlessly with products from other vendors that support those features. To this end, Microsoft is working with the IETF on the draft of LDAP v3 and other draft RFCs.

History of LDAP

X.500, the OSI directory standard, defines a comprehensive Directory Service, including an information model, namespace, functional model, and authentication framework. X.500 also defines the Directory Access Protocol (DAP) used by clients to access the directory. DAP is a full OSI protocol that contains extensive functionality, much of which is not used by most applications.

Because it is an OSI protocol, DAP is significantly more complicated than the more prevalent TCP/IP stack implementations, and it requires more code and computing horsepower to run. The size and complexity of DAP makes it difficult to run on thin clients, such as the PC and Macintosh®, where TCP/IP functionality often comes with the machine. DAP stack implementations are cumbersome to administer, thus limiting the acceptance of X.500. Hence, in 1993, designers at the University of Michigan—with help from the ISODE Consortium—designed and developed a protocol that would work over TCP/IP and was small enough when implemented to run on a thin client, such as a computer running Windows® operating system or a Macintosh. This protocol is called LDAP.

The LDAP version 1 Specification was published in March 1994. The LDAP version 2 Specification was published as rfc1777 by the Access Searching and Indexing of Directories (ASID) working group, part of the IETF, in March 1995. In April 1996, forty companies—including Microsoft, Netscape, and Novell—announced support for the LDAP protocol in their Directory Services products so that they could operate with each other as well as integrate with the Internet. LDAP version 3.0 has gone through several drafts, but as of January 1997, it is not completed.

Lightweight Directory Access Protocol (LDAP) Overview

LDAP defines the following four components:

  • Data Model. Defines the syntax of the data in the directory..

  • Organizational Model. Defines how the data is organized in the directory.

  • Security Model. Defines how the information in the directory is accessed in a secure manner.

  • Functional Model. Defines the operations for querying and modifying the directory.

The Data Model

The data model is centered around entries which are composed of attributes. Each attribute has a type and one or more distinct values. This defines what kind of information is allowed in the values. LDAP data elements are string types. LDAP relegates the knowledge of a value's syntax to the application program rather than lower-level protocol routines.

Which attributes are required and allowed in an entry are controlled by a special objectClass attribute in every entry. The values of this attribute identify the type of entry (for example, commonName, organization, and so on). The type of entry determines which attributes are required, and which are optional. For example, the object class commonName requires the surname and FirstName attributes, but description and others are optional.

The Organization Model

Entries are organized in a Directory Information Tree (DIT) and divided among servers in a geographical and organizational distribution. Each entry, with the exception of the root, has a parent entry. Each entry has a fully qualified name: the Distinguished Name (DN). Each component of the DN is called a Relative Distinguished Name (RDN). The Distinguished Name for any entry is constructed by concatenating the Relative Distinguished Names of the entry's ancestors.

Figure 1 depicts the relationship between entries, attributes, and values and shows how entries are arranged into a tree.

Cc749950.figure1(en-us,TechNet.10).gif

Figure 1:

The Functional Model

The functional model in LDAP defines the operations for querying and modifying the directory. It defines the operations for:

  • adding an entry from the directory.

  • deleting an entry from the directory.

  • modifying an existing entry.

  • changing the name of an existing entry.

  • querying for an entry in some portion of the directory based on a criterion specified by a query filter.

A typical search operation might involve searching the entire tree under the organization "Microsoft" for people with the name "Mohan Cavale," retrieving the e-mail address for each entry found.

The Security Model

LDAP version 2 defines an authentication model based on clear text passwords or Kerberos V4.1. LDAP version 3 defines an extensible model based on the Simple Authentication and Security Layer (SASL). SASL uses a layered architecture for using different security providers. LDAP version 3 defines the packet formats of the SASL requests and responses between the LDAP client and server. It supports both security authentication and encryption using different SASL mechanisms.

In addition to SASL, LDAP version 3 also supports secure connections using the Secure Sockets Layer (SSL) protocol.

The Topological Model

A major advantage of LDAP is that it you can build a global directory structure using LDAP. It is essentially a directory Web in much the same way that HTTP and HTML are used to define and implement the global hypertext Web. One or more LDAP servers together make up the directory tree. An LDAP client connects to an LDAP server and makes a request. If the information is not available locally, the server attempts to connect to another LDAP server that can fulfill the request. LDAP uses this referral capability to implement a global directory structure of independent LDAP servers that appear to be a single LDAP server to the client.

LDAP C-Binding API

RFC 1823 specifies the C-binding APIs for a client to access a Directory Service that supports the LDAP protocol. This API set is extremely simple and supports both synchronous and asynchronous calls to the server. However, it is very low level and means a lot of work for LDAP developers. To make it easier for developers to write LDAP-enabled applications that take advantage of LDAP-based directory services such as Active Directory, Microsoft introduced ADSI.

Microsoft's commitment to LDAP-based Directories

Today's customers demand multi-vendor integration. Core network level inter-operability is extremely important for multi-vendor integration of services. Microsoft completely supports the LDAP specification. However, the complexity of writing applications to the LDAP API set results in increased development time and costs when compared to the higher-level component systems. For this reason, Microsoft believes that application developers will, over time, use the higher-level abstractions such as ADS, rather than coding directly to low-level API sets.

It is with this view that Microsoft has built an LDAP provider for the ADSI API set. Via service providers, ADSI permits an application to access directories from different vendors based on different standards. More importantly, it allows these directories to be accessed using a single API set as COM components or Automation objects.

Microsoft recognizes that there are customers that need to use LDAP Directory Services today with an option to migrate to Directory Services based on other emerging standards later. ADSI, with its provider/client architecture, enables an application that is using those APIs to use different Directory Services, both proprietary and standards-based, with very few changes to an application.

Microsoft's LDAP-based Directory

Active Directory

Active Directory combines the best of the DNS as a locator service and LDAP as its core protocol. This facilitates work with Directory Services from other vendors running on non-Microsoft operating systems. This Directory Service can support more than 10 million objects offering unparalleled scalability. In addition to LDAP, Microsoft's plans include support in the Active Directory for the following X.500 protocols:

  • Subsets of the 1993 Directory Access Protocol (DAP)

  • 1993 Directory System Protocol (DSP)

  • Directory Information Shadowing Protocol (DISP)

Active Directory is the store for security principals in Windows NT operating system, including user accounts, groups, and domains. Active Directory, then, replaces the registry account database and is a trusted component of the Local Security Authority (LSA).

Active Directories are extensible through a schema mechanism by defining their own object types.

Security in Active Directory

Active Directory permits both authenticated and unauthenticated access to the Directory Service for clients talking over LDAP. With unauthenticated access, clients can access objects that have ACLS that allow everyone (or unauthenticated users) to access them. Active Directory allows administrators to set ACLS on entries as a whole and on attributes within entries.

Authenticated access of the Active Directory over LDAP supports both private key and public key-based authentication. The MIT Kerberos V5 authentication protocol is supported with extensions for public key-based authentication, as well as password-based authentication. Internet clients can also be authenticated using X.509 v3 Public Key Certificates. Active Directory supports impersonation, after a client is authenticated, using appropriate authentication scheme. This provides for a tight integration with the rest of the Windows NT security system.

LDAP and Security in Active Directory

The Security Support Provider Interface is based on a provider/client architecture so that applications writing to these APIs can use different Security Providers. Microsoft's LDAP client and Active Directory use the Security Support Provider Interface (SSPI) APIs for authentication and security; hence, they can use any SSPI providers for establishing and conducting a secure LDAP session. The next major release of Windows NT will ship with SSPI providers for SSL 3.0, Kerberos v5, and NTLM.

APIs to access LDAP Directory Services

Microsoft provides powerful, flexible, and easy-to-use APIs to access LDAP Directory Services.

LDAP C-Binding API

Microsoft supports RFC 1823, which specifies the C-binding APIs for a client to access a Directory Service that supports the LDAP protocol. LDAP client support will be included in all future versions of the Active Directory SDK. The LDAP client is supported on the following platforms:

  • Windows NT 3.51, 4.0, and 5.0

  • Windows 95

Active Directory Service Interfaces

An easier way than low-level LDAP C API calls to access directory services is ADSI. An ADSI provider maintains the implementation of objects and dependent objects for a particular namespace. Figure 2 demonstrates that, with ADSI, clients can be concerned only with getting and using interfaces on an object, and not with the details of where and how the software of an object is implemented. This means that developers, administrators and end-users alike can benefit from an easier way to access and manage distributed services.

Cc749950.figure2(en-us,TechNet.10).gif

Figure 2:

The ADSI SDK providers are available for the following Directory

  • Windows NT 4.0

  • Novell NetWare 3.x and 4.x

  • Active Directory

  • any Directory Service that supports LDAP RFC-1777.

ADSI components are designed to meet the needs of traditional C and C++ programmers, system administrators, and sophisticated end users. ADSI components present the directory as a set of COM objects, which provide behavior in addition to data. With ADSI components, development of directory-enabled applications is fast and easy.

Future of LDAP

Microsoft is actively working with the IETF on defining the LDAP v3 specification and will support LDAP v3 and later versions in Active Directory when the specification becomes available as an RFC.

Conclusion

Microsoft views connectivity to disparate computing platforms as a basic right. Fundamentally, if you are buying networked systems from different vendors, products must contain core services to ensure interoperability. To provide this support, Microsoft supports a variety of standards and protocols, and works with third parties to ensure support for even more standards and protocols on Microsoft platforms. This support includes LDAP and its technologies that provide interoperation. Microsoft clients and servers are also designed to interoperate with other products that support LDAP.

While Microsoft is completely committed to LDAP, LDAP interoperability is just one part of Microsoft's broad work toward a single system image in which users and administrators do not have to be aware of the differences between systems on a multi-vendor network. Microsoft is committed to providing support for both open and vendor-specific standards to give customers the interoperation they need to truly enable computing for competitive advantage. To make sure that customers and developers can leverage all of the directory service technology in a distributed environment, Microsoft built ADSI.

Programming your application to a standard set of APIs does not make your application portable. Portability is achieved through a carefully-defined implementation within a layered services architecture—these layers are known as abstraction layers and are used to segregate critical services. Abstraction layers enable developers to change application components and platforms, without necessarily affecting the application or other components. ADSI is based on this layered architecture, where an application developer can change the provider and Directory Service that the application is using without going through major changes. Programming to these APIs is easier and achieves greater application portability.

For More Information

For the latest information on Active Directory, check out our World Wide Web site at https://www.microsoft.com/win32dev/netwrk/ole\_ds.htm.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

0297 Part no. 098-68763