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,
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
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.