When the AD class is a structural class (e.g., the User class), the class maps to two WMI classes:
- One class prefixed with ads_ and implemented as a WMI abstract class (abstract qualifier set). For example, the User class will map to an ads_user WMI abstract class.
- One class prefixed with ds_ and implemented as a WMI dynamic instance class. For example, the User class maps to a ds_user dynamic instance class. A dymanic instance class has the provider qualifier, which specifies the provider that supports the class (in this case, Microsoft|DSLDAPInstanceProvider|V1.0).
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.
Register
