The end result for many IT departments was an inconsistent user environment, where the security settings often varied wildly from machine to machine. The additional administrative overhead was reflected in more instances of reported malware, an increase in helpdesk calls, the necessity to reconfigure (or even worse, re-image) user machines, restore data on a more frequent basis and so on.
The first step in implementing UAC was to revamp how User Accounts worked in Windows Vista. When looking at a basic clean install of Windows Vista, there are four basic users / groups to consider:
OK - looking at the list above, it's very easy to get confused about what's going on with User Accounts. By default, all users (except the Built-In administrator) run as Standard users on Windows Vista. Only the Built-In Administrator runs with unrestricted access. By the way - in Windows Vista, the built-in Administrator account is disabled by default! By disabling the Built-In Administrator account, one of the most common attack vectors against poorly configured systems is mitigated. Something to note at this point is that with the Built-In Administrator account disabled, you cannot use that account to log into safe mode. Also, if the Built-In administrator is the only active local administrator account detected on the system during an upgrade from Windows XP to Windows Vista, this account remains enabled. However, the account will be put into Admin Approval mode, which means that it is subject to UAC restrictions.
Therefore,Windows Vista requires you to create an Administrative account during the setup process. When you log on to Windows Vista with this account, two versions of the account's access token are created. The first one, is the administrative level token that has the full rights and privileges. The second token is a standard user token that has no administrative rights.
So what happens when a user with Administrative rights wants to perform an Administrative task on the system? In previous versions of Windows, Standard users would have either had to log off or invoke RunAs to pass administrative credentials. However, with UAC, Administrative users are prompted to provide confirmation when they attempt to perform administrative tasks. This is known as the Elevation Prompt. The image below shows the basic Consent Prompt. However, based on the way that the Local Security Policy / Group Policy is configured, Administrative users can also be prompted to re-enter their credentials. Several customers that I have worked with have implemented this policy as a means to guard against apathy and automatically clicking through the Consent prompt without verifying the actions.
To quickly wrap up this introduction to UAC, here's a quick summary of the way that the UAC prompting behavior can be configured. The settings can be configured either locally or via GPO:
The following table describes the User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode and the User Account Control: Behavior of the elevation prompt for standard users settings.
User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode
There are three possible values:
Prompt for consent
|User Account Control: Behavior of the elevation prompt for standard users||
There are two possible values:
|Prompt for credentials|
OK - that's all for this post. I know that there's a lot of information to digest here, but once you get a good handle on UAC and how it impacts Windows Vista you've made a giant leap forward in really understanding the Operating System!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.