Least Privilege

Creating the Azure SDK sample database on SQL Server

2008-11-13T10:51:00.002+01:00

The default installation of the Microsoft Azure SDK comes with a few samples that require SQL Server Express 2005 or 2008. If you have SQL Server installed you need to edit a file named Microsoft.Samples.ServiceHosting.targets and add /server:localhost to tell DevTableGen.exe to use the default SQL Server instance rather than localhost\SQLExpress.

The Microsoft.Samples.ServiceHosting.targets file is located in the C:\Program Files\Windows Azure SDK\v1.0\samples\MSBuild folder. I edited the file, searched for /database and added /server:localhosts and I was then able to create the sample database with RunDevStore.cmd batch file.

Windows 7 UAC: prompt for consent for non-Windows binaries

2008-11-05T16:21:00.012+01:00

Windows 7 brings a few changes to User Account Control (UAC).

Build 6801 shows three new options for the “Behavior of the elevation prompt for administrators in Admin Approval Mode” policy. The options are “prompt for credentials on the secure desktop”, “prompt for consent on the secure desktop” and “prompt for consent for non-Windows binaries”. Of the three, the latter looked interesting and so I decided to test its behavior with three Microsoft executables with different file manifest.

As expected, this option turns out to be useful when logged in as an administrator (in admin approval mode) for applications that have the highestAvailable and asAdministrator requested execution level in their file manifest. These applications, such as mmc.exe and SystemsPropertiesperformance.exe for example, are silently elevated.

On the other hand, applications with a requested execution level of asinvoker such as Process Explorer v11.21, are not elevated by default. This, for an application like Process Explorer, may seem strange at first but, asInvoker, is indeed correct as the application can operate even as a standard user – although most interesting features do require administrative privileges. To execute with administrative privileges you would have to right-click on the executable and select “Run as administrator” from the context menu.

While this option is only valid for applications digitally signed by Microsoft it could help reduce a few of the popups that systems administrators have to deal with.

SE_GROUP_USE_FOR_DENY_ONLY Vs Restricted SIDs

2008-10-31T15:00:00.016+01:00

There seem to be some confusion between SIDs with the SE_GROUP_USE_FOR_DENY_ONLY attribute set, Restricted SIDs and when to use one or the other.

The documentation is fairly clear about it … as long as one fully understands the relationship between Access tokens and Access Control Lists (ACLs).

Both deny-only SIDs and restricted SIDs are used when creating a Restricted Token. Such token is useful when you want to spawn a child process that has fewer privileges and groups than the original.

To explain the difference between the two it is important to briefly review the basics of Access Control Entries (ACEs) and Access Control Lists (ACLs). An ACE determines the access level for a given SID and whether it allows or denies access. An ACL is a list of ACEs. For a given securable object, you will find a Discretionary ACL (DACL) that controls access to the resource and a System ACL (SACL) that control auditing.

Unless one is explicitily granted a permission access is denied. The only exception is a NULL DACL where everyone is granted access. On the other hand, an empty DACL denies access.

It seems hence intuitive to conclude that one only has to omit a given SID from a process token in order to deny access to a given resource. That will work most of the times, but not always. The reason is that access may still be granted depending on the groups the user is member of and the object DACL. The only 100% sure, and therefore secure, way is to explicitely deny access.

Example: consider a folder where the system administrator has added to the DACL an access-denied entry for members of the group Marketing. If the Marketing group SID is not present in the process token then the process may still have access to the folder if any other ACE in the DACL allowed access to the token.

When calling CreateRestrictedToken one should therefore specify in the SidToDisable list the SIDs that one wishes to deny access to secureble objects. A common example is stripping down an Administrative token by setting the Administrators group SID to SE_GROUP_USE_FOR_DENY_ONLY by including it in the SidsToDisable list.

The Administrators group will be checked against access-denied ACEs in the DACL and access will be denied in case of a match.

Restricted SIDs are a bit more complicated to grasp ... mainly because of their name. Restricted SIDs should be intended as the "list of of SIDs you wish your token to use to gain access to a securable object".

