Vista - Login scripts vs UAC

I'm running into a problem that login scripts run with elevated
privileges, whereas the user does not, meaning that I can't share drives
automatically.

The only solutions I can find so far are cheap hacks using the task
scheduler, which I don't really considered acceptable.

Are there any other tricks I'm missing to share a few folders out to
users automatically?

I'm on a Windows 2003 active directory using group policies to push the
login script, Vista on all client machines.
--
Insert something clever here.

If all else fails could you add credentials to the logon script? The
username and password need not be THE administrator, just an account with
permissions to the shares.

http://computerperformance.co.uk/Log..._arguments.htm

Guy


"DevilsPGD" <spam_narf_spam@crazyhat.net> wrote in message
news:nk4lt29ks89klps0bq87kjofol09dlpnnc@4ax.com...
> I'm running into a problem that login scripts run with elevated
> privileges, whereas the user does not, meaning that I can't share drives
> automatically.
>
> The only solutions I can find so far are cheap hacks using the task
> scheduler, which I don't really considered acceptable.
>
> Are there any other tricks I'm missing to share a few folders out to
> users automatically?
>
> I'm on a Windows 2003 active directory using group policies to push the
> login script, Vista on all client machines.
> --
> Insert something clever here.

"DevilsPGD" <spam_narf_spam@crazyhat.net> wrote in message
news:nk4lt29ks89klps0bq87kjofol09dlpnnc@4ax.com...
> I'm running into a problem that login scripts run with elevated
> privileges, whereas the user does not, meaning that I can't share drives
> automatically.

Hmm, you don't need elevated privileges to map a network drive. Can you post
your script (without sensitive details) so we can figure out which part
causes UAC and if this part can be moved to *startup* scripts?

Wait a minute... I think I got it. Do you mean that you are sharing local
workstation drives with logon script? If yes, use startup scripts instead.

Basically, the rule for scripts is: if operation/setting is system-wide
(read "requires admin rights"), use startup scripts. If it is a per-user
setting or operation, use logon scripts. It is not Vista-specific and apply
to all recent Windows versions in domain environment.

There's also a registry key that controls automatic creation of
administrative (hidden) shares.

--
Alexander Suhovey

In message <etS8YmQVHHA.1200@TK2MSFTNGP04.phx.gbl> "Alexander Suhovey"
<asuhovey@gmail.com> wrote:

>"DevilsPGD" <spam_narf_spam@crazyhat.net> wrote in message
>news:nk4lt29ks89klps0bq87kjofol09dlpnnc@4ax.com...
>> I'm running into a problem that login scripts run with elevated
>> privileges, whereas the user does not, meaning that I can't share drives
>> automatically.
>
>Hmm, you don't need elevated privileges to map a network drive. Can you post
>your script (without sensitive details) so we can figure out which part
>causes UAC and if this part can be moved to *startup* scripts?

@ECHO OFF
NET USE M: /d
NET USE M: \\yakko\media /PERSISTENT:NO /YES

>Wait a minute... I think I got it. Do you mean that you are sharing local
>workstation drives with logon script? If yes, use startup scripts instead.

My startup scripts work great (and they do most of the important stuff).
Unfortunately startup scripts aren't what I'm trying to do... Read on

>Basically, the rule for scripts is: if operation/setting is system-wide
>(read "requires admin rights"), use startup scripts. If it is a per-user
>setting or operation, use logon scripts. It is not Vista-specific and apply
>to all recent Windows versions in domain environment.

Understood -- Sorry, from your response, I wasn't clear about the
problem I'm having.

First off, for non-administrator users there is no problem, the drive
letters get mapped properly. Also, if an administrator logs in on a
UAC-disabled system, there is no problem.

The problem is only reproducible when an administrator logs in to a UAC
enabled system. The issue is that login scripts *are* run elevated
(without a prompt to the user, thank gawd), and when an elevated program
creates a drive mapping, that drive mapping isn't seen by non-elevated
apps.

As a I test, I set my login script to be interactive, and to run
asynchronously, and launched CMD. From there, I performed a number of
actions which require elevation (ipconfig /flushdns is a nice easy one)

(This is fantastic from a system management point of view, since it
allows me to install and configure legacy apps for users that would
otherwise trigger UAC popups)

