proposed changes to UAC mechanism, RunAs, and documentation

S

stumppc

Guest
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/newsg....vista.security
 
You're barking up the wrong tree. Try here:
https://feedback.windowsvista.microsoft.com...a_master&scrx=1


"stumppc" <stumppc@discussions.microsoft.com> wrote in message
news:40809FED-17C0-4EB9-A304-68D6F74733B1@microsoft.com...<span style="color:blue">
> Hello -
>
> Someone please forward the comments below to people working on Vista</span>
Service<span style="color:blue">
> 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</span>
XP/2000.<span style="color:blue">
> If anything, Vista should have "Run Elevated as Current User", "Run</span>
Elevated<span style="color:blue">
> as Different User", and "Run Standard as Different User" options instead</span>
of<span style="color:blue">
> the current Run as Administrator. What if you are a power user - the "Run</span>
as<span style="color:blue">
> 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</span>
any<span style="color:blue">
> of the current options for getting around UAC controls/prompts that stop</span>
or<span style="color:blue">
> break administrative scripts based on batch/vbs/wsh/AutoIT/KiXtart/etc.</span>
There<span style="color:blue">
> 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.</span>
Most<span style="color:blue">
> SMB organizations will not buy add-on (think MS SMS) or third party tools</span>
to<span style="color:blue">
> repackage, rewrite, sign, or execute their current administrative</span>
automation<span style="color:blue">
> under Vista. Only allowing signed content to run/install is not a fix of</span>
any<span style="color:blue">
> sort - malware writers will just start digitally signing their stuff.</span>
Also,<span style="color:blue">
> for most organizations only allowing installs/scripts to happen from</span>
certain<span style="color:blue">
> 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</span>
bad<span style="color:blue">
> practice that diminishes the usefulness of UAC greatly. Unfortunately that</span>
is<span style="color:blue">
> 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</span>
and<span style="color:blue">
> similar for users who are not Domain Admins and Local Administrators at</span>
the<span style="color:blue">
> same time. If you are logged in as a Local Admin but not a Domain Admin</span>
you<span style="color:blue">
> have to revert to things like invoking RUNAS from the CMD prompt to</span>
properly<span style="color:blue">
> 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</span>
note<span style="color:blue">
> 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</span>
this<span style="color:blue">
> link to open the suggestion in the Microsoft Web-based Newsreader and then
> click "I Agree" in the message pane.
>
></span>
http://www.microsoft.com/communities/newsg...ows.vista.secur
ity
 
Thanks - I looked all over for that link and could not find it for some
reason. Would you believe it only allows for a 1000 character submision?
Whoever made that feedback submission page makes MS look like they don't
really want to hear from users...

"Mark H" wrote:
<span style="color:blue">
> You're barking up the wrong tree. Try here:
> https://feedback.windowsvista.microsoft.com...a_master&scrx=1
>
>
> "stumppc" <stumppc@discussions.microsoft.com> wrote in message
> news:40809FED-17C0-4EB9-A304-68D6F74733B1@microsoft.com...<span style="color:green">
> > Hello -
> >
> > Someone please forward the comments below to people working on Vista</span>
> Service<span style="color:green">
> > 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</span>
> XP/2000.<span style="color:green">
> > If anything, Vista should have "Run Elevated as Current User", "Run</span>
> Elevated<span style="color:green">
> > as Different User", and "Run Standard as Different User" options instead</span>
> of<span style="color:green">
> > the current Run as Administrator. What if you are a power user - the "Run</span>
> as<span style="color:green">
> > 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</span>
> any<span style="color:green">
> > of the current options for getting around UAC controls/prompts that stop</span>
> or<span style="color:green">
> > break administrative scripts based on batch/vbs/wsh/AutoIT/KiXtart/etc.</span>
> There<span style="color:green">
> > 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.</span>
> Most<span style="color:green">
> > SMB organizations will not buy add-on (think MS SMS) or third party tools</span>
> to<span style="color:green">
> > repackage, rewrite, sign, or execute their current administrative</span>
> automation<span style="color:green">
> > under Vista. Only allowing signed content to run/install is not a fix of</span>
> any<span style="color:green">
> > sort - malware writers will just start digitally signing their stuff.</span>
> Also,<span style="color:green">
> > for most organizations only allowing installs/scripts to happen from</span>
> certain<span style="color:green">
> > 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</span>
> bad<span style="color:green">
> > practice that diminishes the usefulness of UAC greatly. Unfortunately that</span>
> is<span style="color:green">
> > 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</span>
> and<span style="color:green">
> > similar for users who are not Domain Admins and Local Administrators at</span>
> the<span style="color:green">
> > same time. If you are logged in as a Local Admin but not a Domain Admin</span>
> you<span style="color:green">
> > have to revert to things like invoking RUNAS from the CMD prompt to</span>
> properly<span style="color:green">
> > 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</span>
> note<span style="color:green">
> > 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</span>
> this<span style="color:green">
> > link to open the suggestion in the Microsoft Web-based Newsreader and then
> > click "I Agree" in the message pane.
> >
> ></span>
> http://www.microsoft.com/communities/newsg...ows.vista.secur
> ity
>
>
> </span>
 
On Tue, 26 Aug 2008 05:45:13 -0700, stumppc
<stumppc@discussions.microsoft.com> wrote:
<span style="color:blue">
>Thanks - I looked all over for that link and could not find it for some
>reason. Would you believe it only allows for a 1000 character submision?
>Whoever made that feedback submission page makes MS look like they don't
>really want to hear from users...</span>

Split your submission into smaller bits... like only one suggestion
per submission.

DUH!
 
Back
Top