Vista - demo RunAs for HTAs (and other filetypes) on Win7/Vista - feedback requested

Here's a demo script intended to simplify running HTAs elevated - and with
one change, the value of the ext variable, it can be applied to any other
type of pseudo-document on Windows. I'd appreciated feedback from anyone who
tries it out. Here are some comments about how the script works; the script
itself is at bottom:

(1) No elevation needed to run the script: per-user setting
It's annoying (and misses the point) to force someone to figure out how to
elevate files in order to run a script that makes it unnecessary to elevate
files. This is particularly true for HTAs, which are graphical in nature.
This script makes its changes in HKCU to avoid the entire problem.

(2) Adds runas for XP+
After running the script, if you right-click an HTA file there will be a
RunAs choice on the context menu. Although elevation becomes important with
Vista, the runas works on XP as well; if you choose RunAs, you'll be
prompted for a set of alternate credentials for running the file (not
necessarily administrator). On Vista+, there will be a UAC shield shown on
the context menu next to this choice as well.

(3) Win7: HTAs with "admin" in their names _automatically_ ask for
elevation.
The DefaultAppliesTo value set at the end of the script is a new addition in
Windows 7 (and I believe in 2008R2 as well). There's a small amount of
documentation in the MSDN "Creating Context Menu Handlers" topic:
http://msdn.microsoft.com/en-us/libr...71(VS.85).aspx
By giving DefaultAppliesTo the literal value
System.ItemName:"admin"
we tell Windows that any HTA containing admin in its name as a distinct
token should treat RunAs as its default verb. So on Win7, if you have a file
named "Admin AccountUI.hta" and double-click it, it will automatically
prompt for elevation when launched. If you right-click the file, you'll see
the "Run as Administrator" choice is bolded as the default. You can still
choose to do a normal Open operation from the context menu.
Note that the word "admin" MUST be a distinct token in the name.
Adminfile.hta won't work; variations that use spaces, underscores, periods,
or any other non-alphanumeric character legal in a filename will work to set
the "admin" word off.

(4) Roaming profiles on mixed 32-bit/64-bit networks - DO NOT use this!
Because it will fail in "interesting" if essentially harmless ways as you
work on different machines. I suggest changing the HKCU part of
UsrFiletypeBase to HKLM and running the script from an elevated command
prompt on a machine where you'll be working. You'll lose (1), but it will
work as expected.


'AddUserRunasForHta.vbs
Option Explicit
Dim WshShell
Set WshShell = CreateObject("WScript.Shell")
Dim ext: ext = ".hta"

' Find the filetype for an hta. We already know
' this is "htafile", but doing it this way with
' ext defined above makes it easy to change the
' script to work for any file type by just editing
' ext's value.
Dim filetype
filetype = WshShell.RegRead("HKCR\" & ext & "\")
Dim cmd
cmd = WshShell.RegRead("HKCR\" & filetype & "\shell\open\command\")
Dim UsrFiletypeBase
UsrFiletypeBase = "HKCU\Software\Classes\" & filetype & "\shell\"

' Add a RunAs "verb" for <filetype> files
WshShell.RegWrite UsrFiletypeBase & "runas\command\", cmd

' Makes runas prompt for elevation: works on XP and newer
WshShell.RegWrite UsrFiletypeBase & "runas\HasLUAShield", ""

' On Win7 and newer only: makes files of type <filetype>
' AUTOMATICALLY ask for elevation if they contain "admin"
' as a distinct alphanumeric string. Names that work:
' User Account - Admin.hta, admin_something.hta, x.admin.hta
' don't work:
' admintool.hta, admin32ui.hta
WshShell.RegWrite UsrFiletypeBase & "runas\DefaultAppliesTo", _
"System.ItemName:""admin"""

"Alex K. Angelopoulos" <alex(dot) k(dot again)angelopoulos(at)gmail.com> wrote:

Your address is wrong!
Have you tried it with .BAT and .CMD?
The "RunAs" verb fails for these two because their command string does not
include an executable. You have to add the prefix "%COMSPEC% /C " there.
I've been adding "RunAs" for .BAT, .CMD, .HTA, .JS, .JSE, .VBE, .VBS, .WSF,
..WSH, .REG, .INF, .MSC, .MSI and .MSP to [HKLM\Software\Classes\...\Shell]
since Windows 2000. Yes, it works very well.-) But: beware of KB830568!

I also add a "RunAs" to "Directory\Shell" and "Drive\Shell":

[HKCR\Directory\Shell\RunAs]
@="Start command prompt as..."
[HKCR\Directory\Shell\RunAs\Command]
@="%ComSpec% /K PushD %L"

and the following to .DLL, .OCX and .AX:

[HKCR\<filetype>\Shell\RunAs]
@="Register ... as..."
"Extended"="" ; don't confuse your Lusers;-)
; show the extra context menue entries only with [Shift] pressed
[HKCR\<filetype>\Shell\RunAs\Command]
@="%SystemRoot%\\System32\\RegSvr32.Exe %L"

Also handy is:

[HKCR\CLSID\{20D04FE0-3AEA-1069-A2D8-08002B30309D}\Shell\RunAs]
@="Manage as..."
"SuppressionPolicy"=dword:4000003c
[HKCR\CLSID\{20D04FE0-3AEA-1069-A2D8-08002B30309D}\Shell\RunAs\Command]
@="%SystemRoot%\\System32\\MMC.Exe /S %SystemRoot%\\System32\\CompMgmt.Msc"

[...]
"RunAs" came with Windows 2000.
XP does not support the "HasLUAShield" entry, this is for Vista+.
In case you put the entries under HKLM consider to add an empty value
"Extended" too.

Stefan

On Aug 7, 3:12*am, "Alex K. Angelopoulos" <alex(dot) k(dot again)
angelopoulos(at)gmail.com> wrote:Do you read minds?? I was just wishing for this. Thanks

"OldDog" <mikef2691@xxxxxx> wrote in message
news:3932e71b-9432-4246-83cc-710e66a373a3@xxxxxxYes, way cool.

What I have done is somewhat different. I have a batch script that prompts
for an alternate username. It then uses runas to run another instance of
itself. That other instance then runs IE to display a shared folder on our
server. That folder contains shortcuts to applications I want to run under
the alternate credentials given. These can then be run without having to
supply the password each time.

/Al

Thanks; there were some handy things here. Inline. : )

