Re: proposed changes to UAC mechanism, RunAs, and documentation

You're barking up the wrong tree. Try here:
https://feedback.windowsvista.microsoft.com/default.aspx?productkey=winvista&mkt=en-us&backurl=http://support.microsoft.com/gp/cp_vista_master&scrx=1


"stumppc" <stumppc@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:40809FED-17C0-4EB9-A304-68D6F74733B1@xxxxxxxxxxxxxxxx
Hello -

Someone please forward the comments below to people working on Vista
Service
Pack 2:

The "Run as Administrator" option that appears when you right-click on a
shortcut or program should be changed in Vista to say "Run Elevated as
Current User". The Run As Administrator doesn't prompt for credentials in
instances where a Local Admin is already logged in, breaking the
functionality of "Run As" as it was previously created and used in
XP/2000.
If anything, Vista should have "Run Elevated as Current User", "Run
Elevated
as Different User", and "Run Standard as Different User" options instead
of
the current Run as Administrator. What if you are a power user - the "Run
as
Administrator" option may need to be used by that user - that is very
confusing to the user since they are not an administrator.

Vista's UAC implementation does not take into account or allow
administrative scripts to operate as they have in the past. I do not like
any
of the current options for getting around UAC controls/prompts that stop
or
break administrative scripts based on batch/vbs/wsh/AutoIT/KiXtart/etc.
There
needs to be a straightforward method for people to execute administrative
scripts without turning off UAC. These scripts need to be able to run
administrative functions with elevated privileges without UAC prompts.
Most
SMB organizations will not buy add-on (think MS SMS) or third party tools
to
repackage, rewrite, sign, or execute their current administrative
automation
under Vista. Only allowing signed content to run/install is not a fix of
any
sort - malware writers will just start digitally signing their stuff.
Also,
for most organizations only allowing installs/scripts to happen from
certain
locations is just not possible.

How about a new default user group in Windows like this: Local group with
automatic, silent UAC elevation? This way UAC is left intact and
administrators can choose which accounts can silently elevate their
privileges. This group should also have some security event log auditing
turned on by default.

We need two classes of accounts - those that silently elevate their
privileges and those that do not. Accounts with the silent elevation
privilege may not even be Local Admins or Domain Admins, but with special,
custom privileges instead. Just silently elevating all Local Admins is a
bad
practice that diminishes the usefulness of UAC greatly. Unfortunately that
is
the best option for most admins right now.

I notice several deficincies in Microsoft documentation about UAC posted
online:

There appears to be no differentiation between Local Administrator and
Domain Administrator. There is clearly different behavior with MMC tools
and
similar for users who are not Domain Admins and Local Administrators at
the
same time. If you are logged in as a Local Admin but not a Domain Admin
you
have to revert to things like invoking RUNAS from the CMD prompt to
properly
run your MMC tools.

There is very little info about users who have rights more than a standard
user but less than a Local Admin, like power user. The document does not
note
the fact that any user who logged in with privileges higher than standard
user appears to receive two tokens too and UAC applies in that instance as
well.

Thanks for listening,

James
MCSE +Security Server 2003, XP
CompTIA Security+

----------------
This post is a suggestion for Microsoft, and Microsoft responds to the
suggestions with the most votes. To vote for this suggestion, click the "I
Agree" button in the message pane. If you do not see the button, follow
this
link to open the suggestion in the Microsoft Web-based Newsreader and then
click "I Agree" in the message pane.


http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?mid=40809fed-17c0-4eb9-a304-68d6f74733b1&dg=microsoft.public.windows.vista.secur
ity


.

Relevant Pages

  • Re: proposed changes to UAC mechanism, RunAs, and documentation
    ... The "Run as Administrator" option that appears when you right-click on a ... Vista's UAC implementation does not take into account or allow ... We need two classes of accounts - those that silently elevate their ... user but less than a Local Admin, ...
    (microsoft.public.windows.vista.security)
  • proposed changes to UAC mechanism, RunAs, and documentation
    ... The "Run as Administrator" option that appears when you right-click on a ... Vista's UAC implementation does not take into account or allow ... Accounts with the silent elevation ... If you are logged in as a Local Admin but not a Domain Admin you ...
    (microsoft.public.windows.vista.security)
  • Re: Seltsamer Prozess der svchost lastet CPU aus - Virus?
    ... solche Zwecke aber lieber Explorer++, ... Ich lese das mal als "okay, UAC macht tatsächlich Workflows kaputt, ... Umgebungen, wo mir der Account "Administrator" nicht zu Gebote steht, ... administrative Aufgaben ausführen musst? ...
    (de.comp.security.misc)
  • Re: Quick: Where is the equivalent of the Display control panel in Vista?
    ... didn't understand how UAC works. ... designed to install with this limited set with no problem. ... Administrator, and everything goes fine. ... recognizes it as a setup file and asks to bump up the setup file. ...
    (comp.sys.mac.advocacy)
  • Vista "complaints"
    ... Recent misconceptions about Vista and UAC posted to the Focus-Apple group, ... administrator, and combined with the many configuration options Vista ... that Win XP gave her the ability to add permissions to her normal ...
    (Focus-Microsoft)