Guest stumppc Posted August 26, 2008 Posted August 26, 2008 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 Quote
Guest Mark H Posted August 26, 2008 Posted August 26, 2008 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 Quote
Guest stumppc Posted August 26, 2008 Posted August 26, 2008 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> Quote
Guest Paul Montgomery Posted August 26, 2008 Posted August 26, 2008 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! Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.