Could someone explain to me the "UAC" issue?

[Rat]

Please?

I was thinking that maybe the InstantSupport server could always install itself as a service and then uninstall itself once the user closes it.

Perhaps this will eliminate the "UAC" issue... I don't really know since I have never seen the problem and I don't have a Vista/Win7 machine handy to try it out with.

[B]

You've probably heard that UAC stops everything, dims the screen, and prompts the user. This is designed to stop rogue programs from changing critical settings without the user's permission, as well as to annoy users enough so that they will consider Linux and OSX as viable operating system alternatives. Apparently, unless VNC is running as a service, this disables remote VNC access until the local user acknowledges the UAC prompt, allowing the app to continue.

This is, of course, what UAC is designed to do, bug one about certain privilege escalations. It does seem kind of silly that simply running the SAME program as a service makes the problem disappear (without so much as a prompt?) but that's Windows I guess.

Anyway, I don't see why one couldn't make "service" mode the (switchable) default -- in fact that's just what I think SCPrompt does. The only consideration is that, naturally, one needs to be running with admin rights to install the service.

[supercoe]

Rat,

As B stated, the customer would require admin privileges in order to run InstantSupport the way you want.
I have many customers on Domain networks where they don't have admin privileges and this is why the default run of InstantSupport is in user mode.

I've already implemented the ability to disable UAC prompts without installing into 4.0

I prefer to simply modify the customers UAC settings instead of installing a service but the ability to install as a service will remain for permanent situations.

[bigdessert]

WOOHOO, Can't wait for 4.0. Please at least always keep things an option for service. In many cases we just need to jump in quick to see a message or something of the sort. Installing a service every time we would connect causes so much extra time.

[supercoe]

bigdessert,

Don't worry, installing as a service will always remain just an option.

[Rat]

... Funny just wrote my own Disable/Restore UAC Function... Can't test it though don't have a Vista/Win7 system available.

If anyone can be bothered then please let me know if you see any problems with it:

Code: Select all

Func DisableUAC($Disable)  ; Disable/Restore UAC prompt dialog setting
	$Result = 1

	$Key = "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System"
	$Value = "ConsentPromptBehaviorAdmin"
	$Type = "REG_DWORD"

	$RegData = RegRead($Key, $Value)
	If @Error Then Return False ; Key doesn't exist, (probably not Vista or Windows 7)

	If $Disable Then
		$Result = IniWrite($TempPath & '\chunkvnc.ini', 'UAC', 'Prompt', $RegData)        ; Store original UAC setting, (so that it can be restored later)
		If $Result = 1 And $RegData <> 0 Then $Result = RegWrite($Key, $Value, $Type, 0)  ; Disable the UAC prompt dialog, (if were able to store original UAC setting and it requires changing)
	Else
		$RestoreData = IniRead($TempPath & '\chunkvnc.ini', 'UAC', 'Prompt', '')
		If $RestoreData = '' Then Return False  ; Ini value doesn't exist and therefore has never been previously disabled
		If $RestoreData <> $RegData Then $Result = RegWrite($Key, $Value, $Type, $RestoreData)  ; Restore the UAC prompt dialog setting, (if it requires changing)
	EndIf

	If $Result = 0 Then Return False  ; Error: failed to do task
	Return True
EndFunc     ;==>DisableUAC

[gilrim]

HKLM isn't writable for users that haven't been granted local admin, no?

[Rat]

Yeah I wondered about that too...

Supercoe says that ChunkVNC should run as a normal user because many of his clients inside corporate domains etc. But he also says that he has added UAC disabling to version 4. I'm keen for version 4 to arrive so I can see what approach he has used.

I also wondered that once you have agreed to run the app initially whether or not that implies you have admin access?

Maybe someone else can shed some light on this issue here.

[supercoe]

Rat,

1) Have the script run itself again privileged.
2) Reg change ConsentPromptBehaviorAdmin=0
3) Run vnc server again privileged.

It's more complicated than this as I backup and restore the users original UAC setting among other things but you get the drift.

[Rat]

1) Have the script run itself again privileged.

hmmm... I think I will need some code example for this. Do you mean to use "#RequireAdmin" or "RunAs" or somthing like that?

3) Run vnc server again privileged.

... as above?

[supercoe]

Rat,

#RequireAdmin is a compiler directive, if this is used the executable would always need admin privileges.

Currently I'm using RunAs in this way but I've yet to do much XP testing.

Code: Select all

ShellExecute(@ScriptFullPath, "-disableuac", @ScriptDir, "runas")

Once the script is elevated it can spawn elevated processes (vnc server) but since the server was first run as user the vnc server must be closed and run again as an elevated process.

[Rat]

A friend of mine tested my "DisableUAC()" code on a Windows 7 machine and a Vista machine both as a user and admin. It appears to work ok. The script also included the original Firewall message dialog killer code, (see below)...

Code: Select all

DisableUAC(True)  ; Disable the UAC prompt dialog

; Background Loop
While True
	; Close any windows firewall messages that popup. The windows firewall doesn't block outgoing connections anyways.
	if WinExists('Windows Security Alert') then WinClose('Windows Security Alert')

[supercoe]

Rat,

What do you mean your friend tested as user and admin?

Admin, your code should work just fine.
User, doesn't have access to HKLM...

[ltctech]

UAC is a royal pita when it comes to providing remote support.

For now I just added the #RequireAdmin directive to my script.

Not only is the user prompted with a UAC screen when they open a secured dialog, but since the server is not elevated it cannot control the dialog in question.

The directive fixes the issue but at a cost, not every user has admin privileges. I think the correct solution is to elevate with runas as pointed out earlier, but there should be two buttons on the GUI one to run as admin, the other as user. This way you have the best of both worlds...

[supercoe]

Itctech,

Currently you must use the Install Service option to get around UAC.
I've added the ability to elevate without installing as service for the next release.

[Rat]

What do you mean your friend tested as user and admin?

Admin, your code should work just fine.
User, doesn't have access to HKLM...

Yeah exactly, I think it still works under Vista and Windows 7 because of Registry Virtualisation. I would love someone to provide a defintive answer to this or to do some more testing of my "DisableUAC()" function, (posted earlier in this thread).

[supercoe]

Rat,

Now I understand your idea but it won't work without being admin.
Registry virtualization will not override ConsentPromptBehaviorAdmin to disable UAC. You must elevate first then change the HKLM key.

[Rat]

Yep I'm pretty sure you're right too... Registry Virtualization should only apply to keys like "HKLM/Software" etc.

I will harass my friend who did the testing for some more information... can't at the moment though since he's currently in Norway (designing micro-helicopter drones for the military:)

So how are you "elevating" users permissions? Are you asking them to manually provide admin authentication?

[supercoe]

I have the script run itself as admin.