|
|
The Active Directory supports 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 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). Since 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 used, 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 who desire 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 only for the directory service objects.
The ADSI provider implements requests made to the host and dependent objects. The objects can be one of two types—container objects and leaf objects. 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, which is currently at version 2.5, is available from Microsoft 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.
James Morris, 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
***
Active Directory's UI data is stored in a Display Specifier object, whose attributes define the UI elements. The property pages for the Active Directory can be a COM object or an HTML file. The Display Specifier object stores the URL of the HTML page or the universally unique identifier (UUID) of the COM object.
For system administrators, the properties associated with system management are stored in the Admin-Property-Pages. Those for end users are stored in the Shell-Property-Pages. Menus for end users are different from those for administrators. Thus, the context menu for users is Shell-Context-Menu; for administrators, Admin-Context-Menu.
 |
|
|
| Top |