WMI Security Settings

Article
10/22/2009

Microsoft® Windows® 2000 Scripting Guide

The second, and typically optional, part of WMI monikers is the security settings component. The security settings component has been a source of confusion for many system administrators. This is primarily because of the impersonationLevel setting, which behaves differently depending on the version of WMI installed on a target computer.

The optional security settings component lets you specify several different security settings that are used to connect to and communicate with WMI. The security settings you can control as part of the moniker string include:

Impersonation level, expressed as "winmgmts:{impersonationLevel=Value}".
Authentication level, expressed as "winmgmts:{authenticationLevel=Value}".
Authenticating authority, expressed as "winmgmts:{authority=ntlmdomain:DomainName}" or "winmgmts:{authority=kerberos:DomainName\ServerName}".
Privileges to grant or deny, expressed as "winmgmts:{(Security, !RemoteShutdown)}".

Impersonation Level

The first two settings, impersonationLevel and authenticationLevel, are not specific to WMI but rather are derived from DCOM, which WMI uses to access the WMI infrastructure on remote computers. In the context of WMI, impersonation governs the degree to which your script will allow a remote WMI service to carry out tasks on your behalf. DCOM supports four levels of impersonation: Anonymous, Identify, Impersonate, and Delegate. These levels are defined in Table 6.6.

Table 6.6 DCOM Impersonation Levels

Value	Description
Anonymous	Hides the credentials of the caller. WMI does not actually support this impersonation level; if a script specifies impersonationLevel=Anonymous, WMI will silently upgrade the impersonation level to Identify. This is in some ways a meaningless exercise, however, because scripts using the Identify level are likely to fail.
Identify	Enables objects to query the credentials of the caller. Scripts using this impersonation level are likely to fail; the Identify level typically lets you do no more than check access control lists. You will not be able to run scripts against remote computers using Identify.
Impersonate	Enables objects to use the credentials of the caller. It is recommended that you use this impersonation level with WMI scripts. When you do so, the WMI script will use your user credentials; as a result, it will be able to perform any tasks that you are able to perform.
Delegate	Enables objects to permit other objects to use the credentials of the caller. Delegation allows a script to use your credentials on a remote computer and then enables that remote computer to use your credentials on another remote computer. While you can use this impersonation level within WMI scripts, you should do so only if necessary because it might pose a security risk. You cannot use the Delegate impersonation level unless all the user accounts and computer accounts involved in the transaction have all been marked as Trusted for delegation in Active Directory. This helps minimize the security risks. Although a remote computer can use your credentials, it can do so only if both it and any other computers involved in the transaction are trusted for delegation.

As noted, Anonymous impersonation hides your credentials and Identify permits a remote object to query your credentials, but the remote object cannot impersonate your security context. (In other words, although the remote object knows who you are, it cannot "pretend" to be you.) WMI scripts accessing remote computers using one of these two settings will generally fail. In fact, most scripts run on the local computer using one of these two settings will also fail.

Impersonate permits the remote WMI service to use your security context to perform the requested operation. A remote WMI request that uses the Impersonate setting typically succeeds, provided your credentials have sufficient privileges to perform the intended operation. In other words, you cannot use WMI to perform an action (remotely or otherwise) that you do not have permission to perform outside WMI.

Setting impersonationLevel to Delegate permits the remote WMI service to pass your credentials on to other objects and is generally considered a security risk.

The confusion surrounding the impersonationLevel setting has to do with the default impersonation behavior, which differs based on the version of WMI installed on the target computer. WMI versions prior to version 1.5 use Identify as the default impersonationLevel setting. This forces WMI scripts that connect to remote computers to include impersonationLevel=Impersonate as part of any moniker string. With the release of WMI version 1.5 in Windows 2000, Microsoft changed the default impersonationLevel setting to Impersonate. This is a registry-based setting that can be managed by means of the following entry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\Scripting\Default Impersonation Level

If your WMI scripts connect only to computers with WMI version 1.5 or later, the change eliminates the need to explicitly set impersonationLevel. However, by omitting impersonationLevel=Impersonate, scripts accessing computers with an earlier release of WMI fail. For backward and potentially forward compatibility, you should always explicitly set impersonationLevel.

Authentication Level

The authenticationLevel setting enables you to request the level of DCOM authentication and privacy to be used throughout a connection. Settings range from no authentication to per-packet encrypted authentication. The seven permissible moniker settings include Default, None, Connect, Call, Pkt, PktIntegrity, and PktPrivacy, each described in Table 6.7. Specifying an authenticationLevel is more of a request than a command because there is no guarantee that the setting will be honored. For example, local connections always use authenticationLevel=PktPrivacy.

Table 6.7 DCOM Authentication Levels

