Comment Feed for UAC - What. How. Why. (Going Deep on Channel 9)

Re: UAC - What. How. Why.

Jason Foster — Fri, 18 Sep 2009 11:57:54 GMT

Whether it can happen on XP or not, we would hope that Vista and beyond would be better :)

I'm new to Vista/Windows 7 (i.e. UAC), I just installed Windows 7 a few weeks ago on my Wife's computer, and today I took the plunge and installed Windows 2008 R2 on a new computer I bought for myself. I'm a developer.

So far, I must heartily agree with the second post in this thread, that there is something messed up with fileshares. I'm seeing more or less the same behavior as he descirbed.

I've created a user on the Windows 7 computer, and added him to the administrators group and every other group on the computer, and then I gave all of these groups read/write access to a new fileshare.

However, the only way I can access the share is if use the "Administrator" account for the credentials to access the fileshare.

The other account can access the public share, but not the additional shares.

I'm not looking for a solution - this is a home network, I'll just login with the Administrator account and be happy ever after - but I'm just trying to underscore a problem and provide some agreeance with that poster, even if it is 2 years later :)

Re: UAC - What. How. Why.

Marc Roussel — Sat, 09 Aug 2008 10:21:26 GMT

My Protected Mode is always Off even tought I set it Enabled in every Zone
No I'm not running IE in Administrator mode
Yes my UAC is enabled
Yes I'm using Windows Vista Home Premium SP1 Everything is up to date
No I didn't change anything in my IE setting since this has happened last month only
Yes I did try a full IE Reset

Oh and its IE7 :)
What else ?

Thank you for your help

Re: UAC - What. How. Why.

JonSchwartz — Mon, 14 Apr 2008 14:34:22 GMT

avgroenink:

This is actually unrelated to UAC. The system will set the owner of objects created by admin/elevated tokens to the Administrators group; this prevents any non-elevated malware running as you from coming along later on and being able to modify the object (which it would be able to do if your user SID was set to the owner instead).

Since you're a member of the Administrators group, this is the behavior you'll get in the case with UAC turned off (since you're running as a full admin).

With UAC on, my suspicion is that you somehow ended up with Explorer running elevated (e.g., it died and you restarted it from an elevated instance of Task Manager, etc), and that's why you ended up with the unexpected ACL there.

Let me know if I'm reading the config or folder locations incorrectly, in which case I'll go back to the drawing board for the answer :)

--Jonathan

Re: UAC - What. How. Why.

avgroenink — Sat, 12 Apr 2008 08:24:54 GMT

Addition to my previous post: when I create a new folder on the desktop, it is owned by "Administrators" (plural) and the group is Domain Users. It has no permissions:

cygwin$ ls -l ~/Desktop
d---------+ 2 Administrators Domain Users 0 Apr 12 10:19 New folder

cygwin$ ls -lad ~/Desktop/
drwxrwxrwx+ 6 annius Domain Users 12288 Apr 12 10:19 /home/annius/Desktop/

(permissions 777 set on Desktop is probably due to one of my previous attempts to get full ownership of the files on my desktop).

Re: UAC - What. How. Why.

avgroenink — Fri, 11 Apr 2008 15:45:11 GMT

I am not sure what I am experienced has anything to do with UAC, but I suspect it does.

I am logged in as a regular user ("annius") and I am in the administrators group. When I create a folder in my Documents folder, it is owned by "annius" as I would expect. When I create a folder on the desktop, it ends up owned by "Administrator" (I don't need to answer any prompts to get it owned by Administrator). Subsequently, I can't rename it or put anything inside it.

Could this be because I once "elevated" and as of that moment I my Windows explorer runs as "Administrator"?

This happens regardless of whether I have UAC enabled or disabled.

The only thing that is special is that this happens on a laptop machine that operates inside the windows domain at work when I am at work, then I put it to sleep, and take it out of sleep at home where the domain "is not there". Again, not sure that that has anything to do with the problem.

Re: UAC - What. How. Why.

Gordon Martin — Fri, 30 Nov 2007 21:49:07 GMT

Thanks for your response Jonathan! Some great detail there.

A quick follow-up on some of the questions:

2) Good details regarding communication with Outlook. But I think creating a script which launches via Scheduled tasks which then picks up message contents via an intermediate INI file or through some kind of listening code is beyond the reach of most administrators. Unless Microsoft provides some guidance/sample code to support this approach, I think most admins will simply end up elevating Outlook. However, if COM is as strict as you say it is, elevation of Outlook may not be the end of the world. I think another valid approach would be to find a third-party e-mail package that isn’t quite so strict. I assume that if I am elevating a tool it would still be able to communicate with any application operating at the user level – such as a third-party e-mail product.

