Using WMI to Monitor AD

Monitoring a Windows environment is a crucial security task for every network administrator. One vital monitoring task is looking for modification of sensitive information in Active Directory (AD). In this first article of a two-part series that will demonstrate how to leverage Windows Management Instrumentation (WMI) monitoring capabilities to track modifications made in AD, I explain how to track AD group modifications.

The AD WMI Providers
Windows 2000 Server and later versions include three new AD WMI providers: Microsoft|DSLDAPClassProvider|V1.0, Microsoft|DSLDAPInstanceProvider|V1.0, and Microsoft|DSLDAPClassAssociationsProvider|V1.0. These providers give WMI consumers (i.e., any application that uses WMI management information) access to AD. WMI consumers include Windows Script Host (WSH), Windows .NET Framework applications, enterprise-management software, or any other COM-compliant application. You'll find the three WMI providers in the root\directory\LDAP Common Information Model (CIM) repository namespace.

An understanding of the AD schema is a great asset when working with the AD WMI providers because WMI reflects the AD schema's logical structure. For readers with little or no AD schema experience, I recommend you learn more about the subject by reading "Diving into the AD Schema," September 2001, InstantDoc ID 21839.

The first of the three new WMI providers, Microsoft|DSLDAPClassProvider|V1.0, maps the AD classes defined in the AD schema to corresponding WMI classes. This provider is called a class provider because it exposes only classes to WMI. The second provider, Microsoft|DSLDAPInstanceProvider|V1.0, is responsible for mapping instances of AD objects. An instance is the actual representation of an object created with the definition that the class provides. For example, when you create a user in AD, Microsoft|DSLDAPInstanceProvider|V1.0 maps the user instance to a corresponding WMI user instance. The role between these two WMI providers is clearly distributed: One provider maps the AD classes to WMI classes, and the other provider maps AD instances to WMI instances. The class mapping is dynamic, which means that each time a WMI consumer accesses the root\directory\LDAP namespace, the class provider dynamically recreates the set of exposed classes within the namespace. Therefore, if you extend the AD schema, the resulting set of new classes will be automatically mapped in the root\directory\LDAP namespace.

The third provider—Microsoft|DSLDAPClassAssociationsProvider|V1.0—maps the relationships that exist between AD containers (e.g., domain object container, organizational unit—OU—object container) and the objects that these containers contain (e.g., OU; computer, user, or group objects). Just as the instance provider is related to the class provider, the association provider is related to the instance and class providers by exposing the relationships between instances of objects. All three providers act as an interface between the WMI standards and AD standards. Now that you know about the roles of each provider, let's examine the implementation of WMI's representation of AD.

Understanding the WMI AD Representation
When performing the AD-to-WMI mapping, which mirrors classes and instances from AD into the root\directory\LDAP CIM repository namespace, the AD providers follow naming rules to preserve the relationships that exist between the AD classes and instances. Let's look at an example for the AD User class. As defined in the AD schema, the AD User class is created from a class hierarchy starting from a root class called Top, as Web Figure 1 (http://www.winnetmag.com/windowsscripting, InstantDoc ID 41835) shows. To obtain the User class, the AD schema defines several subclasses. This subclass creation is called a derivation of classes, in which the parent class is called a superclass. First, the Person class is derived from the Top (parent) class. Next, the organizationalPerson class is derived from the Person class, then the User class is derived from the organizationalPerson class. Each subclass inherits the set of AD attributes from the superclass.

In AD, the User class is defined as a structural class, which allows the creation of user instances from it. However, the Top, Person, and organizationalPerson classes are abstract classes; they're used as parent templates to create their respective subclasses, but you can't create instances of an abstract class. As I mentioned earlier, AD classes are mapped to their equivalent WMI classes in the root\directory\LDAP namespace. In the case of an abstract class, the WMI equivalent abstract class always uses the Lightweight Directory Access Protocol (LDAP) display name of the AD class with a ds_ prefix. For example, the AD organizationalPerson class has a corresponding ds_organizationalPerson WMI class. Because this AD class is an abstract class, the WMI equivalent class is also an abstract class for which the abstract qualifier is set. A qualifier is an attribute of the WMI class definition. You can see qualifiers by using WMI CIM Studio, which you can download from http://download.microsoft.com/download/.netstandardserver/install/v1.1/nt5xp/en-us/wmitools.exe. Launch the program, select the class, right-click in the window showing the class properties, and select Object Qualifiers.

   Previous  [1]  2  3  4  5  Next