The Access Check performed for a restricted token against an object consists hence of two phases. The 1st phase consists of checking the list of "regular" SIDS contained in the token against the DACL and, if access has not been denied, the restricted SIDs against the access-allowed SIDs of the DACL. The access granted will consists of the most restrictive of the two.

Next: CreateRestrictedToken sample code

Developing without Administrative Privileges

2007-09-10T11:03:00.000+01:00

Contributed by Davide D'Aprile

Introduction

In the present post we’ll investigate on what developing software without administrative privileges really means, keeping well in mind that the principle of least privilege doesn't say that no user can have permissions beyond those granted to a standard one, but rather that a user should have exactly the privileges needed to do the job. Developers are not an exception: they may need a few more permissions, but only a few.

This last assertion is in opposition to a conventional wisdom, asserting that a developer should have administrative privileges, given that he performs a lot of critical activities, like debugging, interacting with IIS, writing into registry’s protected regions, and so on.

However, this is the just one of the different reasons, implying that a developer has to work with a Least Privilege User Account (LUA), due to the potentially dangerous and malicious operations he could be a victim of by using an administrative account. Visual Studio and its components are becoming a popular target for hackers and it is time that measures are taken to secure development workstations.

In addition, the right practice of using a LUA account facilitates the development of so-called LUA Bug-free code. Remember that a LUA Bug “occurs when an application—or a feature of an application—works correctly when run with elevated privileges but fails to work for a LUA user when there is no technical or business reason for requiring elevated privileges”.

In the two following sections we’ll stress firstly which classes of privileges are needed to productively work in a LUA environment during some typical phases occurring in the software development process; finally, we’ll concentrate on the widely-used VISUAL STUDIO .NET.

The Software Development Cycle in a LUA Environment

This section takes into account the software development process within the .NET environment, as discussed in Developing Software in Visual Studio .NET with Non-Administrative Privileges.

Development and Debugging

Consider the two local groups that Visual Studio provides during the installation phase, to face at the potential problems could occur when developing without administrative permissions, i.e. Debugger Users and VS Developers, might not be really necessary. In fact, whereas the former is for web developers having to interact with Internet Information Server, the latter is useful only to debug server applications. Given the dangerous powers deriving from to belong to these privileged groups should be evaluated very carefully.
The following table summarize the different scenarios to be managed during the Debugging phase, performed in a local machine.

Account Type	Application ownership
Normal User	Owned, within the same security context
Normal User + SeDebugPrivilege (WIN) Administrator Group (.NET framework)	Other's, within the same security context
Administrator Group	Owned or Other's, with different security context
Debugger Users Group	Owned native or managed application

At BeyondTrust, for example, we do not debug locally if privileges beyond the ones of the basic user are required. Our build process copies files to a network share and then we debug remotely onto a test virtual machine. The virtual machine does not contain any data and would pose little problems if compromised.

Registering COM components

One of the most common complaints about developing under a LUA account is that one cannot register COM components. That is only partially true: the problem is not the COM registration process but rather how the various components are registered. COM components, with the exception of services can, and should be, registered under HKCU. The real issue are the default settings that, for example, Visual Studio uses when creating ATL/COM components which default to HKLM. By taking the time to edit the RGS files one can register and utilize COM components under a LUA account.

Developing LUA Bugs-free Software Products

In order to develop LUA Bugs-free software products, a developer should:

use per-user registry keys whenever possible;
e.g. write to HKEY_CURRENT_USER, rather than HKEY_CURRENT_USER;
use file system regions accessible to Standard Users;
- e.g. write into My Documents folder;
Using Program Files only to store static, read-only program and data files;
be prepared to deal with the Code Access security (CAS), a .NET Common Language Runtime feature that assign permissions to code, rather than relying on the security context of the user under which the code is running.

Avoid developing applications that require Full Trust; on the contrary, Partially Trusted Application (PTA) with the lowest level of permissions should be considered.

The code calling the PTA has to acquire permission to access the protected resources the code uses.

Privilege Manager Tips: controlling access to securable resources

2007-08-31T13:28:00.000+01:00

