| Date: | August 22, 2012 / year-entry #196 |
| Tags: | tipssupport |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20120822-00/?p=6793 |
| Comments: | 31 |
| Summary: | A customer liaison asked the following question on behalf of his customer. When I do a shift-right-click on a shortcut to a program, I see the following: On Windows Server 2008, shift-right-click does not offer the option Run as different user. On Windows 7, shift-right-click does offer the option Run as different user. On Windows Server... |
A customer liaison asked the following question on behalf of his customer.
I found this question interesting for a variety of reasons. First of all, it comes dangerously close to being one of those Please tell me I'm not hallucinating type of requests. These support requests take the following peculiar form:
"Um, if you say so. I wasn't there." But in this case, it started out looking like it was going to turn into a Please tell me I'm not hallucinating request, then veered into "Is X the reason the feature was added back?" This is a rather peculiar question, because knowing the answer one way or the other doesn't actually take you any closer to a solution to the problem. (And I don't know the answer, but fortunately, it wasn't relevant to solving the customer's problem.) Another interesting thing about the customer's question is that he never actually comes out and asks the question. He sort of says a few related things, and asks a tangential question, but never comes right out and asks, "How do I get the Run as different user option to work on my Windows Server 2008 R2 machine?" It's like a kid who pointedly hangs around a candy bowl, hoping that an adult will say, "Here, have a piece of candy." You're a grown-up now. You don't have to linger around the candy bowl hoping somebody will figure out that you want some candy. You should just ask, "May I have a piece of candy?"
The customer liaison replied, "It appears that the option for Require trusted path for credential entry is not enabled. The customer is going to do a clean install and test on a non-domain-joined machine to avoid any GPOs." Some time passed, and the customer liaison reported back with a resolution.
It was very nice of the customer liaison to reply with confirmation that the problem was solved. This is, unfortunately, a notable event. Most of the time, people never report back if your suggestion solved their program; they only come back if your suggestion didn't help. Which means you're not sure if your suggestion solved the problem, or if it didn't solve the problem but they decided to continue the investigation somewhere else. Bonus chatter: This shows yet another reason why you should use Group Policy Objects to manage group policies rather than custom scripts that whack registry keys. In addition to the fact that registry key whacking may not work, there are tools for processing Group Policy Objects that make this sort of investigation much easier. |
Comments (31)
Comments are closed. |
There is a much bigger issue with the runas verb; when UAC is off it does not revert back to the NT5 UI so if you are using the verb programmatically to elevate you need to be prepared for this and check in the child process that you really are elevated…
If you want to hear back from a customer, you might want to let them know that. As in "Please let us know if these steps resolved your problem".
I'm trying to decide whether making the Server 2008 R2 behavior a <P> instead of an <LI> was intentional. The <LI> makes sense because they're three different OSes. But the <P> could also make sense because Windows 7 and Windows Server 2008 R2 are more closely related than Windows Server 2008 R2 and Windows Server 2008.
It seems as if the headaches of your profession stem more from the way people ask questions than the questions themselves…
Wow a strange GP post.
You wouldn't believe how many times the question boils down to "How do I join domain but ignore /beep/ GP because I own the machine and don't want to deal with the /beep/ setting set by the /beep/ domain admin."
Hope you have flame retardant.
<P>? <LI>? What is this talk?
Raymond, you will probably never understand this, but to a lot of people it's very important to understand why people act the way they do (and by extension why software is the way it is).
James: In Raymond's quoted question the "On Windows Server 2008" and "On Windows 7" have dots (are list entries or <LI>), but the "On Windows Server 2008 R2" does not (is a new paragraph <P>).
It's more like:
We did X, then Y, then Z, and then Q happened. This leads us to theory A. Is that right? Or maybe we're not, and W affects Q as well?
Which is a reasonable question IMO.
I remember I ranted loudly on the E7 blog about Run as different user missing and having to use SysInternals ShellRunAs and MS listened! So people ranting is good. I also ranted about invert selection disappearing, and a dozen other things. :D
The customer's question "Is that right?", which attracted your flippant "Um, if you say so; I wasn't there", was surely intended to mean "Is that to be expected?". I also suspect that the 'beating around the bush', which you seem to consider childish, is a cultural thing; it's exactly the way I would be likely to phrase it (I'm from the UK).
A literal answer (such as Yes or No) is possible but not helpful. I read "Is this right?" as "Was the feature added back because of customer complaints?" instead of "Is this expected?". The answer to the customer liaison could be "Yes, the feature was added back to Windows 7 because of customer complaints" or "No, the feature was added back to Windows 7 because we decided it should be there".
(MS doesn't have to say "I don't know; I wasn't there"; MS should know whether the behavior is expected.)
And then you can answer the CL's other question with "No, whether this appears does not depend on how you installed Windows Server 2008 R2".
Neither one of those answers gives what the customer really wanted to know, of course.
@Richard Russell
Whether the question is "is that right?" or "is that expected?", it's still a poor question. A good question is "I am trying to do X and I'm hitting problem Y, how can I do X?". If you are requesting tech-support via email, you are not starting a conversation. A conversation this way could take weeks and waste everyone's time. To get the best result, you need to be precise about what you are trying to achieve, what problems you are hitting, and any and all contextual information that you can provide (whether or not you think it will be relevant). "Beating around the bush" is not childish, it is ineffective. It wastes everyone's time forcing the support person to try and "guess" at the problem. If UK culture causes this issue, then it's something you need to address as an engineer, because it is simply un-workable in this medium.
I want to run Visual Studio as Raymond because then maybe I'd understand the code I was looking at.
No, wait, I bet he looks at gnarlier code than I normally do. Dang, never mind.
Please don't trust Raymond's conversations here, it's not the original text, it been changed for comic effect and to make the customer look stupid.
@Jonathan: > Which is a reasonable question IMO.
Right. And a customer is like a kid which looks at an empty bowl and asks: "I suppose we're out of candies today, aren't we?" It's not like they're afraid to ask for candies. They might just think it would be stupid to ask for candy when there are clearly none in the bowl.
@Raphael: 'Trusted path' here means 'use the secure desktop', that special place where only SYSTEM can create windows (and therefore shatter attacks are not possible). My assumption is that Windows 7 doesn't implement the general collection of credentials for a different user under the secure desktop. It can clearly do so for over-the-shoulder elevation requests from UAC, when a standard user runs a program marked requiresAdministrator, so this seems like an omission. CredUIPromptForWindowsCredentials supports the CREDUIWIN_SECURE_PROMPT flag to create the dialog on the secure desktop.
Windows 7 now allows you to use Fast User Switching when on a domain, so if your administrator has set the policy, just hit Ctrl+Alt+Del, select Switch User, then log in as the other user account. Of course that will load the profile, the user's desktop, etc.
Alternatively you could change your user account to be a standard user, rather than an administrator, and then the regular elevation prompt will do what you want. Or, it's possible to configure UAC to prompt for username and password even for administrators. Set the policy "User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode" to "Prompt for credentials". I admit I don't know whose token is then used to run the program, if you enter different credentials: the user whose desktop is shown, or the user whose credentials were entered!
The customer will almost always ask why something was changed. The rep needs to ask, because otherwise it becomes "Microsoft sucks" afterwards. Also the last three major companies/organizations I've worked at had a hide/disable nothing policy. Instead, you leave an option like this enabled, and display "I can't do that because of policy whatever.". Users do complain, but it measurably reduces support calls.
Displaying the option disabled and placing a tooltip saying why would be a similar approach. The idea is that if you tell the user why they can't do something, then they won't call asking.
I would see run as as a good candidate for that. Just always return true, and then when user picks it, tell them why it doesn't work. You don't hide an app because it's deny execute, and this is parallel to that.
Should make the shell faster, too. No more testing policy before displaying a verb.
This still raises the question of *why* runas is disabled when Trusted Path is enabled.
Also, what valid reasons are there to disable UAC?
@Raphiel: Also, what valid reasons are there to disable UAC?
Easy. UAC is incompatible with runas /netonly as elevation loses the explicitly loaded network credentials.
@Raphael
In our organization, admins and users are strictly separate. Users have restricted accounts, and admins log into an account with administrative rights whenever they need to install or update something (they have restricted accounts for testing purposes and internet browsing, too). UAC is simply not needed, and a hassle for the admins.
[I just flip the order. Elevate first, then runas /netonly. -Raymond]
I'm injecting network credentials at login for the entire session.
@Sean: A "hassle" perhaps, but also a useful safeguard. Are you doing administrator-like things 100% of the time that you are logged in? Probably not, and so UAC prevents the non-administrator tasks from doing administrative things without your authorization. Probably that's the entire reason why UAC was added in the first place.
@echo off
run-elevated.lnk runas /netonly /user:REDMONDMatEer cmd.exe
@Maurits: run
ECHO exit>runas.cmd
and/or
ECHO X5O!P%@AP[4PZX54(P^^^^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*>cmd.exe
before you call godmode.bat
@JamesJohnston
Because UAC is sometimes too helpful to elevate setup programs even when elevation is not needed. So instead of figuring out where the setup programs write to and writing RunAsInvoker/ADDREDIRECT myself, turning off UAC and letting Windows redirect registry locations is much easier.
And good luck writing compatibility shims for msi installers that are extracted with random name at runtime, AND dependent on being passed handle or some such values from the main stub.
@Stefan that's one of the reasons elevation changes the CWD to %systemroot%system32
You don't need to disable UAC to run setup programs AsInvoker. There's a separate policy to disable elevation of files named in a way suggestive of installers.
@Maurits: where's the contract that guarantees that "runas" and "cmd.exe" are not evaluated before elevation?
ECHO >run-elevated.lnk …EICAR… is still possible.
hahaha, I love how in the linked article, one of the first responses suggests hiding the item instead of disabling it. You can never win can you?