Create and modify groups by using automation: If you have a very large network to control with numerous domain controllers, computers, users, etc., you will be interested to know that you can use a method other than the Active Directory Users and Computers console to control these large environments. With the advent of Windows 2000, a new method became available for network administrators-scripting using Active Directory Service Interface (ADSI). ADSI is a set of COM interfaces that confronts the challenges in a distributed computing environment. ADSI can be used to access directory services' features and present a single set of directory service interfaces to the administrator for the management of resources on the network. Network Administrators can now use ADSI to automate many of the more common tasks, such as adding and removing both users and groups, setting permissions, and even managing printers across a distributed network.
While using the GUI interface remains an available option, being able to develop automated solutions for time consuming and repetitive tasks such as adding users to a new group has given the network administrator the ability to use their time in a cost-efficient fashion. Active Directory was introduced with Windows 2000, and runs on Windows 2000 and Windows Server 2003 domain controllers. It is important to note that ADSI client applications can run not only on Windows 2000 and Windows XP clients, but also on Windows 95, Windows 98 and Windows NT4.0 (SP6a), if you have the Active Directory Client Extensions installed. This section will examine the ways that you can automate some of the group management tasks faced by network administrators. Before you begin to work with ADSI there are a few basic concepts you should learn such as: Binding, Containers and Children, Getting and Setting Properties.Binding Objects must be bound to a computer, domain controller, printer, user or any other object in the directory structure in order to use ADSI properties and methods. After these objects have been bound object properties can be read or changed, and methods can be called that are applicable to the object type.
An ADSI ADsPath (or binding string) consists of a provider and a path. The provider is the part of the string that specifies what type of namespace is being bound to. With ADSI, there are four different types of providers:
• WinNT - Windows NT 4.0 PDCs and BDCs, Windows XP and Windows 2000/2003 not running Active Directory
• LDAP - LDAP servers, including Exchange 5.x, Windows 2000/2003 Active Directory
• NDS - Novell Directory Services servers
• NWCOMPAT - Novell Netware servers.
These provider names are case sensitive, and should be written exactly as noted above.
The path is exactly that-the path to a computer, object or user.
Look at the following example of a binding string:
Set objTarget = GetObject("WinNT://TotalRecall/TRPublicComputer/Deborah,user")
The Set objTarget script.
Notice that "WinNT:" is the provider; "//TotalRecall" is the domain; "/TRPublicComputer" is the computer; "/Deborah" is the object; and ", user" is the class identifier.
While the provider is mandatory, one can list all, some or none of the path. If no path is provided, ADSI will bind to the root of the namespace, and access will be allowed to all objects in the enterprise. Listing only the domain will bind to the root of the specified domain. Listing just the computer, or computer and class identifier, will bind to the local computer accounts.
Containers and Children
A container is an object that holds a collection of similar objects. For example, a domain is a container because it holds computers as members. A group is a container that holds users as members. All objects in a container have the same Class attribute, although they may not have associated ADsPath attributes.
A child of an object is an item one level below that object in the directory structure. A child is, in a sense, the flipside to a member. While an object's member must have the same class, but not necessarily a related ADsPath, an object's child does not need to have the same Class attribute as another child of the same object. It does, however, have a directly related ADsPath attribute. A domain's children are objects directly beneath the domain, such as users, global groups or computers.
These two relationships-container and member, object and child-define the two basic ways objects relate to each other in ADSI.
Two common administrative tasks are creating and deleting groups. It is through the IADs Container interface, used by all ADSI container objects, that we will accomplish the automation of these tasks. The properties of the IADs Container interface that are supported are:
• Filter - When enumerating a container's contents, the filter restricts the return to objects who's Class matches the classes listed in the property of the filter.
• Count - the number of objects in the container, or if a filter has been specified, the number of the objects of classes listed in the filter.
There are some methods that we will be using when working with groups that are specifically tied to the IADs Container interface:
• GetObject - Binds the directory item with the specified ADsPath to a named variable.
• Create - Creates a new object in the current container. The class must be specified.
• Delete - Removes an object from the current container. Again, the class must be specified.
• Movehere - Moves the object from its original location to the current container. The object MUST be in the same directory namespace; for example, you cannot move an object from a WinNT: namespace to a LDAP: namespace.
• Copyhere - Creates a copy of the object in the current container. The same namespace restrictions apply.
Getting and Setting Attributes: When looking at the ability to automate common network tasks, aside from creation and deletion, the most common use for any ADSI object is to be able to read data from it or modify the data contained in it. The data is contained in the object properties. Any ADSI object (except for the Namespaces object) employs the six properties of the IADs interface. These properties are:
• Name - the name of the object
• Class - the schema class name of the object
• GUID - the GUID (Globally Unique Identifier) that gives the object a unique identity
• ADsPath - a case-sensitive string used to uniquely identify the object's path in directory services
• Parent - the ADsPath name of the object's parent container
• Schema - the ADsPath of the object's schema class object.
Some of the methods we will be using on these properties are:
• Get - Retrieves the value of the property
• Put - Sets the value of the property
• GetInfo - Retrieves the values of the object's properties from directory services and places them in the local property cache
• SetInfo - Saves the changes made to the object's properties to directory services.
With that information, let's look at some ways to automate group tasks.
Jada Brock-Soldavini is author of book InsideScoop to Windows Server 2003 Certification Examination 70-290 Managing and Maintaining a Microsoft Windows ServerTM 2003 Environment. Jada works for the State of Georgia as a Network Services Administrator. She has co-authored or contributed to other numerous works pertaining to Microsoft Windows technologies. In her spare time she enjoys cooking, writing and reading anything that pertains to Network and Security technology. To buy my book, please visit www.totalrecallpress.com.
- Article Word Count: 1148
- |
- Total Views: 182
- |
- permalink