locked
UAC keeps coming back on all by itself. RRS feed

  • Question

  • I'm the kind of person who just needs to turn UAC off.  It's a great idea for the vast majority of regular users, though, so I'm not canning it, just asking some questions on how to actually turn it off so that it stays off.

    I'm using Windows 7 x64 on a laptop that's just on its own, no domain, no group policy etc.

    Anyway, I've got my UAC slider all the way down the bottom (and have rebooted), yet I still need to explicitly right-click and choose "Run as Administrator" if I need to run something as an administrator.  (for example the command prompt, if I want to run "chkdsk c: /f" or "pskill explorer.exe" or use ProcessExplorer and look at the threads in system processes or whatever.)  The thing is I want to run most of my stuff as administrator without the need to right-click each time.  Just take a look at some of the crazy problems I see and need to work with: http://users.on.net/~MRIS/Problem_20090207_0701.mht

    I know that I can tick "run as administrator" in the advanced tab for the shortcut that launches these as a work-around but I want it for all my sysinternals utilities, and there's lots of them.  I'm also sick of clicking "show for all users" in things like task manager when I launch it via CTRL-SHIFT-ESC. 

    There's a Group Policy setting in the registry named:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA
    That I think is responsible.
    However it always comes back and gets set to 1, which I fear is responsible for the "your UAC is off, but you still can't run stuff as Administrator unless you specifically shift-right-click and choose "Run As Administrator"".

    I set it to zero or delete the value and it just comes back!!!!

    Why does this GPO setting keep coming back?
    Saturday, February 7, 2009 4:20 PM

Answers

  •  
    MRIS said:

    How do I track how this is getting there?



    It turns out a file named "registry.pol" in this folder:
    C:\Windows\System32\GroupPolicy\Machine\
    was doing it.
    • Marked as answer by Mark L. Ferguson Saturday, February 14, 2009 2:44 PM
    • Unmarked as answer by Mark L. Ferguson Saturday, February 14, 2009 2:44 PM
    • Marked as answer by MRIS Sunday, February 15, 2009 4:27 AM
    • Unmarked as answer by MRIS Sunday, February 15, 2009 4:30 AM
    • Marked as answer by MRIS Sunday, February 15, 2009 5:03 AM
    Saturday, February 14, 2009 1:43 PM

