Hello Everyone, My name is Frank Kim and I work in Developer Support.  My expertise is in Windows Security (Authorization + Authentication), Remote Desktop and Windows Services.  For my first blog post, I thought I would discuss an interesting issue encountered by several of my customers.

User Access Control (UAC) was introduced in Windows VISTA to force users to run as non Administrators.  A lot of applications encountered "Access Denied" errors when UAC was enabled.  A bad answer to resolving this issue was to turn off UAC. We would assume that if UAC was turned off and if the user was running as a FULL administrator, everything would just work.  In the case below, this wasn't true.

Let me explain what was going on.  With the introduction of UAC, we also introduced the Windows Integrity Mechanism.  The purpose of Windows Integrity is to restrict the access permissions of applications running under the same user account that are less trustworthy.  The mechanism prevents less trustworthy code from modifying objects at a higher level.  (This definition is from the following MSDN article):

http://msdn.microsoft.com/en-us/library/bb625962.aspx

The Windows Integrity Mechanism is used in Internet Explorer and is known as "Protected Mode".  Basically, it prevents code in Internet Explorer from accessing secured objects such as files since IE is running at a lower level.

I had several developers encounter impersonation issues with LogonUser() when UAC was turned off and the issue was with Integrity Levels.  What was happening is if you were running as a normal user (medium integrity level) and you attempt to impersonate a user who belongs to the Administrator group, you would get the following scenarios.

1. If UAC was turned ON, due to UAC, the user who was an Administrator would still be running as a non-Administrator and thus their resultant integrity level wouldl be medium.  A medium integrity level user can impersonate a medium integrity level user.

2. If UAC was turned OFF, the user whose an Administrator would be running as an actual Administrator and thus their resultant integrity level would be a high.  If a medium integrity level user attempts to impersonate an high integrity level user, the resultant impersonation would be at the IDENTIFY level and NOT IMPERSONATION level. 

This resultant impersonation level led to "Access Denied" issues in the code since at the IDENTITY level you can only do AccessChecks.