Hi Rick,
Thanks for your comments. I'm new to the UAC team, but I'll try to answer
as completely as possible.
UAC is intended to allow users to run without being administrator (among
other goals). This is really important for the split-token admin case, but
also very important for standard users (it creates the elevation pathway to
allow them to do an admin task or get an admin to come and elevate to do the
task for them). Standard users who are never allowed to elevate *still* get
some benefit from UAC, because having UAC turned on enables virtualization
features that allow apps to run as a standard user that didn't previously
run that way.
In general with this issue, this is an organization in transition that wants
to run users as standard users, but that has some remaining issues. This
method was provided as a way to get them closer, but buy time towards
solving all the problems. There is some security risk, but it's less
exposure than running without UAC enabled.
In a lot of ways, UAC helps you to see problems that were there already.
For standard users (as I understand it), this mapped drive issue already
existed. UAC puts us on a path to running as standard user, but there are
some fundamental issues that remain. In many cases, we have provided
mitigations that allow you to defer part of that effort but we can't help
the fundamental security issues that may accompany them (I imagine that in
general these are security issues that you were already accepting). So to
get the most out of UAC, you should find the right way to resolve these
issues for all users.
To that end, you might try getting the logon script to run as both elevated
and non-elevated admin and mapping the drives in both. Because the mapping
was controlled by a trusted source in both instances, you're safe and didn't
need to share mapped drives across the elevation boundary. I've included
some snippets from a bug discussing the issue below:
----------------------------
Description of the issue:
User GP Scripts can be run either in LUA mode or elevated mode.
Each of the modes has its corresponding issues:
1. LUA/UAP mode: Script runs in the context of the LUA token. if
the script calls into any code that might need elevation, a LUA prompt will
be generated. User will need to interact with the prompt to continue and
will create complications in various script modes like async/hidden mode.
2. Elevated mode: Script runs in the context of full admin token.
Certain operations like drive mapping has issues. A drive mapped in this
mode is not visible to the users when they are logged in. Tracked by bug
1575721.
GP currently runs the scripts in elevated mode and thus we hit issue in
1575721 as drives mapped in elevated user context are not visible to LUA
user.
Workaround:
1. There is way to launch a script in LUA/UAP context from elevated
process using TaskScheduler APIs.
• I have written a sample script that does this. It is attached
with this mail. Usage: cscript launchapp.wsf <AppPath>
2. If IT Admin needs to run any of the GP scripts in LUA/UAP mode
[like the script that maps drive for the user], then it needs to use the
script [sample script above] to launch the existing script in LUA/UAP mode.
• Lets suppose the GP logon script Script-UAP.wsf needs to run in
LUA/UAP context because it is mapping drives for the user.
• Create another script Launch-Script-UAP.wsf which will just use
the sample script above to launch Script-UAP.wsf in LUA/UAP mode. Deploy
this script as GP logon script.
More information in
http://technet2.microsoft.com/Windo...878e-48db-a3c1-4be6ac7cf7631033.mspx?mfr=true .
Search for launchapp.wsf
HTH,
James Finnigan[MSFT] (
http://blogs.msdn.com/jamesfi)
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
Rick S. said:
Thanks for your response.
Isn't UAC essentially intended to protect administrative users who are not
otherwise restricted as standard users? What are the risks of turning it
off
(to fix the logon script issue) for standard users? As I understand it,
the
EnableLinkedConnections setting does not "join" the limited session to the
elevated session in any way but only makes sure that mapped resources are
shared. As far as I know, mapped resources have always been "one way" so I
don't think the user exposes himself by having concurrent mapped drives in
both contexts.
In any case, it is certainly the most elegant workaround I've seen. I
can't
believe Microsoft would make something as common as mapping drives in a
logon
script so difficult. It seems that every time I turn a corner, there's
another gotcha in Vista that requires hours of research and trial and
error
to resolve.
Problems aside, there's much that I appreciate about Vista. It's to bad it
comes at the expense of performance.
Rick S.
Here's what I've gleaned from internal discussions around this:
The "EnableLinkedConnections" policy relies on the user being a member
of the Administrators group and sharing across the boundary between
non-elevated and elevated (which can lead to intentionally mis-
directed drive mappings by malware). It is essentially a workaround
for customers that are in the process of moving their users to
standard user, but need to do so gradually and keep them as members of
the Administrators group in the short-term.
If you have a reliance on mapped drives across the elevation boundary,
you'll have issues running as a standard user (with a separate admin
account) and potentially in other scenarios as well.
HTH,
James Finnigan[MSFT] (
http://blogs.msdn.com/jamesfi)
This posting is provided "AS IS" with no warranties, and confers no
rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