I was able to confirm that my "M" drive does get mapped in the logon
script, but only within the context of the logon script.

To reproduce this, open up a elevated command prompt and a non-elevated
command prompt, and type "net use y: \\something\valid" and "net use z:
\\something\elsevalid" in the elevated and non-elevated windows
respectively, then open up Windows Explorer, you'll see Z:, but not Y:

NOW... All that being said, I had a shower-epiphany today, and I think
I've got a hack. I'll try it once my VMs are done the test I'm running
right now and I have some time to poke around, but...

My thinking is to create a "logon-elevated" and a "logon-lua" script,
set the logon script to run asynchronously, and have the logon-elevated
script add a shortcut to the user's start/programs/startup that launches
the logon-lua script. The logon-lua script will remove itself from the
start menu (just for tidy housekeeping purposes), and do whatever it
needs to do.
--
Insert something clever here.

That sounds like it would work. You might want to use the Run regkey
instead of the start key.

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.

"DevilsPGD" <spam_narf_spam@crazyhat.net> wrote in message
newsnnmt2pt0muf1u2a9015s28vsovopqcmb5@4ax.com...
> In message <etS8YmQVHHA.1200@TK2MSFTNGP04.phx.gbl> "Alexander Suhovey"
> <asuhovey@gmail.com> wrote:
>
>>"DevilsPGD" <spam_narf_spam@crazyhat.net> wrote in message
>>news:nk4lt29ks89klps0bq87kjofol09dlpnnc@4ax.com...
>>> I'm running into a problem that login scripts run with elevated
>>> privileges, whereas the user does not, meaning that I can't share drives
>>> automatically.
>>
>>Hmm, you don't need elevated privileges to map a network drive. Can you
>>post
>>your script (without sensitive details) so we can figure out which part
>>causes UAC and if this part can be moved to *startup* scripts?
>
> @ECHO OFF
> NET USE M: /d
> NET USE M: \\yakko\media /PERSISTENT:NO /YES
>
>>Wait a minute... I think I got it. Do you mean that you are sharing local
>>workstation drives with logon script? If yes, use startup scripts instead.
>
> My startup scripts work great (and they do most of the important stuff).
> Unfortunately startup scripts aren't what I'm trying to do... Read on
>
>>Basically, the rule for scripts is: if operation/setting is system-wide
>>(read "requires admin rights"), use startup scripts. If it is a per-user
>>setting or operation, use logon scripts. It is not Vista-specific and
>>apply
>>to all recent Windows versions in domain environment.
>
> Understood -- Sorry, from your response, I wasn't clear about the
> problem I'm having.
>
> First off, for non-administrator users there is no problem, the drive
> letters get mapped properly. Also, if an administrator logs in on a
> UAC-disabled system, there is no problem.
>
> The problem is only reproducible when an administrator logs in to a UAC
> enabled system. The issue is that login scripts *are* run elevated
> (without a prompt to the user, thank gawd), and when an elevated program
> creates a drive mapping, that drive mapping isn't seen by non-elevated
> apps.
>
> As a I test, I set my login script to be interactive, and to run
> asynchronously, and launched CMD. From there, I performed a number of
> actions which require elevation (ipconfig /flushdns is a nice easy one)
>
> (This is fantastic from a system management point of view, since it
> allows me to install and configure legacy apps for users that would
> otherwise trigger UAC popups)
>
> I was able to confirm that my "M" drive does get mapped in the logon
> script, but only within the context of the logon script.
>
> To reproduce this, open up a elevated command prompt and a non-elevated
> command prompt, and type "net use y: \\something\valid" and "net use z:
> \\something\elsevalid" in the elevated and non-elevated windows
> respectively, then open up Windows Explorer, you'll see Z:, but not Y:
>
> NOW... All that being said, I had a shower-epiphany today, and I think
> I've got a hack. I'll try it once my VMs are done the test I'm running
> right now and I have some time to poke around, but...
>
> My thinking is to create a "logon-elevated" and a "logon-lua" script,
> set the logon script to run asynchronously, and have the logon-elevated
> script add a shortcut to the user's start/programs/startup that launches
> the logon-lua script. The logon-lua script will remove itself from the
> start menu (just for tidy housekeeping purposes), and do whatever it
> needs to do.
> --
> Insert something clever here.