One my favorite things you can do with Privilege Manager is to restrict access to a securable object to a given application.

In general, Access Control Lists ( ACL ) apply to users and/or groups, not applications. When you log on you are assigned a Token that contains, among other attributes, the list of groups you belong to. When you start a process ( that is, the instance of an application in memory ) a copy of the token gets associated with the process. When the process tries to access a securable resource the process-token is compared against the ACL of the object to determine what permission should be granted, if any.

Privilege Manager allows you to extend the Windows Security model by adding a new dimension: applications.

Let’s say that for example you want to restrict read/write access to a given folder to the members of the TopSecret group but only when running notepad.exe. Let’s call this folder c:\restricted. With Privilege Manager all you need to do is to create a rule for notepad.exe and add the TopSecret group to the Permissions tab as shown below.

That’s all! Now only authorized users running notepad will be allowed to read/write to the c:\restricted folder. This is because Privilege Manager replaces the default token with the one containing the Permissions and Privileges you have set. In our case, only the TopSecret group.

This principle can also be used, for example, with I/O Device control solution like SecureWave’s Sanctuary Device Control to allow an authorized user to utilize an I/O device, but only when running a given application(s). This is because Sanctuary uses ACLs to control access to I/O devices and trust me, I know how it works as I have founded the company and developed the first version of the product ;-)

NOTE: this rule can only be applied to local securable resources. This is because when you access a remote resource you authenticate to the remote server via the domain controller and hence you end up with your default token.

Applying the principle of Least Privilege to Systems Administrators

2007-08-31T12:32:00.000+01:00

Introduction

Given the complexity and variety of tasks that Systems Administrators carry out they are often the last one to adopt the principle of Least Privilege. Most other users execute only a handful of applications and have little or no need for administrative privileges on their computer.

Because of the information and assets that Systems Administrators have access to however they are a very valuable pray for malware authors and steps should be taken to improve the security of their working environment. However, not all users that have been granted administrative privileges to accomplish administrative tasks are alike.

Categories of Systems Administrators

To better illustrate the point we will categorize Systems Administrators as follows:

Basic System Administrator ( BSA )
Server System Administrators ( SSA )
Domain System Administrator ( DSA )

A BSA will typically have been granted privileges because:

Needs to start/stop a given service
Needs access to IIS
Needs to check logs, etc.

SSA:

Needs to manage a database instance on a given server
Needs the ability to log in locally onto a server for basic maintenance
Install applications, printers, etc.

DSA:

Needs the ability to create domain user/machine accounts
Needs to manage users’ mailboxes
Needs to manage global users’ policies

In general, BSA is granted, for example, to a developer or an external consultant that needs such privileges, often on a single computer, to accomplish a specific activity. SSA is the more common case where one needs to Administer a given machine while DSA is one that has access to Domain Controllers, Exchange servers etc.

Guidelines

1) Internet facing applications such as Web Browsers, Email clients, Instant Messaging, etc. should never, never be executed with Administrative Privileges as they represent the preferred vector of infection.

2) Users who have been made BSA should be removed from the Administrative group and granted just the necessary privileges to accomplish the task. Quite often Administrative Privileges are granted for laziness and/or simplicity because the person charged to grant them does not have the bandwidth to research how to accomplish the given task w/o granting full Administrative Privileges.

3) Users who have been made DSA should use two accounts: their day to day account on their desktop and log onto a remote desktop when they need to operate at the domain level. The remote desktop should be setup so that only the required applications can be executed.

The rationale for the above guidelines is simple: once malware can execute in the context of the logged on user it can access all the information he/she has access to. The greater the user privileges are the greater the potential damage.

The optimal solution would be to have all Systems Administrators running as basic users and elevate their privileges when required. This is the approach chosen by Vista UAC and our own Privilege Manager.

With Privilege Manager you can also select exactly which privilege, if any, you want the user to have when launching a given application ( the privileges are assigned to the process ).

You can also assign given privileges to a user and/or group via the Local Security Settings editor ( secpol.msc ) -- just beware that the privileges will be accessible by all applications started by the user, hence malware included.

