First posted to MSDN on Feb, 19 2007
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.
