UAC bug with runas from command line?

[tcshain]

Hi Folks,

I am experiencing what I believe is a bug with UAC in Windows 7.

I would like to see if anyone can recreate this issue and tell me if it is a bug or is working as expected.

To recreate the issue:

1. Confirm the following local security policy setting is Enabled. Local Policies -> Security Options -> User Account Control: Run all administrators in admin approval mode.

2. Launch a command prompt and open a new elevated command prompt with this command: runas /user:<domain>\<user> cmd.exe

3. Once the new window opens, navigate to your C: directory via My Computer. Once at C: attempt to create a new text document by right click and selecting new. If my suspicion is correct, you will have lost nearly all access to the C: directory.

4. To fix this permission issue, disable the setting mentioned in step 1. Reboot will be required.


Is this working as intended? Is this a bug? I have not come across any thread or document that discusses this issue being caused by the runas command.

I assume the issue is with UAC's admin approval mode, as the disabling admin approval mode appears to resolve the issue.

 

[UsernameIssues]

Welcome to the Seven Forums.

Nice first post. It is always good to see steps to reproduce the problem. In this case, you do not need step 2 to be able to see what you are seeing (which is normal).

1) enable policy (which is enabled by default)
2) use Windows (file) Explorer to navigate to the root of the system drive
3) right click > New
(the only option in the default context menu will be Folder)

This is by design because Windows (file) Explorer is running at the medium integrity level. If you start explorer.exe via "run as admin", it will run at the high integrity level and you will have the complete "New" context menu.

 

[tcshain]

Thanks for the welcome!

Step 2 was necessary for me to produce this issue.

I have domain administrator rights to this machine.
This local policy setting had always been Enabled, and I have always had full access to any portion of my drive, even when I did not elevate windows explorer.

I was testing a few scripts locally and elevated my cmd prompt using the method in step 2. After which my permissions were hosed to the root of C:.

I lost all rights to change any permissions or user accounts on the root folder. Reboot/relog did not help, only changing this policy resolved the issue.

Thanks for the tip to elevate explorer.exe from command line, that will help in a pinch.

However, I shouldn't have to have this setting disabled to make changes as a domain admin correct? Especially if it comes enabled by default as you said, and I've always had access to these functions while logged in as domain admin.

 

[UsernameIssues]

So you are saying that after checking step 1 (in your original post) and before step 2, you have a full "New" context menu in the root of the system drive? For you, doing step 2 actually changes that context menu within an exiting Explorer instance?

Using runas from a non-elevated cmd window did not elevate the second cmd window. It too was running at the medium integrity level (according to Process Explorer). Which is what I would expect.