"Stefan Kanthak" <postmaster@[127.0.0.1]> wrote in message
news:#9hpWK4FKHA.3800@xxxxxxthe email address? No, it's right - put in the periods and @ ...
Ironically, those are the two I haven't bothered with, since out-of-box on
Vista/Win7 they _do_ have "Run as" choices on the context menu! I checked
back on them after reading your post and found that they actually use a
different key called "runasuser" that has a different configuration,
including some GUID-based links.


They configured mmc.exe, the Windows Installer, and regedit to _always_
request elevation when starting in Vista+ (and so do any executables with
"setup" "install" "update" or similar words in their names), which
fortunately slims down the field of items that need attention. (It also
produces a weird "can't-get-there-here" problem. A normal user launching
regedit or clicking a registry merge file can cancel credentials and open
regedit with full personal key control, but none over HKLM; a protected
administrator cannot: cancelling credentials makes regedit not run).

I wasn't aware of KB830568 before. I need to test it on Win7/Vista and see
if it affects the built-in elevation choices - that could cause a weird
lockout.

That's interesting. Network Neighborhood?
I left that in under the theory that it would make things work automatically
after an in-place upgrade to a newer operating system. Probably better if I
implement logic to chop it (and the DefaultAppliesTo) out on operating
systems that don't support it; no point in adding cruft that doesn't do
anything.
What's the purpose of the Extended value? I've only dabbled in context menu
enhancements before this.

"Al Dunbar" <alandrub@xxxxxx> wrote in message
news:OPqgWh6FKHA.4968@xxxxxx

[snip]
Could you post the details of how you do this? That's a nifty way to jump
around a lot of problems without needing anything more than a single known
file as a starting point.

"Alex K. Angelopoulos" <alex(dot) k(dot again)angelopoulos(at)gmail.com>
wrote in message news:u5Lnaj7FKHA.5780@xxxxxxI'll try to provide a demo copy of the script in the next day or so. There
are a few issues with this approach though...

The main one is that all IE windows share a common IE instance running,
apparently, under the credentials fo the account that initiated the first
window. If I have my alternate credential window open and then try to open
an IE window from the non-alternate account, it executes under the alternate
credentials. Because our privileged accounts are not allowed access to the
internet, I typically have to then close the alternate credential IE
window - and also respond to an email asking why I was using a privileged
account to browse...

A similar issue exists with MS office components. If, for example, I run a
script under the alternate credentials that opens word or excel, an error is
raised, as I typically already have MS Outlook open under the non-privileged
account.

/Al

"Al Dunbar" <alandrub@xxxxxx> wrote in message
news:uYMNNy#FKHA.1488@xxxxxx
And I assume "oops!" isn't usually a good answer.
What seems to be the problem there? Scripts that try to use GetObject to use
the application as a server?

"Alex K. Angelopoulos" <alex(dot) k(dot again)angelopoulos(at)gmail.com> wrote:
No, it is even syntactically WRONG: no NUA can send a reply to that
address! Remember: the display name is for humans, the address for the
machines, and the latter is not displayed by current NUA/MUAs.
I've glanced over that in Windows 7, but did not yet check MSDN about it.
Yes, there are some weird or at least hard to explain results with UAC.

BTW: turn on SAFER on XP and set the default level to "Deny", but exempt
administrators; the default rules allow execution in %SystemRoot% and
%ProgramFiles% and below. Now try to run any executable outside of these
directories via "RunAs". That's NOT funny.-(
;-)

No, it's "My Computer", which already has a "Manage" context menu.
I put it's purpose into the comment: when an entry "Extended" exists the
context menu will only show while [Shift] is pressed. Use it to avoid
confusion for your lusers;-)

Stefan

"Alex K. Angelopoulos" <alex(dot) k(dot again)angelopoulos(at)gmail.com>
wrote in message news:eYskCABGKHA.1336@xxxxxxI have a number of administrative scripts that write their output into a
file and then display the file's content.txt file using Word or Excel.