The Active Directory Services Interface

If you’ve used Windows 2000, you’d have noticed the

integration of its admin interfaces and tools into the Microsoft Management

Console (MMC). The MMC allows delegation of tools to different users, so that a

large corporation can manage a Win 2k-based network better. However, sometimes

the MMC just doesn’t do what you need to. This is where ADSI comes in.

In his book "Business@The Speed of Thought", Bill

Gates gives an example of the processes that happen even before a new employee

joins Microsoft. Most large corporations would follow a minor variation of the

same. Take, for instance, a user named Morpheus joining a fictional corporation

called "The Matrix". The processes involved before his first day at

office would involve the system administrator setting up a domain account,

creating his home directory, adding him to the correct user groups, creating a

mail account and other assorted MIS stuff. All this is easily possible through

Win 2k’s administration tools. However, the poor system administrator needs to

do each step one by one, making sure that he resolves conflicts if any, and

finally sends an e-mail to the new user as well as his boss that he is all set

to join up. Now, extrapolate this scenario to a hundred users joining up, say as

temporary summer trainees. I’d hate to be in the poor sys admin’s shoes.

This is where a customized solution for this company would be

helpful. A single, simple interface for the harassed administrator or his

subordinates would really help. What about a solution like a free Hotmail

account? The new user simply sees a Web page the first time he sits on his

machine and registers his details, and everything is automatically done for him.

Such solutions are possible through Active Directory Services

Interface. ADSI is a set of interfaces or "handles" that allows

developers to manipulate the Active Directory using COM objects. The best part

is that not only is ADSI easy to understand and develop, you can also use any

programming language you’re comfortable with, such as VB, VC++, VBScript,

JavaScript, etc. The technologies that can interface with the ADSI scripts

include the Windows Script Host, Windows Script Components, Active Server Pages

(ASP), or HTML applications. So you have a choice of languages and user

interface you wish to provide.

ASPs lets you run the scripts as a Web page, HTAs as small,

distributable programs, WSH as quick and dirty scripts that do your job without

bothering about the user interface, and VB or VC for a really big application if

you want to go that way. Anyway, the choice is yours. Let’s find out what ADSI

can do for you. The language I chose is VBScript and the interface is WSH (as I

want to concentrate on the ADSI part and not the user interface programming

part).

ADSI namespaces....>>>

ADSI namespaces

ADSI contains a large number of different namespaces, or what

you can term as top-level objects. Depending on the configuration of your Win 2k

setup, you’ll find a few additions to these. The common ones are–Win NT, NDS,

LDAP, and NWCOM PAT. Win NT and LDAP namespaces are the ones that we’ll

discuss here. The difference between the two lies mostly in that Win NT is used

to refer to a particular machine, whereas LDAP queries the domain. These are the

interfaces that allow manipulation of objects such as user, groups, services,

ADS schema, etc. You could also have IIS as another namespace if it’s

installed.

To check what are the namespaces on your machine save the

following as a VBS file and run it.

Set oADSI = GetObject("ADs:") ‘ Get the Root ADS object

For Each Child in oADSI

sNS = sNS & Child.Name & vbCrLf

Next

WScript.Echo sNS

This’ll give you a small popup that lists the top-level

namespaces available on your machine.

Now to find out the properties of the Win NT object, try the

following script:

Set oW = GetObject("WinNT://powerhouse")

Replace powerhouse with your machine name.

Try LDAP://domain if on a Win 2k domain controller.

s = "Name: " & oW.Name & CHR(13)

s = s & "Class: " & oW.Class & CHR(13)

s = s & "GUID: " & oW.GUID & CHR(13)

s = s & "AdsPath: " & oW.ADsPath & CHR(13)

s = s & "Parent: " & .Parent & CHR(13)

s = s & "Schema: " & oW.Schema

wScript.Echo s

This shows you the ADS–related properties of your domain.

By simply changing the first line to include, say your username, you can see

your properties. For example, if the first line is changed to Set oW = GetObject

("WinNT://powerhouse/vinod"), the result you’ll see is different.

Each ADS object belongs to a class–user, group, or service

(you might have more depending upon what you have installed–IIS, print

services, etc). To see a list of members of each class, simply use the following

script as a template. Change the filter property to one of the classes to see