3) Yes, I’ve seen the Consent vs. Credentials security settings before, but that is not a very friendly solution. The problem is that the consent approach is great for 98% of a user’s experience – particularly when they have legacy apps that need local admin rights in order to run. It’s just that remaining 2% where there is no way to elevate to another admin account at all. It wouldn’t be very nice if we make someone suffer 98% of the time by forcing credentials just to make the remaining 2% possible. There are two things that I would like to see change – either of which would greatly improve my situation. One would be to offer a button on the consent prompt such as “enter credentials” so that the user can choose to enter credentials for another account for only the 2% of the time when it is required. I also really miss the “Run As…” option on the context menu. As discussed, the “Run as administrator…” prompt has its limitations.

Currently, most of our administrators have resorted to using the RUN AS command from a CMD window in order to get their work done. It’s funny to have this beautiful OS, but to spend all our time in a black DOS screen. This problem would go away if we could get a RUN AS on the context menu (I just might try to write one).

While I’ve got your ear, I’d love it if you would explain to everyone the behavior of the Windows Explorer (file manager). It clearly doesn’t follow the usual application elevation rules. We now use the “Launch folder windows in a separate process” option to allow us to elevate Explorer, but even with that option it will not allow us to elevate to another admin account. If we travel to a user’s desk, it is not possible to elevate Explorer with an admin account and perform functions reserved for administrators. In fact, Explorer is downright misleading on the whole subject. If we try to manage files in the System32 folder with a user account, Explorer will prompt for all sorts of credentials and things as if it will elevate us, but in the end we don’t get what we need. Either nothing happens or we get messages unrelated to what is really happening. This has been very frustrating and has cost many people time as they scratch their heads trying to figure out what is happening. What is happening? Could you tell us?

At the moment, the only way we have been able to do our jobs has been to perform things like system32 file management from the DOS prompt. Lately we have actually been finding third-party file management programs on administrator PCs. It was surprising, but actually makes sense. Third-party file managers look like normal applications to Vista and therefore elevates normally. It then becomes possible for administrators to do a lot of their work without resorting to a DOS CMD window.

Thanks for your time Jonathan, it is much appreciated,

Gordon Martin
http://VistaVitals.blogspot.com

Re: UAC - What. How. Why.

JonSchwartz — Tue, 13 Nov 2007 16:51:36 GMT

Yup -- still monitoring the forum actively :)

Some great questions there -- here goes:

1) Mapped drives get interesting in combination with the "split-token" account, because of a weird dichotomy in the system (in large part historical) -- the drive letters are per-user, but the underlying drive mappings are per-LUID (i.e., distinct for each individual logon, even for the same user). This is why the mappings disappear when you elevate, and the setting you found tells the OS that you want the mappings you make non-elevated to be mirrored into your elevated context as well -- under the covers, the NTLanman network provider maps the drive and then asks the LSA to find the associated elevated token and use it to mirror the mapping. Technically, it opens a small loophole since non-elevated malware can now "pre-seed" a drive letter + mapping into the elevated context -- that should be low-risk unless you end up with something that's specifically tailored to your environment.

2) For COM servers configured as "Activate as Activator," COM does some very strict matching to ensure that the client/caller and the COM server have the same security attributes -- this was actually the case pre-Vista as well (e.g., blocked from clients started with runas.exe, running in a different TS session, running with a filtered token, etc). It's done to prevent attacks against the client both via spoofing (i.e., malware can spoof the class/ROT registration) and COM callbacks (from the lower-privileged server). One possible solution for you would be to route the script to something running as the interactive user, and then to call Outlook from there -- the simplest solution that comes to mind would be to use a Scheduled Task for this (i.e., script passes the information to the task, which invokes Outlook).

