Active Directory Service Interfaces (ADSI)

To make it easy to directory-enable any application, Microsoft has provided Active Directory Service Interfaces (ADSI). ADSI is a collection of several interfaces that can be used to access the Active Directory from within executable application programs. Programmers might want to use ADSI instead of the LDAP C API because ADSI makes it possible to write an application that can access directory services from multiple providers. If the directory service provider has designed its directory service product to be compliant with at least version 2.0 of LDAP, ADSI should be capable of providing an interface into the directory. The current version of ADSI is 2.5, and it is included with Windows 2000/2003.

In addition to providing access to Microsoft directory products, such as Exchange Server 5.5, ADSI has been tested by Microsoft against the following:

• Netscape Directory Server 1.0

• University of Michigan's SLAPD Server

• Novell's LDAP-enabled NDS product

ADSI provides an interface that allows all the functionality of the LDAP C API, but does so in a manner that is easier to understand and write code for. Another reason for using ADSI in application development is that ADSI can be used by many higher-level programming languages, including Microsoft Visual BASIC, Perl, Rexx, and C or C++.

ADSI uses the Component Object Model (COM) interface to allow programmers to access and manipulate the underlying directory objects found in multiple directory services. A program written using ADSI should function correctly with any directory service for which ADSI has a provider interface.

Directory-Aware Application Programming

ADSI is one of the features of Microsoft's development of Active Directory Services that might benefit large enterprises the greatest. If the Active Directory were limited to specific types of objects or attributes that could be stored in the directory, and if only programs supplied by Microsoft were able to access and manipulate the directory store, there wouldn't be much to say about Active Directory beyond its being a major improvement in the administration of Windows servers and clients.

However, if it's properly employed, using ADSI to incorporate application program configuration information into the directory database along with other types of data can produce real cost benefits in a large network. For example:

• Many applications use similar configuration information that is duplicated in each application's specific configuration data file (or, possibly Registry entries). Information about computers and locales can be stored in the directory, along with other configuration information, and shared by many applications.

• Shared information that already is stored in the directory can be shared by ADSI-aware applications. User information already is stored in user objects in the Active Directory. By extending this object and adding attributes, you can create a customized user object that can be used by applications unique to your environment. Eliminating redundant resources of information also can help ensure a greater accuracy in your database because data must be updated only once in a single location.

• Applications that depend on central configuration databases found on servers in the network can benefit from reduced downtime. If a server that contains configuration data files goes offline, clients must wait for the server to return to working order. If the clients use the Active Directory, replicas of the directory can be configured so that the loss of a server no longer is a point of failure.

• Applications can "publish" themselves in the Active Directory, listing the services that they can give to clients and the information needed to use the service. In a volatile network in which users move frequently, reconfiguring applications can be simplified by having the application programmed to locate the information it needs for the new locale.

Many types of applications can benefit from using the Active Directory. Human resource departments and security departments can share a common user database resource by storing information in the directory. System management products can be written to access the information already contained in directory user and computer objects.

Now It's Just Domain Controllers and Member Servers

When you create a domain controller for a Windows server, you are no longer required to do so during the installation of the operating system, which was the case with Windows NT. And to make things even easier, you no longer must create primary and backup domain controllers. In Windows Server, no distinction is made as to primary or backup domain controllers. Instead, each domain controller in a domain (and there can be as many as you need) holds a complete copy of the domain's partition of the Active Directory. Updates can be made at any domain controller, and updates are propagated using multimaster replication to all other domain controllers in the domain.

Remember that in the Active Directory domain, names are expressed as DNS-style names. That is, instead of naming a domain acme, for example, it is now named acme.com, which is a DNS-style name. When you create a tree of domains in the Active Directory, you must use a hierarchical DNS naming scheme so that you maintain a contiguous namespace.

Each domain in the tree is a subdomain of the topmost domain. The domain tree provides a two-way transitive trust relationship between all domains that exist in the tree. Inheritance of security rights flows downward from the top of the tree, so you can assign users administrative access rights and permissions at a single point in the tree, and therefore grant them the same rights for child objects farther down the tree.

When you have a network that is composed of disparate namespaces, you can create separate trees and group them into a forest. Recall that a forest is a collection of domain trees. In this type of organization, each domain tree represents a contiguous namespace, but other disjointed namespaces are in the network. A domain forest is used in a similar manner to a domain tree, in that users can still be granted access rights in domains that are contained in other domain trees. The main difference between a domain tree and a forest is the disjointed namespaces.