4.5 The WMI Security provider

4.5 The WMI Security provider

Since WMI implements some security scripting capabilities, it is interesting to examine closely the WMI Security provider capabilities. Available under Windows NT, Windows 2000, Windows XP, and Windows Server 2003, and registered in the Root\CIMv2 namespace, the WMI Security provider is implemented as an instance and a method provider. It allows you to retrieve or change security settings that control ownership, auditing, and access rights to the files, directories, and shares. Table 4.5 summarizes the WMI Security provider capabilities.

Table 4.5: The Security Provider Capabilities

Provider Name	Provider Namespace	Class Provider	Instance Provider	Method Provider	Property Provider	Event Provider	Event Consumer Provider	Support Get	Support Put	Support Enumeration	Support Delete	Windows server 2003	Windows XP	Windows 2000 Server	Windows 2003 Professional	Windows NT 4.0
WMI security Provider
SECRCW32	Root/CIMV2		X	X				X	X	X	X	X	X	X	X	X

The WMI Security provider supports several WMI classes representing the security settings on files, folders, and shares. These classes are listed in Table 4.6.

Table 4.6: The Security Providers Classes

Name	Type	Comments
Win32_Ace	Dynamic	Specifies an access control entry (ACE). An ACE grants permission to execute a restricted operation, such as writing to a file or formatting a disk. ACEs particular to WMI allow logons, remote access, method execution, and writing to the WMI repository.
Win32_LogicalFileSecuritySetting	Dynamic	Represents security settings for a logical file.
Win32_LogicalShareSecuritySetting	Dynamic	Represents security settings for a logical file.
Win32_SecurityDescriptor	Dynamic	Represents a security descriptor structure.
Win32_SID	Dynamic	Represents an arbitrary security identifier (SID). This property cannot be enumerated.
Win32_Trustee	Dynamic	Specifies a trustee. Either a name or a SID (byte array) can be used.
Win32_AccountSID	Association	Relates a security account instance with a security descriptor instance.
Win32_LogicalFileAccess	Association	Relates the security settings of a file/directory and one member of its DACL.
Win32_LogicalFileAuditing	Association	Relates the security settings of a file/directory and one member of its SACL.
Win32_LogicalFileGroup	Association	Relates the security settings of a file/directory and its group.
Win32_LogicalFileOwner	Association	Relates the security settings of a file/directory and its owner.
Win32_LogicalShareAccess	Association	Relates the security settings of a share and one member of its DACL.
Win32_Logical_ShareAuditing	Association	Relates the security settings of a share and one member of its SACL.
Win32_SecuritySettingOfLogicalFile	Association	Represents security settings of a file or directory object.
Win32_SecuritySettingOfLogicalShare	Association	Relates the security settings of a share object with the object.

Since the WMI Security provider retrieves security settings from the file system, it is clear that an association exists between the CIM representation of the file system object (i.e., file, directory, or share) and its security settings CIM representation. We can see this association in Figure 4.13A, where the CIM_LogicalFile class is associated with the Win32_LogicalFileSecuritySetting class by the Win32_SecuritySettingOfLogicalFile Association class. Remember that the CIM_LogicalFile is a superclass for the CIM_DataFile and CIM_Directory classes (see Chapter 2, Figure 2.12, "The CIM_LogicalFile class and its child classes." It is interesting to note that the Win32_LogicalFileSecuritySetting class represents the exact same file system object as the CIM_LogicalFile superclass and that both classes use the same key property to locate their corresponding instances, which is the path of the file or the folder they represent. However, the set of properties exposed by both classes is different. Basically, the CIM_LogicalFile class exposes information purely related to the file system settings (i.e., creation date, size, attribute settings, etc.), while the Win32_LogicalFileSecuritySetting class represents some security settings (control flags, owner permissions). You can use WMI CIM Studio or the LoadCIMInXL.Wsf script shown in Sample 4.32 in the appendix to examine and compare the properties exposed by both classes.

As mentioned before (see Figure 4.11), a security descriptor contains a Discretionary ACL (to define access settings) and a System ACL (to define auditing settings). Therefore, a file system object has relationships with the Win32_SID class representing the granted entities at the Discretionary ACL and System ACL levels. These relationships are represented in Figures 4.13B and 4.13C.

Figure 4.13: The Win32_LogicalFileSecurity Setting class associations.

Figure 4.14: The owner and group associations.

We also mentioned that a security descriptor contains an owner and a group. This implies that a file system object also has relationships with the WMI classes representing the owner and the group coming from the security descriptor. These relationships are represented in Figure 4.14A for the owner and Figure 4.14B for the group. Since a user and a group correspond to a security principal, the Win32_LogicalFileSecuritySetting class representing the file system object is associated with the Win32_SID class, which represents the SID of the owner or the group.

To resolve the SID to an account, the Win32_SID class is associated with the Win32_Account class (Figure 4.15) with the Win32_AccountSID association class.

Figure 4.15: The Win32_Account class and the Win32_SID class association.

Everything that applies for a file or a directory is also applicable for a share. The logic is exactly the same. However, since a share doesn't have any owner or group, the Win32_LogicalShareSecuritySetting class is only associated with the Win32_Share class, which represents the share instance, and with the Win32_SID class, which represents the granted entities at the Discretionary ACL level. These relationships are represented in Figure 4.16.

Figure 4.16: Win32_LogicalShareSecuritySetting class associations.

By using all these relationships, we decipher the security descriptor content by using the abstraction layer of the CIM repository. However, at no time do we look at the security descriptor directly. We always look at the security descriptor information through the relations defined in the CIM repository between different classes representing some items of its logical structure.

Another solution is to retrieve a security descriptor in a Win32_SecurityDescriptor instance. This solution is the best approach, because it provides a closer look at the security descriptor content. Moreover, this technique allows the implementation of a deciphering technique applicable to any security descriptor (i.e., file, Active Directory, registry key, etc.) and therefore applicable to any security descriptor access method.