ADSI Layers

Microsoft® Windows® 2000 Scripting Guide

The ADSI architecture can be visualized as consisting of five layers, as shown in Figure 5.8. From the bottom of the figure up, the layers are:

• Directory or Namespace

• ADSI Provider

• ADSI Router and Registry

• Property Cache

• ADSI application

Figure 5.8 ADSI Architecture

The five layers appearing in Figure 5.8 reside in two places. The lowest layer, the directory or namespace, resides on computers running directory services accessible by ADSI, and the other three layers reside on client computers.

Directory Namespace

A directory service stores information about all resources on a network and makes the information accessible to users and applications. The directory is the physical database where information about the network is stored.

A namespace is an area where a name can be resolved. For example, the Domain Name System (DNS) namespace is a tree of domains where host names and IP addresses are contained. Name resolution allows computers to use the DNS namespace to resolve host names to IP addresses and IP addresses to host names. Similarly, a directory namespace is a defined area where a network name (directory element) can be resolved into an object regardless of where it resides within the namespace. In the case of Active Directory, the namespace is the forest and Active Directory provides name resolution services.

Any network names in Active Directory can be resolved into objects. For example, directory elements such as domains, user accounts, groups, OUs, and computers can all be resolved into objects. In turn, the object contains properties that you can manage using ADSI scripts. For example, after you have obtained a domain object using a script, you can create OUs; after you have obtained an OU object in a script, you can create user accounts, groups, and other objects.

Providers

ADSI is not part of the directory service itself, but it provides the interfaces to interact with the directory namespace. You can use ADSI to access all of the following directory namespaces:

• LDAP directories, including Active Directory

• Security Accounts Manager (SAM) databases, in both local workstations and Windows NT domains

• Internet Information Services (IIS) metabase

• Novell NetWare Directory Services (NDS)

• NetWare Bindery

ADSI providers access the directory namespace and create virtual representations of objects that you then administer with ADSI interfaces. In the suite of ADSI DLLs, there is a subset of provider DLLs that access various directory services, as shown in Table 5.5.

Table 5.5 ADSI Providers and the Directory Services They Access

ADSI providers act as the intermediaries between a directory namespace and an ADSI application, such as an ADSI script. All of the listings in this chapter bind to Active Directory using the LDAP provider or the GC provider.

Note

• Provider names are case sensitive. All ADSI providers listed are uppercase except for the WinNT provider, which is a mixture of uppercase and lowercase. Also, unlike the other providers listed, the IIS provider is not categorized as a system provider.

Binding to a directory varies from one provider to the next. However, the binding syntax always begins with the name of the provider, followed by a colon, two forward slashes, and a path distinctive to the type of directory you are binding to.

As explained in "Step 1: Establishing a Connection" earlier in this chapter, the ADsPath is the name of the provider combined with the path to a directory object. The ADsPath syntax from one provider to the next is unique to avoid naming conflicts from one directory namespace to the next. The following list shows ADsPath syntax examples for many of the ADSI providers:

• LDAP provider path to a domain controller in the na.fabrikam.com domain: LDAP://dc=NA,dc=fabrikam,dc=com. Notice that the example does not specify a server name, just a domain name. This method of binding is called serverless binding. It is a good idea to use serverless binding whenever possible so that the script is not tied to completing a bind operation to a specific domain controller.

• GC provider path to a global catalog server in the na.fabrikam.com domain: GC://dc=NA,dc=fabrikam,dc=com.

• WinNT provider path to a domain controller in the na.fabrikam.com domain: WinNT://NA.

• IIS provider path to the IIS server sea-dc-01.na.fabrikam.com: IIS://sea-dc-01.na.fabrikam.com.

• NDS provider path to a directory server in the na.fabrikam.com domain: NDS://server01/o=org01/dc=com/dc=fabrikam/dc=na.

• NWCOMPAT provider to a bindery server: NWCOMPAT://server01.

The ADSI OLE DB provider uses the same ADsPath syntax as the LDAP and GC providers but with additional parameters to control what is returned by a search operation. For more information, see "Searching Active Directory" earlier in this chapter.

Tip

• Use rootDSE to avoid hard-coding distinguished names into the ADsPath of an Active Directory bind operation. For more information about rootDSE, see "Root Directory Service Entry" earlier in this chapter.

There is a special provider called the ADSI namespace provider. You can use this provider to return a list of all providers installed on a client computer, as shown in Listing 5.54.

Listing 5.54 Displaying a List of Installed ADSI Providers

1
2
3
4

Set objProvider = GetObject("ADs:")
For Each Provider In objProvider
 Wscript.Echo Provider.Name
Next

When this script runs, it echoes the name of each installed provider, as shown in the following list that was generated from a Windows 2000 Professional computer:

WinNT:
NWCOMPAT:
NDS:
LDAP:
IIS:

Caution

• Although the ADSI WinNT provider can be used to manage a subset of objects and attributes in Active Directory, using the WinNT provider to manage Active Directory is not recommended because it can have adverse effects on a script's performance and resiliency.

Router

When a script calls the GetObject function, the ADSI router receives the request, identifies the provider being requested, searches the registry for information about the provider, and then loads the provider into local memory. The router identifies the provider by matching the provider name (its ProgID) with its ProgID as listed in the registry. The provider then passes the requested named element back to the ADSI router, and the router creates the ADSI object that is then passed back to the calling script.

The ADSI Router is responsible for creating many of the ADSI core objects and the corresponding interfaces used to manage elements in ADSI-supported directories. After object creation (completing the binding operation), object management, such as reading and writing object attributes, is undertaken directly between the ADSI application and the provider.

Property Cache

Immediately following the binding operation, a region of local memory is set aside to hold a virtual representation of an Active Directory object. The Active Directory object and its attributes are not downloaded to the property cache during the binding operation. This is important because the Active Directory object can contain hundreds of attributes, most of which you will not need to manage in a single script. For more information about the local property cache, see "Data Caching" earlier in this chapter.

ADSI-Enabled Applications

This is the top layer of ADSI, and is where you interact with the rest of the architecture. All of the listings in this chapter demonstrate how to use WSH and VBScript to create scripts that interact with ADSI. Many other applications depend on ADSI, such as the Active Directory Users and Computers and ADSI Edit snap-ins. These GUI-based applications can help you manage directories and gain a further understanding of how directories operate.