Mouse and Keyboard Stop Working

[jdelgado89]

Hi,

After performing a windows update the mouse and keyboard stop working. I can connect but no mouse or keyboard. I am running Windows 7 64 bit.

I have uninstalled and reinstalled but the issue continue any ideas.

Thanks

Thanks
Julio

[Rudi De Vos]

1) check if full and readonly password differ
2) check if option disable keyboard is not ON
3) If UAC started applications are open and winvnc is NOT running as service, mouse clicks and keyboard input is blocked by UAC, you still can move the mouse.

[redge]

right click on winvnc and select install service and then start service

[topic=16839][/topic]

[riow]

Really HARD to make the mouse and keyboard worked on remote winvnc (win7 x64). Will try again...

[jdelgado89]

Thanks Rudi, passwords where the same and the disable keyboard was on. Don't know how it was check but any how I got it working last night. So this morning I power up the pc with the ultravnc server I try to connect and I could not connect I have to reset password and i notice that the disable keyboard was check again. Very strange. viewer is 1.0.8.2 I am going to update it today.

thanks

[Rudi De Vos]

Make sure that ,when you get the runas popup to save your settings,
the user has access to modify the ultravnc.ini file, else value's
are temp saved in memory.
On reboot, you are back to the old....

The service can't emulate a domain admin ( premission denied),
no emulation no access to ultravnc.ini.

Workaround:
-run winvnc as application to save settings
-run uvnc_settings.exe tool to make changes ( take effect after restart uvnc)

[B]

Huh, that might explain some things for me.

But I don't understand why the service can't emulate a domain admin when a domain admin installed the service and is willing to provide domain admin credentials?

And even so, we're only talking about access to a local machine file, so any local admin rights should be sufficient; I think I'm lost.

[Rudi De Vos]

The problem is
-A service has always access to any file.
-We don't want that guest can change the settings.

Solution
Make the service impersonate the current user.

But the local user "system" can't impersonate " a domain user". If this was
possible, everybody that could install a service would also be able to become any domain user, inclusing domain admin.
The impersonation function fail with permission denied.

If winvnc is started as application, we don't need to impersonate the current user, we just use the credentials from the user that started
winvnc. No problems.

I hope this make sense....

[B]

Yes, it does make a lot of sense; thank you Rudi.

Though if the domain user's credentials are made available to the service explicitly (in some fashion) I would think it should still be workable.

Another thing, about the "problem" -- why prevent the "guest" from changing VNC settings when that "guest" is being granted, via VNC control of the desktop, full control of the machine in every other way? Hmm, I guess it's because you're allowing for conditions in which remote users control the desktop who do NOT necessarily have "local admin" rights to the whole machine. I guess I'm just used to knowing that the VNC service already has full machine control -- when I do file transfers I can get to whatever I want just by VNC authentication alone.

I've never run uvnc_settings.exe -- is that the same thing as modifying the services's ultravnc.ini file manually (e.g. in Notepad)? (I understand that either way we have to restart uvnc or the machine.)

[Rudi De Vos]

FT:
[x]User Impersonation
-FT happen as desktop user, is this is a guest, you only
can overwrite, wtite/read with guest permissions.
-You have acces to mapped folders
[_]User Impersonation
-FT happen as "system"
-You don't have acces to mapped folders

uvnc_settings is just a ultravnc.ini editor.
Via the standard file security you can give/deny access to groups/users
to modify ultravnc.ini.

Remote users.
The viewer doesn't use the credentials of the viewer PC.
( Would be impossible if this is a unix client)

[B]

Well I guess UltraVNC's file transfer permissions are a lot more fine-grained than the TightVNC file transfer I usually use!

Oh I never meant that you were checking the remote viewer's credential on his REMOTE machine -- of course that would be useless. I should have written that (I am guessing) you are preventing guests from access to the service because someone might want to remotely control a desktop of a limited user.

Anyway thanks for the explanations.