Manage Directory Resources with Active Directory Services Interface

Do you want to use scripting or Visual Basic (VB) to enhance your user administration and network resource management? Would you like to use a C compiler to create utilities that work without modification on both Windows NT and NetWare? Do you want to add 200 user accounts with proper settings in a batch run or print a customized report of your users?

In February, Microsoft released a specification that makes these tasks possible: Active Directory Service Interfaces (ADSI) 1.0. ADSI is not a multivendor or Internet Engineering Task Force (IETF) standard; the copyright belongs solely to Microsoft. With ADSI, you can manage the resources in your directory services--and it doesn't matter which network environments those resources come from.

ADSI works with true directory services, such as NetWare 4.x's Novell Directory Services (NDS) and NT 5.0's Active Directory (AD). ADSI also works with network environments that don't have a directory service, such as NetWare 3.x (instead, its Bindery stores user accounts and other objects) and NT 4.0 (instead, its Security Accounts Manager--SAM--stores the user database and domain models). Of course, you need an ADSI provider for all these environments.

When you have a true directory service, you can create directory-enabled applications with ADSI, whether you are an inhouse developer or independent software vendor (ISV). These applications go beyond network administration. They use the directory service as a distributed information store to add value to current networked applications.

How does ADSI work? NT, NetWare, and other network operating systems have native APIs for accessing and managing network resources. ADSI just puts a uniform layer on top of the native APIs so that you don't need to use different software development kits (SDKs) or learn different APIs to program for multiple network environments. ADSI abstracts the objects and interfaces of the underlying directory services and creates component object model (COM) objects and interfaces for you to use.

Using ADSI might sound difficult, but it's not. You are probably already familiar with part of ADSI's technology: COM. ADSI uses the same COM technology as distributed component object model (DCOM) and ActiveX components. You just need to learn about those technological areas that you might not be too familiar with: the ADSI environment and ADSI objects.

The ADSI Environment
Both the ADSI application and provider run on your workstation. The target server does not need any ADSI support or installation. The server just receives native calls. The main platform for the 32-bit ADSI program is currently NT 4.0, although ADSI also supports Windows 95, as Figure 1 shows. ADSI talks to four different providers: ADSNW.DLL for NetWare 3.x, ADSNDS.DLL for NetWare 4.x, ADSNT.DLL for NT 4.0, and ADSLDP.DLL for NT 5.0 and Lightweight Directory Access Protocol (LDAP) 2.0. These providers convert ADSI calls to Win32 API, NetWare, or LDAP calls.

Although you can use ADSI with different networks, it has the closest relationship with NT 5.0's AD. ADSI's and AD's terminology, design, structure, and name are similar. ADSI will be the primary interface for programming to AD; Messaging API (MAPI) and the traditional C language API for LDAP will be secondary.

You can use VB 4.0 (32-bit version), VB 5.0, Visual C++ 4.2, and Visual J++ with the Java Virtual Machine (JVM) to develop applications. According to Microsoft, you can also use any other application development tools that bind and invoke interfaces in COM objects or act as an Object Linking and Embedding (OLE) automation controller. For example, you can use ADSI with NT 5.0 Windows Scripting Host (WSH) to develop Visual Basic Script (VBScript) batches or scripts (see the sidebar "Use ADSI with WSH," page 164).

ADSI's Object Architecture
You won't find ADSI's object architecture complicated, but you might find it confusing because every element in the network directory service is referred to as an object. The object referral process begins when the network directory service abstracts its resources by creating objects to represent them. So, for example, users, servers, and printers become objects in the directory service (NDS or AD). ADSI, in turn, abstracts these NDS and AD objects into COM objects, as shown in Figure 2.

AD COM objects include dependent objects. Dependent objects are COM objects that represent common functions, such as collection handling. Because you can access dependent objects only through their host AD objects, I will not discuss them further.

AD COM objects represent elements in the underlying directory service. Two types exist: AD leaf objects and AD container objects. If an object can contain another object--just like an electronic folder can contain an electronic file--the object is an AD container object (herein referred to as simply container). If an object cannot house another object--just like a file cannot contain a folder--the object is an AD leaf object (or just leaf). Simply put, containers can house leafs, but leafs cannot house containers. Table 1 contains ADSI standard containers and leafs.

A container isn't limited to holding leafs. Just like an electronic folder can contain other folders, a container can hold other containers. For example, containers house AD Schema containers, which play an important role in ADSI. An AD Schema container holds the objects that define the schema for a particular part of a directory service. This container houses three different types of objects: AD Schema class objects, AD Property objects, and AD Syntax objects.

AD Schema class objects represent the different types, or classes, of elements in a directory service. One AD Schema class object exists for each type, such as user, computer, group, and organization. The AD Schema class object tells which properties are mandatory and which are optional for the corresponding object type. For example, the AD Schema class object for user might have a mandatory property of user name and an optional property of fax number. The AD Schema class object also tells whether the object's class is derived from other classes (and thus would support also their properties).

The AD Property object represents one property of the AD Schema class object. Thus, in this example, you need two AD Property objects: one to represent the user name and the other to represent the fax number. If two AD Schema class objects have the same property, they share the AD Property object. For example, if the AD Schema class objects of user and organization both have the property of fax number, only one AD Property object of fax number will exist.

Each property uses a syntax, which is represented by the AD Syntax object. So, in this example, you need two AD Syntax objects: one to represent the string syntax of the name property and another to represent the fax number syntax of the fax number property.