WMI Access Denied

by trondhindenes at 2012-12-10 04:25:24

Im trying to do a simple WMI query against a Workgroup-based Windows 2012 Server. I’ve turned off the Windows Firewall and verified that the local administrator account is valid. I’m starting to think that Microsoft tightened the security around “untrusted” connections from 2008R2 to 2012. Anyone know anything about this?

by RichardSiddaway at 2012-12-10 10:05:33
Is DCOM running and configured on the remote machine?

Have you tried the query against a domain machine?

Can you post the WMI code that is throwing the error. If you accessing the IIS classes for instance you will need to use Packet Privacy - add -Authentication 6 to your Get-WmiObject call
by trondhindenes at 2012-12-10 14:14:18
Right now I’m only testing with a simple query like this:
gwmi -query “Select * from Win32_ComputerSystem” -computer “Win2012Svr” -credential (get-credential)

DCOM is running but I haven’t configured it for anything special, it’s a vanilla install.
by RichardSiddaway at 2012-12-10 23:45:17
I have seen issues where you try to getthe credential in the get- environment call. WIN connects with your current credential and fails before it asks for the new credential.

$cred= get- credential
get- wmiobject -query . … - credential $cred etc

btw you can just use the classname parameter in this car. it doesn’t. HAVE to be query
by cscott at 2013-02-15 11:00:31
I am dealing with this same issue. The script below works for a domain user with admin privileges however, i am getting access denied for a local user who is in the Administrator’s group. I’ve checked that Dcom is activated. Basically, i’m trying to confirm that the supplied credential works.

get-AccountLogin : Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

+ get-AccountLogin <<<< -computer $computer -userName $userName -password $password
+ CategoryInfo : NotSpecified: (:slight_smile: [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,get-AccountLogin

[code2=powershell]$computer =“COMPUTERNAME”
$userName =“ACCOUNTNAME”
$password =“PASSWORD"

function get-AccountLogin
[Parameter(ValueFromPipeline=$True, Position=0, Mandatory=$True)]
,[Parameter(ValueFromPipeline=$True, Position=1, Mandatory=$True)]
,[Parameter(ValueFromPipeline=$True, Position=2, Mandatory=$True)]
Process {
$securepwd = ConvertTo-SecureString $password -asplaintext -force
$account = $($computer)+”&quot;+$($username)
#$account = “DOMAINNAME”+"&quot;+$($username)
$credential = New-Object System.Management.Automation.PSCredential($account,$securepwd)
$colItems = Get-WmiObject -Class Win32_Process -Authentication 6 -Locale “MS_409” -Namespace “ROOT\CIMV2” -Credential $credential -ComputerName $computer
foreach ($ObjItem in $colItems)
write-host “Process Name:” $ObjItem.name
Write-Warning “Failed to retrieve namespace information from $($Computer)”
Write-Error $_
END {}
get-AccountLogin -computer $computer -userName $userName -password $password[/code2]
by DonJ at 2013-02-17 12:57:08
Default security on the WMI repository is to only allow remote queries by members of the machine’s local Administrators group. Ensure you’re providing the credential of a user in that group.
by cscott at 2013-02-18 06:54:52
I have verified that the user is a local administrator on the target computer. The script works for a domain user in the administrators group but not for a local user with the same privileges.
[code2=powershell]$account = $($computer)+"&quot;+$($username)
#$account = “DOMAINNAME”+"&quot;+$($username)[/code2]
by cscott at 2013-02-18 14:31:04
I ran the WMIDiag tool and i am intrigued by the following section in the report. This seems like the behavior i am encountering in my testing. Any suggestions on how to prevent filtered token scenario?

32835 14:46:13 (0) ** INFO: Local Account Filtering: … ENABLED.
32836 14:46:13 (0) ** => WMI tasks remotely accessing WMI information on this computer and requiring Administrative
32837 14:46:13 (0) ** privileges MUST use a DOMAIN account part of the Local Administrators group of this computer
32838 14:46:13 (0) ** to ensure that administrative privileges are granted. If a Local User account is used for remote
32839 14:46:13 (0) ** accesses, it will be reduced to a plain user (filtered token), even if it is part of the Local Administrators group.

32840 14:46:13 (0) **
32841 14:46:13 (0) ** Overall DCOM security status: … OK.
32842 14:46:13 (0) ** Overall WMI security status: … OK.