In early 2002, Microsoft took a huge security initiative to make the Windows platform more secure. This initiative
One of the WMI COM/DCOM modifications impacts the WMI asynchronous scripting. Actually, Microsoft added one new feature under Windows Server 2003 to enforce security of the WMI asynchronous calls.
The security descriptor set on a CIM repository namespace can't be set to NULL.
The ADSI WMI Extension is removed under Windows Server 2003.
A new built-in group, called the Windows Authorizations Access
To understand the impact of the security initiative on the asynchronous scripting, it is necessary to look at some of the mechanisms involved at the COM/DCOM level when WMI asynchronous operations or events are involved. However, we will not delve into the details of the COM/DCOM interfaces to explain this. Instead, we will give a high-level overview of the mechanism and how a script making use of an asynchronous call can be affected.
Generally speaking, when a WMI client application
Figure 4.36: A WMI client application performing an asynchronous operation.
When working at the COM/DCOM level, the WMI client application has control of the authentication level for the
outgoing calls (see the first book,
Understanding WMI Scripting,
Chapter 4, sections 4.3.3, "The security settings of the moniker," and 4.4.1, "Establishing the WMI connection"). In such a case,
retrieves the WMI client security settings when called, and always attempts to call back the client sink routine with the same authentications level (see Figure 4.36, arrow 2). For obvious security reasons, it is always recommended that
Figure 4.37: A WMI client application performing an asynchronous operation where UnSecApp.Exe is involved.
When a WMI script invokes an asynchronous operation, the WMI COM underlying mechanism starts
in a separate process on the client (see Figure 4.37, arrow 1). Once started,
passes its own sink to the client.
When using asynchronous operations or event notifications in this implementation (Windows NT 4.0, Windows 2000, and Windows XP), it is recommended you take some
If you can implement a logic that does not use asynchronous calls for your scripts, consider this option as the best option from a security standpoint. Therefore, you should always try to consider a synchronous or semisynchronous scripting technique when possible.
If you must
Despite the previous recommendations, if you must perform some critical operations in the event sink in an administrative security context, as we will discuss in the next section, under Windows Server 2003 you can activate a
Under Windows Server 2003, Microsoft created a wrapper for UnSecApp.Exe. This wrapper plays the role of a security broker between the WMI client and the WinMgmt.Exe to validate the callbacks executed on the UnSecApp.Exe sink.
However, by default, this wrapper is disabled to ensure a backward compatibility with the WMI asynchronous applications previously developed. If the environment requires a stronger security, it is possible to enable the wrapper in two ways:
By programming: This is only possible for the WMI COM/DCOM applications. In such case, the wrapper behavior can be determined by application, which means that one WMI client application could require authenticating the callbacks, while another will run with the default settings (Everyone).
By changing a registry key: This is the technique to use for the WMI scripts, because there is no way from the scripting environment to determine the wrapper behavior. It is important to note that if the registry key is modified to enable the wrapper to only accept the authenticated calls, the setting is global for all applications (see Figure 4.38). There is no granularity available.
Figure 4.38: The registry activating the new lockdown mechanism of Windows Server 2003.
The registry key to change is located in the registry hive HKLM\SOFTWARE\Microsoft\WBEM\CIMOM, where the
value must be changed as
To allow anonymous calls (default), the UnsecappAccessControlDefault value must be set to 0.
To allow authenticated calls (global setting), the UnsecappAccessControlDefault value must be set to 1. Althought the default registry key value is set to 0, it is recommended to set it to 1 if you plan to use asynchronous calls in your applications or scripts.
Once enabled, the wrapper intercepts every callback to
in order to verify the identity of the component performing the callback, which should normally be
(see Figure 4.39). Actually, the wrapper
Figure 4.39: A WMI client application performing an asynchronous operation where UnSecApp.Exe is involved and when the Windows Server 2003 lockdown mechanism is activated.
As long as the script runs in an authenticated security context, the activation doesn't affect the operation. However, if the callback is delivered under a different identity, the callback will not be returned to the sink routine, and UnSecApp.Exe will place an entry into the event log. However, the activation of the registry key setting could only affect applications in pre-Windows 2000 environments due to the lack of LocalSystem identity.
LocalSystem in a Kerberos environment has an identity in an Active Directory environment like any other users. For instance, this allows the Windows services to run in the machine security context rather than a specific domain
When creating a namespace in the CIM repository, the only element of information required is the name of the namespace, since the
If by any chance the security descriptor is set to null on a namespace, the namespace will inherit the security of the parent namespace, since the "non-inheritance" option is not set. However, by eliminating the ability to set a null security descriptor, Microsoft wants to prevent
In Chapter 5 of the first book, Understanding WMI Scripting, we see how the ADSI WMI Extension can be used from scripts. This extension is available under Windows NT 4.0 (if ADSI and WMI are installed), Windows 2000, and Windows XP. Under Windows Server 2003 with the security push initiative, this extension has been removed from the Operating System. At writing time, the availability of this extension as a separate download is still under discussion at Microsoft. Actually, Microsoft decided to remove this extension from the Operating System for two reasons:
One of the drivers during the security push was to leave only enabled
Although the ADSI WMI Extension is not subject to any particular security thread, Microsoft decided to remove it, since it requires high-level privileges to run.
The Windows Authorizations Access Group (WAAG) is a new built-in security group introduced in Windows Server 2003. The members of this group are allowed to look up group membership for a particular user. For example, the idea is that user "Alain Lissoir" should not be able to look up other users in the Active Directory and find out that they are
Developing WMI Solutions: A Guide to Windows Management Instrumentation
Microsoft Windows Scripting with WMI: Self-Paced Learning Guide
Windows Internals, Part 1: Covering Windows Server 2008 R2 and Windows 7
Understanding WMI Scripting: Exploiting Microsoft's Windows Management Instrumentation in Mission-Critical Computing Infrastructures (HP Technologies)