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 rootdirectoryLDAP 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 rootdirectoryLDAP 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 rootdirectoryLDAP 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 rootdirectoryLDAP 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 rootdirectoryLDAP 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.

When the AD class is a structural class (e.g., the User class), the class maps to two WMI classes:

Figure 1 shows the qualifiers for the ads_user class. You'll notice the presence of other qualifiers representing AD information defined in the schema and used to create the user class definition (e.g., governsID, lDAPDisplayName, objectClassCategory). In a similar fashion, the AD syntax is mapped to the WMI syntax with the help of qualifiers. Web Table 1 (http://www.winnetmag.com/windowsscripting, InstantDoc ID 41835) shows the syntax mapping and how AD values are converted to WMI-suitable values when necessary. The end result is that WMI exposes AD classes as WMI classes, as Web Figure 2 shows, and AD instances as WMI instances, with the correct syntax and value conversions. (There's one exception to the naming convention for the RootDSE Active Directory object. The RootDSE LDAP object available from any AD instance is represented by the RootDSE WMI class, which is an exact match between the names.)

When you create an AD user object, it's always created in a container. The default container for user objects is the Users container, but you can use any other supported container, such as an OU or a domain. In the AD schema, the containers that can hold user objects are defined with the possSuperiors and systemPossSuperiors attributes of the AD User class definition. These attributes reference the AD class (using their LDAP display names) representing the supported containers. For example, with the User class, you can find the domainDNS class for the Domain container and the builtinDomain class for the Builtin container in the systemPossSuperiors attribute. You can see that a relationship exists between the User class and the supported AD container class definition, but because the CIM repository doesn't have containers, WMI represents this relationship by implementing several associations. An association is a link that exists between two or more classes, which is realized by the creation of an Association class instance. The WMI AD providers implement this association with the ds_LDAP_Class_Containment association class.

After user objects are instantiated, their instances are contained in an existing container. The same kind of relationship exists between the instances and their containers but at the instance level instead of the class level. WMI represents this relationship at the instance level with the ds_LDAP_Instance_Containment association class.

Every WMI instance representing an AD object uses the object's Active Directory Service Interfaces (ADSI) path. The ADSI path is represented in the WMI class definition with the ADSIPath WMI property. For example, the ADSIPath property for a user object called "LISSOIR Alain" and located in the Users container of an AD domain called LissWare.Net will be LDAP://CN=LISSOIR Alain,CN=Users,DC=LissWare,DC=Net.

You can apply all this information about the User class and its WMI equivalents to any other class defined in the AD schema; the logic is always the same. Now that you understand how classes and objects are mapped within WMI, let's look at how to use WMI to leverage AD information to perform AD data monitoring.

Monitoring AD Group Memberships
Everyone knows the importance of AD group memberships. From a security point of view, some groups are more sensitive than others. For example, administrators don't want to see just anyone added to the Enterprise Admins group. By using the WMI AD provider and a WMI Query Language (WQL) event query, you can receive a WMI event notification when a modification is made to a group such as the Enterprise Admins group. You can monitor any AD object; you just need to select the WMI class corresponding to the AD class of the object you want to monitor, which is why understanding the mapping that exists between AD and WMI is so important.

The following code illustrates a simple WQL event query that you can use to monitor the Enterprise Admins group in AD:

Select * From  __InstanceModificationEvent  Within 10  Where TargetInstance ISA  'ds_group' AND  TargetInstance.ds_name=  'Enterprise Admins'

This WQL event query requests a notification within 10 seconds for any modifications made to an instance of the Enterprise Admins group. I used this query in a script I created to monitor Windows group modifications, which Listing 1 shows. You can download the script and the helper functions it uses from the Windows Scripting Solutions Web site. Go to http://www.winnetmag.com/windowsscripting, enter InstantDoc ID 41835 in the InstantDoc ID box, then click Download the Code. The script uses this WQL event query with command-line parameters to specify the groups for which you want to monitor modifications. When a WMI notification is received, the script sends an HTML email alert. The sample script is an immediate application of the WMI AD providers and the WMI monitoring capabilities. You must run the script in the Administrator security context, with the groups you want to monitor listed on the command line separated by a space. The command's syntax is

GroupMonitor.wsf "GroupName1"["GroupName2"] ["GroupNameN"][/Machine:value] [/User:value][/Password:value]

The GroupName1 to GroupNameN values in the command-line definition represent the list of groups to monitor. The /Machine switch represents the name of the domain controller (DC) to which WMI should connect (the default is localhost). The /User switch specifies the username to use for the WMI connection, and the /Password switch specifies its associated password. For example, to monitor the Enterprise Admins and Domain Admins groups for modifications from a DC named ServerA.LissWare.Net, you'd use the command

GroupMonitor.Wsf "Enterprise  Admins" "Domain Admins"  /Machine:"ServerA.LissWare.Net" 

You can use any server as long as the selected server is part of an AD forest. Therefore, if you select a DC, the detection of a group modification will occur either when the modification is made on that server or when a modification made on any other DC that's part of the selected server domain is replicated to the selected server. To determine which DC is the origin of the group change, you need to analyze AD metadata replication. Unfortunately, you can't use WMI to access this information. Some tools, such as repadmin.exe (included in the Windows Support Tools) can display the origin of an AD object modification. However, the AD metadata auditing process is outside the scope of this article. Instead, let's look at leveraging the WMI interface in a sample script.

Scripting Group Monitoring
The script to monitor Windows group modifications starts with command-line parameter definitions, as the code at callout A in Listing 1 shows. The script then includes a series of helper functions to handle some specific tasks during the script's execution. The helper functions, which callout B references, are

Next, the script creates a series of WMI objects, as the code at callout C shows. These objects establish the WMI connection to the rootdirectoryLDAP namespace and submit the WQL event query. By default, the script creates an objWMIdateTime object from the SWbemDateTime WMI COM object. This COM object, which is available only under Windows Server 2003 and Windows XP, converts the Distributed Management Task Force (DMTF) datetime format to a readable string. (More information about the DMTF datetime format is available at http://msdn.microsoft.com/library/en-us/wmisdk/wmi/date_and_time_format.asp.) If you must run the code under Win2K, you must change the line