Privileges

Useful privileges include:

Add log on locally
Allow log on through Terminal Services
Back up / Restore files and directories
Change the System time
Create global objects
Create permanent Shared Objects
Debug programs
Force shutdown of a remote system
Increase scheduling priority
Load and Unload decide drivers
Manage auditing and Security log
Perform volume maintenance tasks
Take ownership
Etc.

See the following Microsoft TechNet article for a description of each privilege.

Many common administrative tasks are carried out from Control panel Applets and/or Microsoft SnapIns.

Control Panel Applets and Microsoft Management Console ( MMC )

SnapIns

Here is a list that we have compiled for Vista for our own Privilege Manager.

· Add Hardware
path="%"%SystemRoot%\system32\hdwwiz.exe"

· Back up files
path="%%SystemRoot%\system32\sdclt.exe"

· Back up computer
path="%%SystemRoot%\system32\sdclt.exe

· Date and Time (Control Panel)
path="%%SystemRoot%\system32\rundll32.exe”
args="%SystemRoot%\system32\shell32.dll,Control_RunDLL %SystemRoot%\system32\timedate.cpl,Date and Time”

· Date and Time (Control Panel: Set the Date and Time)
path="%%SystemRoot%\system32\rundll32.exe” args="Shell32.dll,Control_RunDLL timedate.cpl”

· Date and Time (Taskbar)
path="%%SystemRoot%\system32\rundll32.exe” args="Shell32.dll,Control_RunDLL %SystemRoot%\System32\timedate.cpl”

· Defrag
path="%%SystemRoot%\system32\dfrgui.exe”

· Device Manager
path="%%SystemRoot%\system32\mmc.exe”
args="%SystemRoot%\system32\devmgmt.msc”

· Disk Management
path="%%SystemRoot%\system32\mmc.exe”
args="%SystemRoot%\system32\diskmgmt.msc”

· Font Size and DPI
path="%%SystemRoot%\system32\DpiScaling.exe”

· Indexing Options: File Types
path="%%SystemRoot%\system32\rundll32.exe”
args="%SystemRoot%\system32\shell32.dll,Control_RunDLL %SystemRoot%\system32\srchadmin.dll,Indexing Options”

· Indexing Options: File Types (Change How Windows Searches)
path="%%SystemRoot%\system32\rundll32.exe”
args="Shell32.dll,Control_RunDLL srchadmin.dll,,2"

· iSCSI Initiator
path="%SystemRoot%\system32\iscsicpl.exe"

· Offline Files
path="%SystemRoot%\system32\rundll32.exe" args="%SystemRoot%\system32\shell32.dll,Control_RunDLL %SystemRoot%\system32\cscui.dll,Offline Files"

· Programs and Features - Windows features
path="%SystemRoot%\system32\OptionalFeatures.exe"

· Regional and Language Options – Administrative
path="%SystemRoot%\system32\rundll32.exe" args="%SystemRoot%\system32\shell32.dll,Control_RunDLL %SystemRoot%\system32\intl.cpl,Regional and Language Options"

· Restore files
path="%SystemRoot%\system32\sdclt.exe"
args="/restorewizard"

· System Properties - Advanced System Properties
path="%SystemRoot%\system32\SystemPropertiesAdvanced.exe"

· System Properties - Computer Name
path="%SystemRoot%\system32\SystemPropertiesComputerName.exe"

· System Properties – Performance
path="%SystemRoot%\system32\SystemPropertiesPerformance.exe"

· System Properties - Remote Access
path="%SystemRoot%\system32\SystemPropertiesRemote.exe"

· System Properties - System Protection
path="%SystemRoot%\system32\SystemPropertiesProtection.exe"

· Windows Firewall
path="%SystemRoot%\system32\rundll32.exe" args="firewall.cpl,ShowControlPanel"

If what your BSA or SSA needs to accomplish falls under one of the above you should hence consider upgrading to Windows Vista/UAC, using our own Privilege Manager or some of the alternatives described in the Applying the Principle of Least Privilege to User Accounts on Windows XP paper.

