Article ID: 2019185 - View products that this article applies to.
With User Account Control (UAC) enabled, you may receive the following error when attempting to copy a file from a mapped drive to a local directory:
The underlying cause is UAC and the interaction with split token. When an administrator logs onto a machine with Admin Approval Mode enabled (AAM), the user is granted two access tokens: a full administrator access token and a filtered standard user access token. By default, when a member of the local Administrators group logs on, the administrative Windows privileges are disabled and elevated user rights are removed, resulting in the standard user access token. The standard user access token is then used to launch the desktop (Explorer.exe). Explorer.exe is the parent process from which all other user-initiated processes inherit their access token. As a result, all applications run as a standard user by default unless a user provides consent or credentials to approve an application to use a full administrative access token. Contrasting with this process, when a standard user logs on, only a standard user access token is created. This standard user access token is then used to launch the desktop.
The following conditions must be in place for the error to occur:
The user has mapped a drive using either the Map Network Drive option in Windows Explorer or by running the net use command in a non-elevated command prompt. Mapped drives can be seen by running net use as a standard user from a non-elevated command prompt. In this case the drive was mapped as a standard user.
Running the same command in an elevated command prompt (selecting Run as Administrator), there is no mapped drive listed.
This clearly shows that the elevated session does not see the standard user’s mapped drive and therefore is unable to complete the copy operation. This behavior is by design.
By default, AAM is enabled for accounts that are members of the local Administrators group. The setting can be found in the Security Options node of Local Policy, under Security Settings and is configurable with the Local Group Policy Editor (secpol.msc) and with the Group Policy Management Console (GPMC) (gpedit.msc). For more information on UAC see the following article.
When the administrative user logs on, Windows processes the logon scripts using the elevated token. The script actually works and maps the drive. However, Windows blocks the view of the mapped network drives because the desktop uses the filtered token while the drives were mapped using the elevated (full administrator) token.
Before Windows 2000 SP2, device names (i.e. mapped drives) remained globally visible until explicitly removed or the system restarted. For security reasons, we modified this behavior starting with Windows 2000 SP2. From this point forward, all devices are associated with an authentication ID (LUID), which is 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 the CreateProcessAsUser API, but UAC dramatically increases the number of users who will be using these concepts.
The result is that 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, using the WNetAddConnection API, or otherwise). There is a mitigation in place for the scenario of launching from Windows Explorer. If you double-click on an executable that is either detected as an installation file or is manifested as requireAdministrator, Windows can detect that it was elevated and that there is an error indicating the path was not found, and copy that drive mapping over from the original LUID. However, that is the only scenario that is automated.
(http://go.microsoft.com/fwlink/?LinkId=151500)for other considerations.