Understanding User Account Control (UAC), A Brief Summary

  • Article

Below are some notes I took while troubleshooting a UAC issue. I found it useful to understand the difference between Rights and Permissions, as well as how to identify when UAC was coming into play.

What is the Difference Between Permissions and Rights (Privileges)?

Permissions apply to Objects

  • A permission is an authorization to perform an operation on a specific object, such as a file.
  • Every container and object on the network has a set of access control information attached to it that is called a security descriptor. This information controls the type of access that is allowed to users and groups. For example, each file has a security descriptor.
  • Each permission that an object’s owner grants to a particular user or group is stored as an ACE (Access Control Entry).
  • The entire set of permission entries in a security descriptor is known as a permission set or ACL (Access Control List).

Rights (Privileges) apply to User Account Actions

  • User rights enable administrators to assign specific privileges and logon rights to groups or users. These rights authorize users to perform specific actions, such as logging on to a system interactively or backing up files and directories. User rights are different from permissions because user rights apply to user accounts and permissions are attached to objects.
  • Administrators can use user rights to manage who has the authority to perform operations that span an entire computer, rather than a particular object.

Conflict between Rights vs Permissions

  • Conflicts between privileges (rights) and permissions normally occur only in situations where the rights that are required to administer a system overlap the rights of resource ownership. When rights conflict, a privilege (“right”) overrides a permission. This is partly why when UAC is enabled, you may get prompted when trying a certain administrative operation even though you have full control permissions on the folders/regkeys needed. The problem is typically attributed to the administrative right not being invoked.
  • Reference: How Permissions Work https://technet.microsoft.com/en-us/library/cc783530(v=WS.10).aspx

 

UAC (User Access Control)

Standard and Administrator Access Tokens

  1. When an administrator logs on, the user is assigned two separate access tokens:
    • a full administrator access token and a
    • standard user access token.
  2. The full administrator access token is not invoked until the user attempts to perform anadministrative task.
    • In other words, if you log on as a member of the local administrators group, you will run with your administrative privileges disabled until you attempt to run an application or task that has been marked to require administrative privileges. When UAC is enabled, local administrator accounts run as standard user accounts until elevation is required.

When does UAC come into play?

  1. At process creation.
    • You can see the type of token an account is running with by viewing the ProcessCreation entry in the security event log.
    • You can run the PowerShell script below to extract this information from the security event log.

#if no events returned, verify you have 'Audit Process Tracking' security auditing enabled per https://technet.microsoft.com/en-us/magazine/dd365937.aspx

cls

$evtLogEntries=$null

$evtEntry=$null

$user_nameonly_withoutdomainprefix='OSAdmin'

$datetimeAfter=get-date"1/19/2017 4:00:00 pm"

$evtLogEntries=$null

 

$evtLogEntries=Get-EventLog-LogNameSecurity  -After  $datetimeAfter  -EntryTypeSuccessAudit  -Message"A new process has been created*"|Where-Object {$_.Message -match"Account Name:`t`t$user_nameonly_withoutdomainprefix"}

 

foreach( $evtEntryin$evtLogEntries){

    write-host$evtEntry.TimeGenerated

    $startIdx=$null

    $len=$null

    $startIdx=$evtEntry.Message.IndexOf("Subject:")

    $len=$evtEntry.Message.IndexOf("Token Elevation Type indicates")-$startIdx

    write-host$evtEntry.Message.substring($startIdx,$len)

 

    switch ( $evtEntry.Message.substring($evtEntry.Message.IndexOf("%%"),6))

    {

        "%%1936" { write-host"`tToken Elevation Type: Type 1 is a full token with no privileges removed or groups disabled.  A full token is only used if User Account Control is disabled or if the user is the built-in Administrator account or a service account."}

        "%%1937" { write-host"`tToken Elevation Type: Type 2 is an elevated token with no privileges removed or groups disabled.  An elevated token is used when User Account Control is enabled and the user chooses to start the program using Run as administrator.  An elevated token is also used when an application is configured to always require administrative privilege or to always require maximum privilege, and the user is a member of the Administrators group."}

        "%%1938" { write-host"`tToken Elevation Type: Type 3 is a limited token with administrative privileges removed and administrative groups disabled.  The limited token is used when User Account Control is enabled, the application does not require administrative privilege, and the user does not choose to start the program using Run as administrator."}

        default  { write-host"`tToken Elevation Type:Unable to determine token elevation type."}

    }

    write-host"------------"

    }

Sample script result when launching notepad.exe while running as a user with OS Admin rights and WITHOUT specifying the “run as administrator” option:

5/14/2015 3:58:09 PM

Subject:

Account Name:OSAdmin1

Account Domain:Machine1

Logon ID:0x87b7d7

Process Information:

New Process ID:0x18c

New Process Name:C:\Windows\System32\notepad.exe

Token Elevation Type:%%1938

Creator Process ID:0xa34

Process Command Line:

Token Elevation Type: Type 3 is a limited token with administrative privileges removed and administrative groups disabled.The limited token is used when User Account Control is

enabled, the application does not require administrative privilege, and the user does not choose to start the program using Run as administrator.
ProcessExplorer_SecurityProps

Why was UAC created?

  1. Historically, most IT departments have granted users full administrator rights on their machines to simplify management and minimize failures. Application developers designed their applications assuming that they would be installed and run as an administrator. Even when Windows® XP was initially installed, all user accounts were created as local administrators.
  2. UAC reduces the number of programs that run with elevated privileges, therefore helping to prevent users from accidentally/unknowingly changing their system settings, and helping to prevent "malware" from gaining system-wide access.
  3. This shift also encourages developers to write more secure applications because they can eliminate unnecessary requests for excessive administrative-level access to Windows resources only by using the minimal required permissions. Well-designed UAC experiences allow users to be more productive when running as Standard users.

 

How is it decided if elevation is required?

  1. The application may have the “Run this program as an administrator” privilege level set (right click exe properties ->compatibility tab->privilege level)
  2. The application performs operations which actually require administrator rights (such as start/stop services, backup operations, registry access,etc). See Developing Applications that Require Administrator Privilege https://msdn.microsoft.com/en-us/library/windows/desktop/dd550643(v=vs.85).aspx
  3. The application has a manifest which marks it as requiring  administrator rights (manifested with RequireAdministrator).  See Step 6: Create and Embed an Application Manifest (UAC) https://msdn.microsoft.com/en-us/library/bb756929.aspx
  4. Reference: User Account Control Step-by-Step Guide https://technet.microsoft.com/en-us/library/cc709691(v=WS.10).aspx

 

Fany Carolina Vargas | SQL Dedicated Premier Field Engineer | Microsoft Services