Informal View on the ADSI Architecture

For a beginner, the main challenge in studying ADSI is arguably the great number of exposed interfaces (over 50) which in turn have many methods and properties. If, however, one understands the ADSI essentials and certain restrictions, it is easy to begin using ADSI, and then gradually learn new interfaces and advanced programming topics.

Attributes and Properties

Let us outline the problem in general words. All you need to do is to select a directory object — a user, group, computer, or some other item — and perform some action over its properties.

Hereafter, the terms attribute and property will be used as synonyms. Attribute is an element of an object stored in Active Directory, whereas property relates to an ADSI object represented programmatically. You can find mapping between ADSI properties and Active Directory attributes in the ADSI SDK.

ADSI System Providers

Any directory object exists in a namespace that is specific to each directory type. (The hierarchical structure of Active Directory evidently differs from the flat name- space of Windows NT domains.) Besides, a user in a Windows NT 4.0 domain has a set of attributes different from the attribute set available for a user in Active Directory. Therefore, ADSI has a specific system provider (or simply provider) for every supported directory type. Here are four main ADSI providers:

Provider name	Directory	DLL name(s)
WinNT:	Windows NT 4.0 domains	adsnt.dll
LDAP:	LDAP servers (Exchange 5.x and Active Directory)	adsldp.dll, and adsmext.dll
NDS:	Novell Directory Services (NDS)	adsnds.dll
NWCOMPAT:	Novell NetWare bindary (3.x)	adsnw.dll

(Provider names are case-sensitive!) The following script lists all providers installed in a system:

    'Dim objRoot, objChild As IADs    Set objRoot = GetObject ("ADS:")    For Each objChild In objRoot      WScript.Echo objChild.Name    Next 

When selecting a system provider, you define both the naming conventions for a directory object and the ADSI program representation of this object (i.e., the set of exposed properties and methods).

ADSI also supports so called IIS Admin Objects that provide programmatic access to Internet Information Services (IIS). Using scripts for administering IIS metabase is a vast and specific subject, so we shall not discuss it in the book.

Interfaces and Methods

A programmer can access the ADSI objects that correspond to the directory objects via COM interfaces, or, more precisely, through methods and properties of these interfaces. Therefore, the selected interface determines what operations can be performed with the object, or which information can be retrieved/set. Compare, for instance, the lists of methods and properties of the IADs and IADsUser interfaces. Some interfaces are supported by each provider, whereas some interfaces can be supported by only one provider. For example, Table 16.1 lists some basic ADSI objects for the LDAP provider, together with the ADSI interfaces, which the provider supports. (You can also find a similar table for the WinNT provider and other providers.)

Table 16.1: Basic ADSI Objects and Corresponding Interfaces Supported by the LDAP Provider

ADSI object	Supported interfaces
General object (generic features of user, computer, group objects, etc.)	IADs
	IADsContainer
	IDirectoryObject
	IDirectorySearch
	IADsPropertyList
	IADsObjectOptions
	IADsDeleteOps
Group account	IADsGroup
Organization unit	IADsOU
Print queue	IADsPrintQueue
	IADsPrintQueueOperations
RootDSE	IADs
	IADsPropertyList
Schema	IADs
	IADsContainer
User account	IADsUser

In Table 16.1, you can see that many ADSI objects implement two or more interfaces. This means that you can call any method of any implemented interface, and the object exposes all properties defined in these interfaces. This table must serve as a starting point for selecting a suitable interface, or for understanding methods and properties that ADSI provides for a directory object. You need not learn all or most of the interfaces (especially in the beginning). Quite a few interfaces, called core interfaces, can cover most of your needs. (See the table in Appendix C. These interfaces are shown in bold.) The IADs and IADsContainer interfaces provide access to practically any directory object, and allow you to perform a number of manipulations with objects - create, delete, rename, enumerate, and so on. The IADsOpenDSObject interface allows users to specify alternative credentials when binding to an object. (See Chapter 17, "Scripting Administrative Tasks," for examples.)

As you can see from the table of the supported interfaces (Appendix C), the WinNT provider does not support, for example, OU objects, and the LDAP provider does not support file shares or services. Therefore, you should not be under the impression that either the LDAP or WinNT provider is better. Certainly, only the LDAP protocol can provide full value access to Active Directory. Nevertheless, there are operations that can only be performed via the WinNT provider and situations where this provider produces a more compact code (for example, when filtering objects of a given type in an entire domain regardless of organizational units and other containers). You can use it effectively even in a pure Windows 2000/.NET environment.

For a programmer, selecting a provider and interface for a directory object is, therefore, a crucial operation that determines the methods and properties that will be accessible later. The ADSI SDK help file contains lists of interfaces and properties supported by each provider, and you can print out the necessary tables. If you have a solid understanding of all the stated considerations, you will have no problems when declaring variables or calling an object's methods.

The IADsADSystemlnfo Interface

There is a very useful interface available only under Windows 2000/XP/.NET and not mentioned in the basic ADSI SDK documentation (see the updated documentation in the Platform SDK). It allows you to retrieve current domain information for a client computer. To use this interface, you must first explicitly create an instance of the ADsSystemInfo object. Look at the following code snippet - it illustrates how to use some methods of the IADsADSystemInfo interface.

    Dim objSysInfo    Set objSysInfo = CreateObject ("ADSystemInfo")    ' In a VB program the next statement is sufficient:    '    Dim objSysInfo As New ADSystemInfo    WScript.Echo objSysInfo.ComputerName    WScript.Echo objSysInfo.DomainDNSName    WScript.Echo objSysInfo.ForestDNSName    WScript.Echo objSysInfo.IsNativeMode    WScript.Echo objSysInfo.PDCRoleOwner    WScript.Echo objSysInfo.SiteName    WScript.Echo objSysInfo.GetAnyDCName    WScript.Echo objSysInfo.UserName 

The last statement displays the DN name of the currently logged on user.

Such a script can be useful for determining which domain, site, and DC a client is currently connected to.