none
Using WMI without admin rights

    Question

  • Hi,

    I want to use WMI to control the LCD brightness of my laptop (as it is done by various tools) via WmiMonitorBrightness et al. Unfortunately I get a permission denied when run as a user who is not in the Administrator group.

    Following google research, I tried to:

    • Put the user into "Distributed COM Users", "Performance Log Users", "Performance Monitor Users"
    • Additionally, using WmiMgnt.msc, I used "WMI Control" -> Properties -> Security and gave the user all permissions on node Root, WMI and the single node (ms_409) under WMI

    However, still permission denied. Is there something missing?

    Or does Windows really not provide a better granuliarity than admin/non-admin?

    Thanks

    Peter

    Sunday, July 21, 2013 7:41 PM

Answers

  • I HAVE FOUND THE ISSUE!!

    The user was in the group "Remote Desktop Users". As soon as a user is member of this group, it seems that I get the permission denied.

    But this raises the important question: WHY? And how to deal with that?

    Monday, July 22, 2013 3:18 AM

All replies

  • Don't need an Admin. You just need a correct set of documentation.

    $monitor=@(gwmi WmiMonitorBrightnessMethods -ns root/wmi)[0]
    $monitor.WmiSetBrightness(0,10)


    ¯\_(ツ)_/¯

    Sunday, July 21, 2013 8:09 PM
  • Hi jrv,

    Thanks so far.

    Are you sure?

    Windows PowerShell
    Copyright (C) 2012 Microsoft Corporation. All rights reserved.
    
    PS C:\Users\peter> $monitor=@(gwmi WmiMonitorBrightnessMethods -ns root/wmi)[0]
    gwmi : Access denied
    At line:1 char:12
    + $monitor=@(gwmi WmiMonitorBrightnessMethods -ns root/wmi)[0]
    +            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : InvalidOperation: (:) [Get-WmiObject], ManagementException
        + FullyQualifiedErrorId : GetWMIManagementException,Microsoft.PowerShell.Commands.GetWmiObjectCommand
    
    PS C:\Users\peter>

    If I execute the same thing with admin rights, it works perfectly.

    Please note that the user "peter" is not in the "Administrators" group, as indicated in the first posting. This should be avoided!

    Thanks

    Peter

    Sunday, July 21, 2013 10:10 PM
  • I created a brand new user that is a standard user.  My systems have never had DCOM changed from installation as there is never a reason to do this for most legitimate or normal operations.

    Here is a screenshot of the test.  I dumped the username and list od admins so youcan see that the user is not an admin.

    All users have launch access to WMI.  Some classes in WMI require token like the 'security' token or the 'backup' token. 

    The DCOM group is for remote launch and does not effect local access.

    I am afraid your 'Googgle' research has sent you down a rabbit hole.

    Try running the test on a machine that has not been played around with to prove that ir works as I have noted.


    ¯\_(ツ)_/¯

    Monday, July 22, 2013 12:30 AM
  • That's INCREDIBLE!

    I did the same:

    But WTF could that be?? (Evidently, it has to do with the user profile).

    But it's a brand new Win8, just installed 2 days ago (though this user was created using the Migration Tool).

    What could be the problem with the profile? I would really like to avoid re-creating the user profile (and loosing all my settings etc.). Is there any debugging/logging functionality related to WMI?

    Edit: Ok, there is an event log, but "Unknown" is a very bad PossibleCause. I appreciate any hints for debugging!

    Id = {E9181CE9-859B-0003-6B46-18E99B85CE01}; ClientMachine = THINKTANK; User = thinktank\peter; ClientProcessId = 2192; Component = Unknown; Operation = Start IWbemServices::ExecQuery - root\wmi : select * from WmiMonitorBrightnessMethods; ResultCode = 0x80041003; PossibleCause = Unknown




    Monday, July 22, 2013 1:36 AM
  • Yes but it won't help you here.  The problem is likely a corrupted hive or virus.

    Try exporting the settings and importing into a new user.

    Since this is no longer  and never was a scripting problem I recommend either recreating the user or contacting Microsoft support.


    ¯\_(ツ)_/¯

    Monday, July 22, 2013 1:57 AM
  • I tested and it works for me as well (using standard user that's not a member of Administrators).

    Agree that this is not a scripting question but rather some kind of system configuration issue.

    Bill

    Monday, July 22, 2013 2:21 AM
    Moderator
  • Hi all,

    Thank you for your support! Sorry for putting this into the wrong forum, I was redirected here from an MSDN C# forum because they told me there is no specific WMI forum but the Scripting folks have a good grasp on WMI (which seems to be the case).

    My problem becomes even crazier: Even when I add the admin group I get the permission denied!!

    I tried to create a new user and copy the old user profile to the new user (using "Copy To" in "Advanced System Settings"+Window Enabler). But there's some issue, Windows always loads a temporary profile :(

    Is there maybe a more specific forum where I could ask?

    I really really don't want to re-create the profile, I lost most of my settings already because the Migration Tool did barely migrate any settings. I spent the last days in setting up everything as it should.

    What I will do next is to backup the user profile and delete it. Then I could see if it is related to the profile/hieve or the user/SID. I am pretty sure it will be related to the profile ... any hint on what I could do next?

    Best,

    Peter

    EDIT: Ok, it is indeed not the profile! I just renamed c:\Users\peter to c:\users\Backup.peter.Backup. Therefore I am signed on with a temporary user profile. And I still get "Permission denied". Where in the system could lie a user-specific WMI configuration data?

    Monday, July 22, 2013 2:51 AM
  • I HAVE FOUND THE ISSUE!!

    The user was in the group "Remote Desktop Users". As soon as a user is member of this group, it seems that I get the permission denied.

    But this raises the important question: WHY? And how to deal with that?

    Monday, July 22, 2013 3:18 AM
  • Hi all,

    Thank you for your support! Sorry for putting this into the wrong forum, I was redirected here from an MSDN C# forum because they told me there is no specific WMI forum but the Scripting folks have a good grasp on WMI (which seems to be the case).

    My problem becomes even crazier: Even when I add the admin group I get the permission denied!!

    I tried to create a new user and copy the old user profile to the new user (using "Copy To" in "Advanced System Settings"+Window Enabler). But there's some issue, Windows always loads a temporary profile :(

    Is there maybe a more specific forum where I could ask?

    I really really don't want to re-create the profile, I lost most of my settings already because the Migration Tool did barely migrate any settings. I spent the last days in setting up everything as it should.

    What I will do next is to backup the user profile and delete it. Then I could see if it is related to the profile/hieve or the user/SID. I am pretty sure it will be related to the profile ... any hint on what I could do next?

    Best,

    Peter

    EDIT: Ok, it is indeed not the profile! I just renamed c:\Users\peter to c:\users\Backup.peter.Backup. Therefore I am signed on with a temporary user profile. And I still get "Permission denied". Where in the system could lie a user-specific WMI configuration data?

    Somehow you have altered the settings and now you have issues. I recommend backing up and doing a reinstall. Export users using the migration wizard. Do not copy the profile.

    You should post in the Windows 7/8 forum for help with fixing this kind of issue.  They handle this stuff all of the time.


    ¯\_(ツ)_/¯

    Monday, July 22, 2013 3:25 AM
  • Another bit of info.  When you reinstall do not install any non-Microsoft software.  Test a user.  Import old user settings into tested new user.  Test again and verify that this works.  Add other software one piece at a time and test in between until you find the software that is altering the settings. 

    Under no circumstance should you shut off or alter the UAC default settings until you have found what is altering the system settings.


    ¯\_(ツ)_/¯

    Monday, July 22, 2013 3:28 AM
  • Hi jrv,

    Thanks again. However, it seems you have overlooked my latest reply. I have found the issue: Whenever a user in the "Remote Desktop Users"-group I get the permission denied. That's very interesting (and problematic for me) ... I would really like to find the root cause and resolve it.

    This really seems so be a deep WMI issue (maybe bug?). If you would end this thread here, do you have a recommentation where to discuss WMI issues?

    Thanks,Peter

    Monday, July 22, 2013 3:34 AM
  • Don't mistake a new symptom for a solution.  You have a bad install or a damaged install.  Either re-install according to my instructions of call Microsoft support.


    ¯\_(ツ)_/¯

    Monday, July 22, 2013 3:38 AM
  • If you really want to spend time trying to figure out a very complex technology (WMI) then go ahead but post questions to the platform forum.  This is a scripting forum and not a place to get assistance with computer repairs.

    Sorry and good luck.


    ¯\_(ツ)_/¯

    Monday, July 22, 2013 3:40 AM
  • Hi,

    As I said, there is nothing damaged, this is either a bug or a terrible side effect (you may try adding your user to the "Remote Desktop Users"-group, I bet you'll also get permission denied now). It can't be a feature in any case ;-)

    I posted this in the Management forum of Windows Server, I find it appropriate there (didn't find the platform forum).

    In any case, thanks a lot for helping me tracking this down via PowerShell. This really helped me a lot.

    Best,

    Peter

    Monday, July 22, 2013 4:03 AM
  • Interesting.

    I'm seeing the same behavior. If I add a test account that could previously run jrv's initial code to the RDP group, I'm also getting an access denied error on this line: $monitor=@(gwmi WmiMonitorBrightnessMethods -ns root/wmi)[0].

    Don't retire TechNet!

    Monday, July 22, 2013 4:11 AM
  • Yup - it looks like a real bug.

    For some reason WMI is assuming that membership in the remote desktop means you are running remotely.  This is probably a side-effect of the virtualization of the account/session on Windows 8.


    ¯\_(ツ)_/¯

    Monday, July 22, 2013 4:31 AM
  • I should mention, I'm running 7.

    Don't retire TechNet!

    Monday, July 22, 2013 4:32 AM
  • Is it possible for a process to drop an ACL group entry from its process token by itself? I.e., that the process drops the group "Remote Desktop Users" and afterwards calls the WMI?

    I doubt because a group could also have DENY meaning that a process can not only decrease but also increase its rights when dropping a group.

    (I am just thinking about possible, yet ugly, workarounds ...)

    Monday, July 22, 2013 4:38 AM
  • Is it possible for a process to drop an ACL group entry from its process token by itself? I.e., that the process drops the group "Remote Desktop Users" and afterwards calls the WMI?

    I doubt because a group could also have DENY meaning that a process can not only decrease but also increase its rights when dropping a group.

    (I am just thinking about possible, yet ugly, workarounds ...)

    WMI thinks that the user is remotely connected.  WMI is denied for remote users. Only admins are allowed remote access.

    The DCOM group gets you into DCOM but WMI has more restrictions. WMI is rejecting remote users as it should.  It is failing to check that the user is console connected.  My guess is that thisis because the console has been completely redirected through TS on Vista and later.

    I suspect that there is a KB somewhere telling how to resolve this.  A call to MS might help.


    ¯\_(ツ)_/¯

    Monday, July 22, 2013 5:04 AM