Sign in to follow this  
Followers 0
jstump1

Vista UAC - your feedback please

1 post in this topic

Hi All -

I just fired off a couple of emails to Microsoft (probably won't do any good) but I thought I would post it here. If anyone is interested in this topic please leave feedback. I am a admin-for-hire who is finally trying to come up with some best practices for implementing Vista on SMB networks. Like it or not UAC is here to stay and needs to be left turned on in Vista, otherwise more problems will arise in the future. Right now I think I am stuck enabling/disabling UAC via Group Policy from time to time for my AutoIT and other scripts or allowing automatic/silent privilege elevation for Local Admins (another Group Policy setting).

Do any of you developers think it is possible to create an installable service that would allow AutoIT users to circumvent UAC prompts, kind of like how scheduled events do?

Here is my response to this junk documentation from Microsoft:

http://technet.microsoft.com/en-us/library/cc709628.aspx

Hello -

I've been studying UAC for a couple of weeks now and I notice several deficincies in your documentation.

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.

Sidenote - please forward 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 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 built-in 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.

Thanks for listening,

Share this post


Link to post
Share on other sites



Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0