4.3 WMI and Active Server Page (ASP)

4.3 WMI and Active Server Page (ASP)

Most of the scripting techniques we learned in previous chapters are applicable to Active Server Page (ASP) scripts. However, to run a WMI script from an Active Server Page (ASP) script, it is important to note two important points, where security is the main aspect to consider when developing WMI-ASP solutions. This is why we cover this information in this chapter. The two points to remember are:

1. The asynchronous scripting technique cannot be used within an ASP script, because the VBScript CreateObject statement does not support the connection to a sink routine, such as the CreateObject statement used with WSH (i.e., Wscript.CreateObject statement).

2. Regarding the security settings: Some parameters must be carefully considered regarding the platform the ASP script is run from.

4.3.1 Authentication settings

Authentication settings are as follows:

• Security configuration under Windows NT 4.0: To run a WMI-ASP script under the Windows NT 4.0 platform, a registry key must be modified to grant the Scripting API all of the permissions of the account running Internet Information Services (IIS). If not, then the browser client must contain the necessary permissions and security settings. The registry key to be modified is located in the HKLM\Software\Microsoft\WBEM\Scripting registry hive, where the DWORD value Enable for ASP must be set to 1 (see Figure 4.2). Of course, changing this registry key is granting all privileges to the account running IIS, which represents some danger, since you will be granting all privileges without any further considerations. We will see later in this section that different approaches can be used to minimize such a risk.

  
  Figure 4.2: Granting all Scripting API permissions to the IIS account.

• Security configuration under Windows 2000 and above: Under Windows 2000 and above, there are several ways to customize the IIS security. Of course, since a WMI-ASP script can perform some critical tasks, it is important to request the user to authenticate. Therefore, the recommended approach is to disable the anonymous access for the authentication protocol used. As we will see, the authentication method used will impact the WMI security configuration. Under Windows 2000 and above, you have a choice:

  • The Windows Integrated Authentication: As we can see in Figure 4.3, the Windows Integrated Authentication (WIA) is enabled for ASP, while the anonymous access is disabled. This security setting doesn't require any specific WMI security configuration. Enabling the Windows Integrated Authentication implies the use of Kerberos or NTLM.

    
    Figure 4.3: Setting the Windows Integrated Authentication.

  • Passport or digest authentication: The passport or digest authentications (see Figure 4.4) require that the CIM repository namespace Remote Enable privilege be granted to accounts authenticated by one of these protocols, since the user access is treated as a remote user access. For instance, creating a Windows Security Global Group and including the users authorized to remote access a selected namespace is a good practice (see Figure 4.5). Note that with the digest authentication, passwords are still wrapped in a password encryption key, but they are not hashed.

    
    Figure 4.4: Setting the passport or digest authentication.

    
    Figure 4.5: Enabling remote access for remote users.

  • Anonymous and basic authentications: For obvious security reasons, it is recommended not using the anonymous and basic authentications, which are a clear-text authentication without encryption. Obviously, anonymous basically means "no authentication," which is not a recommended approach. However, the Remote Enable privilege is not required for these two authentication methods if they are used.

4.3.2 Customizing IIS 5.0 and above

Regarding the security configuration under Internet Information Server (IIS) 5.0 and above, the authentication settings previously reviewed are not the only things to consider when setting up an IIS server running WMI-ASP scripts. Actually, the location of the authentication-level definitions is also very important. IIS can enforce the authentication at the Web Server level, the virtual directory, or the file level (see Figure 4.6).

Figure 4.6: The three IIS locations where authentication can be defined.

Moreover, for WMI-dedicated security, it is a good practice to create an independent directory structure, which contains all HTML pages and WMI-ASP scripts (see Figure 4.7). This organization allows you to customize specific security settings independently from the rest of the server security. For example, Figure 4.7 shows that the WMI-ASP Script folder is not under the WWWRoot folder, which allows the creation of specific access rights on the file system to access the WMI-ASP scripts.

Figure 4.7: The isolated file system directory from the WWWRoot folder.

In order to increase the WMI-ASP script security, it is a good idea to disable the anonymous access and enable the Windows Integrated Authentication (WIA), as shown in Figure 4.3.

However, there are some situations where anonymous access is required. By default, Web clients accessing IIS are using the IIS logon identity (i.e., IUSR_<machine_name>). Therefore, it is a good idea for a more secure approach to create a new interactive user account. This allows you to define security settings that suit the WMI-ASP Scripts virtual Web site requirements without impacting the overall IIS security (unless you modify the security at the server level). From the directory security tab of the virtual directory properties, you can define the new logon identifier and enter the appropriate password in the authentication methods user interface, as shown in Figure 4.8.