Microsoft Security Bulletin Summary for August 2007 – running as basic user pays off big time!

2007-08-16T14:04:00.000+01:00

Reviewing the Microsoft Security Bulletins for August shows that all 12 of them would be mitigated by users running without Administrative privileges.

The full security bulletin can be found here: http://www.microsoft.com/technet/security/bulletin/ms07-aug.mspx

You will see that they all allow remote code execution and the code will execute in the context of the logged on user. If logged on with Administrative privileges the code will be able to, for example, install and execute a kernel rootkit, a keylogger etc. while when logged on as a user it will be restricted to the data the user has access to as well as potentially spawning a user mode process.

The forgotten Folder Option ...

2007-01-18T09:56:00.000+01:00

In a previous blog entry, I have run into an interesting error message that lead me to believe I run into a bug, or at least a poorly written error message. It turned out that I made a mistake as I always set the "Launch folder window in a separate process" folder option as it allows me to run explorer.exe elevated when I need it. As I was setting up a new Vista test box I forgot to check that check box and hence run my test without the required privileges.

That said, the error message you get when you try to write to a protected folder depends on how you copy the files. If you start from a regular explorer.exe process ( no privs) and elevate when prompted you get the strange error message I reported earlier ( location unavailable ). When you try to copy the same files to the same location from an elevated explorer.exe then you get a message that you don't have the required permission to perform that action, which is the correct error message. I still hold that the first error message shown is not correct.

RSA 2007 Peer to Peer sessions

2007-01-16T18:14:00.000+01:00

I have been accepted as a Peer to Peer facilitator at RSA 2007. I'll moderate a discussion on how to implement the Least Privilege principle in a Windows environment. The session will take place on 02/07/2007 from 1:40 PM to 2:30 PM. The session code is P2P-205B.

I'll report here on the session and hence, if you have any issue that you feel it should be discussed, or simply want to meet me then send me an email ( marco.peretti <> gmail.com ).

UAC & UNC

2007-01-16T17:09:00.000+01:00

Have you ever tried to copy files from a network location to a protected one? I was setting up a new Vista box for remote debugging and needed to copy a few files from our test server to c:\windows\system32. The UAC reminded me that this operation required elevation only to fail right after with this error message:

This is odd, because with Explorer.exe elevated I had access to the share, even the mapped drive, however, when I tried to copy the files to the protected location it still failed. I have checked with a kernel debugger and dllhost.exe, the program that carried out the elevated file copy, run in the same logon session as all my other applications. It turned out that the write operation was caused by the ACL on the target directory. Microsoft, to protect critical resources, has restricted write access to only the TrustedInstaller user, and denied write permissions to everybody else, including SYSTEM and Administrators as show here below.

The error message I was shown was misleading to say the least. Yet another Vista/UAC bug?

You can find more information on the TrustedInstaller and Windows Resource Protection here.

More of the same ...

2007-01-12T15:40:00.000+01:00

