Authentication, Impersonation and Privileges

So, you want to use a new WMI namespace you have discovered that lets you work with IIS.

PS> Get-WmiObject -Namespace ‘root\webadministration’ -List -ComputerName web01
Get-WmiObject : Access denied
At line:1 char:14
+ Get-WmiObject <<<<  -Namespace ‘root\webadministration’ -List -ComputerName web01
    + CategoryInfo          : NotSpecified: (:) [Get-WmiObject], ManagementException
    + FullyQualifiedErrorId : System.Management.ManagementException,Microsoft.PowerShell.Commands.GetWmiObjectCommand

OK not good.

First thing to try is running PowerShell with elevated privileges – Right click and Run as Adminsitartor.

Nope – still not working

Secondly lets try –EnableAllPrivileges

PS > get-help get-wmiobject -Parameter EnableAllPrivileges

-EnableAllPrivileges [<SwitchParameter>]
   Enables all the privileges of the current user before the command makes the WMI call.

    Required?                    false
    Position?                    named
    Default value
    Accept pipeline input?       false
    Accept wildcard characters?  false

This means that the system recognises our credentials and the privileges we get from them e.g, we are an administrator.

Bad news is that doesn’t do any good. Time to look at the documentation. The IIS provider requires packet privacy which means we need to use the –Authentication parameter.

PS > get-help get-wmiobject -Parameter Authentication

-Authentication <AuthenticationLevel>
    Specifies the authentication level to be used with the WMI connection. Valid values are:

    -1: Unchanged
    0: Default
    1: None (No authentication in performed.)
    2: Connect (Authentication is performed only when the client establishes a relationship with the application.)
    3: Call (Authentication is performed only at the beginning of each call when the application receives the request.)
    4: Packet (Authentication is performed on all the data that is received from the client.)
    5: PacketIntegrity (All the data that is transferred between the client  and the application is authenticated and v
    erified.)
    6: PacketPrivacy (The properties of the other authentication levels are used, and all the data is encrypted.)

    Required?                    false
    Position?                    named
    Default value
    Accept pipeline input?       false
    Accept wildcard characters?  false

Get-WmiObject -Namespace ‘root\webadministration’ -List -ComputerName web01 -Authentication 6

This works BUT you still need to have started PowerShell with elevated privileges.

What happened?

We got caught by WMI providers author. They decided it would be a good idea if the data transmitted was encrypted. 

The various values for the authentication parameter are outlined in the table

Value	Meaning
-1	Unchanged – authentication remains as it was before
0	Default COM authentication level. Authentication is negotiated. WMI uses default Windows Authentication setting. The None setting (1) is never the result of a negotiated authentication.
1	None. No COM authentication in performed.
2	Connect. COM authentication is performed only when the client establishes a relationship with the server. No further checks are performed.
3	Call. COM authentication is performed only at the beginning of each call when the sever receives the request. Only packet headers are signed. No data is encrypted.
4	Packet. COM authentication is performed on all the data that is received from the client. Only packet headers are signed. No data is encrypted
5	PacketIntegrity. All the data that is transferred between the client and the application is authenticated and verified. All packets are signed. No data is encrypted.
6	PacketPrivacy. The properties of the other authentication levels are used, and all the data is encrypted.

These are DCOM authentication levels. DCOM is the transport mechanism for accessing remote machines

Most of the time we don’t need to worry about –Authentication but the most common value if we do will be to use packet privacy

These values are contained in the System.Management.Authenticationlevel enumeration

PS > [enum]::GetNames(“System.Management.Authenticationlevel”)
Default
None
Connect
Call
Packet
PacketIntegrity
PacketPrivacy
Unchanged

So we can do this

Get-WmiObject -Namespace ‘root\webadministration’ -List -ComputerName web01 `
-Authentication ([System.Management.Authenticationlevel]::Packetprivacy)

OR

Get-WmiObject -Namespace ‘root\webadministration’ -List -ComputerName web01 `
-Authentication Packetprivacy

to make the command more readable.

If you think you have a problem with the authentication level try this test

[enum]::GetNames(“System.Management.Authenticationlevel”) |
foreach {“`n$_”; Get-WmiObject -Namespace ‘root\webadministration’
-List -ComputerName web01 -Authentication $_}

You will get Access Denied messages for all but the packet privacy level.

The last part of the puzzle is Impersonation

PS > Get-Help get-wmiobject -Parameter Impersonation

–Impersonation <ImpersonationLevel>
    Specifies the impersonation level to use. Valid values are:

    0: Default (reads the local registry for the default impersonation level , which is usually set to “3: Impersonate”
    .)
    1: Anonymous (Hides the credentials of the caller.)
    2: Identify (Allows objects to query the credentials of the caller.)
    3: Impersonate (Allows objects to use the credentials of the caller.)
    4: Delegate (Allows objects to permit other objects to use the credentials of the caller.)

    Required?                    false
    Position?                    named
    Default value
    Accept pipeline input?       false
    Accept wildcard characters?  false

The Impersonate (3) level is what we want. Anonymous isn’t actually used by WMI and Identify usually only allows the checking of access controls.

Delegation is a security risk and isn’t recommended as it can be used to access resources on other systems from the target.

To check the local registry look in 

Get-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\WBEM\Scripting -Name “Default Impersonation Level”

while you are doing that check out

Get-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\WBEM\Scripting -Name “Default Namespace”

as well

In addition to the IIS provider the Microsoft Cluster Services WMI provider also need packet privacy.

Next time you get an Access Denied

1. Check running PowerShell with elevated privileges
2. Try –EnableAllPrivileges
3. Test against various authentication levels (my feeling is to always go to packet privacy as it seems to be that or the default)
4. Check the Impersonation level

If that doesn’t work – leave a comment here and I’ll try and help