The following seems to work and should be able to be set by GPO.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
EnableLinkedConnections=dword:1

See http://support.microsoft.com/default.aspx/kb/937624

Is there any reason not to use this?

"James Finnigan [MSFT]" wrote:

> That sounds like it would work. You might want to use the Run regkey
> instead of the start key.
>
> 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.
>
> "DevilsPGD" <spam_narf_spam@crazyhat.net> wrote in message
> newsnnmt2pt0muf1u2a9015s28vsovopqcmb5@4ax.com...
> > In message <etS8YmQVHHA.1200@TK2MSFTNGP04.phx.gbl> "Alexander Suhovey"
> > <asuhovey@gmail.com> wrote:
> >
> >>"DevilsPGD" <spam_narf_spam@crazyhat.net> wrote in message
> >>news:nk4lt29ks89klps0bq87kjofol09dlpnnc@4ax.com...
> >>> I'm running into a problem that login scripts run with elevated
> >>> privileges, whereas the user does not, meaning that I can't share drives
> >>> automatically.
> >>
> >>Hmm, you don't need elevated privileges to map a network drive. Can you
> >>post
> >>your script (without sensitive details) so we can figure out which part
> >>causes UAC and if this part can be moved to *startup* scripts?
> >
> > @ECHO OFF
> > NET USE M: /d
> > NET USE M: \\yakko\media /PERSISTENT:NO /YES
> >
> >>Wait a minute... I think I got it. Do you mean that you are sharing local
> >>workstation drives with logon script? If yes, use startup scripts instead.
> >
> > My startup scripts work great (and they do most of the important stuff).
> > Unfortunately startup scripts aren't what I'm trying to do... Read on
> >
> >>Basically, the rule for scripts is: if operation/setting is system-wide
> >>(read "requires admin rights"), use startup scripts. If it is a per-user
> >>setting or operation, use logon scripts. It is not Vista-specific and
> >>apply
> >>to all recent Windows versions in domain environment.
> >
> > Understood -- Sorry, from your response, I wasn't clear about the
> > problem I'm having.
> >
> > First off, for non-administrator users there is no problem, the drive
> > letters get mapped properly. Also, if an administrator logs in on a
> > UAC-disabled system, there is no problem.
> >
> > The problem is only reproducible when an administrator logs in to a UAC
> > enabled system. The issue is that login scripts *are* run elevated
> > (without a prompt to the user, thank gawd), and when an elevated program
> > creates a drive mapping, that drive mapping isn't seen by non-elevated
> > apps.
> >
> > As a I test, I set my login script to be interactive, and to run
> > asynchronously, and launched CMD. From there, I performed a number of
> > actions which require elevation (ipconfig /flushdns is a nice easy one)
> >
> > (This is fantastic from a system management point of view, since it
> > allows me to install and configure legacy apps for users that would
> > otherwise trigger UAC popups)
> >
> > I was able to confirm that my "M" drive does get mapped in the logon
> > script, but only within the context of the logon script.
> >
> > To reproduce this, open up a elevated command prompt and a non-elevated
> > command prompt, and type "net use y: \\something\valid" and "net use z:
> > \\something\elsevalid" in the elevated and non-elevated windows
> > respectively, then open up Windows Explorer, you'll see Z:, but not Y:
> >
> > NOW... All that being said, I had a shower-epiphany today, and I think
> > I've got a hack. I'll try it once my VMs are done the test I'm running
> > right now and I have some time to poke around, but...
> >
> > My thinking is to create a "logon-elevated" and a "logon-lua" script,
> > set the logon script to run asynchronously, and have the logon-elevated
> > script add a shortcut to the user's start/programs/startup that launches
> > the logon-lua script. The logon-lua script will remove itself from the
> > start menu (just for tidy housekeeping purposes), and do whatever it
> > needs to do.
> > --
> > Insert something clever here.
>
>