3) You can actually configure the UAC policies to change the prompt type from "Consent" to "Credentials" for cases where users have (effectively) multiple admin accounts. Take a look at http://blogs.msdn.com/uac/archive/2006/01/22/516066.aspx for a good walk-through and screenshots with secpol.msc.

4) If the program is marked as "requireAdministrator," we won't accept anything less than a full admin token -- in the example you gave, the user will actually get a credential prompt (rather than consent) since the user's elevated token doesn't contain the "Administrators" SID.

--Jonathan

Re: UAC - What. How. Why.

Gordon Martin — Wed, 07 Nov 2007 21:19:22 GMT

Hello Jonathan and Chris,

I hope you are still monitoring this forum thread even if it is getting a bit stale.

I just watched your video and absolutley loved it. It is great to be able to get insight into what the developers of such a critical feature were/are thinking. It has refreshed a lot of the random bits I have collected in the past and put them into context quite nicely.

I love what UAC is trying to do, unfortunately I am one of those that isn't a big fan of the cost incurred by me and my company by allowing UAC to run. I totally get Vista trying to compartmentalize things and not letting things run roughshod over the whol OS - a long overdue feature. I understand that once developers are retrained to create applications that are obediant, life will be good. But in the mean time my life is much more difficult and the cost to my organization is likely to be high.

I'd like you to convince me that I am wrong. Here are a few issues I'd love clarified and I have yet to find anyone knowledgeable enough to answer (you look knowledgeable enough :-)

1) I have network admin scripts and tools that are located on network shares which also store logs there. When I try to elevate these tools with my admin account (which they need to run), they fail because the drive mappings disappear. This is because of the mappings being associated with my filtered token and my full token not being able to access them - if I understand things properly. I found KB article 937624 which describes creating the key HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\EnableLinkedConnections = 1 to allow the mappings to be visible from every priviledge level. BUt I have not found any information to describe what is actually happening technically or if this opens any kind of UAC loopholes. Can you comment?

2) Some of the elevated tools I run must send e-mails via Outlook. I have found that the scripts are only able to interact with Outlook if they first elevate Outlook as well. This obviously scares the hell out of me. Why is it necessary to do this? Why isn't my elevated script allowed to talk to an instance of Outlook operating at a lower level?

3) We have had to give some user accounts local admin priveledges in order to be able to properly install and use some older products that don't obey the new rules yet. The problem is that some of these users like to use domain admin tools that require their seperate domain admin account. However, when they go to elevate these admin tools, they are only given the UAC Consent prompt rather than the UAC Credentials prompt. Obviously Vista sees the full token for the Local admin and thinks that is good enough when clearly it isn't. How do we work around this? Is a better solution coming? (i.e. a button in the corner of the Consent dialog that lets us choose to enter credentials).

4) An extension of number 3) above... UAC is obviously being fooled by the presense of a full token - any full token. Will UAC make the same mistake if a program needs a full admin token, but the best the user has is Print Manager priviledges for his full token? Will UAC notice that the user falls short and ask for Credentials instead of Consent?

Sorry for the long e-mail but it looks like I might finally have someone knowledgeable to answer my questions here.

Sincerely,

Gordon Martin
http://VistaVitals.blogspot.com

Re: MMC Snap-in: UAC - What. How. Why.

JonSchwartz — Thu, 23 Aug 2007 15:05:21 GMT

sz204:

From the description, the problem hits because MMC is running elevated while your second app is not; as a result, the COM server runs elevated when started from MMC and the non-elevated app can't access its ROT entries.

I asked the COM folks for suggestions, and they mentioned two possible ways to solve this:

        1. The COM server can register in the ROT using
             ROTFLAGS_ALLOWANYCLIENT -- this is described
             towards the end of
             http://msdn2.microsoft.com/en-us/library/ms679687.aspx

        2. You can configure the COM server to RunAs
             "Interactive User" -- note that this solution assumes
             that the COM server itself doesn't need any admin
             privileges and will always be used in a scenario where
             a user is logged on (else it will fail to CoCreate).

--Jonathan

MMC Snap-in: UAC - What. How. Why.

sz204 — Mon, 20 Aug 2007 09:32:23 GMT

Hi,

We have a COM based application written in C++, and have difficulty to make it work on Vista. Will you please give guidance?

