Get-WmiObject Access Denied Error

I am using this powershell command to retrieve BIOS information and I keep getting this error:

PowerShell Command:  Get-WmiObject -Class _ComputerName machine2 -Credential $creds

Error message: Get-WmiObject : Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

Note 1:The computer that I am running the command from is not join to my domain so I supplied a local admin credential on the remote target machine that is joined to a domain and it gives me the error above

Note 2: It works when I supply a domain account that is tied to the local admin

Thanks
AnagkazoSystems EngineerAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

footechCommented:
From https://msdn.microsoft.com/en-us/library/aa822854(v=vs.85).aspx
User Account Control Settings

Starting with Windows Vista, under User Account Control (UAC) access-token filtering can affect which operations are allowed in WMI namespaces or what data is returned. Under UAC, all accounts in the local Administrators group run with a standard user access token, also known as UAC access-token filtering. An administrator account can run a script with an elevated privilege—"Run as Administrator".

When you are not connecting to the built-in Administrator account, UAC affects connections to a remote computer differently depending on whether the two computers are in a domain or a workgroup. For more information about UAC and remote connections, see User Account Control and WMI.

DCOM Settings

DCOM settings are unchanged in Windows Vista. For more information, see Securing a Remote WMI Connection. However, UAC affects connections for nondomain user accounts. If you connect to a remote computer using a nondomain user account included in the local Administrators group of the remote computer, then you must explicitly grant remote DCOM access, activation, and launch rights to the account.


From https://msdn.microsoft.com/en-us/library/aa826699(v=vs.85).aspx
Handling Remote Connections Under UAC

Whether you are connecting to a remote computer in a domain or in a workgroup determines whether UAC filtering occurs.

If your computer is part of a domain, connect to the target computer using a domain account that is in the local Administrators group of the remote computer. Then UAC access token filtering will not affect the domain accounts in the local Administrators group. Do not use a local, nondomain account on the remote computer, even if the account is in the Administrators group.

In a workgroup, the account connecting to the remote computer is a local user on that computer. Even if the account is in the Administrators group, UAC filtering means that a script runs as a standard user. A best practice is to create a dedicated local user group or user account on the target computer specifically for remote connections.

The security must be adjusted to be able to use this account because the account never has had administrative privileges. Give the local user:
•Remote launch and activate rights to access DCOM. For more information, see Connecting to WMI on a Remote Computer.
•Rights to access the WMI namespace remotely (Remote Enable). For more information, see Access to WMI Namespaces.
•Right to access the specific securable object, depending on the security required by the object.

If you use a local account, either because you are in a workgroup or it is a local computer account, you may be forced to give specific tasks to a local user. For example, you can grant the user the right to stop or start a specific service through the SC.exe command, the GetSecurityDescriptor and SetSecurityDescriptor methods of Win32_Service, or through Group Policy using Gpedit.msc. Some securable objects may not allow a standard user to perform tasks and offer no means to alter the default security. In this case, you may need to disable UAC so that the local user account is not filtered and instead becomes a full administrator. Be aware that for security reasons, disabling UAC should be a last resort.

Disabling Remote UAC by changing the registry entry that controls Remote UAC is not recommended, but may be necessary in a workgroup. The registry entry is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy. When the value of this entry is zero (0), Remote UAC access token filtering is enabled. When the value is 1, remote UAC is disabled.

You could try setting LocalAccountTokenFilterPolicy to 1.  I rarely work with workgroup machines, but I believe I've tested this successfully in the past.  But when I want to access WMI remotely using a domain account that is not a member of the local administrators group, I set up the WMI security to give the user Remote Enable rights.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
AnagkazoSystems EngineerAuthor Commented:
Thanks footech.  setting the "LocalAccountTokenFilterPolicy" to 1 solved the issue.
0
AnagkazoSystems EngineerAuthor Commented:
Thanks footech.  setting the "LocalAccountTokenFilterPolicy" to 1 solved the issue.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows OS

From novice to tech pro — start learning today.