views:

976

answers:

2

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"?

+1  A: 

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
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".
Jonathan.Peppers
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
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?
Jonathan.Peppers
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
+1  A: 

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.

Jonathan.Peppers
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