Transactional Vista: Kernel Transaction Manager and friends (TxF, TxR)

I really don't understand why there's been this backlash about UAC. Something had to be done, and UAC is I think a very pragmatic and yet elegant solution. Sure at first its a little shocking - but the truth is, even as a developer, that once you've reached
a steady state and your machine is broadly speaking configured with the various tools and packages you need to create code etc then the number of secure-desktop prompts you encounter falls away dramatically. To the point that I definately **feel** more secure
under UAC. I get a real sense of comfort knowing that I'm not being to be led into letting some bit of malware run off with the system.
The only thing I have done is to enable the capital 'A' (legacy) administrator account so that I can occasionally launch a PowerShell instance in "XP security backwards compatibility mode". And in almost all cases that's because of some batch tool that does
have a manifest to prompt for privilage elevation build in. Nope, UAC is a Good Thing - more of the same please.
fernaus wrote:I wanted to express the exact same sentiments as the first poster. I recently upgraded to Vista because of UAC. It works perfectly well, it is not intrusive because after the first couple of days you are hardly ever prompted and in fact whenever I get a UAC prompt, I already was prepared, because I expected to get one. It will all be worth it, the moment I get my first UAC prompt I did not expect.
AndyC wrote:Ok, you asked, so I'll tell you the one UAC issue that is bugging me right now: File sharing.
On XP members of both Power Users and Administrators can share folders on the network. The same appears to be true on Vista, but only if you create a custom MMC snap-in, as the 'Share...' context menu item insists that you must elevate to a full Administrator account (both with and without the wizard). Is there any workaround for delegating the right to share folders to standard users, or at least to make the experience a little less odd for members of the Power User group?
dot_tom wrote:I really don't understand why there's been this backlash about UAC. Something had to be done, and UAC is I think a very pragmatic and yet elegant solution. Sure at first its a little shocking - but the truth is, even as a developer, that once you've reached a steady state and your machine is broadly speaking configured with the various tools and packages you need to create code etc then the number of secure-desktop prompts you encounter falls away dramatically. To the point that I definately **feel** more secure under UAC. I get a real sense of comfort knowing that I'm not being to be led into letting some bit of malware run off with the system.
The only thing I have done is to enable the capital 'A' (legacy) administrator account so that I can occasionally launch a PowerShell instance in "XP security backwards compatibility mode". And in almost all cases that's because of some batch tool that does have a manifest to prompt for privilage elevation build in. Nope, UAC is a Good Thing - more of the same please.
Sven Groot wrote:
AndyC wrote:Ok, you asked, so I'll tell you the one UAC issue that is bugging me right now: File sharing.
On XP members of both Power Users and Administrators can share folders on the network. The same appears to be true on Vista, but only if you create a custom MMC snap-in, as the 'Share...' context menu item insists that you must elevate to a full Administrator account (both with and without the wizard). Is there any workaround for delegating the right to share folders to standard users, or at least to make the experience a little less odd for members of the Power User group?
The Power Users group is deprecated, the only reasons it's still there is for (wait for it) backwards compatibility (even says so in the group's description). You shouldn't be using it.
BlackTiger: I could move those folders without even needing to elevate, so I don't know what you're talking about.
EDIT: Or perhaps you mean that you could change the location but couldn't access them afterwards? That can happen if your account doesn't have the necessary rights to the new location. But that's not UAC's fault, it can happen on XP too.
Sven Groot wrote:
The Power Users group is deprecated, the only reasons it's still there is for (wait for it) backwards compatibility (even says so in the group's description). You shouldn't be using it.
BlackTiger wrote:So (I'm not MS employee!), please tell me why I have this problem ONLY IF UAC IS ENABLED.
I do think UAC is a good and needed thing. It's clear that running as an admin all the time is dangerous.
What I don't undertand is why or how come changing your system DPI is so risky for your sistem that only administrator can do it? What was the criteria used to rate it so dangerous?
Atte:
Raptor
Jonathan here (the guy from the video) to answer some of the questions that were posted.
BlackTiger:
The issue you hit isn't actually related to UAC. The problem actually involves a subtlety with running elevated combining with the method you used to change your configuration.
When you're running elevated (either as a member of the Administrators group with UAC turned off, or after going through the elevation prompt with UAC on), any directories/files that you create are owned by the Administrators group, rather than your user account.
When you relocated the directories, you had UAC turned off so the ACL was set in a way that granted no access to your user account directly (i.e., you had access via membership in the Administrators group). When you turned UAC back on, you were then running with
a filtered, non-admin token and as a result, had no access to the directories that you had created when you were running elevated.
That's also why you only see the issue when UAC is enabled.
JChung2006:
The modal dialog behavior (or rather, switching to the secure desktop to display the elevation dialog) is actually configurable by policy. If you want to switch it off, simply do:
Start
"Local Security Policy" (launches secpol.msc)
Local Policies --> Security Options
Select "User Account Control: Switch to the secure desktop when prompting for elevation"
Change the policy to "Disabled"
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.
The huge caveat here is that turning off this policy exposes you to UI spoofing attacks that target the elevation dialog (e.g., overlaying different text, or a different dialog image entirely, on top of the elevation prompt). This becomes possible once
the elevation dialog is displayed on the user desktop.
--Jonathan
raptor3676 wrote:What I don't undertand is why or how come changing your system DPI is so risky for your sistem that only administrator can do it? What was the criteria used to rate it so dangerous?
jimbawb wrote:My main gripe about UAC (Trust me, I'm not about to disable it) is simply around UI:
Sometimes not enough information is presented for me to be able to make a decision on whether to allow the operation or not. Some of the names are quite obvious (e.g. when doing file operations), but what I'd prefer to see is an "advanced" version of this dialog detailing:
- Who (which process, its PID, its location on the filesystem) is requesting the operation
- Exactly what does granting this privilege mean (they have rights to do what now?). When running applications that do things under the covers, it may not always be possible to directly link an action you performed to the UAC prompt that just popped up.
- A verifiable link to confirm they are who they say they are, e.g. validate their signing certificate if present.
JonSchwartz, thanks for the replies. I'll see if I can get a list of what they do....probably mostly gaming and all the anti cheat, autopatch stuff.
Anyways, last time I checked IVC, they didn't have an announcement, but I'm glad they are going to support Vista!
Now once more I have something else to add. Some apps will not set themselves as default unless they are run as admin the first time. Foxit PDF reader and µtorrent exibit this behavior. It took a little while to figure out why Foxit PDF wasn't opening my PDFs
by default. So all I did was run it as admin one time, then after that things work. So that might be something to look into.
Hello. I’m the other UAC team member from the video.
David62277: I can understand your concerns around deployment to Standard Users, in fact, whenever I give a talk about moving an environment to Standard User desktops this is the first issue I mention. Fortunately, there is a solution built into Windows – it’s called Group Policy Software Installation (GPSI).
There is documentation about GPSI available here: https://technet2.microsoft.com/WindowsServer/en/library/b7c2efc1-207e-4089-8490-0d002daf8b6c1033.mspx?mfr=true
GPSI allows an IT Pro to install products on a system by pushing them directly onto the machine, by allowing the users to initiate the installation of specified MSIs, or by automatically installing the products when necessary. This technology also includes facilities for updating the applications without needing to visit each machine.
There are reasons that GPSI may not be perfect for your environment. In those cases, our customers generally acquire a 3rd party product to help solve this problem. While we understand that this isn’t optimal, the cost of these products generally are covered by the reduction of the TCO of the environment.
That’s a very good question. Thanks!
ChrisCorio,
Thanks for the reply. I am aware of how to install software using group policy. It is a great feature that we use now to install the Citrix client to all new domain computers. The problem is that NONE of the software packages that we have here (Accounting
Firm) install from a .msi.
I will have to look into some 3rd party apps. Is there any particular package that Microsoft endorses?
Also, would it be possible using GPOs (maybe a custom one?) to allow certain installers in a specific path to automatically install as an admin? Like say... a GPO that allows a specific installer located at \\server\apps\software\install.exe to automatically
install as an admin?
Again thank you for your reply
David
JonSchwartz wrote:(hit "Post" a tiny bit too soon there)
It looks like Internet Video Converter has a Vista-compatible version (1.40) coming out next week, based on the announcement at http://www.ivcsoft.ca.cx/.
--Jonathan
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.
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?
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 . . .
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.
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
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
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
https://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
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
https://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
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
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.
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
when a standard user cannot CHANGE the location of network from public (WHICH was once connected to as PRIVATE and is SELF SWITCHING to PUBLIC) THERE IS A PROBLEM!!!!!!!!
FIX your WINDOWS UAC
I fixed it with WinAero Tweaker, cuz evidently Windows Developers are to dumb...