RE: Vista group policy, 2003 server...help ?
- From: Ashish <Ashish@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 1 Jun 2007 03:44:01 -0700
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. Nonadministrative
limited and elevated tokens are mostly identical, with regard to privileges
and groups. Therefore, a process started with a nonadministrative limited
user token can view processes started with a nonadministrative 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 Group Policy object that
includes a logon script to map network drives. A nonadministrative user logs
on to the domain from a Windows Vista computer. After Windows Vista loads the
desktop, the nonadministrative 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.
To configure launchapp.wsf to postpone the execution of a logon script
1. Copy the logon script and the launchapp.wsf script to a network share.
2. Start Group Policy Management Console (GPMC). In GPMC, right-click the
GPO you want to modify, and then click Edit.
3. In the User Configuration node, expand Windows Settings, and then click
Scripts.
4. Right-click Logon, and then click Properties.
5. In the Logon Properties dialog box, click Add.
6. In the Script Name box, type launchapp.wsf
7. In the Script Parameters box, type the full path and name to logon.bat
More Info:
http://technet2.microsoft.com/WindowsVista/en/library/5ae8da2a-878e-48db-a3c1-4be6ac7cf7631033.mspx?mfr=true
Ashish
"Someone" wrote:
Hi,.
I've been looking around and I can not find a clear answer, so I figured
someone here might be able to lead me in the correct direction.
I have a 2003 server (PDC) and have a bunch of policys run to map network
drives, home share and re-direct "My Documents" to the home share. They
have always worked fine on 2000 and XP boxes (and still do).
As we are thinking about moving some clients to Vista, I setup a test
machine with Vista Ultimate and added it to the domain. It's not obeying any
of the policys, it will connect to the domain and can manually map drives
but, none of the policys work.
Do I need to adjust some Vista setting or do some changes on the server to
get them work under vista ???
Thanks for anyone's help here....
- Prev by Date: Re: EFS GPO not being applied
- Next by Date: RE: Windows 2003 File Server speed issues
- Previous by thread: Re: EFS GPO not being applied
- Next by thread: Re: Lost DC login password
- Index(es):
Relevant Pages
|
