Active Directory Blog : Vista, User Account Control

Thoughts on Single Sign On and Credential Providers

Tim Springston — Tue, 26 May 2009 19:35:26 GMT

We use the term single sign on (SSO) to describe a variety of behaviors in Windows and other applications where the result is simply to prevent the user from being prompted to provide their credentials again and again; to ideally enter their credentials...(read more)

How To Cut Down On User Account Control Prompting

Tim Springston — Fri, 23 Mar 2007 22:46:00 GMT

We’ve had a few customers tell us that they would really like to not be prompted in application launch scenarios with some applications. There are some valid reasons why this may not be entirely helpful and reduction in clickage can be good when it doesn’t lessen security.

Say you logon with Group Policy Creator Owner domain security group privileges. If that is the only elevated, or most privileged, security group you have membership to then opening regedit.exe with your standard credentials (saying “don’t elevate” essentially) shouldn’t be a big concern right? Since the security group that got UAC to give you a split token logon doesn’t give you additional privileges to do things with the registry. But you get prompted anyway, every time you open regedit.exe with UAC enabled.

So you may want to make it so that you aren’t prompted for that application and maybe some others. Barring turning off User Account Control what option do you have?

Well, here it is. You’ve got to create a little “shim” and apply it. It’s not difficult and it does the job nicely. Keep in mind that if you do this you will need to right-click the program and choose “Run as administrator” ever after if you want that application to run with high privileges-so this could really impair an application that must have those credentials to run properly. So choose wisely on when to do this, and test it first before deploying to your users!

Here are the steps:

1) Download and install the Application Compatibility Toolkit (link below).

2) Open the Compatibility Administrator application with elevated credentials.

3) In the left hand pane, right-click on the database under Custom Databases and select Create NewàApplication Fix

4) Enter the name and other details of the application you want to alter behavior on and then browse to it to select it.

5) Click Next until you are in the Compatibility Fixes screen.

6) To prevent being prompted to elevate an application (which means that it will always use the less privileged credential to run) place a checkmark next to RunAsInvoker.

7) Click Next and then Finish.

8) Select File and Save As. Save the file as a filename.SDB type file in a directory you will easily find it.

9) Copy the <filename>.sdb file to the Vista computer you want to alter the elevation prompt behavior on.

10) Open an elevated command prompt.

11) Run the command (without the quotes, assuming you copied the file to the Windows directory on C:): “sdbinst c:\windows\<filename>.sdb” and then press enter.

Microsoft Application Compatibility Toolkit 5.0

http://www.microsoft.com/downloads/details.aspx?FamilyId=24DA89E9-B581-47B0-B45E-492DD6DA2971&displaylang=en

More info on the other options you have in altering application launch behavior are available at the URL below:

Application Compatibility Feature Guide

http://www.microsoft.com/technet/desktopdeployment/bdd/standard/AppCompact_6.msp

I’ve got some really interesting (at least I think so) posts coming up folks-so stay tuned and as always let me know if you have any questions.

I’ll Say It Again- User Account Control

Tim Springston — Mon, 29 Jan 2007 20:58:00 GMT

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:

http://www.microsoft.com/technet/sysinternals/utilities/ProcessExplorer.mspx

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

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>_Classes\VirtualStore\Machine\Software.

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%\AppData\Local\VirtualStore. 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:

http://technet2.microsoft.com/WindowsVista/en/library/00d04415-2b2f-422c-b70e-b18ff918c2811033.mspx?mfr=true

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!

A Vista UAC story: Can’t change the time Zone?

Tim Springston — Fri, 12 Jan 2007 18:25:00 GMT

We have internal discussion lists in Microsoft that act as clearinghouses for technical issues or hot topics. One of the first thing a fledgling or newly assimilated Microsoftie must do is decide what discussion lists to join for their role.

I am internal “owner” of the support alias for Vista’s new User Account Control. This in itself typically doesn’t generate anything worthy of comment, but recently it did.