On Jun 14, 4:36 pm, Rick S. <R...@discussions.microsoft.com> wrote:
> The following seems to work and should be able to be set by GPO.
>
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Syste*m
> EnableLinkedConnections=dword:1
>
> Seehttp://support.microsoft.com/default.aspx/kb/937624
>
> Is there any reason not to use this?
>
>
>
> "James Finnigan[MSFT]" wrote:
> > That sounds like it would work. You might want to use the Run regkey
> > instead of the start key.
>
> > 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.
>
> > "DevilsPGD" <spam_narf_s...@crazyhat.net> wrote in message
> >newsnnmt2pt0muf1u2a9015s28vsovopqcmb5@4ax.com...
> > > In message <etS8YmQVHHA.1...@TK2MSFTNGP04.phx.gbl> "Alexander Suhovey"
> > > <asuho...@gmail.com> wrote:
>
> > >>"DevilsPGD" <spam_narf_s...@crazyhat.net> wrote in message
> > >>news:nk4lt29ks89klps0bq87kjofol09dlpnnc@4ax.com...
> > >>> I'm running into a problem that login scripts run with elevated
> > >>> privileges, whereas the user does not, meaning that I can't share drives
> > >>> automatically.
>
> > >>Hmm, you don't need elevated privileges to map a network drive. Can you
> > >>post
> > >>your script (without sensitive details) so we can figure out which part
> > >>causes UAC and if this part can be moved to *startup* scripts?
>
> > > @ECHO OFF
> > > NET USE M: /d
> > > NET USE M: \\yakko\media /PERSISTENT:NO /YES
>
> > >>Wait a minute... I think I got it. Do you mean that you are sharing local
> > >>workstation drives with logon script? If yes, use startup scripts instead.
>
> > > My startup scripts work great (and they do most of the important stuff).
> > > Unfortunately startup scripts aren't what I'm trying to do... Read on
>
> > >>Basically, the rule for scripts is: if operation/setting is system-wide
> > >>(read "requires admin rights"), use startup scripts. If it is a per-user
> > >>setting or operation, use logon scripts. It is not Vista-specific and
> > >>apply
> > >>to all recent Windows versions in domain environment.
>
> > > Understood -- Sorry, from your response, I wasn't clear about the
> > > problem I'm having.
>
> > > First off, for non-administrator users there is no problem, the drive
> > > letters get mapped properly. Also, if an administrator logs in on a
> > > UAC-disabled system, there is no problem.
>
> > > The problem is only reproducible when an administrator logs in to a UAC
> > > enabled system. The issue is that login scripts *are* run elevated
> > > (without a prompt to the user, thank gawd), and when an elevated program
> > > creates a drive mapping, that drive mapping isn't seen by non-elevated
> > > apps.
>
> > > As a I test, I set my login script to be interactive, and to run
> > > asynchronously, and launched CMD. From there, I performed a number of
> > > actions which require elevation (ipconfig /flushdns is a nice easy one)
>
> > > (This is fantastic from a system management point of view, since it
> > > allows me to install and configure legacy apps for users that would
> > > otherwise trigger UAC popups)
>
> > > I was able to confirm that my "M" drive does get mapped in the logon
> > > script, but only within the context of the logon script.
>
> > > To reproduce this, open up a elevated command prompt and a non-elevated
> > > command prompt, and type "net use y: \\something\valid" and "net use z:
> > > \\something\elsevalid" in the elevated and non-elevated windows
> > > respectively, then open up Windows Explorer, you'll see Z:, but not Y:
>
> > > NOW... All that being said, I had a shower-epiphany today, and I think
> > > I've got a hack. I'll try it once my VMs are done the test I'm running
> > > right now and I have some time to poke around, but...
>
> > > My thinking is to create a "logon-elevated" and a "logon-lua" script,
> > > set the logon script to run asynchronously, and have the logon-elevated
> > > script add a shortcut to the user's start/programs/startup that launches
> > > the logon-lua script. The logon-lua script will remove itself from the
> > > start menu (just for tidy housekeeping purposes), and do whatever it
> > > needs to do.
> > > --
> > > Insert something clever here.- Hide quoted text -
>
> - Show quoted text -

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

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.

"jamesfinnigan@gmail.com" wrote:

> 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
>
>

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/Window....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." <RickS@discussions.microsoft.com> wrote in message
news:8DE38E2C-4715-4A6D-880B-CF0D63B12FF2@microsoft.com...
> 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.
>
> "jamesfinnigan@gmail.com" wrote:
>
>> 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
>>
>>