User Account Control on Windows Vista provides a convenience feature which allows you to elevate a process without leaving the current desktop. (For a discussion of why this is a convenience feature, rather than a security feature, see Mark Russinovich's blog entry here: http://blogs.technet.com/markrussinovich/archive/2007/02/12/638372.aspx).
Let's explore this at a fairly high level. To simplify things, let's assume you are running as an administrator with UAC enabled (although, to be more secure, it is better to run as a standard user). When you log in, you create a new token. We then detect that you have UAC enabled, we log in a second time, and end up with a new (highly restricted) token, which we use to launch the shell. There are two separate login events. When you are prompted to elevate, you go through consent.exe, which is able to leverage the Application Information service to essentially call CreateProcessAsUser with the fully-charged admin token. Remember - we are calling CreateProcessAsUser with a token generated with a separate login.
This convenience feature makes it easier to run into issues with mapped network drives. Prior to Windows 2000 SP2, device names remained globally visible until explicitly removed or the system restarted. For security reasons, we modified this behavior beginning with Windows 2000 SP2. From this point forward, all devices are associated with an authentication ID (LUID) - an ID generated for each logon session. (A process running in LocalSystem context can create a device name in the Global device namespace, although local namespace objects can hide global namespace objects.)
Because these mapped drives are associated with LUID, and because elevated applications are using a different LUID generated during a separate login event, the elevated application will no longer see any mapped drives for this user. (You will notice the same behavior previously using RunAs or CreateProcessAsUser, but UAC dramatically increases the number of users who will be using these concepts.)
The result? If you elevate a command prompt, you will no longer see any local namespace mapped drives created from your original login (whether created through a logon script, WNetAddConnection, or otherwise). We do put a mitigation in place for the scenario of launching from the shell. If you double click on an executable that is either detected as a setup or is manifested as requireAdministrator, we can detect that we just elevated and suddenly are getting an error message indicating that the path was not found, and copy that drive mapping over from the original LUID. However, that is the only scenario that we can automate.
So, if you need to leverage mapped drives from an elevated process, you should be certain to map these drives in the contect of the elevated login.
you can set this value and you will get access to those drives from both integrity levels.
http://www.windowsconnected.com/forums/thread/7315.aspx
UAC team is working on a KB, and I will have a post on this before too long.
Last time around, we looked at an application compatibility side-effect of User Account Control on Windows
So how does MS expect us to change our logon scripts to work by mapping network drives? Shouldn't there be some documentation on how to do this appropriately. I did try the Launchapp.wsf on the TechNet article but errors out with a syntax error just launching the script. I have tried the registry key EnableLinkedConnections and it works. However you can't make a startup script edit the registry to deploy such a change. It seems this is a catch 22 situation. Does anybody else know how to make this work?
What is the error you are seeing? I assume you are talking about the article at http://technet2.microsoft.com/WindowsVista/en/library/5ae8da2a-878e-48db-a3c1-4be6ac7cf7631033.mspx?mfr=true ?
I cannot get the EnableLinkedConnections to work. Anyone else successful?
I have a variation on this behaviour. If the user is a standard user the log on script works fine and maps the drives. However, if I add the user to the local admin group the mappings fail to appear.
You must reboot after you set the new DWORD.
I map network drive in elevated contect, however, if after this I start a DOS window also in elevated contect, I CANNOT see any of the mapped drives.
However, if I start DOS windows in non-elevated mode, it's ok.
Why is this so inconsistent?
Mapped drives are associated with a logon session, as mentioned before. It's not just elevated or non-elevated, but each time you log in. We just happen to have two different logon events when creating the split token we use in Vista.
If you're seeing the drives in a non-elevated command shell (DOS is long gone, but I know what you mean), then the mapped drives must have been created from that logon session, and not from the session from which your elevated token came. How are you mapping these drives, and from what application?
I have also been unsuccessful with utilizing the EnableLinkedConnections = 1 registry fix. I have rebooted as well. It just doesn't work for me.
On a side note, before applying this fix, if I opened a command prompt under the limited token, my drives show (net use) and are available. If I opened an elevated command prompt, the drives are listed, however they are all marked "unavailable", thus inaccessible as well. This functionality existed before and after the registry fix above.
Any thoughts on how to get this to work?!
The registry key is not supported. I'd re-run the script to map your drives after you elevate, or else use UNC paths instead of mapped drives.
In ref. to http://technet2.microsoft.com/WindowsVista/en/library/5ae8da2a-878e-48db-a3c1-4be6ac7cf7631033.mspx?mfr=true
If the user is NOT an administrator on the Vista computer to which they are logging, the standard drive mapping script (XP) works; but the launchapp approach does not.
If they ARE an administrator, then the standard mapping script fails; but the launchapp approach works.
Steve.Darnall
I guess we are seeing similar issue when we execute our setup program from a network mapped drive in explorer but don't see that drive in our setup program (InstallShield 12). Any solution or workaround for us to try out?
We should be catching and detecting the launch of the setup program and then mapping that over so you can execute after you elevate. What exactly are you doing in the setup that isn't seeing this? I'm not familiar with all of the versions of InstallShield out there. Are you creating an MSI? Is this a custom action? How are you retrieving the mapped drive? What are you then trying to do with it?
Chris,
We're porting a legacy app that uses Wise Install System.
Our app uses mapped drives; it can't use UNC.
I, too, am having trouble getting mapped drives to be visible to the Wise Installer. Whether (as we prefer so we avoid your scanning a 100mb file) I use a tiny Setup.exe stub marked as RequiresAdmin which simply shells to the Wise-created .exe, or just run the Wise .exe standalone, no mapped drives are seen by the installer.
As a developer, I'm running as an admin. I believe that EnableLinkedConnections is necessary for me to see the mapped drives. But as a standard user, I've yet to be able to see them from the elevated Wise installer, even if it's launched from the Explorer.
In the past we've had users map drives in the Windows Explorer and then run our installer and then our app. But it appears that there are additional steps required here?
I'm not sure what steps are required, or how to make them straight-forward for our end-users.
Any help?
Thanks.
Tom (across Lake Washington in Seattle)