You may have heard rumors (probably a result of the gargantuan, all-powerful behemoth that is the Microsoft marketing division) that we are soon to do the general release of Windows Vista. As part of the gearing up for showing people how truly cool Vista is (and believe me, it is) one of the things our marketing gurus are doing is toting laptops with Vista on them in order to demonstrate the coolness factor to everyone.

But of the many machines their test folks had set up for them, one of the laptops was not working as expected. The intention was to demonstrate that, while User Account Control was created to limit the use of the “full” token (one with Administrator or other greater access), some actions were altered to make them doable with less privileges. The intention was to maintain that balance between security and going batty from clicking too many “may I use the full token/provide me a full token” prompts.

Some articles which go over UAC, and the effort to make available actions to Standard Users which do not potentially lead to vulnerabilities, are here:

Understanding and Configuring User Account Control in Windows Vista

http://technet2.microsoft.com/WindowsVista/en/library/00d04415-2b2f-422c-b70e-b18ff918c2811033.mspx?mfr=true

How Windows Vista Helps Protect Computers From Malware

http://technet.microsoft.com/en-us/windowsvista/aa940967.aspx

To get back to the story, I was contacted by one of our marketing folks. One of the laptops they were preparing to take on the road and use to show the coolness of Vista to people was giving them a problem. Oddly, only one of the laptops they had prepared was not allowing them to change the time zone, which as you can read in the articles above, was one of the actions that was altered to allow Standard Users to do it.

The marketing person was nice enough to let me remotely access and trouble shoot the problem laptop. The error given was generic, not a true “access denied” that you would normally expect. And the problem did not occur for an Administrative user. Strange.

Much of User Account Control works in new process creation; in other words, happens when you launch a program. I didn’t spend too many cycles going over it, but changing the system time did not strike me as a new process creation scenario offhand.

So I decided to take a look at the registry and file objects that were being accessed when you try to change the system time as that Standard User (Toby in UAC parlance). In Windows Vista you must use the new Sysinternals tool Process Monitor (which can do many other very cool things) to do that. That’s available here:

Windows Sysinternals

http://www.microsoft.com/technet/sysinternals/default.mspx

When monitoring the registry and file accesses as I reproduced the problem, however, no access denieds appeared at all. Perplexing. In fact, it almost instantly appeared to start processing the little .WAV file that sounds off when the error was thrown.

That seemed to me to mean that the failure is occurring prior to the registry and file access. Which means it was either UAC or some other, more elemental, security reason.

Vista has some Windows component event logs for UAC, on by default, but they showed nothing related to this since, as I had been suspecting, UAC was not coming into direct play here.

Ultimately, user rights in Windows help to govern what actions can be done by what principals within the operating system at a very granular level.

Vista defines a new user right for changing the time zone, added as part of the general “make the Standard User able to do more without elevated privileges” initiative.

By default, Vista has the local Users group there. In the marketing persons laptop instance, that local security group was missing. So, his user was rightly prevented from taking that action.

It may have been done by an app install, or manually by someone. I was not sure. This is also configurable via GPO, but that’s not likely the culprit in a computer that isn’t, and never was, joined to a domain.

It can be pretty difficult to add the BUILTIN\Users back to that setting so to save myself some time I added Toby specifically back to that user right and then rebooted.

To go to that setting on your Vista computer:

-Open an elevated GPEDIT.MSC

-Go under Computer Configuration->Windows Settings->Security Settings->Local Policies->User Rights Assignment

-The setting is "Change the time zone"

This may be a less common type of thing that you in the real world will see with Windows Vista UAC, but I encourage you to take a couple of thoughts with you from this:

-UAC, or related actions for it, doesn’t end at assessed process elevation

-Process Monitor is a good way to troubleshoot things like this, which aren’t a traditional access denied error, and seem to fall into a grey area

-Not all users need to be Admins anymore…so you may not need to use UAC day-to-day after all

Have a great day everyone!