The shifting sands of "Run as different user"
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 2008 R2 (the server counterpart to Windows 7), shift-right-click does offer the option Run as different user.
The option to run a program as another user (other than Administrator) was present in Windows XP, but it was lost in Windows Vista. It appears that we responded to those complaints by restoring the functionality in Windows 7.
Is that right?
The odd thing is that my customer has the Run as different user option available on their Windows 7 machines, but not on their Windows Server 2008 R2 machines. Does whether you have access to Run as different user depend on how you installed Windows Server 2008 R2? (If it matters, my customer installed it via the Microsoft Deployment Toolkit.)
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:
We did X, then Y, then Z, and then Q happened. Is that right?
“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?”
My psychic powers tell me that they have set the Require trusted path for credential entry policy. The Run as different user feature is disabled if you set this policy.
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.
The culprit was indeed the Require trusted path for credential entry policy. It didn’t show up in a GPO search because they were setting the policy via a script rather than deploying a group policy object.
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.
Light
Dark
0 comments