Our application talks to a COM exe, we also have a MMC snap-in talks to this COM exe, i.e. the application communicate with MMC(snap-in) via this COM exe.

Both the application and MMC(Snap-in) can start an instance of the COM exe if non-existence, and then share between each other.

On Vista, if the COM exe is started by either of them, the other one will fail to connect to the running COM exe, i.e. the code hr = GetActiveObject(...) returns faiure.

Following "Windows Vista Application Development Requirements for User Account Control Compatibility" document, I rebuilt the application embeding a manifest file with "level="requireAdministrator" uiAccess="false", the problem is gone.

However, we do not want to give the application "Administrator" right. so I tried to embed the manifest file to the snap-in DLL. No effect, the problem returns, GetActiveObject(...) gives me failure.

What is the best way to deal with this problem?

Thanks in advance.

Re: UAC - What. How. Why.

JonSchwartz — Thu, 10 May 2007 14:34:51 GMT

jbarklage

How is the error manifesting (e.g., "error dialog through the Shell that says xxxx")?

It's possible that the error is due to lower permissions due to UAC, but it's unlikely. UAC would be affecting things only if all of the following are true:

      1. Your users were running as members of the Administrators
           group

      2. The share is ACLed such that only admins can write to it

      3. The file share is also a Vista machine

      4. Your users have local accounts, rather than domain accounts

#1 + #2 would be required for a permission problem, since your users wouldn't be running as full admins unless they explicitly elevate. However, #3 + #4 would also be required for the token filtering to propagate on the wire -- by default, filtered admins using domain accounts get their full token on the target (Vista) machine to allow for remote administration.

One last thought -- could it be due to the firewall (either the one shipped in the box or a different one that you install on your client machines)?

--Jonathan

Re: UAC - What. How. Why.

jbarklage — Wed, 09 May 2007 22:08:55 GMT

I have nothing against UAC, i don't hate it, i don't love it.

I am a network admin for a consulting firm and some of our clients are starting to get Vista machines. We had one the other day tell us that they are unable to save files to the network shares. Tells them Unable to save files, does not matter what file type. :s

Is this issue caused by UAC? Would turning it off correct this or is this question for a different forum? Many thanks for your assistance.

Justin [H]

Re: UAC - What. How. Why.

JonSchwartz — Wed, 25 Apr 2007 21:29:07 GMT

Jason,

I dug into this one and it ends up being due to legacy behavior in the filesystem, where it returns ERROR_ACCESS_DENIED from MoveFile(Ex) in this case, rather than ERROR_SHARING_VIOLATION (or something similar). As a result, the Shell thinks that it needs to elevate (which it now has the ability to do via UAC, vs. XP when it could simply fail out), even though it's doomed to failure.

The filesystem folks are currently thinking through some ideas for what we can do here moving forward. It gets tricky since this particular case has existed in the filesystem since (at least) NT4, so simply changing the error code becomes very risky in terms of App Compat.

--Jonathan

Re: UAC - What. How. Why.

jasony — Sat, 21 Apr 2007 18:38:14 GMT

Jon:

Thank you for your replies. It's great to see you take such a proactive, enthusiastic stance with both the technology and your customers.

On another note, I ran into a behavior I'm not so sure is a bug but rather just misleading. I created a folder on the desktop and then later tried to rename it. I received three prompts including a UAC prompt. Finally, the rename failed. I was logged in as admin and had adequate permissions. After a google or two, I realized I had a word doc open that was in the folder. I closed the documents and renamed the folder without any prompts. In other words, the interaction I had with the system gave me the impression it was a security restriction of some kind and nothing about open file or anything of that sort. I know this may not be in your area but the access denied and UAC prompt was confusing. In XP it's real clear: "close down any open programs."

For what it's worth . . .

Re: UAC - What. How. Why.

JonSchwartz — Fri, 20 Apr 2007 15:37:49 GMT

