Practical Usage of ADSI | Windows NT/2000 ADSI Scripting for System Administration

Practical Usage of ADSI

In addition to allowing closer ties with existing workflow processes, the multi- tier nature of ADSI's architecture allows you to quickly and easily convert theoretical principles into practical applications. Whether these principles center on creating a more efficient internal workflow process, or you simply have a requirement to be able to quickly search a given namespace, ADSI can help.

In the sections that follow, you will take a more in-depth look at some of the more significant practical applications of ADSI, including the following:

Shadowing business workflow processes
Enforcing naming standards
Automating system management

You will also explore the way ADSI employs property caches, conducts namespace searches, and utilizes security.

Shadowing Business Workflow Processes

Just as you might prefer clothing that has been tailored to fit your body shape, today's enterprise demands applications that combine the advantages of shrink-wrapped functionality with the ability to tailor the application to suit the needs of the business. Microsoft and other vendors have clearly responded to these demands, and many new office automation applications on the market today offer the ability to modify default behavior and automate the use of such products through VBA.

Before Web-based applications became possible, internal workflow processes often were required to change to fit the flow of the application. In such cases, software vendors were sculpting business processes, rather than following the more logical approach that business requirements should instead drive the application development effort.

With the advent of COM support in Web server applications, robust Web applications can be rapidly developed to exactly shadow the workflow processes of any business unit. Using COM objects, you can easily separate application logic from business logic, thus creating an application that is both flexible and easy to modify. In addition, Web-based applications offer the following advantages:

User interface images can be modified to match current corporate marketing collateral and aesthetic standards
Managers can consolidate multiple tools into a single common interface, thus reducing the user learning curve required to use the application effectively

By studying a business workflow, a developer can create an application that automates several of the processes contained within the workflow and exactly shadows existing business processes.

To better understand how ADSI fits into the workflow, suppose a new employee has joined your company. To be effective on her first day of work, she requires desk space, a telephone, a workstation, and accounts in the NT, Exchange, Novell, and UNIX namespaces. Using ADO, you can write a script to capture data from the human resources database, and subsequently create accounts in the LDAP directory, NDS, Exchange, and the Windows NT SAM. Using this data with each appropriate ADSI service provider, you can automatically assign group and distribution list membership to this new user based on the data found in the HR database.

Enforcing Naming Standards

Before the introduction of ADSI, there was little that could be done to incorporate business rules into Windows NT administrative workflows. For example, suppose all workstation accounts created in resource domains are required to be eight characters long, begin with "WKS," and follow a naming standard based upon the business unit the device is assigned to. Although a common requirement, the default Windows NT tools could provide no method for enforcing such a standard. Neither Server Manager nor User Manager enables you to specify any custom-defined standards for the fields in the SAM, and in turn a user can create accounts that do not accurately follow the naming standards established for the enterprise.

Using ADSI, however, an HTML or Visual Basic form can be developed to enforce a pre-defined naming standard before creating the account.

Automating System Management

Quite often, administrative tasks must be performed upon every workstation in a region, or occasionally, upon the entire enterprise. Whether it is the addition of a new file system share or changing the password of the local administrator account on every machine in the domain, these tasks are very well suited to scripting efforts using ADSI.

To better understand the extent to which ADSI supports system management in the enterprise, consider the following types of management that can be automated using ADSI:

Domain management
Exchange Mailbox management
File session management
Group management
IIS Metabase management
Print management
Service management
File Share management
User management

The following Visual Basic code segment illustrates the power of ADSI by enumerating all computer accounts in the domain and setting the local "administrator" account password to a known value:

 On Error Resume Next Dim TargetDomain as String Dim ADsPath as String Dim Domain as IADsContainer Dim Computer as IADsComputer Dim LocalAdminAccount as IADsUser TargetDomain = "  Resource_Domain_Name  " ADsPath = "WinNT://"&TargetDomain Set Domain = GetObject(ADsPath) Domain.Filter=Array("Computer") For Each Computer in Domain      Set LocalAdminAccount = GetObject("WinNT://"&TargetDomain&"/"& Computer.Name&"/  administrator,user")      LocalAdminAccount.SetPassword = "Tweek@Coffee"      If Err. Number=0 then Debug.Print "Local administrator password changed on " &  Computer.Name      Err. Number = 0 Next

In just a few lines of Visual Basic code, you are able to change the local administrator password for every Windows NT workstation in a given resource domain. Consider for a moment how long this would take if you were required to do it manually using User Manager. This same concept can be applied in many ways, allowing the addition of a new "workstation administrators" group in the user domain to be added to the local administrators group on each machine, or perhaps removing a group from all machines in a given resource domain.

