Understanding Active Directory, Part VI
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The Active Directory supports the development of additional snap-in administrative tools through its Active Directory Services Interface (ADSI) API. The primary purposes of this API are to permit third-party software vendors to develop additional tools, to allow system administrators to write related scripts, and to afford more open interfaces with other directory services.
ADSI Resources
ADSI is perfect for automating administrative tasks such as changing passwords, creating users complete with Exchange mailboxes, working with file shares, and creating computer accounts.
The ADSI is based on the common object model (COM). Because it is a set of COM-based interfaces on the Active Directory (as well as to Win9x and Windows NT), it permits the administrator or software developer to work with the Active Directory without worrying about its internals. As is true with all COM development, a number of programming languages can be utilized, including C, C++, Java, and Visual Basic. Associated APIs that can be modified within the context of the Active Directory are the LDAP API (RFC 1823 for the C language) and MAPI.
ADSI is part of the Windows Open Services Architecture (WOSA) and the Open Directory Service Interfaces (ODSI). A discussion of these models, architectures, and interfaces is outside the scope of this book, but system administrators desiring additional information can download an assortment of white papers directly from the Microsoft Web site.
The architecture of the Active Directory employs a number of service interfaces that manage the object mode, schema, caching, namespace, navigation, and searching. It is based on an object model consisting of ADSI host objects and dependent objects. The host and dependent object relationship is different from the container/contents relationship that is part of the Active Directory itself, in that it acts as a parent and child relationship for the directory service objects only.
The ADSI provider implements requests made to the host and dependent objects. The objects can be one of two types. Directory service container objects can hold other ADSI objects. They include Namespace, Country, Locality, Organization, Organizational Unit, Domain, and Computer. Directory service leaf objects cannot be used as containers of other objects. They include User, Group, Alias, Service, Print Queue, Print Device, Print Job, File Job, File Service, File Share, Session, and Resources.
ADSI, currently at version 2.5, is available from the Microsoft Web site at http://www.microsoft.com/adsi. For development work, both the ADSI and ADSI SDK are necessary. The SDK contains a large variety of samples in C++, VB, and J++; as well as a sample ADSI provider and some tools to explore ADSI.
Sample ADSI Scripts
James Morris, a member of the Microsoft Windows 2000 rapid deployment program and a software engineer for the University of Washington, kindly offered the following two example scripts that can be used in connection with ADSI.
Sample 1: VB code for adding full name and description to a user
Private Sub Form_Load()
' Define the user object
Dim user As IADsUser
' Set the Domain equal to your domain
domain = "DOMAIN"
'Bind to the user object Administrator using the WinNT provider
Set user = GetObject("WinNT://" & domain & "/Administrator")
' Set the properties
user.FullName = "Jane Doe"
user.Description = "Senior Accountant" & domain
'It's important to commit the changes!
user.SetInfo
End Sub
***
Sample 2: VBScript to enumerate objects on a computer
Dim ComputerName
'Set the name of the computer to work with
ComputerName = "computer1"
'Bind to computer object using the WinNT provider
Set compobj = GetObject("WinNT://" & ComputerName & ",computer" )
'Echo the objects to the screen
For each obj in compobj
wscript.echo obj.Name
Next
***