Stefan,

        Remember that the case where the standard user actually knows the administrator's credentials is not the norm (except for folks like us :) ). Generally, the administrator needs to come over to the machine and enter her credentials to run the application; think of the example of a child in the home needing to get his parent to install a per-machine application (or alternatively, to get an exception to Parental Controls), or an enterprise desktop user who needs that same permission from an enterprise (or Help Desk) administrator to make machine-wide changes.

        As for application installers that currently launch the application at the end of the setup both elevated and in the wrong context, I agree. We're actively working with the associated ISVs to get that fixed in the next release of their app and have published developer guidance to the same effect.

        The design suggestion here is that developers structure their "install + first run" with the autorun (or initial stub) EXE acting like a bootstrapper that launches both the setup EXE (elevated) and then the application itself (in the same context as the autorun/stub) once the setup completes. This keeps things robust to any future changes and also covers any/all edge cases w.r.t. the initial context for the autorun/stub (e.g., running in Protected-Mode IE, running with a custom filtered token, etc).

--Jonathan

Re: UAC - What. How. Why.

StefanT — Fri, 20 Apr 2007 10:46:41 GMT

Hello Jon,

let me get this straight: You are worried that an user who has the credentials of an admin-user, could expose data of other users on the same pc? Hmm, I *think* that user can do that anyway.

I think it's more dangerous to start a newly installed application as an admin user. Why?
The standard-user thinks he has not the right or power to do any real damage to the OS. But the first "playing around" with a new application could possibly kill of the OS or can do real damage because it's the enviroment of an admin-user.

From this point of view, the UAC is not much more than a nicer "run as ..." feature. Why can't the "UAC-Service" sense the end of an installation and the first start of the application?

Stefan

Re: UAC - What. How. Why.

JonSchwartz — Fri, 20 Apr 2007 00:41:26 GMT

StefanT:

For the elevations, we needed to make sure that we didn't end up with users stepping outside of their groups/roles as part of the elevation, since that can lead to vulnerabilities or information disclosure as a result. For example, anything the elevated application (running as "standard user + admin SID") would save in its user profile would be accessible to the standard user later on and could expose data to which they otherwise wouldn't (and shouldn't) have access (e.g., results of a system scan that enumerates other users' files, etc).

JasonY:

You're correct about Windows Meeting Space being in the same bucket as IE. As for why we used the "unidentified" dialog in that case, it's primarily because the description and guidance is almost exactly what we'd want to say for a dialog specific to this category of system EXEs. That said, if we were to get feedback that multiple customers were seeing this dialog as part of a normal use scenario and getting confused/misled as a result, we'd definitely look into a new flavor of the dialog with more specific text.

I just verified that the bug you mentioned is on the Firewall team's radar. Very nice catch -- definitely let me know if you run into other spots like that!

--Jonathan

Re: UAC - What. How. Why.

jasony — Wed, 18 Apr 2007 17:08:24 GMT

I watched your video again and caught a reply to my own comment-- some programs you don't want to run as admin even windows programs-- so they get the "more dramatic" UI. You used IE as an example. I'm assuming Meeting Place would also fit.

The only thing I would add is the fact that the title of these pop-ups state's that it's an unidentified application. Do you really want Windows not identifying IE or Meeting Place?

Re: UAC - What. How. Why.

jasony — Wed, 18 Apr 2007 17:02:01 GMT

I may have found another bug. Running Vista Business. I disabled elevation prompts for standard users.

As a standard user, I get the expected dialog box denying my account access and not prompting me except when I try to change Windows Firewall settings. Instead, it just sits there. Specifically, I navigated to CP and selected Windows Firewall. From there, I'm selecting Change Settings. It has the Security shield next to it so I'd expect one of those "you-can't-do-this" window but I get nothing.

FYI . . .

Re: UAC - What. How. Why.

jasony — Wed, 18 Apr 2007 05:06:20 GMT

Just have to say- EXCELLENT stuff. Love Channel 9. Keep it up.

FOR JOHN or CHRIS: I started right-clicking a bit to see the different credential windows and I noticed that when I run as elevated against Windows Meeting Space i get a unidentified program prompt saying it's an unrecognized and unsigned app.

Normal?

Re: UAC - What. How. Why.

StefanT — Thu, 12 Apr 2007 15:51:17 GMT

Hi, this video was very interesting. I'm using Vista as a standard user since I got my new notebook and found the UAC-popups annoying in the beginning but since most of the installations are done, it's ok for me.

My proplem with UAC is: When I install an application I have to provide the credentials of an administrator. After doing so, the installer runs as administrator-user.

Why is that? Shouldn't the standard user getting an "admin-token" and run the installation?

