You may heard of a little thing we like to call Windows Vista. In fact, you may be slightly deafened by our marketing making sure you do know about it.
Vista contains various security enhancements all designed to work toward the goal of keeping folks from unintentionally getting compromised by bad people. Bad guys have a nasty habit of attempting to attack the most widely adopted platforms (most bang for their “buck”), and guess what that’s Windows.
So let’s go over how User Account Control works first, then we’ll go over the tools and techniques you as an admin or troubleshooter can use to find out if UAC is involved in a problem or not, and if it is how to fix it.
A perhaps oversimplified (and not entirely accurate but it helps) way of thinking of things is that Windows creates an user token at logon which acts as a bit of a keychain. Next, picture the keys on that keychain as the security groups that the user belongs to, whether local or domain/forest based. There are also suspect privileges, otherwise known as user rights, that are assessed, but let’s not dispel my keychain analogy.
With UAC, at user logon the credentials for that user are assessed to see if they belong to any highly privileged groups, like Administrators. If they are, we create two different tokens for that user. One contains all the normal security group memberships and privileges that the user normally has, including Administrators and the like, just like if the user was logging on to Windows XP.
The other token, or keychain, created is minus all of the highly privileged security groups, and actually contains a deny for them. It’s also missing all of the user rights (privileges) that allow things that could be scary if a bad person had somehow gained access to the user’s credentials or compromised their session in some way that allowed them to execute code as that user.
So we have those two keychains created, behind the scenes, at user logon. To understand how we use those tokens we first need to understand how these tokens are used within Windows a little bit. The usual manner in which an application is launched is by using Explorer.exe (the shell) to open a new process for that application. The user token that is used to run that application under would be taken, essentially, from Explorer.exe. So, if a user double-clicked on IGNOREWORK.EXE what was really happening was that Explorer.exe was running code to run IGNOREWORK.EXE in a new process using the context of the user who did the double-clicking.
UAC adds a complex but useful twist to that. Remember that is the user was identified as being privileged one they have logged on and gotten two tokens created. The less privileged one is used to run Explorer.exe. When the application is chosen to launch (like when the user double-clicks on IGNOREWORK.EXE or whatever) there are some checks to see if the application has a manifest which says “hey, I need to run as highest privileges”, or “don’t trust me overmuch”. Applications which are written for Vista compliance will have these, other’s will rely on user intervention or an application compatibility database that is either edited by the user when they choose what integrity level to run as, manually edited, or distributed by an admin (though some aspects of that-like via group policy-may be included in future server product). Vista compliant applications will have a manifest detailing the requested level of access. Others will rely on that little application compatibility database on the computer. It’s also worth noting that our developers have spent a lot of time and effort to making the most common and widespread applications work out of the box by creating entries, or shims, for them in that application compatibility database already.
Application installers are identified and treated differently as well, but it’s less complex and easier to deal with.
So we have a lot of logic which takes place that helps identify which token and integrity level the application should use, and sometimes this logic results in a prompt to the user “do you want to allow this to run elevated?” or “can you type in the admin credentials?”. The level of access the application gets depends on that result.
Anybody fall asleep yet? Wake up, there’s more!
In addition, we also know that applications sometimes struggle with registry key permissions which can cause odd behavior. In the past, that’s been an argument for simply letting all of your users to run as local administrators. Since in lower integrity levels you don’t have the advantage of using Administrator group membership to ease you along and give you that access there needs to be some help there. In those situations, file and registry virtualization helps. Basically, for certain files and registry paths, if the process (application) gets a deny the system copies and allows access to a duplicate of that registry or file object. This is done seamlessly so that the application just works. The duplicate is created on the fly, unnoticeable. This is an “on-demand” thing so it only happens when the application attempts to do a file or registry read or write where it doesn’t have access.
That’s the basics. Now let’s go over two basic things to look at when troubleshooting.
Is UAC Being Used?
Identify whether the session is running with the “split token” at all. In other words, at logon, was the user identified as one that needs to have a lower integrity token created? Is UAC on at all?
By default no event is logged for the simple act of UAC split token logon. What you can look for though is what token Explorer.exe (and possibly others) is running under using the latest Process Explorer. Like we talked about above, the token (aka keychain) will be different. The latest version of Windows Explorer contains addable columns for Integrity Level and Virtualization which, when added, will display those details for the processes running when you look in Process Explorer’s main view.
Process Explorer can be downloaded here:
Level of Medium or Low will be the indicator of UAC being present, and the process being ran as a Standard User. A High listing for a process means that process is running in the highest elevated context, so perhaps a user chose “run as Administrator” for it. Also, the virtualization flag may or may not be on, but if it is there then that is most likely a lower integrity process that may need that assistance to run well.
Keep in mind that if you launch a new Explorer.exe process and choose to elevate it when you launch it then things will look like, and in some ways run like, you aren’t experiencing a UAC logon at all.
Task Manager, by the way, can also do the display of virtualization if you don’t have access to the internet to download Process Explorer. It does not however display integrity level or the other great details you can get from Process Explorer.
Virtualization can be a factor when the application needs access to some file or registry based resources. I can’t conceive of too many scenarios where this will come in, but it could happen. So here are a few things to keep in mind:
-Not all registry objects are virtualizable, some can even be specifically marked as not virtualizable intentionally
-A process must have the Virtualized “flag” on to gain a virtualized copy of a file or registry object on the lack of access
Registry virtualization can be checked to see if the registry value is there by looking in the per-user location of HKEY_USERS<User SID>_ClassesVirtualStoreMachineSoftware.
The virtualized registry entries are stored in the USRCLASS.DAT file. As a result, virtualized registry keys do not roam with a roaming profile. If a user logs into a different computer with the same roaming profile which was used at another computer where registry entries were virtualized, then the keys will need to be virtualized for that user again on the new computer, as needed. That shouldn’t be a problem since virtualization happens seamlessly and without stutter behind the scenes. But I mention it so you can know as much as possible.
File virtualization will be located in the user-based profile location of being <drive letter>:Users%username%AppDataLocalVirtualStore. These should roam with the profile (to be honest I haven’t tested that with the released version of Vista). A directory structure mimicking the original will be created there along with the virtualized file.
In the new Event Viewer (EVENTVWR.MSC) a new node for Application and Services Logs is present. More information for UAC is available in the Application and Services LogsàMicrosoftàWindowsàUAC and UACFileVirtualization nodes. Some events of interest are:
o Event 5000 –A noticed action took place against a file that is excluded from virtualization.
o Event 4000 –Creation of virtualized file.
o Event 4002 –Request deletion of virtualized file.
I will mention that there were some cool events for process elevation under the UAC log by default that could be helpful, but I’m not seeing them in the released product. I’ll dig in on that and see how to get them and comment or update this post later on that.
More information on UAC generally, including references on the groups which will cause creation of the split token logon, is here:
I’m not certain what level of detail folks are interested in with respect to the UAC feature for future posts so I’d like to hear from you all. There’s quite a bit more we can talk about. I will say that generally I’m avoiding discussing the application compatibility aspect as a focus since it’s on the edge of what a directory services or security specialist will want or need to know in my opinion. But I can always direct you to info on it.
Take care out there and post comments or email me. I look forward to hearing from you all!