Group Policy Scripts can fail due to User Account Control
The main goal of User Account Control (UAC) is to lessen the exposure and attack surface of the operating system. UAC does this by requiring all users to run in standard user mode. This limit minimizes the ability for users to make changes that could destabilize their computers or unintentionally expose the network to viruses through undetected malicious software (also called malware) that has infected their computer.
With UAC, you can run most applications, components, and processes with a limited privilege, but have "elevation potential" for specific administrative tasks and application functions. Windows accomplishes this by using two access tokens for each user: limited and elevated access tokens. Access tokens identify the user, the user's groups, and the user's privileges. The system uses access tokens to control access to securable objects and to control the ability of the user to perform various system-related operations on the local computer.
An elevated token, for a local administrator, includes and enables all of the administrative privileges. UAC requires local administrators to use their elevated token when attempting to perform a system-only task or administrative task. A limited token, for a local administrator, includes all of the administrative privileges; however, these privileges are disabled. This allows Windows to view the administrative user and a normal user, with the option to elevate their privileges.
By default, all users logging on to Windows Vista use their full token to process Group Policy and logon scripts. However, they use their limited user token to load the desktop and all subsequent processes. Non-administrative limited and elevated tokens are mostly identical, with regard to privileges and groups. Therefore, a process started with a non-administrative limited user token can view processes started with a non-administrative elevated token. Windows allows this because the viewing application does not require any elevation to view the process started with the elevated token.
Windows processes a locally logging on administrator the same way. Group Policy and logon scripts process using the elevated user token, and the desktop and all subsequent processes use the limited token. However, there is a privilege difference between the limited and elevated user token. Therefore, Windows restricts processes started with a limited token from the ability to share information with processes started with the elevated token.
UAC may prevent Group Policy logon scripts from appearing to work properly. For example, a domain environment contains a GPO that includes a logon script to map network drives. A non-administrative user logs on to the domain from a Windows Vista computer. After Windows Vista loads the desktop, the non-administrative user starts Windows Explorer. The user sees their mapped drives. Under the same environment, an administrative user logs on to the domain from a Windows Vista computer. After Windows Vista loads the desktop, the administrative user starts Windows Explorer. The user does not see their mapped drives.
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 limited token while the drives were mapped using the elevated token.
To get around this issue, administrative users should map network drives under the limited user token. This mapping is accomplished by using the launchapp.wsf script shown in Appendix A, which works by scheduling the commands using the task scheduler. The task scheduler launches the script under the administrative full token, thereby allowing Windows Explorer, other limited token processes, and the elevated token process to view the mapped network drives.