Access and manage user accounts and network resources, no matter what network environment they come from
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.
Previous
Register