These are just a few small examples of the benefits of administrative function automation; as you study each chapter in this book, you will invariably think of dozens of applications to help tackle a particular administrative issue in your enterprise.

Property Cache

In an effort to reduce the amount of time spent traversing the network to retrieve and set properties, ADSI employs a property caching model. Every ADSI interface derived from the IADs interface supports this caching model through the GetInfo and SetInfo methods .

GetInfo

The GetInfo method is called each time a request for new data is made from the directory. If you wish to retrieve the value of the FullName field in the SAM for user TEck, use the following Visual Basic code:

 Dim User as IADsUser Set User = GetObject("WinNT://Domain/Eckth,user") Debug.Print "The Full Name value for user EckTh is: "&User.FullName

Although User.GetInfo was never explicitly called, any property retrieved from the directory will implicitly call the GetInfo method. If you reference User.FullName again elsewhere in your code, ADSI will return the value held in the property cache rather than performing another lookup in the directory.

SetInfo

ADSI also exposes the SetInfo method in the IADs interface to reduce the required number of directory write events. If you are creating a new object in a namespace, you can set several properties upon creation of the object, yet only one write operation will be performed upon the directory. Like the Windows Registry, most directories have been optimized for fast queries, but in exchange for this optimization, sport relatively poor write performance. To minimize network traffic, ADSI's property cache allows you to perform a single write operation, which is best utilized by restricting the number of calls to the SetInfo method.

Consider the following Visual Basic code:

 Dim Container As IADsContainer Dim User As IADsUser Set Container = GetObject("WinNT://Domain_Name") Set User = Container.Create("User", "EckTh") User.FullName = "Thomas E. Eck" User.Description = "PSC, Chicago, Intranet Engineering" User.SetInfo

In the preceding example, you create the user, populate the full name field, and write the description field. The only time the directory is ever updated is when User.SetInfo is called.

GetInfo/SetInfo Combination

Although the necessity of the SetInfo method is rather obvious, the explicit use of the GetInfo method may not be quite as clear. Using a combination of the GetInfo and SetInfo methods found in most ADSI interfaces, a crude transaction server can be implemented.

Consider the following Visual Basic code as an example:

 Dim User as IADsUser Dim Retval as Boolean Set User=GetObject("WinNT://Domain/TEck,user") User.FullName = "Thomas Eck" User.Description = "PSC, Stamford, Intranet Engineering" Retval = MsgBox("Are you sure you wish to change the Fullname, and Description Values for  user TEck?", vbYesNo + vbCritical + vbDefaultButton2,  "Confirm Action") If Retval = vbYes Then      User.SetInfo 'Commit the transaction to the directory Else      User.GetInfo 'Rollback the trans/Repopulate cache with old values. End If

In the preceding example, the property cache is populated with some new values for your test account, but before committing the information to the directory, the user has a chance to roll back the transaction. If the user cancels the changes, the GetInfo method is called explicitly to repopulate the property cache with the old values for the user.

If the transaction is canceled without the explicit call to GetInfo , any subsequent calls to User.FullName or User.Description would reflect the changes that were supposed to be abandoned because the property cache still holds these values.

Namespace Searches

ADSI can act as an OLE-DB provider to allow native database queries to be performed using ActiveX Data Objects (ADO) against directory service namespaces. Considering that queries are the most often performed action on any directory structure, the ability to query a directory as a native OLE-DB source can be a powerful feature. Using ADSI in this way, you can design extremely robust directory service applications that take advantage of result sets derived from table joins between a directory service and an external database.

Unfortunately, the use of ADSI as an OLE-DB provider is only supported when querying against LDAP and NDS namespaces. To search the Windows NT namespace, you must instead enumerate the domain and then manipulate the result set using conditionals. Enumeration examples using ADSI can be found throughout this book, whereas the use of ADSI as an OLE-DB provider is only covered in Chapter 11, "Programmatic Management of LDAP Infrastructures" due to the fact that searches using ADO are only possible in LDAP namespaces.

Security Objects

ADSI provides interfaces for both authorization and authentication against the Active Directory using either NTLM or Kerberos as the authentication method. This incredibly powerful feature enables developers to script secure single-signon solutions using ADSI to authenticate against the Active Directory or another LDAP infrastructure. ADSI allows a secure single-signon mechanism to be brought to every aspect of the enterprise, including intranet and extranet applications. Authentication against the Active Directory using ADSI is covered in more detail in Chapter 12, "Programmatic Management of the Windows 2000 Active Directory."

Top