All replies

  •  You are expecting the behavior to change for admin rights. Turning off the UAC does not lift the restriction for that, it simply disables the request for elevation, making it twice as hard to lift. There are utilities available, (especially the built in one in Task Scheduler) to make running a task by-pass the elevation request. Goggle should hit a number of articles on that, though this Forum has the policy of not recomending third party solutions. One I know of is Utility Spotlight Script Elevation PowerToys for Windows Vista:
    Rating posts helps other users
    Mark L. Ferguson MS-MVP
    Saturday, February 7, 2009 6:04 PM
  • You are going to need to configure registry auditing (auditpol.exe and enable auditing on the registry key) or use Process Monitor (microsoft.com/sysinternals) in boot logging mode to determine what is turning the registry values back on, since you state you are not getting from a group policy.
    Ned Pyle [MSFT] - MS Enterprise Platforms Support - Beta Team
    Saturday, February 7, 2009 7:59 PM
  • Ned Pyle [MSFT] said:

    You are going to need to configure registry auditing (auditpol.exe and enable auditing on the registry key) or use Process Monitor (microsoft.com/sysinternals) in boot logging mode to determine what is turning the registry values back on, since you state you are not getting from a group policy.

    I think I've been able to narrow things down.  Here's what I think is happening:

    I've joined the google chrome development channel, which means a new build of the browser every week or so.
    The problem is that the google chrome self-update system only works if UAC is ON.
    So what I do is move the UAC slider one notch up, thus enabling it.  I then reboot.
    I then allow google chrome to do it's self-update to get to the next build, which works fine.
    I then move the UAC slider all the way back down again, thinking that this turns UAC off again. I then reboot.
    However when the computer starts up again, it's then that I notice that the following local group policy setting:
    User Account Control: Run all administrators in Admin Approval Mode
    is set to Enabled.

    I guess enabling UAC (move slider up 1 notch) enables that policy setting, however disabling UAC again (move slider all-the-way down) leaves that policy setting enabled.

    This means that the UAC slider, if that's all that users have access to doesn't work.  It enables something that can't be disabled again by reversing the action.  This is obviously a bug in the beta software.  I've sent the feedback to Microsoft.

    • Marked as answer by MRIS Sunday, February 8, 2009 1:40 PM
    • Unmarked as answer by MRIS Monday, February 9, 2009 12:10 AM
    Sunday, February 8, 2009 1:38 PM
  • I just followed your steps a clean repro machine (i.e. no third party applications installed) and did not experience your symptoms. I still highly recommend you follow the steps above to use Process Monitor or Auditpol to determine what is turning UAC back on.

    I would not assume that you have found a bug in UAC that no one has seen by now. As we have seen recently, this is a highly visible component that is constantly under a microscope. If it could not be turned off due to a bug that has been visible to the public for a month (and to internal beta users for 2 months), it would be well known by now and all over the internet.


    Ned Pyle [MSFT] - MS Enterprise Platforms Support - Beta Team
    Sunday, February 8, 2009 8:01 PM
  • Ned Pyle [MSFT] said:

    I just followed your steps a clean repro machine (i.e. no third party applications installed) and did not experience your symptoms. I still highly recommend you follow the steps above to use Process Monitor or Auditpol to determine what is turning UAC back on.


    Ned Pyle [MSFT] - MS Enterprise Platforms Support - Beta Team



    It turns out you're partially right. 

    I've just done the UAC-on (reboot) then UAC-off (reboot) and sure enough my process explorer was able to launch as administrator once the system came back. 

    However I noticed that the action center had a message, that went along the lines "you need to reboot your PC to turn UAC back on".  This is even though I had just turned it off prior to the previous reboot and had NOT touched it yet.

    Simply rebooting the PC one more time and voiala: all three of these facts were true:

    A. UAC still had the slider all the way down

    B. Launching process explorer the same way as above this time resulted in all the system processes having access denied.  (hence it was not running as administrator.)

    C. The local policy: User Account Control: Run all administrators in Admin Approval Mode is set to Enabled.


    So Ned, did you reboot that third time?

    I'll take your advice and will setup the auditing.  Give me a week or so to get the results.
    Sunday, February 8, 2009 11:40 PM
  • The plot is certainly thickening.

    I tried turning on success auditing for object access, but my security log just jams full of millions of messages about evey little thing that goes down.  I thought you had to explicitly enable auditing on an object and have the audit policy enabled before it logs stuff,but there is too much junk to wade through, and I feel the 20MB security log just rotates right through within every 40 seconds, so the actual thing I want to see is gone anyway.

    Anyway I did an RSOP.MSC, and noticed this (see attached screenshot).
    RSOP screenshot

    Notice how there is some kind of local policy that is turning this sucker back on.

    How do I track how this is getting there?
    Saturday, February 14, 2009 1:13 PM
  •  
    MRIS said:

    How do I track how this is getting there?



    It turns out a file named "registry.pol" in this folder:
    C:\Windows\System32\GroupPolicy\Machine\
    was doing it.
    • Marked as answer by Mark L. Ferguson Saturday, February 14, 2009 2:44 PM
    • Unmarked as answer by Mark L. Ferguson Saturday, February 14, 2009 2:44 PM
    • Marked as answer by MRIS Sunday, February 15, 2009 4:27 AM
    • Unmarked as answer by MRIS Sunday, February 15, 2009 4:30 AM
    • Marked as answer by MRIS Sunday, February 15, 2009 5:03 AM
    Saturday, February 14, 2009 1:43 PM
  • When you type GPEdit.MSC you will open the Policy editor, and find all the settings in your registry.pol. I would suspect a relic of an upgrade from Vista for the Security Center.
    Rating posts helps other users
    Mark L. Ferguson MS-MVP
    Saturday, February 14, 2009 2:53 PM
  • That is very peculiar - there really shouldn't be anything in the registry.pol file for local policy - local GP is just direct editing of the registry and file system. And your error screen actually implies that something was outside of GPO modifying your settings, but using the domain-based policy caching mechanism to do it. Ordinarily I would say this was likely malware, except that it would be trying to turn your UAC settings off :). You using any add-on security software, and can you reproduce your behavior again (or is it fixed for good now)?
    Ned Pyle [MSFT] - MS Enterprise Platforms Support - Beta Team
    Sunday, February 15, 2009 2:49 AM
  • Yes, the problem has been permanently fixed.
     
    For the curious, here is a copy of the Registry.pol file, I've uuencoded it so that I can paste it here, since no attachments are allowed:

    begin 600 Registry.pol
    M4%)E9P$```!;`%,`;P!F`'0`=P!A`'(`90!<`$T`:0!C`'(`;P!S`&\`9@!T
    M`%P`5P!I`&X`9`!O`'<`<P!<`$,`=0!R`'(`90!N`'0`5@!E`'(`<P!I`&\`
    M;@!<`%``;P!L`&D`8P!I`&4`<P!<`%,`>0!S`'0`90!M````.P!%`&X`80!B
    M`&P`90!,`%4`00```#L`!````#L`!````#L``0```%T`6P!3`&\`9@!T`'<`
    M80!R`&4`7`!0`&\`;`!I`&,`:0!E`',`7`!-`&D`8P!R`&\`<P!O`&8`=`!<
    M`%<`:0!N`&0`;P!W`',`7`!3`'(`<`!6`#(`7`!$`&P`;````#L````[````
    M```[```````[`%T`6P!3`&\`9@!T`'<`80!R`&4`7`!0`&\`;`!I`&,`:0!E
    M`',`7`!-`&D`8P!R`&\`<P!O`&8`=`!<`%<`:0!N`&0`;P!W`',`7`!3`'(`
    M<`!6`#(`7`!%`'@`90```#L````[```````[```````[`%T`6P!3`&\`9@!T
    M`'<`80!R`&4`7`!0`&\`;`!I`&,`:0!E`',`7`!-`&D`8P!R`&\`<P!O`&8`
    M=`!<`%<`:0!N`&0`;P!W`',`7`!3`'(`<`!6`#(`7`!-`',`:0```#L````[
    M```````[```````[`%T`6P!3`&\`9@!T`'<`80!R`&4`7`!0`&\`;`!I`&,`
    M:0!E`',`7`!-`&D`8P!R`&\`<P!O`&8`=`!<`%<`:0!N`&0`;P!W`',`7`!3
    M`'(`<`!6`#(`7`!3`&,`<@!I`'``=````#L````[```````[```````[`%T`
    `
    end


    The ascii interpretation of this file goes like this:

    C:\>type Registry.pol
    PReg☺   [ S o f t w a r e \ M i c r o s o f t \ W i n d o w s \ C u r r e n t V e r s i o n \ P o l i c i e s \ S y s t e m   ; E n a b l e L U A   ; ♦   ; ♦   ; ☺   ] [ S o f t w
    a r e \ P o l i c i e s \ M i c r o s o f t \ W i n d o w s \ S r p V 2 \ D l l   ;   ;     ;     ; ] [ S o f t w a r e \ P o l i c i e s \ M i c r o s o f t \ W i n d o w s \ S r
    p V 2 \ E x e   ;   ;     ;     ; ] [ S o f t w a r e \ P o l i c i e s \ M i c r o s o f t \ W i n d o w s \ S r p V 2 \ M s i   ;   ;     ;     ; ] [ S o f t w a r e \ P o l i c
    i e s \ M i c r o s o f t \ W i n d o w s \ S r p V 2 \ S c r i p t   ;   ;     ;     ; ]
    C:\>

    Any idea where this file might have come from?  Yes, this Windows 7 beta was upgraded from Vista x64 with SP1
    Sunday, February 15, 2009 4:29 AM
  • You will need to find out what application has been modifying that file, especially if your computer has never been joined to the domain. Are you 100% sure of that? Because the other entries are related to software restriction policies v2 (applocker) which are typically configured by a domain administrator in domain-based policy. None of those entries exist by default when you install Win7.

    You can see for yourself, but local group policy does not edit that policy file - it enables the actual registry entries. Rename the file then use GPEDIT.MSC to enable/disable UAC - you will see that the edits occur directly in the registry only, and that file should not be recreated.


    Ned Pyle [MSFT] - MS Enterprise Platforms Support - Beta Team
    Sunday, February 15, 2009 4:44 AM
  • Ned Pyle [MSFT] said:

    Because the other entries are related to software restriction policies v2 (applocker) which are typically configured by a domain administrator in domain-based policy.



    I did experiment with software restriction policies, exercising the new features such as allow by publisher (like in the video, selected word, then unticked the specifics to only permit that publisher), then allowing only Microsoft apps to run.  However I thought I had turned all that off again.  I did this using local group policy via gpedit.msc

    Correlating the date/time of the .pol file with what I was doing at the exact time are:
    1. Unsucessfully installed the new Vista x64 drivers for the Intel 4965AGN wireless adaptor.  This required a system restore to recover from.
    2. Experienced lots of Google Chrome crashes at this time... (3:17am in the morning... of 26 Jan 09)

    Maybe the wirless driver installer used an older API call to turn UAC back on after it ran the install?

    Anyway, thanks for the assistance to both of you, I'm happy for this thread to close.
    Sunday, February 15, 2009 4:58 AM
  • This did the trick to me:

    Beside turning UAC (User Access Control) off in the control panel, still programs were running restricted. This option made the trick to me.

    Local Security Policy > Local policies > Security options >

     "User Account Control: Run all administrators in Admin Approval Mode": Disable

    Wednesday, October 2, 2013 8:26 AM
  • Thanks all, this was/is the right direction for me, looked for "ages" in my Vista.

    Regards

    Monday, April 13, 2015 7:20 AM
  • Did you delete the registry.pol?
    Friday, January 5, 2018 4:00 PM