Figure 4.8: Enabling anonymous access with IIS.

Note that to secure applications, IIS 5.0 also has the ability to isolate applications in different security contexts. IIS 6.0 uses the concept of application pools to implement the same functionality. You can refer to the IIS documentation for more information about these security features.

Of course, since a different user account for the virtual Web site identity is used, you must make sure that this user account has access to the CIM repository accessed by the WMI-ASP script. For instance, if the WMI-ASP script uses the Win32_Service class located in the Root\CIMv2 namespace, the WMI-ASP-Script user must be enabled and have remote access granted on that namespace. Even if everything is executed locally, the remote access must be granted, since the user account is treated by IIS as a remote user access (see Figure 4.9).

Figure 4.9: Ensuring WMI CIM repository access for the WMI-ASP dedicated account.

From a scripting point of view, developing WMI logics in ASP pages is the same as developing WMI logics in WSH (the exception, as mentioned in the beginning of this section, is that asynchronous calls are not supported). Of course, since the scripting environment is different, the output of information must be handled in respect to the ASP context and must make use of HTML tags.

Sample 4.1 shows an example of an ASP script listing the state of all Windows services in an HTML page (see Figure 4.10). To get this ASP script running, make sure that the IIS security settings are set accordingly, as explained previously, in regard to the operating system and IIS version used.

Figure 4.10: Viewing all Win32_Service instance states from the Web.

Sample 4.1: Viewing all Win32_Service instances with their status from a WMI-ASP script

  1:<%@ LANGUAGE="VBSCRIPT"%>  2:  3:<html>  4: <head>  5:  <title>WMI Service Monitor</title>  6: </head>  7:  8: <body>  9: <% 10:   Dim objWMIServices 11:   Dim objWMIInstance, objWMIInstances 12: 13:   Set objWMILocator = CreateObject("WbemScripting.SWbemLocator") 14:   Set objWMIServices = objWMILocator.ConnectServer(cComputerName, cWMINameSpace) 15: 16:   If Err.Number = 0 Then 17:      Set objWMIInstances = objWMIServices.InstancesOf ("Win32_Service") 18: %> 19:      <table BORDER="1"> 20:      <tr> 21:       <th>Name</th> 22:       <th>Service State</th> 23:       <th>Service Start Mode</th> 24:      </tr> 25: <% 26:      For Each objWMIInstance in objWMIInstances 27:          If objWMIInstance.Started = False And objWMIInstance.StartMode = "Auto" Then 28: %> 29:             <tr> 30:              <td> 31:               <font color="#FF0000"><b> 32:               <%=objWMIInstance.DisplayName%> 33:               </b></font> 34:              </td> 35:              <td> 36:               <font color="#FF0000"><b> 37:               <%=objWMIInstance.State%> 38:               </b></font> 39:              </td> 40:              <td> 41:               <font color="#FF0000"><b> 42:               <%=objWMIInstance.StartMode%> 43:               </b></font> 44:              </td> 45:             </tr> 46: <% 47:          Else 48:             If objWMIInstance.Started = True Then 49: %> 50:             <tr> 51:              <td> 52:               <font color="#008000"> 53:               <%=objWMIInstance.DisplayName%> 54:               </font> 55:              </td> 56:              <td> 57:               <font color="#008000"> 58:               <%=objWMIInstance.State%> 59:               </font> 60:              </td> 61:              <td> 62:               <font color="#008000"> 63:               <%=objWMIInstance.StartMode%> 64:               </font> 65:              </td> 66:             </tr> 67: <% 68:             Else 69: %> 70:             <tr> 71:              <td> 72:               <%=objWMIInstance.DisplayName%> 73:              </td> 74:              <td> 75:               <%=objWMIInstance.State%> 76:              </td> 77:              <td> 78:               <%=objWMIInstance.StartMode%> 79:              </td> 80:             </tr> 81: <% 82:             End If 83:          End If 84:      Next 85: %> 86:      </table> 87: <% 88:   Else 89: %> 90:      <table> 91:       <tr> 92:        <td>Error - <%=Err.description%>, <%=Err.number%>, <%=Err.Source%></td> 93:       </tr> 94:      </table> 95: <% 96:   End If 97:  %> 98: </body> 99:</html>