If I’m an Administrator, Why Do I Get Access Denied ?

User Account Control (UAC) can seem mysterious. After all, if I’m a member of the Administrators group, shouldn’t I have access to everything?  If you’re a developer, you’ll run into a UAC issue sooner or later.  In this post, I’ll cover the basics that every developer should know.

Standard User by Default

Running applications as “Standard User” by default is what UAC is all about. Running processes with as few rights and privileges as possible is a common security defense in depth technique. UAC accomplishes this during the logon process. The traditional NT security model created a single access token at logon that all processes on the desktop used. The token contained privileges based on the groups the logged on user belonged.  With UAC enabled, the logon process creates the traditional “full” token and also creates a limited “filtered” token.  The filtered token contains only “standard user” privileges.

Here’s a slide to help illustrate the “by default” part.

The magic happens when explorer.exe is started using the filtered token.  Explorer.exe is your taskbar and is responsible for starting everything on the desktop. By default, child processes are started with the same token as their parent. Therefore, since explorer.exe is started with the filtered token, everything that is launched by the taskbar is standard user by default (presto!).

Bonus question: What token is used to start explorer.exe with UAC disabled? Answer: The full administrator token.  This is why Windows 7 (and Vista) behave like traditional NT with UAC disabled.

What if you want to use the full token?  You can run you application elevated (right click and select “Run as Administrator”). This will start the application with the full token instead of the filtered token. As an application developer, if you have a good reason to always start an application with the full token, you would set the appropriate run level in the manifest.

Let’s take a look at two different command prompts to illustrate this concept.

What’s a Standard User?
A standard user is only allowed to change their own settings and environment (per user).  An administrator can change system wide settings (per machine). Here’s a table of examples of what you can and can’t do as a standard user:

Allowed Not Allowed
Run most applications Install applications
Change per user settings Change system components
Read from per user and per machine locations Change per machine settings
Create local objects Perform operations requiring Admin privileges
Write to per machine locations
Create global objects

Just by simply limiting the scope of changes a user/application can perform can have a big impact on security, reliability, and stability of a machine. Enterprise guys who manage lots of desktops like the concept of standard user because it helps lower their TCO.

Finding UAC Issues
The first step to determine if you have a UAC issue is to try running the application elevated (right click – Run as Administrator). You can also try turning UAC off.  If your application works in one of these scenarios, you probably have a UAC issue.

UAC issues are caused by an application trying to make a change system wide. This means it’s trying to write to a per machine location or create something globally across all users.

Is your application trying to:

Write to Program Files, Windows, System32, HKLM/Software, or Root?
Create anything “globally” like a memory mapped file?
Send Windows messages between an app running as standard user to one running elevated? (See: this post)
If so, this is where to start looking for the problem.

After you have an idea of where the problem might be, Process Monitor is a great tool to start isolating the issue.  Process Monitor will log all file and registry activity and will usually point you in the right direction.

Read more: Pat's Application Compatibility Blog

Posted via email from jasper22's posterous