The next problem is the little checkbox at the end of the installer saying: "Launch Application now". If this checkbox is set, the first start of the new application runs as admin-user. I did have to configure some software twice because the first time I did it with the wrong user! That's at least annoying.

Maybe I'm getting this completly wrong but after watching the video I find this behaviour strange.

Greetings from Germany,
Stefan

Re: UAC - What. How. Why.

JonSchwartz — Wed, 11 Apr 2007 15:56:13 GMT

Just a quick update on the Gadget download experience -- it turns out that the third prompt in the sequence is actually an IE security prompt, rather than a UAC prompt. Unfortunately, the IE dialog uses the same coloring as one of the UAC prompt variations, which has caused some confusion in cases like this one.

That being said, I'm currently chatting with the IE and Sidebar teams to get the experience here improved.

--Jonathan

Re: UAC - What. How. Why.

JonSchwartz — Mon, 09 Apr 2007 18:23:33 GMT

SmallTalk:

Nice catch -- bad repro steps on my part. Ironically enough, I'm very familiar with the SKU differentiation around secpol.msc -- I just ended up being careless there, since all of my office machines are currently running business SKUs :(

For those who are looking to modify the policies with RegEdit, the following values map to the policies I mentioned earlier:

Key: HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System

Values:
        ConsentPromptBehaviorAdmin
                0 -- elevate without prompting
                1 -- prompt for credentials to elevate
                2 -- prompt for consent to elevate (default)

        PromptOnSecureDesktop
                0 -- prompt on user desktop
                1 -- prompt on secure desktop (default)

evildictaitor:

Thanks for the heads-up on the Gadget download experience. I'll look into it and make sure the right folks are on it.

Wodei:

The times you've needed to run an MSI from an elevated CMD window are actually bugs in the MSIs themselves. Essentially, each MSI action can be marked as running as the user (i.e., non-elevated) or as the machine (i.e., elevated). Over the course of Vista, we saw quite a few MSIs that had per-machine custom actions mismarked as per-user -- we shimmed them (via MSI transforms, which get installed to %WinDir%\AppPatch\msimain.sdb as part of the OS shim infrastructure), but some obviously managed to fall through the cracks. If you can point me at the problematic MSIs, I can make sure the ISV knows what needs to be done (and potentially get them shimmed for SP1).

Note that not all MSIs require elevation, since MSI packages can be marked as entirely per-user. I expect to see much more of this moving forward (e.g., it would be ideal for a game demo or "try and buy" software).

For WinRAR, version 3.7 should be fully Vista-compliant, including elevation only when necessary (e.g., unpacking to an admin-only folder, vs. your user profile) and fixing the issue with the context menu handler. The Visual Studio team, similarly, has their elevation behavior at the top of their list right now.

In theory, the shield should automatically be appearing on any EXE that's marked to require elevation -- any inconsistency there, like you said, makes the marking nearly valueless. I'll see if we can repro that on-site with the VS and WinRAR settings you described.

Re: UAC - What. How. Why.

smalltalk — Mon, 09 Apr 2007 16:51:44 GMT

Sadly, it appears that the Microsoft Engineers responsible for UAC aren't even aware that secpol.msc is not included in Home versions of Vista.

Did you guys get a say in that decision? I assume not since you don't even know it is a missing feature.

Fortunately for the very high tech home users (like grandma) they can simply use RegEdit to change UAC policies. User friendly and very efficient.

Confirms my suspiscions that the "user community" that was asked to review the UAC design was mostly MS marketing managers. ;)

Lots of prompts

evildictaitor — Sun, 08 Apr 2007 16:10:27 GMT

You mention in the video that you'd like information where lots of prompts come up, so I thought you'd appreciate this one, although only one is a UAC UI prompt:

Downloading a new gadget to the sidebar:

1. From the site, where you find a nice gadget to download, you click it. Microsoft's website then queries that you are about to download another persons code. Click OK. Dialog1.

2. You are now redirected to the download itself. It asks you if you'd like to save/run it. Click Run. Dialog2.

3. The program downloads, but it's a dot-gadget file, so you need to click Open. Dialog3.

4. But the dot-gadget file was from a website. In comes UAC to tell you of the fact, and we answer OK or stick in a password. Dialog4.

The sidebar finally installs it's gadget.