Vista UAC - Trouble Mapping Network Drives

L

2

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

Lifetime answered 12/8, 2009 at 15:52 Comment(3)

This question might belong on serverfault. – Cookie 12/8, 2009 at 16:4

No, it's a question about programming - they need to inherit privileges across elevation. I don't know the answer though :) – Carvalho 12/8, 2009 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. – Lifetime 12/8, 2009 at 21:36

L

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.

Lifetime answered 13/8, 2009 at 13:40 Comment(6)

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. – Cherrylchersonese 20/4, 2010 at 13:38

This solution is marked by Microsoft as an unsupported workaround that makes your system unsafe. Use it at your own risk... – Undesirable 11/10, 2011 at 14:5

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. – Lifetime 11/10, 2011 at 15:29

Yeah, not sure how to get it back. This question is from 2009. – Lifetime 16/11, 2012 at 18:28

Perhaps this is the link with the same info, since the original is dead? support.microsoft.com/kb/937624?wa=wsignin1.0 – Ainsworth 14/2, 2013 at 19:14

A technet article that describes the problem and the registry setting: technet.microsoft.com/library/ee844140.aspx – Grayce 25/8, 2015 at 13:31

S

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.

Sheela answered 12/8, 2009 at 16:30 Comment(4)

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". – Lifetime 12/8, 2009 at 20:30

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? – Sheela 12/8, 2009 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? – Lifetime 12/8, 2009 at 20:50

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. – Cherrylchersonese 20/4, 2010 at 13:35

L

2