members of that class. You can also see more than one class by using a

comma-delimited list within the



Array ( ) keyword.

Set oW = GetObject("WinNT://powerhouse")

oW.Filter = Array("group")

For Each item In oW

sItem = sItem & group.Name & CHR(13)

Next

Wscript.Echo sItem

Property values can also be read or written using scripts.

The ADSI model is so extensible, thanks to the LDAP based back-end processing,

that you can script not only things that are a part of the



Win 2k operating system, but also ones that are add-ons and use the ADS, such as
IIS and Exchange 2000. However, programming the interfaces for these is way

beyond the scope of this article. To learn how to go about doing it, take a look

at the admin scripts that come with IIS 5.

To read or set property values, one must query the correct

interface collection and read its value. Use the following script to retrieve

the properties of each user on the system.

Set oW = GetObject("WinNT://powerhouse")

oW.Filter = Array("user")

For Each user in oW

Set userClass = GetObject(User.Schema)

on error resume next

Wscript.Echo "======"

WScript.Echo

Wscript.Echo "USER: " & User.Name

Wscript.Echo "––––––"

WScript.Echo "Mandatory properties for " & User.Name &

":"

For Each property In userClass.MandatoryProperties

WScript.Echo " " & property & ": " &

User.Get(property)

Next

Wscript.Echo "––––––"

WScript.Echo

WScript.Echo "Optional properties for " & User.Name &

":"

For Each property In userClass.OptionalProperties

WScript.Echo " " & property & ": " &

User.Get(property)

Next

Next

Run this script from the Command Prompt using cscript.exe.

Enter "cscript list.vbs" to see the results. You might have to pipe it

through MORE or redirect to a file to see the list. The script itself is pretty

self-explanatory. It simply cycles through all the users of the specified

machine or domain and lists their properties and values.

To create a new user and set his properties, do the

following.

sUserName = "Morpheus"

Set oW = GetObject("WinNT://powerhouse")

Set newUser = oW.Create("user", sUserName)

newUser.SetInfo

newUser.FullName = "Morpheus X"

newUser.Description = "Is he the ONE?"

newUser.SetInfo

WScript.Echo "ADSI Path: " & newuser.ADsPath

set oG = GetObject("WinNT://powerhouse/Administrators")

oG.Add(newUser.ADsPath)

Wscript.Echo newUser.Name & " (" & newUser.FullName &

") has been added to the Administrators Group"

set userClass = GetObject(newUser.Schema)

on error resume next

Wscript.Echo "==========="

WScript.Echo

Wscript.Echo "USER: " & newUser.Name

Wscript.Echo "––––––––––"

WScript.Echo "Mandatory properties for " & newUser.Name &

":"

For Each property In userClass.MandatoryProperties

WScript.Echo " " & property & ": " &

newUser.Get(property)

Next

Wscript.Echo "––––––––––"

WScript.Echo

WScript.Echo "Optional properties for " & newUser.Name &

":"

For Each property In userClass.OptionalProperties

WScript.Echo " " & property & ": " &

newUser.Get(property)

Next

This script creates a user called Morpheus, sets his full

name and description properties, and adds him to the administrator’s group

(see visual on previous page). It then shows a list of all the properties for

this user.

The LDAP namespace lets you manipulate the ADS using the LDAP

syntax. The only difference in using the two is that the LDAP method lets you

use the standard "dc=domain, dc=com" type of syntax to traverse the

directory. However, LDAP is the only way to traverse sections of the tree if you’ve

changed the internal Win 2k directory schema itself. However, this can’t be

covered here. Look out for a detailed hands-on on modifying the Win 2k Active

Directory structure.

ADSI scripting is a vast and interesting topic. However, a

lot of the ADS interfaces depend on what you’ve installed on your machine and

what you want to do with it. As you can see, scripting ADSI with a few lines of

code can really reduce administrator headaches. Using WSH, the File SystemObject,

VBA, ASP, and ADSI, one can easily create scripts that do a lot of complex

things such as picking up a list of new entrants from an Access or Excel file

and generating accounts, usernames based on company policy, home directories,

and permissions. ADSI is a powerful and customizable method of automating

mundane and repetitive administrative tasks, and using it appropriately can help

save a lot of time and resources.

Vinod Unny is a technology consultant at iSquare Technologies