TRC Perform Action on Target

(imported topic written by GwyndafDavies)

Hi,

I’ve been having problems with getting the right access when logging onto the target. I have a target which is a locked down user in a e.g ‘locked down user’ domian. This user does not have access to view task manager or view installed software in the control panel etc.

However, I’m remoting into the target using a local Admin account. When I log in locally on the target I get all the admin rights, however when I remote in via TRC and then attempt to open task manager I get access denied (prompted for authentication). When I open the control panel I see the same as the locked down user. Is this a limitation? I’m launching the task manger or control panel from the ‘perform action in target’.

The target in question is Windows 8.

Regards,

Gwyn - UK IEM Consultant

(imported comment written by 978-0201616224)

Hi Gwyn,

When you enter the admin user id and password when you take over the target, that authentication step is only used to grant you access to the remote control function. It does not change who is currently logged on to the desktop.

TRC is to be compared with Microsoft Remote Assistance and not Microsoft Remote Desktop. With Microsoft Remote Desktop, you actually log in to a different desktop.

If you need to run administrator tasks while using remote control, you can use fast user switching. This puts the user’s desktop in the background and allows you to log in to a new desktop with your admin credentials. If fast user switching is disabled in Windows, you’ll have to log out from the user’s desktop and log in with the administrator account.

HTH,

Chris

(imported comment written by 978-0201616224)

Hi Gwyn,

There’s some additional things to consider when you’re doing administrator tasks in a remote session. Since your users are locked down, you need to make sure that they can take back control of the machine while it’s logged in with the admin account. There are two ways in which a user can do this, and TRC has policies to address these situations.

The local user has priority when using the mouse or keyboard. This means he can take back control after you’ve logged in as Administrator. To prevent this, enable the AllowInputLock policy in the target’s registry setting. Then, before logging in, from the controller’s action menu, select ‘Enable input lock’. This blocks input from the local mouse and keyboard so the user can see what you’re doing, but he can not interrupt you.

The local user can also end the session at any time by pressing the Pause key (aka the Panic key), even when the input lock is enabled. You can set the SessionDisconnect policy in the registry to LOCK. This causes the desktop to be locked when the session is ended, preventing the user from accessing the admin desktop. The alternative is to disable the panic key function by setting the DisablePanicKey policy to yes. However, this alternative has the downside that the user has no way to end the session.

With kind regards,

Chris

(imported comment written by GwyndafDavies)

Hi Chris,

After looking into the underlying technology I understand where your coming from. I’ve tested your suggestions and everything works fine as fast user switching isn’t disabled in the environment.

The only problem is that on the hardware doesn’t have a pause key (New Thinkpad T440’s etc). Also - This is a general concept across a lot of manufacturers at the moment where there is no Pause key. You have to use FN + P. Unfortunately as the keyboard is locked I can’t use the panic button. Is there a configuration to change the panic key?

Kind Regards,

Gwyn