On-Demand Assist – No admin rights!
Within our enterprise, as a security measure we set the policy of “User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode” to “Prompt for credentials”. This forces a UAC prompt whenever a process needs admin rights.
After connecting to an On-Demand Assist session, there are 2 problems preventing us from functioning. FIRST problem is if you click on the session and do something like open “Services” and attempt to stop a service, you get a UAC prompt on your console computer. You can enter the local .\administrator & password, but it will NOT accept it. For this to work, you must “elevate” your session to an administrative session, but that forces a UAC prompt to appear on the “remote client” computer, which our users do not have admin rights, preventing this from working. If we select to elevate the session to an administrative session, the UAC prompt should only appear on my console computer and I can enter local admin credentials which in turn are passed to the remote client computer, WITHOUT forcing a UAC prompt on their computer. The SECOND problem with On-Demand Assist is similar. If you take Remote Control of the client computer, if you perform an administrative action like try to install software, when a UAC prompt appears on the client computer, I “lose” keyboard/mouse functionality and I cannot enter admin credentials and our users are not admins and we cannot give them our admin passwords, so again, we are stuck and On-Demand Assist really is of very limited use to us. We have no problems with any of this if we are ‘inside’ our network, which uses the normal Goverlan agent and not the remoteclient agent. But when a client it outside and we have to use On-Demand Assist, we can’t elevate the session to an admin session, nor can we type in a UAC prompt on the client computer during remote control. We would request that elevating the session and keyboard/mouse issue be addressed so it works for us.
