8

We have an application that programmatically maps network drives. On Vista with UAC on, we get some strange issues.

Our application maps the drive non-elevated, so if the user browses explorer and double clicks to run an exe, it prompts for UAC. So when they approve it, it prompts for a username/password for the share... Strange since the credentials are saved.

It turns out, an elevated process cannot access a mapped drive that was mapped from a non-elevated process.

To see this issue in action, do the following steps:

  • Run cmd.exe with no UAC
  • Run "net use w: \yourHostname\yourShare /user:yourUser yourPassword /persistent:yes"
  • Run cmd.exe as Administrator
  • Type "w:", and see the error message

At this point you can run plain "net use" and see the connection on the elevated cmd is Unavailable but the other non-elevated cmd sees it as OK.

Does anyone know a workaround to fix this issue? or maybe a way to map a network drive to "All Users"?

jonathanpeppers
  • 26,115
  • 21
  • 99
  • 182
  • This question might belong on serverfault. – Matt Ball Aug 12 '09 at 16:04
  • No, it's a question about programming - they need to inherit privileges across elevation. I don't know the answer though :) – bdonlan Aug 12 '09 at 16:14
  • This is definitely a programming question, we use the WNetAddConnection2 and WNetCancelConnection2 from our application, but this is analogous to the "net use" command. – jonathanpeppers Aug 12 '09 at 21:36

2 Answers2

2

This is by design.

Even though the user account is the same, with the elevated version having a token with membership in the administrator group and addition privileges, the tokens are created independently and thus have different LUID's and appear to the kernel to be from different user logons. Since they are from different logons, mapped drives are not shared between them.

http://blogs.msdn.com/cjacks/archive/2007/02/19/mapped-network-drives-with-uac-on-windows-vista.aspx discusses this in additional detail.

Michael
  • 54,279
  • 5
  • 125
  • 144
  • So if a user on Vista maps a network drive, they basically cannot run any exe from a mapped drive? It would only work if their windows account username/password matches that of the mapped drive? This seems like a poor situation "by design". – jonathanpeppers Aug 12 '09 at 20:30
  • 1
    Even though they have the same user name, elevated vs non-elevated are still distinct users. Should a normal user be able to map drives into an admin user account? Could this cause a DOS if a normal user squats on a drive mapping than an admin needs? Could it cause an EOP if the normal user directs the drive mapping to some place the admin doesn't expect and causes them to run a different binary? – Michael Aug 12 '09 at 20:42
  • I'm saying Microsoft implemented this poorly. Elevated should not be a different user in any form or fashion, it seems like they took a shortcut in my opinion. Is there not a workaround for a situation such as this? – jonathanpeppers Aug 12 '09 at 20:50
  • 2
    Poorly is being kind. An installer asks where to install something - end user attempts to browse to a mapped folder - but what? Where are all my mapped drives? They're gone because the installer process had to run elevated. And in what universe does it make sense for the Admin to have less privileges than the normal user? No. UAC is full of holes, and only a superficial balm rather than a real attempt at security under Windows. – Mordachai Apr 20 '10 at 13:35
2

Check out this link: Regedit Link

They describe a registry key that allows elevated users to access mapped drives and vice versa. This solves all my issues and was exactly what I was looking for.

EDIT:

The original link is dead, but here's the text as copied from the Jan 24, 2009 snapshot at www.archive.org:

If you are finding that you don't have access to mapped drives from your admin token try the following. When running as a protected admin you have two tokens and this key will maintain the connection for both tokes (that is my understanding anyway). It can also help to clear up issues with Login scripts.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System EnableLinkedConnections =(dword)1

Also of use is the "'Group Policy Scripts can fail due to User Account Control" section of this doc.

http://technet2.microsoft.com/WindowsVista/en/library/5ae8da2a-878e-48db-a3c1-4be6ac7cf7631033.mspx?mfr=true

I will be posting more information on this soon.

InteXX
  • 6,135
  • 6
  • 43
  • 80
jonathanpeppers
  • 26,115
  • 21
  • 99
  • 182
  • This should have been the default setting in the registry. Unless it then gives a way for low-privilege users to access privileged only shares, which should be a separately handled issue. – Mordachai Apr 20 '10 at 13:38
  • This solution is marked by Microsoft as an unsupported workaround that makes your system unsafe. Use it at your own risk... – Robert Oct 11 '11 at 14:05
  • I'm not sure how allowing an elevated process to access a network share created by a non-elevated process is unsafe. Isn't an elevated process in the door already? Still it is a weird issue, I'd rather use an unsupported workaround to fix it for most people. – jonathanpeppers Oct 11 '11 at 15:29
  • Yeah, not sure how to get it back. This question is from 2009. – jonathanpeppers Nov 16 '12 at 18:28
  • Perhaps this is the link with the same info, since the original is dead? http://support.microsoft.com/kb/937624?wa=wsignin1.0 – SilverSideDown Feb 14 '13 at 19:14
  • A technet article that describes the problem and the registry setting: https://technet.microsoft.com/library/ee844140.aspx – oleschri Aug 25 '15 at 13:31