Value	Description
None	Does not use any authentication. All security settings are ignored.
Default	Uses a standard security negotiation to select an authentication level. This is the recommended setting because the client involved in the transaction will be negotiated to the authentication level specified by the server. DCOM will not select the value None during a negotiation session.
Connect	Authenticates the credentials of the client only when the client tries to connect to the server. After a connection has been made, no additional authentication checks take place.
Call	Authenticates the credentials of the client only at the beginning of each call, when the server receives the request. The packet headers are signed, but the data packets exchanged between the client and the server are neither signed nor encrypted.
Pkt	Authenticates that all data packets are received from the expected client. Similar to Call; packet headers are signed but not encrypted. Packets themselves are neither signed nor encrypted.
PktIntegrity	Authenticates and verifies that none of the data packets transferred between the client and the server have been modified. Every data packet is signed, ensuring that the packets have not been modified during transit. None of the data packets are encrypted.
PktPrivacy	Authenticates all previous impersonation levels and signs and encrypts each data packet. This ensures that all communication between the client and the server is confidential.

Authority Setting

The authority setting allows you to specify the security package that is used to authenticate your WMI connection. You can specify standard NTLM or Kerberos authentication. To use NTLM, set the authority setting to "authority=ntlmdomain:DomainName" where DomainName identifies a valid NTLM domain name. To use Kerberos, specify "authority=kerberos:DomainName\ServerName". You cannot include the authority setting in WMI monikers that access the local computer.

Privileges

The final security setting is privilege overrides. This setting allows you to grant or revoke privileges as part of a WMI moniker string. For example, you might grant yourself the Security privilege to successfully query the Windows NT/2000 Security Log. Privileges you can grant or revoke are shown in Table 6.8.

Table 6.8 Privileges and Descriptions

Privilege	Description
CreateToken	Required to create a primary token.
AssignPrimaryToken	Required to assign the primary token of a process.
LockMemory	Required to lock physical pages in memory.
IncreaseQuota	Required to increase the quota assigned to a process.
MachineAccount	Required to create a computer account.
Tcb	Identifies its holder as part of the trusted computer base. Some trusted, protected subsystems are granted this privilege.
Security	Required to perform a number of security-related functions, such as controlling and viewing audit messages. This privilege identifies its holder as a security operator.
TakeOwnership	Required to take ownership of an object without being granted discretionary access. This privilege allows the owner value to be set only to those values that the holder might legitimately assign as the owner of an object.
LoadDriver	Required to load or unload a device driver.
SystemProfile	Required to gather profiling information for the entire system.
SystemTime	Required to modify the system time.
ProfileSingleProcess	Required to gather profiling information for a single process.
IncreaseBasePriority	Required to increase the base priority of a process.
CreatePagefile	Required to create a paging file.
CreatePermanent	Required to create a permanent object.
Backup	Required to perform backup operations.
Restore	Required to perform restore operations. This privilege lets you set any valid user or group SID as the owner of an object.
Shutdown	Required to shut down a local computer.
Debug	Required to debug a process.
Audit	Required to generate audit-log entries.
SystemEnvironment	Required to modify the nonvolatile RAM of systems that use this type of memory to store configuration information.
ChangeNotify	Required to receive notifications of changes to files or directories. This privilege also causes the system to skip all traversal access checks. It is enabled by default for all users.
RemoteShutdown	Required to shut down a computer using a network request.
Undock	Required to remove a computer from its docking station.
SyncAgent	Required to synchronize directory service data.
EnableDelegation	Required to enable computer and user accounts to be trusted for delegation.

In addition to granting privileges, you can also disable privileges by prefacing the privilege name with an exclamation mark (!).

Note

Disabling a privilege means that the script, or anything running in the script process, cannot carry out a particular action. For example, if you disable the Shutdown privilege, neither the script nor any anything running in the script process can shut down the computer. This provides an additional layer of security: It prevents the script from doing anything you do not want it to do.

The privileges to be enabled on a connection are specified by including the name of the privilege within parentheses. If the privilege is to be disabled, it is preceded by an exclamation mark. The following moniker string enables the LockMemory privilege and disables the IncreaseQuota privilege:

Set objSWbemServices = GetObject _
    ("winmgmts:{impersonationLevel=impersonate,(LockMemory, !IncreaseQuota)}")

Granting privileges within a script does not confer those privileges upon the user. For example, suppose you try to run a script that includes the Shutdown privilege. If you do not already have the Shutdown privilege, the script will fail; as is always the case with WMI, you are not allowed to use a script to carry out a task that you would otherwise not be able to perform. To carry out a task that requires a privilege such as Shutdown or Backup, two things must be true:

The script must specify the privilege in the connection string.
You must already possess the privilege.

Including Security Settings in Moniker Strings

The general format you use when including security settings in WMI monikers is as follows:

Set objSWbemServices = GetObject("winmgmts:"                  & _
"{SecuritySetting1=Value,"   & _
"SecuritySetting2=Value,"    & _
"(Privilege1,!Privilege2)}")

Here you can see that the security settings component immediately follows the colon in the "winmgmts:" prefix and is enclosed inside braces. Multiple settings must be comma delimited, and override privileges are further separated inside parentheses and also comma delimited.

Partager via