Comments

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

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

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

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

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

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

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

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

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.

Sorry for the slow post/response -- was out of town for a bit.

AJenbo:

Agreed on the environment settings UI -- that's a spot that needs to be refactored, and it's on our list.  Obviously, I can't give a specific date or ship vehicle, but it's definitely being investigated and scoped out as I write this.

Raptor3676:

The same applies to the DPI settings -- those are currently done per-machine down inside of the User/GDI infrastructure (win32k.sys) and need to be supported per-user (similar to display resolution).

smalltalk:

The default UAC settings in Vista are actually the result of extensive usability studies and customer feedback over the Vista development cycle.  A very good read is Jim Allchin's final blog entry, which digs into some of the tradeoffs that had to be made regarding security and usability:

http://windowsvistablog.com/blogs/windowsvista/archive/2007/01/23/security-features-vs-convenience.aspx

That being said, the settings you mentioned can be controlled by policy.  To change your prompt policy from "consent" to "credentials," do:

      Start

      "Local Security Policy" (launches secpol.msc)

      Local Policies --> Security Options

      Select "User Account Control:  Behavior of the elevation prompt for administrators in Admin Approval Mode"

      Change the policy to "Prompt for credentials"

Note that you'll need to explicitly launch secpol.msc elevated (via right-click + "Run as administrator...") if you're running as a standard user.  The policy change will take effect immediately.

If you want sudo-like behavior, change the policy to "Elevate without prompting" instead -- this allows you to launch items elevated without a prompt until you switch the policy back to "consent" or "credentials."  Another option is to launch an elevated instance of CMD (via right-click + "Run as administrator...") and run a batch of commands from there -- it's actually more secure than using the policy since you're still controlling the exact set of commands that you're running elevated, vs. opening the door for anything on the machine to launch arbitrary executables elevated.