Microsoft yesterday has released a number of security bulletins (
http://www.microsoft.com/technet/security/Bulletin/MS07-002.mspx ) for a number of bugs that would allow remote code execution and are rated as critical.

Most bugs affect Office 2000 and hackers could exploit these bugs simply having the user open a malformed document.

In Microsoft words: "If a user is logged on with administrative user rights, an attacker who successfully exploited this vulnerability could take com plete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less affected than users who operate with administrative user rights."

This is why it is important that an organizations runs all or most of its applications in a least privilege environment. Least privilege is a complimentary solution to the various security solutions on the market ( AV, anti-spyware, etc) as it allows to contain, and often neutralize, undetected and zero-day threats.

The challenge for an organization is how to move to a Least Privilege environment. Windows provides, out of the box, only basic mechanisms such as Runas and User Account Control (UAC) which are more suitable to sys-admins and home users but cannot be used by an organization as they often, if not always, require the user to have an administrative account. Besides the obvious difficulty in managing an additional user name and password users often abuse such privileges to make
un-authorized system changes and install un-authorized applications.

There is clearly a need for a centrally managed solution that allow the organization sys-admin to define policies that elevate the privileges on a per application basis and don't require a second user account.

Regedit.exe and UAC

2007-01-02T13:51:00.000+01:00

In my previous entry I have written about how it was not possible to have two instances of the same application running under different credentials. While driving home for lunch I remembered that I have actually run two instances of cmd.exe countless times, while today, I was testing with regedit.exe. It turns out that it appears that regedit.exe is actually the only application for which you cannot run more than an instance at the time -- UAC or not.

This is by design, and probably due to link between regedit.exe and regedt32.exe. Try running regedt32.exe and look at Task Manager process' list and you will see regedit.exe. A long time ago there used to be two registry editors. Under XP, I think, there were brought together but kept the original file names for backward compatibility.

Difference between a Standard User & Protected Administrator tokens

2007-01-02T10:39:00.000+01:00

If you are evaluating Windows Vista you may need to decide whether your users will be Standard Users or Protected Administrators. With UAC enabled, users will be shown the consent UI but the resulting token will differ. The token generated for a Protected Administrator depends on the "Behavior of the elevation prompt for administrators in Admin Approval Mode" policy. The default policy is set to "prompt for consent" and generates a full admin token. When set to "prompt for credentials" it generates again a full admin token, but for another user account -- pretty much like RunAs. Standard Users always get prompted for the credentials. The latter implies also, for example, different HKCU and so on.

Before we begin, let me clarify that a Protected Administrator is nothing but a member of the Administrators group with UAC enabled. When a Protected Administrator logs in his original token gets saved (the linked token) and his original one replaced by one that looks like:

TS Session ID: 0x1
User: S-1-5-21-2196860067-979979976-148335941-1000
Groups:
00 S-1-5-21-2196860067-979979976-148335941-513
Attributes - Mandatory Default Enabled
01 S-1-1-0
Attributes - Mandatory Default Enabled
02 S-1-5-32-544
Attributes - DenyOnly
03 S-1-5-32-545
Attributes - Mandatory Default Enabled
04 S-1-5-4
Attributes - Mandatory Default Enabled
05 S-1-5-11
Attributes - Mandatory Default Enabled
06 S-1-5-15
Attributes - Mandatory Default Enabled
07 S-1-5-5-0-833662
Attributes - Mandatory Default Enabled LogonId
08 S-1-2-0
Attributes - Mandatory Default Enabled
09 S-1-5-64-10
Attributes - Mandatory Default Enabled
10 S-1-16-8192
Attributes - GroupIntegrity GroupIntegrityEnabled
Primary Group: S-1-5-21-2196860067-979979976-148335941-513

Privs:
19 0x000000013 SeShutdownPrivilege Attributes -
23 0x000000017 SeChangeNotifyPrivilege Attributes - Enabled Default
25 0x000000019 SeUndockPrivilege Attributes -
33 0x000000021 SeIncreaseWorkingSetPrivilege Attributes -
34 0x000000022 SeTimeZonePrivilege Attributes -
Authentication ID: (0,cb8ba)
Impersonation Level: Anonymous
TokenType: Primary
Source: User32 TokenFlags: 0xa00 ( Token in use )
Token ID: e864d ParentToken ID: cb8bd
Modified ID: (0, dfce2)
RestrictedSidCount: 0 RestrictedSids: 00000000
OriginatingLogonSession: 3e7

ParentToken ID points to the linked token.

Which gets changed to a full admin token:

TS Session ID: 0x1
User: S-1-5-21-2196860067-979979976-148335941-1000
Groups:
00 S-1-5-21-2196860067-979979976-148335941-513
Attributes - Mandatory Default Enabled
01 S-1-1-0
Attributes - Mandatory Default Enabled
02 S-1-5-32-544
Attributes - Mandatory Default Enabled Owner
03 S-1-5-32-545
Attributes - Mandatory Default Enabled
04 S-1-5-4
Attributes - Mandatory Default Enabled
05 S-1-5-11
Attributes - Mandatory Default Enabled
06 S-1-5-15
Attributes - Mandatory Default Enabled
07 S-1-5-5-0-1244696
Attributes - Mandatory Default Enabled LogonId
08 S-1-2-0
Attributes - Mandatory Default Enabled
09 S-1-5-64-10
Attributes - Mandatory Default Enabled
10 S-1-16-12288
Attributes - GroupIntegrity GroupIntegrityEnabled
Primary Group: S-1-5-21-2196860067-979979976-148335941-513
Privs:
05 0x000000005 SeIncreaseQuotaPrivilege Attributes -
08 0x000000008 SeSecurityPrivilege Attributes -
09 0x000000009 SeTakeOwnershipPrivilege Attributes -
10 0x00000000a SeLoadDriverPrivilege Attributes -
11 0x00000000b SeSystemProfilePrivilege Attributes -
12 0x00000000c SeSystemtimePrivilege Attributes -
13 0x00000000d SeProfileSingleProcessPrivilege Attributes -
14 0x00000000e SeIncreaseBasePriorityPrivilege Attributes -
15 0x00000000f SeCreatePagefilePrivilege Attributes -
17 0x000000011 SeBackupPrivilege Attributes -
18 0x000000012 SeRestorePrivilege Attributes -
19 0x000000013 SeShutdownPrivilege Attributes -
20 0x000000014 SeDebugPrivilege Attributes -
22 0x000000016 SeSystemEnvironmentPrivilege Attributes -
23 0x000000017 SeChangeNotifyPrivilege Attributes - Enabled Default
24 0x000000018 SeRemoteShutdownPrivilege Attributes -
25 0x000000019 SeUndockPrivilege Attributes -
28 0x00000001c SeManageVolumePrivilege Attributes -
29 0x00000001d SeImpersonatePrivilege Attributes - Enabled Default
30 0x00000001e SeCreateGlobalPrivilege Attributes - Enabled Default
33 0x000000021 SeIncreaseWorkingSetPrivilege Attributes -
34 0x000000022 SeTimeZonePrivilege Attributes -
35 0x000000023 SeCreateSymbolicLinkPrivilege Attributes -
Authentication ID: (0,12fe47)
Impersonation Level: Identification
TokenType: Primary
Source: User32 TokenFlags: 0x0 ( Token in use )
Token ID: 147808 ParentToken ID: 0
Modified ID: (0, 147813)
RestrictedSidCount: 0 RestrictedSids: 00000000
OriginatingLogonSession: 3e7

Notice that the User SID above has not been changed.

Let's now look at a standard user token:

TS Session ID: 0x1
User: S-1-5-21-2196860067-979979976-148335941-1001
Groups:
00 S-1-5-21-2196860067-979979976-148335941-513
Attributes - Mandatory Default Enabled
01 S-1-1-0
Attributes - Mandatory Default Enabled
02 S-1-5-32-545
Attributes - Mandatory Default Enabled
03 S-1-5-4
Attributes - Mandatory Default Enabled
04 S-1-5-11
Attributes - Mandatory Default Enabled
05 S-1-5-15
Attributes - Mandatory Default Enabled
06 S-1-5-5-0-1377206
Attributes - Mandatory Default Enabled LogonId
07 S-1-2-0
Attributes - Mandatory Default Enabled
08 S-1-5-64-10
Attributes - Mandatory Default Enabled
09 S-1-16-8192
Attributes - GroupIntegrity GroupIntegrityEnabled
Primary Group: S-1-5-21-2196860067-979979976-148335941-513
Privs:
19 0x000000013 SeShutdownPrivilege Attributes -
23 0x000000017 SeChangeNotifyPrivilege Attributes - Enabled Default
25 0x000000019 SeUndockPrivilege Attributes -
33 0x000000021 SeIncreaseWorkingSetPrivilege Attributes -
34 0x000000022 SeTimeZonePrivilege Attributes -
Authentication ID: (0,1503e5)
Impersonation Level: Anonymous
TokenType: Primary
Source: User32 TokenFlags: 0x200 ( Token in use )
Token ID: 1649c0 ParentToken ID: 0
Modified ID: (0, 1601f0)
RestrictedSidCount: 0 RestrictedSids: 00000000
OriginatingLogonSession: 3e7

Trying, for example, to edit the firewall settings brings up the Consent UI which prompts us for different credentials and results in a token like the one here below:

TS Session ID: 0x1
User: S-1-5-21-2196860067-979979976-148335941-1000
Groups:
00 S-1-5-21-2196860067-979979976-148335941-513
Attributes - Mandatory Default Enabled
01 S-1-1-0
Attributes - Mandatory Default Enabled
02 S-1-5-32-544
Attributes - Mandatory Default Enabled Owner
03 S-1-5-32-545
Attributes - Mandatory Default Enabled
04 S-1-5-4
Attributes - Mandatory Default Enabled
05 S-1-5-11
Attributes - Mandatory Default Enabled
06 S-1-5-15
Attributes - Mandatory Default Enabled
07 S-1-5-5-0-1377206
Attributes - Mandatory Default Enabled LogonId
08 S-1-2-0
Attributes - Mandatory Default Enabled
09 S-1-5-64-10
Attributes - Mandatory Default Enabled
10 S-1-16-12288
Attributes - GroupIntegrity GroupIntegrityEnabled
Primary Group: S-1-5-21-2196860067-979979976-148335941-513
Privs:
05 0x000000005 SeIncreaseQuotaPrivilege Attributes -
08 0x000000008 SeSecurityPrivilege Attributes -
09 0x000000009 SeTakeOwnershipPrivilege Attributes -
10 0x00000000a SeLoadDriverPrivilege Attributes -
11 0x00000000b SeSystemProfilePrivilege Attributes -
12 0x00000000c SeSystemtimePrivilege Attributes -
13 0x00000000d SeProfileSingleProcessPrivilege Attributes -
14 0x00000000e SeIncreaseBasePriorityPrivilege Attributes -
15 0x00000000f SeCreatePagefilePrivilege Attributes -
17 0x000000011 SeBackupPrivilege Attributes -
18 0x000000012 SeRestorePrivilege Attributes -
19 0x000000013 SeShutdownPrivilege Attributes -
20 0x000000014 SeDebugPrivilege Attributes -
22 0x000000016 SeSystemEnvironmentPrivilege Attributes -
23 0x000000017 SeChangeNotifyPrivilege Attributes - Enabled Default
24 0x000000018 SeRemoteShutdownPrivilege Attributes -
25 0x000000019 SeUndockPrivilege Attributes -
28 0x00000001c SeManageVolumePrivilege Attributes -
29 0x00000001d SeImpersonatePrivilege Attributes - Enabled Default
30 0x00000001e SeCreateGlobalPrivilege Attributes - Enabled Default
33 0x000000021 SeIncreaseWorkingSetPrivilege Attributes -
34 0x000000022 SeTimeZonePrivilege Attributes -
35 0x000000023 SeCreateSymbolicLinkPrivilege Attributes -
Authentication ID: (0,16b095)
Impersonation Level: Anonymous
TokenType: Primary
Source: CredPro TokenFlags: 0x0 ( Token in use )
Token ID: 16bc6b ParentToken ID: 0
Modified ID: (0, 16b73a)
RestrictedSidCount: 0 RestrictedSids: 00000000
OriginatingLogonSession: 3e7

The user SID has changed from S-1-5-21-2196860067-979979976-148335941-1001 to S-1-5-21-2196860067-979979976-148335941-1000 -- which basically means another user account. There are some subtle consequences to this. One that comes to mind is what happens when an application tries to write to HKCU? In my tests, the application always writes to the correct HKCU, that is, according to the user account. This however, may or may not be what you need if all you are trying to do is to run a legacy application.

Bug alert: one annoying feature (bug?) that I have noticed is that, while logged in as a regular user, you cannot start a second instance of an application using different credentials. Start an instance of regedit.exe as a standard user, then right-click on regedit.exe and right-click on it to start it as Administrator. After you'll enter the credentials you'll notice that the focus will switch back to the first instance. The reverse is also true: Vista will prevent you from having two instances of the same application under different credentials. Go figure ...